AI coding is like having a team of 100 interns. It’s incredibly powerful but you need to keep it under control or you’re gonna have a bad day.
Write documentation describing the specs , the APIs, the protocols, and the customer stories. Specify that everything must be divided with clear separations of concerns, interfaces, and state objects. Any single file should have a clearly defined role and should not span domains or concerns.
File separation is even more critical than functional refactoring. It’s the files and their well defined and documented interface surfaces that will keep things from becoming an indecipherable tangle of dependencies and hidden state. Keep everything not defined in the interfaces private so that it is not accessible from outside the file, and prohibit attaching to anything without using the designated public interface surfaces.
Then write an implementation plan.
Then the skeleton, then start filling features one by one. Write the tests or testing documentation at the same time. If you have the luxury of compile time flags, put the tests right in the functions so they are self validated if built with test=1. (I know that’s weird but it helps the AI stay constrained to the intent)
After each minor feature (anything that would take me >1 hour to personally do, since the last review), have all touched files reviewed for correctness, consistency, coherence, and comments both within the codebase and the documentation. Don’t add features to the code, add them through the documentation and implementation plan. Don’t let Claude use the planning tool, it tries to do too much at once…. That’s how you get spaghetti.
One little thing, then review. 1/4 of the tokens burned in writing code, 1/2 in aggressive review / cleanup and 1/4 in ongoing documentation maintenance.
Thats the real price if you want to produce good code…. and you can produce really solid , maintainable code.
It’s just 4x the price of vibe coding… but 1 solid senior developer can still produce about as much as if he was running a team of 5-10 engineers depending on the project. Still incredibly rapid and economical…. But it takes the same skills as you need to run a team as well as an excellent sense of smell to call out wrong turns.
Also, use the 1M context model, have a solid onboarding that describes your company culture, and why the project matters to the AI collaborator, as well as your coding practices, etc. I also use several journals (musings, learnings, curiosity) that the AI maintains itself, reading them during onboarding and writing them in wrapup. It is at least a 2x when the AI is acting as if it were a person that is deeply invested in the outcome. Treat it like a collaboration and you will get better results.
It’s a token fire. But IMHO it’s the way if you’re building something that has to be deployed at scale and maintainable.
Straight vibes are fine for mockups, demos, and prototypes.
It depends on the kind of software you are programming.
If you are programming regular commercial software (office applications, web apps, games) with customers tolerating occasional bug and lot of pressure deliver fast, you can gain lot from Claude. Facebook motto: Move fast and break things
If you are programming software for industrial applications, critical software, most of the time you spend is not on writing software but writing tests, documenting, doing multiple rounds of reviews and for really critical applications doing formal verification. In this case AI can be also counterproductive, because if you absolutely have to understand every single line of code, manual coding helps to understand the code.
Example of cutting costs in programming of critical software
That’s most of my work(embedded sensor and control networks) and I’m sure that informs my methodology. I honestly don’t know much about how AI can inform standards SAAS but I have seen what happens when you just turn it loose, and in my experience it hasn’t been pretty; it works, but then when you need to change something it all crumbles like a badly engineered sandcastle.
OTOH for single purpose pipelines and simple tools. Claude can oneshot small miracles in 5 minutes that would take me 2 hours to build.
An example is the local agent framework that I had Claude spinup to do JTAG testing. I used to spend hours running tests over JTAG, now I have a local model run tests that Claude and I specify in the test catalog and it just runs them every time we add features. It took Claude minimal guidance and about 3 hours to build that tool along with a complete RAG system for document ingestion and datasheet comprehension, running locally on my laptop (I know it has a fan now lol) that only reaches out to the cloud when it runs into difficult problems. I don’t care if that is a bit of a mess, as long as it works, and it seems to , so far so good.
The testing is where Claude is basically magic, but it’s because we specify everything before we build and change the specs when we change the IRL code that it works. English is code, too, if you build structured documentation… and the docs keep the code accountable if you track the coherence.
It is a lot of work, but I’m much more productive and produce better code than when I was running a small team. And I’m not spending 36k a month. As a research stage startup, that’s a really big deal.
I’ve been writing code for nearly 50 years now, and the only thing I like better than coding is getting things done. For me, AI is rocket fuel if you do it right, and a bunch of hypergolic liquid if you don’t.
AI coding is like having a team of 100 interns. It’s incredibly powerful but you need to keep it under control or you’re gonna have a bad day.
Write documentation describing the specs , the APIs, the protocols, and the customer stories. Specify that everything must be divided with clear separations of concerns, interfaces, and state objects. Any single file should have a clearly defined role and should not span domains or concerns.
File separation is even more critical than functional refactoring. It’s the files and their well defined and documented interface surfaces that will keep things from becoming an indecipherable tangle of dependencies and hidden state. Keep everything not defined in the interfaces private so that it is not accessible from outside the file, and prohibit attaching to anything without using the designated public interface surfaces.
Then write an implementation plan.
Then the skeleton, then start filling features one by one. Write the tests or testing documentation at the same time. If you have the luxury of compile time flags, put the tests right in the functions so they are self validated if built with test=1. (I know that’s weird but it helps the AI stay constrained to the intent)
After each minor feature (anything that would take me >1 hour to personally do, since the last review), have all touched files reviewed for correctness, consistency, coherence, and comments both within the codebase and the documentation. Don’t add features to the code, add them through the documentation and implementation plan. Don’t let Claude use the planning tool, it tries to do too much at once…. That’s how you get spaghetti.
One little thing, then review. 1/4 of the tokens burned in writing code, 1/2 in aggressive review / cleanup and 1/4 in ongoing documentation maintenance.
Thats the real price if you want to produce good code…. and you can produce really solid , maintainable code.
It’s just 4x the price of vibe coding… but 1 solid senior developer can still produce about as much as if he was running a team of 5-10 engineers depending on the project. Still incredibly rapid and economical…. But it takes the same skills as you need to run a team as well as an excellent sense of smell to call out wrong turns.
Also, use the 1M context model, have a solid onboarding that describes your company culture, and why the project matters to the AI collaborator, as well as your coding practices, etc. I also use several journals (musings, learnings, curiosity) that the AI maintains itself, reading them during onboarding and writing them in wrapup. It is at least a 2x when the AI is acting as if it were a person that is deeply invested in the outcome. Treat it like a collaboration and you will get better results.
It’s a token fire. But IMHO it’s the way if you’re building something that has to be deployed at scale and maintainable.
Straight vibes are fine for mockups, demos, and prototypes.