Agentic Coding Is a Trap

Try this thought experiment. If, in 6 months, the agents were better coders than you are, would this argument still hold?

This is a personal thought experiment so think it through for yourself. What would the consequence be if the agents really were better than you and you acknowledged that?

The major premise of "It's a trap!" is that it matters if you lose your coding skill. (I'll gloss over general critical thinking and stick with coding for now) However in the world where on any given task it would be done to a higher level of quality and faster if you gave it to the agent, then what are you doing trying to do it yourself? There's plenty of room for that kind of thinking in hobbies, but in the professional world?

Maybe you can add some value in code reviews, but you may also be better off never reading the code at all. Maybe the how of coding stops mattering and the what of products needs to be your top concern.

I can tell you that the agents that I use today are much better coders than I am in the language we're using. I don't write it at all. I couldn't fizzbuzz in it. But with a small team we are building useful internal tools and features at a breakneck pace. I certainly feel the same feelings of getting dumber and losing my coding chops, but I have to step back and say, could what we've built have been built in 5x the time without agents? And the answer is probably no.

The thing I'm mastering now is conjuring software with agents. What lets them rip, what slows them down, where they are today and where they will likely be tomorrow.

I can tell you that you should re-invest in small, modular systems, because agents can build modules and greenfield projects instantly. I can tell you that there is a point at which agents fall over completely even on mid-sized projects, but that that point is receding with each new generation of model, and that Codex 5.4 XHigh Fast set to 500K context window is a beast. (5.5 has yet to win me over)

I can tell you that pushing direct to main is viable, that PRs slow down fully agentic teams, and if your agents have sufficient permissions they can fix things fast enough to be let loose even knowing they may delete your service. I wouldn't do it with your main product yet (unless you're starting your startup today) and I wouldn't try it with a large legacy project. But maybe that rewrite you've always wanted to do is here and just a prompt away.

Now, the sane among you will note that agents are not better today, that they might not ever be, and either way you should never trust a computer to make a decision because it can't suffer the consequences of its actions. Or more down to earth, there are some things that are too important to yolo.

But I will argue that a huge swath of us work in domains where if you're willing to challenge some of the basic assumptions of software development (you should understand the code, it should be maintainable by humans, it should be built to last) then you'll be able to provide very useful software much more quickly than you would otherwise be able to do. Save the skill for your hobbies, and build things people want.

I think the best way to go about this is to start with a manually coded codebase outlining the basic structure of your app (even if ported from some other project) so that you basically define the code "palette" and THEN using AI to add features / edit stuff.

It won't do everything exactly the way you would've coded it but I find this model much better at setting and maintaining "guardrails" for your codebase so you don't find yourself wondering how it all fits together.

It's a good point, and your username definitely checks out. I've also worked at a startup and some smaller companies, and still there's a LOT of "wankery" just different types. No, don't write the code yet, you need to present it to the CEO. Oh, we need to also present it to investors. Wait for a bit, because we have another deal coming down the pipe and we might have to change direction. Oh, a VIP customer just played golf with the founder and you need to go to his house to fix his setup. So much of the software engineer's job in the software industry doesn't involve writing code.

Frankly I don't buy atrophy argument at all. I (and I believe many other people) switched multiple frameworks and languages over the years. I.e., I was an expert in Chef more than 10 years ago, and nowadays I hardly remember anything about it. Calling this a cognitive decline is a significant stretch.

If you're afraid of cognitive decline - try to get to proper orchestration using multiple agents. That's a fun exercise.

I genuinely appreciated this comment—it made me chuckle. That said, I think there are better approaches to working with AI besides “here’s a big vague thing to work on, go write some code”. I think you have to iterate somewhat closely with the AI to write a doc describing exactly what you want the system to do and then scope out very narrow tickets and then have a separate agent do the TDD to actually produce the thing. The key insights here are (1) don’t let a code writing agent have too much scope—just a narrowly scoped ticket, (2) keep the coding agent’s context minimal, (3) don’t let the coding agent write much code without testing it. The agent should make very small changes at a time and then test that everything still works.

You will still need to QA stuff and review PRs, but I think AI done properly can genuinely make some tasks better.