The right way to use it
I think the key to using an LLM is getting yourself out of the fixed mindset of just writing code. You act as the manager who plans the work, or the micro-managing supervisor who inspects it, instead of turning yourself into an outsider. All of this rests on understanding the project and the design, the architecture, the tech. I can get away with not knowing how the “actual code” is implemented, but I have to pay attention to what went in and what came out, and after that to security and performance. As a tech lead I obviously need to understand the tech I’m asking my staff to use, at least well enough.
Small modules, precise prompts (pointing clearly at a specific function or module and the logic it operates on, which itself takes a human who understands the project), architecture design. These avoid the missing context and the maintenance hell that come from handing everything to the AI. Especially thinking about it with a vibe engineering mindset, tests and caution are indispensable too.
Today’s debugging was interesting. Throwing the problem at the AI wholesale didn’t solve it. In the end I hunted around for ages myself, set breakpoints, tracked down where the problem came from, and gave it an explicit instruction to fix that. And at first it actually handed me a very complicated refactor plan, when wrapping a str output at the exit was all it took. It told me three modules had to be refactored before the problem would go away. That’s clearly a problem.
There’s one point I do agree with. Using AI gives you a false sense of mastery, and the moment you hit something the AI can’t solve you’re helpless, even anxious and angry. It gets very bad when I can barely read the code the AI wrote. So understanding the business logic and the project matters enormously, and the most careful way to apply AI, I think, is to spell out “how it should be done, and with what method”, down to the class if possible. It isn’t as fast as handing the whole thing to the AI, but it still gets you twenty or thirty percent more efficiency. Especially thinking about the maintenance hell you may run into later, a structure a human designed rests on knowing the project well, so when something breaks you at least have a clue. The AI sometimes wraps up its errors a bit too perfectly, and then you have no idea where to look when something goes wrong, which is why tests and maintainable design matter so much.
Bash is very flexible, and you can use it to call command-line tools you already have.
Translation note. I wrote this in Chinese. This English version is an LLM translation, so the wording is not mine even though the thinking is. Original: 正确的使用方法.