I'm an ML engineer with an academic background and about eight years of industry experience. I use Python professionally and as a hobby, and I've been experimenting with LLMs for coding. So far, I get the most value from brainstorming, syntax, small optimizations, and reviewing suggestions while I keep control of the design and verify the implementation myself.
Recently, I've seen more people describe highly autonomous coding workflows where an agent is given a broad goal and writes most of the code. Some companies claim that large portions of their codebases are AI-generated, and several experienced engineers say newer models have reached the point where they rarely write code manually. That's very different from my own experience.
For ML and experimental work, I need to understand exactly how data is processed and why each design choice was made. I also find that creating a sufficiently detailed prompt for a complex system can take a long time, and the resulting code often needs substantial correction. Are autonomous coding workflows genuinely useful for serious, maintainable projects, or are they mainly suited to prototypes and disposable experiments? I'd especially appreciate practical experiences, including how much supervision, planning, testing, and review they require.
4 Answers
They can work, but mostly when the result is easy to verify or doesn’t need long-term maintenance. One-off experiments, prototypes, simple interfaces, and exploratory tests are good candidates because you can check the output directly. For important systems, autonomous generation often produces tangled code that is difficult to understand and maintain. Your current approach—designing the solution yourself and using the model for smaller tasks and review—is a sensible default.
The strongest use cases are code review, documentation, brainstorming, finding missing cases, and catching code that is syntactically valid but semantically wrong. Models are also decent at boilerplate when you provide an existing pattern. They remain much weaker at architecture, ambiguous requirements, and understanding the real-world consequences of a design, so every generated change still needs careful review and tests.
A more autonomous workflow can succeed if you treat it as a supervised engineering process rather than giving it a goal and walking away. Spend time creating a plan, documenting assumptions, defining tests, and giving the model useful project context. Have separate passes review the plan and implementation, add automated checks and pre-commit guardrails, and keep the code easy to inspect. In that setup, the model can handle a lot of implementation, but the human still owns the direction and quality.
Some developers report that current coding agents write most of their code, but that usually depends on close monitoring, strong project instructions, and a large test suite. A broad request followed by hours of unsupervised generation is much less reliable than working in small steps and redirecting the model frequently. Better prompts and newer models help, but they don’t remove the complexity ceiling or the need for an engineer who understands the system.
The cost is not just usage-based billing. There is also the time spent reviewing, correcting, and maintaining code that you may not fully understand. For high-stakes work, that tradeoff can easily outweigh the speed gained.
That approach can be productive, but managing context, plans, and reviews takes significant effort. It may reduce typing while increasing the amount of time spent supervising and validating the result.