You might be familiar with this opening sentence if you've worked with LLMs to do something. Nowadays, the usage of this phrase has started to appear in every follow-up message, now it feels like a passive aggressive person trying to map out rage bait. But since it's a next token prediction scenario, there's no point in creating a strawman.

Ever since I started working with LLMs to explore areas that were too much for me earlier, it's been a roller coaster journey. Everything starts off as easy and doable, but as the project grows and the context goes over the limit, you can't rely on any agent completely, you need to understand how each file is related and where the logic lives.

The point I expect everything will eventually reach is where I can just forget about the code and files. But to spin up an instance of any project, you still need an understanding of what works, what doesn't, and what will break with edge cases. It's not like a simple README anymore.

So, what exactly is right?

For any incorrect or problematic response, if we suggest workarounds or potential rethinking, it replies with “you are absolutely right,” which creates more confusion because I still don't know if it's the correct way. So either cross check with other LLMs or start understanding how the code and framework work.

If you are a vibe coder like me, my suggestion is to only give awareness of the context, not the entire thing or what another agent suggested. In scenarios like this, we shouldn't provide solutions or even potential suggestions. Only ballpark level thoughts. Just enough to search the web and find a solution. So we can confidently pick a solution that matches our unique need. This is the approach I follow now.

I went the other way - the blindfolded way - and the result was that things became too complex. Even though I use Git, I had to abandon a few projects because of the stress caused when trying to go back to a point where everything needed to be redone.

I noticed that if a chat drifts out of logical flow, the entire chat becomes unusable. Then we have to edit messages or start fresh. If I keep that in the message it often recall something from it. Editing helps but is not perfect. Another solution is the “project” feature that major platforms now offer. But for a moderately big web app, projects are only halfway helpful because files constantly change, and they must always be kept updated. Otherwise, a small context miss is enough to cause ineffective suggestions that break things later.

Using Git

It was difficult to understand Git at first, so I created my own workarounds. But since I moved from simple HTML, JS and CSS projects to frameworks like Next and Astro, Git became essential. Git is basically a bunch of commands, and deciding what to use when was confusing. Understanding it from a UI perspective made it easier. Some things only reveal their true potential when we genuinely need them and are ready to understand them.

My current workflow is committing everything between potential changes and never relying on the gut feeling of “let's commit after this change.” When working with agents, the way they modify files is risky. If I had a nickel for every time an agent “fixed bugs” in my projects - bugs that were actually features - it would stack up. When I say something doesn't work, it tries to rewrite the file and removes features I added with effort and time. If we're not careful, we lose these, and by the time we notice what's missing, the project has already moved far ahead.

So commit everything after each change, and then run through a checklist of each feature and functionality. It’s a non negotiable rule.

Modular method

If a project starts growing, split files and make it modular. You can reuse modules in other projects and fix simple things without burning tokens. But when modularizing, you need a basic understanding of how the structure works - not the code itself, but the project organization.

Often I face issues where agents and chats get stuck in a certain path. So I switch platforms. When Gemini fails, Deep Seek helps and when Deep Seek gets busy, Claude fixes it in a few messages. When Claude hits limits, Kimi K2 or any other. Never depend on only one model or one platform.

Skeleton building

This is the method I use when brainstorming. I spend time writing a clear initial prompt. This matters. Usually it gives a basic output, and after testing that, I slowly add features one by one. I never touch styling at this stage. Everything stays in my mind. The goal is to create a working skeleton first and then make it usable.

Ever noticed why most vibe coded apps look the same? All those gradients from Claude and default styling. I always add one special instruction at the end of prompt, use only minimal, necessary styling so it can later be changed to match my own vision without wasting tokens.

LLMs now let developers design more easily and give designers the ability to build simple working skeletons. The boundaries are blurring.

The conclusion is that

  • You should be the one who understands everything and in full control.
  • You should not handover the string to any agent.
  • Do not automate until you can do it manually without any issues.

Understanding how everything works is essential, even if you don’t know code deeply. When something breaks, you should at least know which component, utility, or library might be responsible. This means keeping a good commit history and maintaining notes.

If you're working with databases, use DBeaver and you’ll be able to understand and work through SQL queries and databases more easily.

I used to fear and dislike the terminal exploration. Now I think the terminal is my most used interface. Everything you need is available without a UI, and once you settle into a workflow, the urge to explore grows naturally.