|
This is why I don't use agent-first platforms like Claude Code. I want to write software with an AI to assist me, not an AI to write my software for me. I don't want an environment whose main mode of operation is instructing an AI to write code - I want a typical IDE where I can continue writing code myself but with an assistant there to consult whenever I want it. Even then, it's easy to fall into a trap of giving the AI a simple description and letting it fill in the blanks, but I've learned the discipline not to do that, in the same way I learned to think before I speak and design before I write code. Planning mode is my entry point for almost all code I would have the AI write. I already have in mind what I think I want. I get it to create a detailed plan, which inevitably fills in things I didn't specify and even ask questions I hadn't considered. I iterate on this first revision spec until I think it's ready. This results in a task list. But just like waterfall doesn't mean make a plan and execute it all without looking back, executing this plan is also a stepwise iterative process. I let the AI execute the first step. I check its work. I run some tests and see if it behaves like I thought it would - the same stuff I would do during normal development. If I find issues, I go back to the plan and change it, then continue implementing the revised plan. If the previous step lead me into a dead end, I revert that one step and try again with my revised plan. The key thing is this: this was my development methodology before AI entered the picture. Nothing has fundamentally changed. What has changed is that the AI provides input at one or more stages of the flow - offering alternatives, asking questions, running tests, researching and debugging - but in every single step the AI does not decide on the final outcome. Even if the AI wrote all of the code, I still review it and test it. Even if it suggested a design, I compare the options and review the referenced documents and decided for myself. Even if it reviews my code and says it would do a hundred things differently, I decide what suggestions I will act on and how. It's no different than I would do with having a coworker giving me ideas, reviewing my work, or making their own attempt at generating a solution. It's all helpful input and if I'm happy with it I will use it as is, but I'm still responsible for every line of code and I still make all of the decisions about what stays and what goes. I'm sure this sounds wasteful - why use an AI if you have to review it and correct it anyway? For the same reason I delegate tickets to a team of 20 junior developers and don't do them all myself as a principal engineer - I am but one person and they are an army. Even if I have to discuss plans and options with them and review their work, they can spend the same hours I would brainstorming and researching and prototyping and debugging, and I can go over the results with them to make key decisions and make sure we are on the right track. I make the important decisions, but the leg work of getting everything in place is done by someone else who doesn't need as much knowledge or insight or experience. It is a force multiplier. It is the equivalent of a lawyer with a team of paralegals or a professor with a team of researchers and grad students. I can let the AI do the things it does well so that I don't have to, and instead I can spend my time on the things I do well that it can't do. This is where I think we are going wrong with AI in many areas, but particularly in software development. An AI is not a replacement for an engineer - it's an engineer's assistant. It isn't a source of truth - it's a source of ideas. It's not responsible for the outcome - I am. A team of helpers can make an expert more productive, but that team isn't a substitute for the expert. Likewise, juniors still need to gain the same experiences and learn the same practices and make the same mistakes, because they still need to become experts, but they can use the AI as a guide along that journey rather than having to rely solely on another expert for mentorship. |