On Agentic Coding — Safwan Parkar

AI models are getting very good, and agents are genuinely useful. But they are still nowhere near the point where I can let them off the leash.

If you’ve been on X lately, you’ve probably seen posts about Garry Tan shipping code written by AI, and his broader take on lines of code. In its essence, the argument seems to be: if your agents can produce 100K+ lines of code, then lines of code must be a useful metric for productivity, skill, or output. I do not buy that argument at all.

That said, I do think this wave of executives and non-traditional developers building software is mostly a good thing. Software development has always been accessible. Bootcamps, YouTube tutorials, cheap courses, and open-source code have lowered the barrier for years. AI has lowered it even more. I do not think that is bad.

The problem starts when influential people push ideas that will make future developers worse off:

Code organization does not matter
Principles and standards do not matter

Those are exactly the things that make software accessible. Imagine trying to contribute to an open-source project and not even knowing where to start. The usual response is, “If agents are going to do everything for me, why should I care?” Because AI cannot work well in a codebase that is a big ball of mush. Try it.

Principles matter more now

Code organization, standards, and principles matter more than ever in the age of AI. The same people talking about the death of software engineering and the rise of “prompt engineering” will be the first to complain when they have to maintain a messy codebase. Principles are what make codebases navigable. They are also what make AI useful inside them.

I am a big fan of hexagonal architecture because it maps cleanly to how I think about software. It pushes me toward code that scales, and it helps me spot issues faster. Letting agents loose in two different projects made this very obvious to me. One codebase was well organized and followed clear principles. The other was the ball of mush i mentioend earlier.

The generated code was dramatically better in the project with structure. In the other one, it was a nightmare. A simple bug fix took hours because Claude and GPT kept going in circles, trying to understand why a fix in file A broke something in file B. Before AI, everyone would have correctly called that bad engineering. I do not see why the standard should change now.

My agents stay on a short leash

I have not had good results from letting agents work unattended. I have tried a lot: skills, MCPs, different models, different harnesses, all of it. So far, none of it has given me the confidence I need. That will probably change eventually, and I am looking forward to that day. We are just not there yet.

Right now, my best workflow is much simpler: I chat with the agent. I start a session, explain the task, and let my .ai/rules.md do the limiting. My rules include things like:

Do not remove tests to “fix” failing tests
Do not use test-native mocking when a dependency can be stubbed instead

And the most important rule is this: stop after the task is complete so I can review.

That one rule makes generated changes much easier to digest. Small reviewable chunks are far easier to reason about than one giant AI-generated big bang. In practice, that workflow has actually made me faster while also making it easier to take responsibility for what gets merged.

Will this workflow work for everyone? Maybe not. For me, it is a much better experience than cleaning up after an agent that ran wild for hours.

I delegate specific tasks

As the heading suggests, I do not delegate everything to AI. If I know I can do something reliably, even on an off day, the AI can do it for me. If I know how to do it but it feels tedious in the moment, the AI can do it for me. But if something is genuinely uncharted territory for me, I do not hand it over to AI.

My goal as a developer is to master the craft. JavaScript is my language of choice, and I want a deep understanding of how to use it well. I want to understand the ecosystem, its trade-offs, and how to write code that is not just functional, but elegant and maintainable. If I let AI do all of that for me, I will never get there. I will always be one layer removed from the work.

That same idea shapes how I split responsibility. If AI writes the code, I will often write the tests, and vice versa. If I give it full control, then only part of the change is really mine, and I cannot in earnest say I fully stand behind it.

Closing thoughts

AI agents are another tool in the toolbox. Their presence should not change the fact that I am the one responsible for the code that gets pushed. If I cannot take full responsibility for a change, I should not merge it. Simple as that.