Agentic Coding Is a Trap

Interestingly I’ve learned more about languages and systems and tools I use in the last few years working with agentic coding than I did in 35 years of artisanal programming. I am still vastly superior at making decisions about systems and techniques and approaches than the agentic tools, but they are like a really really well read intern who knows a great deal of detail about errata but have very little experience. They enthusiastically make mistakes but take feedback - at least up front - even if they often forget because they don’t totally understand and haven’t internalized it.

The claim you should know everything about everything you work on is an intensely naive one. If you’ve worked on a team of more than one there’s a lot of stuff you don’t totally grok. If you work in an old code base there’s almost every bit of it that’s unfamiliar. If you work in a massive monorepo built over decades, you’re lucky if you even understand the parts everyone considers you an expert in it.

I often get the impression folks making these claims are either very junior themselves or work basically alone or on some project for 20 years. No one who works in a team or larger org can claim they know everything in their code base. No one doing agentic programming can either. But I can at least ask the agent a question and it will be able to answer it. And after reading other people’s code for most of my adult life, I absolutely can read the LLMs. The fact a machine wrote crappy code vs a human bothers me not in the least, and at least the machine will take my feedback and act on it.

This post does not make the claim that "you should know everything about everything you work on" - its making the claim that writing code and being able to read code effectively are intrinsically linked.

Only way to cope with this I found is to grind leetcode or advent of code. It's kinda funny how fast this all changed. Less funny part is the fact that I'm now kinda feared for my job in some time.

Agreed. I don't know anything about turning sand into transistors or assembly but do well. So I don't know my full stack either.

What is important is not being afraid to learn the rest of your system and keeping an index.

Most importantly it's about being able to spin up on anything quickly. That's how you have wide reach. Digging in when you have to, gliding high when you have to. Appropriate level for the problem at hand.

When I was in college eons ago they taught CS folks all of engineering. "When do I need to know chem-e or analog control systems?" We asked. "You won't. You just need to be able to spin up on it enough to code it and then forget it. We're providing you a strong base."

That holds even within just large code bases.

One approach you can use is to ask it to never write the code for you, which forces it to explain and then once you try the idea by coding yourself you get a better understanding of it. I use this approach with code I am required to maintain. It still bites me sometimes because the models still mixes a lot of incorrect information (usually just stuff that was correct in the past but is incorrect now). For throwaway and easy to verify scripts I ask it to generate, but I do ask to avoid over engineering and trying to catch all corner cases cause in scripts I prefer just letting things error as they are better understood as a step that failed. I also avoid languages I find hard to read (like powershell) and prefer to generate things that are short to fit in the monitor so I can read everything and understand (python, bash, batch are my goto scripting languages).