9 ms·
Ask HN: How do you offload all coding to AI?
Hey all, hope everyone is well!
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.
- microbuilderco 6mo ago[dead]
- kenmu 6mo ago[dead]
- deleted 6mo ago[deleted]
- aistackkit 6mo ago[dead]
- maxbeech 6mo ago[dead]
- thienannguyencv 6mo ago"Offloading all coding" is perhaps a misleading expression. Those who say they no longer write code are often describing a change in what kind of work they do, not that they've stopped writing code entirely. They spend more time on technical specification, architectural decisions, considering differences, and figuring out when the model misinterprets intent—and less time on actual code typing. 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).
- raw_anon_1111 6mo agoI agree with this completely. Since coding agents came along, I stay completely on the architectural, requirements level and don’t look at code at all. I have damn good markdown files and I have coding agents transcribe what they are doing and decisions I made.
- ThrowawayR2 6mo agoYou're replying to what looks like a bot account.
- thienannguyencv 6mo ago[dead]
- raw_anon_1111 6mo agoWith brownfield projects, I can’t speak to. All of my (consulting) projects start with an empty AWS account and empty git repo. 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.
- AbanoubRodolf 6mo ago[flagged]
- makingstuffs 6mo agoYeah that pretty much aligns with my experience in regard to feature additions. It’s great at those due to the reasons you mentioned!
- kevinherron 6mo agoComplete opposite in my experience. AI does best in a well established code base where it can use existing patterns as context. When you let it loose on a greenfield project and don't carefully and explicitly keep it in check you get back crap.
- jsxyzb 6mo ago[dead]
- stephenr 6mo ago> leads me to a point where I can see that the issue is a simple fix with a couple lines of code. 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.
- tyzerdako 6mo ago[dead]
- faizantahir_dev 6mo ago[dead]
- ad-tech 6mo agoI disagree that offloading all coding to AI makes sense. We started using Claude heavily for our services work about a year ago and what we found is you still need to understand the codebase deeply to know when the AI is hallucinating or changing wrong things. The prompt-wait-evaluate cycle you mentioned is real and kills productivity on brownfield projects. What actually worked for us was using AI for scaffolding new features or writing tests, not for debugging existing code. On debugging I still do it myself because I know our system and can fix it in 2 minutes vs 20 minutes prompting Claude. The people saying they never write code anymore probably either work on greenfield projects or they're not measuring their actual time cost accurately.
- weihong363 6mo ago[dead]
- BloodAndCode 6mo ago[dead]
- jryan49 6mo agoWhen people say they don't write the code, they mean they don't type it, but if there are not vibe coding garbage they are still watching what the agent outputs, and redirects it when it goes wrong. Instead of fixing the code manually they prompt the LLM.
- paulwelty 6mo agoI don't look at much code in my own work anymore. Sometimes, I'm just lazy. But mostly, I trust but verify. I spent a lot of months looking at every line, hand-editing, etc. I built a fair bit of trust. I learned the best way to assign tasks and structure the work. Beyond that, I definitely keep the architecture for myself. And I do believe that prior manual fluency is a requirement for being this hands off.
- JimSanchez1 6mo ago[dead]
- truepricehq 6mo ago[dead]
- xxwink 6mo agoThe framing of "offload" might be the wrong model entirely. I don't offload coding to AI — I govern it. I work with a two-layer setup: one AI agent as architect and coordination layer, another as implementer. Every cross-file change requires a documented amendment before a single line is written. The AI reads the decision log before touching any file. The result is that the AI produces something coherent and maintainable — not because it's smarter, but because it has constraints. Without them my experience matches what others describe here: it goes rogue and changes unrelated things. The overhead is real but it's architectural overhead, not AI overhead. You'd need the same discipline with a junior human developer.
- stefanhoelzl 6mo agoDo not wait for your agent, launch parallel tasks when your agent is working. Then it does not matter anymore how long your agent takes, as long as you always have at least one idle agent. Codehydra (https://github.com/stefanhoelzl/codehydra https://github.com/stefanhoelzl/codehydra) can help you with this workflow.
- microbuilderco 6mo ago[dead]
- Areena_28 6mo ago[dead]
- 6272connect 6mo ago[dead]