I’ve seen a lot of comments and posts where people have stated they ‘literally’ never write a line of code anymore and was curious as to what people mean when they state this.
I say this as a daily user of Claude code with a max plan, so I’m not bashing LLMs or people who use them. I just find it quite hard to understand how it can be productive to offload _all_ coding, especially on brownfield projects.
My reason for saying this is that I often have to debug and triage issues. Often my triage and diagnosis leads me to a point where I can see that the issue is a simple fix with a couple lines of code.
Of course, Claude could fix the issue but the time taken to prompt, wait for it to spit out a plan, evaluate said plan, wait for it to finish implementing said plan, and then evaluate the work would be considerably longer than just making the change quickly and making a PR myself.
Obviously is also possible to just offload the triage and diagnosis to Claude as well but I personally find it unproductive as it essentially ends up with a higher chance of the LLM going rogue and changing unrelated areas of the codebase.
The economics flip on brownfield for exactly the reason you describe: the diagnosis and fix are tightly coupled. You already did the expensive cognitive work to understand the bug. The AI's planning overhead exceeds the writing overhead at that point.
Where the calculus does shift on brownfield is larger feature additions that can be spec'd in isolation. "Add this new endpoint that follows the same pattern as these three existing ones" works well because the AI can pattern-match against existing code. "Fix this subtle race condition in the session handler" almost never does, because the AI's diagnosis phase is unreliable enough that you'd rather just trace it yourself.
Codehydra (https://github.com/stefanhoelzl/codehydra) can help you with this workflow.
My Claude/Codex session have temporary AWS Credentials in environment variables. The AWS SDK and CLI use those variables automatically.
My AWS account is bootstrapped with infrastructure as code.
They both do pretty well with troubleshooting since they have the code and my markdown summaries from the contract, diagrams, call transcripts, project plan etc.
They can both look at live CloudWatch logs to find errors.
If you can see the problem, know how to fix it, and still ask spicy autocomplete to do it for you, that isn't "using a tool", it's cargo culting.
Your brownfield instinct is right though. The productivity gap between "fixing it yourself" and "require → plan → evaluate → deploy → evaluate" only narrows when the task is large enough to justify the cost incurred, or when you're running parallel agents. For a bug requiring only two lines of code, the cost of context switching alone can negate the return on investment (ROI).