AI is writing more code.
That part is obvious now.
Developers can ask an agent to:
create a feature
write tests
fix a bug
refactor a module
upd...
For further actions, you may consider blocking this person and/or reporting abuse
You're right. LLMs don't replace the real engineers; they just makes our work easier. LLMs may be responsible for writing boilerplate and generating code, but developers are the ones responsible for making sure the AI generated code won't break in production. Nice article.
Exactly — that’s how I see it too.
LLMs are great at reducing repetitive work and speeding up implementation, but the responsibility for architecture, testing, edge cases, security, and production behavior still stays with the developer.
The real value is not “AI replaces the engineer.” It’s AI gives the engineer more leverage — as long as we still understand and verify what gets shipped.
Appreciate the thoughtful comment.
And that's basically why human judgment can't and shouldn't disappear from development with AI: at the end of the day, the human is the one who knows and understands the real functionality you're after. I have a solid harness set up with Obsidian + Orca (Cursor and Codex) with verification skills I keep improving, and still, my own judgment is what keeps everything on track. It's slower than letting it run, but it's the only way I can explain the code afterwards, and if I can't explain it I don't think I really own it at all
Exactly — I really like how you put that.
A good harness can make the workflow faster and safer, but it still can’t replace the judgment that connects the code back to the real requirement.
And I completely agree with this part: if you can’t explain the code afterwards, it’s hard to say you really own it.
That extra review may feel slower in the moment, but it’s what keeps speed from turning into understanding debt later.
Really thoughtful perspective — thanks for sharing your setup too.
The guardrails need the same scrutiny as the code. I wrote a hook to block a tool call and assumed it held. A hook that throws is not a block. Mine was skipped in 574 ms and the tool ran anyway.
The point about responsibility is the one that keeps me thinking. When an agent writes code that breaks in production, the owner is still the human who deployed it. I have started treating agent-written code the same as junior developer code: it needs a thorough review and a clear owner. The eval that catches the most issues is not the linter, it is the "would I merge this if a human wrote it?" test. How do you handle the accountability gap when the agent makes a mistake?
That “would I merge this if a human wrote it?” test is a great standard.
I handle the accountability gap by making ownership explicit before the code ships. The agent can propose and implement, but a human still has to understand the change, review the risk, and decide whether it is safe enough to merge.
For me, the key is not asking “who made the mistake?” but:
Who approved this change, and did they understand what they were approving?
That’s why I like treating agent-generated code the same way you would treat code from a junior developer: useful, often impressive, but never exempt from review.
If the agent makes a mistake, I still see it as an engineering-process failure if nobody caught it before production.
Really good point — accountability probably needs to become an explicit part of AI-assisted development, not an assumption.
"Understanding debt" hits home. I think a lot of teams experience it but haven't had the right words for it yet. Good read.
Exactly — I think that’s why the term resonates.
Teams already know the feeling: the code works, the tests pass, but fewer people can explain why the system behaves the way it does.
Giving that problem a name helps because once you can identify understanding debt, you can start managing it intentionally instead of discovering it during an incident.
Really glad that part stood out to you. Thanks for reading.
That’s a great example of why guardrails need to be tested like real security controls, not just assumed to work.
A hook that “should block” something is not enough if the failure mode is fail-open and the tool still executes. The fact that yours was bypassed in 574 ms makes the point very concrete.
I think the safer mindset is:
guardrail = code + verification + explicit failure behavior
If blocking logic errors, the default should be to stop the action, not continue.
This is a really valuable reminder that agent safety depends just as much on the reliability of the harness as it does on the model itself.