A couple months ago, I started preparing a talk about a feature that went from discussion to pull request in a day. Back then, saying an agent wrote all my code felt like a hot take. Now it just feels normal.
I don’t have a neat answer for when I stopped writing code by hand. Maybe it was in December, when I switched my primary editor from Cursor to Claude Code.
If I’m already in a terminal with an agent open, why would I leave? You change one thing, you have to change three or four. The agent handles it. At first I wanted to know why I couldn’t just change one thing. Let me see the diff. But looking at the diff makes you want to jump in and tweak, so I stopped opening the editor. The question changed from “did the agent write this as I would?” to “does it address the problem?”
I’ve been working in Go for a few months now, but I don’t know Go.
When I joined Amazon in 2017, I didn’t know Java either. All my team wrote was Java. So I wouldn’t embarrass myself, I decided to learn. Read Effective Java, did the exercises, asked questions on pull requests. “This is how I’d do this in Python, is that normal in Java?” After a few months, the language got out of my way and I could work again.
With Go, I haven’t needed to. The tools know it better than I do. When I did the book exercises, writing code by hand felt alien. Compiling the project myself, running the linter, hand-writing the tests.
I know the difference between “I understand this” and “I can currently get away with this.”
Earned knowledge
Early in my career, I worked in the film industry at Light Iron. I built a tool that copied camera negatives for backup and long-term archival. It checksummed each file, copied it to multiple destinations, then read back and verified the checksums matched. The application ran on a portable cart on set as a self-contained app.
Then we started working on John Wick. Our previous shoots had used large camera files from RED cameras, gigabytes each. John Wick shot on an ARRI Alexa, which instead of shooting one large file for a clip, split the files into a single file per frame. At 24 frames per second, we went from processing hundreds of files for a TB drive to hundreds of thousands.
One day, an operator reported a problem. They ran the copy overnight and went home, and when they returned in the morning it seemed stuck at the 6 hour mark. Could I figure out what happened? Production kept delivering new footage and they didn’t want to get behind.
I looked through logs and didn’t see anything obvious. It stopped copying at some point with no explanation. We restarted it and the same thing happened again. Not always at 6 hours, sometimes 3, sometimes 8. Only on this show.
I built a local test rig to reproduce it. Made a bunch of small files, stress-tested it, and eventually found I could take a process sample when it froze. The tool was stuck deep in its copying and checksumming paths.
I still remember debugging under production pressure that week, people asking me why things were broken and I didn’t know, me in the LA office trying to replicate a long failure cycle while the shoot ran on the other side of the country. Scolding people when they turned off the machine after 5 hours to do something else with it.
The copy path and the checksum path each locked files while processing them, but in a different order. With a handful of large files, two workers rarely tried to claim the same lock. With many small ones, suddenly we were hitting deadlocks, where each process was holding a lock another process needed.
I ripped out the per-file locks and replaced them with a semaphore. That’s how I understood deadlocks, to the point where I can tell you about it twelve years later.
If I had today’s tools, they might’ve found the bug in minutes. I wouldn’t have internalized the lesson in the same way.
Cheap code
AI will happily build a custom version of something that’s already solved elsewhere. You can accumulate a surprising amount of complexity taking the shortest path through prompting.
I recently built a personal doc editing tool because I’m tired of Google Docs. Wrote a detailed spec and let an agent run through the task list for a few hours. When I opened the deployed version, it looked horrible. Couldn’t leave a comment, couldn’t add a second doc.
When I went back to fix it, the code didn’t feel mine. I had to reconstruct the decisions I’d asked the agent to make. Even though it was easy to write, I’m still not sure I should’ve been writing it at all.
Judgment
I once asked about a policy-generation feature I thought another team was building. “How can we consume the generated policies for machines?” A few people chuckled. Turns out the AI tool I’d used to prep an agenda had indexed a doc it didn’t understand, so neither did I. I said, “sorry, my mistake, let’s move on.” It was a small mistake, but it felt different from being wrong about something I’d understood deeply enough to ask about.
In another case, I set up a new service from a template. An AI review flagged a health check protocol mismatch and 10 other things. I took its suggestions. I wasn’t confident enough to say the reviewer was wrong.
When the deployment failed, someone else had to help me debug a change I had accepted but not really understood. We spent time guessing which of my changes could be breaking. We eventually fixed it when I compared my code to the template and caught the health check thing, but I couldn’t retrace the steps because some of them weren’t mine.
I didn’t even check.
Is this the right thing to build? Do we want this pattern in the codebase? Should this code exist at all?
A team recently received a thousand-line PR from a well-meaning contributor outside their group. Should they accept it? Reject it? We own the code. If we accept it, we’re the ones getting paged.
In open source, you can see the split. Some people are disabling all AI pull requests. Others are building infrastructure to accept more. Still, what works in open source doesn’t necessarily work inside a company. It’s different when the blast radius is prod going down and someone getting woken up at 2 AM to blearily log into their computer.
Parachuting in
We work in systems where the code is mostly written by someone else, or someone who feels like a stranger. A teammate wrote it. A contractor wrote it. I wrote it six months ago and forgot how it works.
I joined a startup a long time ago and they asked me to figure out how to get them to infrastructure as code. They had an ops contractor and a small fleet of hand-managed machines. Deploys meant SSHing in and updating files.
I asked lots of questions. How do deploys work? Where are our config files? What reverse proxy do we use?
Then the contractor quit without notice. It left me to figure out how to reproduce the environments without the person who made them.
I reverse-engineered enough of it by looking through the machines, reading server configurations, making educated guesses even though I wasn’t educated in devops at the time. Nginx configs, gunicorn, deployment scripts. Then I built a local dev environment, set up database migrations, got to chatops.
A colleague asked how I learned the stuff I poked at. It’s like parachuting onto a mountain. You don’t know the terrain, so you explore the area around where you land and work outward. Eventually you’ve parachuted into enough parts that you understand the shape.
We’re still parachuting in. AI-generated code is the latest version of “someone else wrote this and now I have to understand it.”
What stays the same
I’ve moved from AI autocomplete to an agent in an IDE to an agent in a terminal to parallel agents. I’m having a mental block about what seems like the next step: agent orchestration. I don’t always know what I actually understand versus what I’m getting away with. Moving up one more level of abstraction feels a little scary.
My job was never about writing code. It’s identifying the right problems to solve. It’s giving a shit as a service.
Code is the last tool I want to reach for, because code sticks around. We own it, maybe forever. The upfront part was always cheap compared to maintenance. We’re grappling with what happens when the cheap part gets cheaper.
I want to believe the core job has changed less than the interface has. Some days that feels true. Other days I’m not sure whether I understand more, or whether the tools have gotten better at letting me move before I do.
We just parachute in from higher up now.