The Engineer I Want to Become in the Agent Era

Code is getting cheaper. Judgment isn’t.

That thought stuck with me after watching DHH’s talk on AI agents and software engineering. It made me look at my own work: if an agent can produce a working feature in minutes, what do I need to get better at?

My answer is still taking shape, but I know it isn’t “write longer prompts.” I want to be the engineer who can understand the problem, make sound decisions, work well with agents, and take responsibility for what happens after the code ships.

Understand what the code is doing

Frameworks still matter to me, but knowing their APIs isn’t enough.

An agent can generate a database query with SELECT ... FOR UPDATE. The harder questions come after that: What race condition are we preventing? Could the lock cause another request to wait too long? What happens if the transaction fails halfway through? Is there a simpler way to design the workflow?

Those questions push me toward databases, concurrency, queues, caching, authentication, and the ways systems fail in production. The more I understand those foundations, the better I can judge the code an agent gives me.

Get clearer before I delegate

When a task feels vague, my first instinct is sometimes to start building and figure it out along the way. Agents make that habit more expensive. They can move quickly in the wrong direction, too.

Before asking one to implement something, I want to be able to explain the goal, the constraints, and what must stay true. What data is involved? What could fail? What should happen when two requests arrive at once? How will I know the change works?

That’s more useful than a clever prompt. It’s the work of turning a fuzzy idea into a task someone else can actually complete.

Treat generated code as work to review

I want to give agents meaningful work, with enough context to make good decisions. Their output deserves the same careful review I’d give a teammate’s pull request.

Does the implementation handle the unhappy path? Are permissions checked in the right place? Do the tests prove the behavior, or just repeat the code’s assumptions? Would I feel comfortable debugging this at 2 a.m.?

The fastest way to generate code is not necessarily the fastest way to ship something dependable. As implementation gets easier, confidence in the result becomes more valuable. I want to get better at testing, observing, and debugging real systems, not just accepting a green test run and moving on.

Build across the stack, keep some depth

Agents make it easier to work in an unfamiliar language or part of a product. That opens up ideas I might otherwise put off while learning a new set of libraries.

But I don’t want that freedom to turn into shallow understanding everywhere. I want real depth in backend systems, while getting comfortable enough with frontend, infrastructure, and AI tooling to build a complete product. If an agent helps me cross a boundary, understanding the decisions on the other side is still my job.

That also changes what I want my projects to show. A working app is a start. A stronger project shows why it was built that way, what trade-offs I made, how it behaves under pressure, and whether people actually use it.

Keep learning what lasts

There will always be another model, agent framework, or tool to try. Experimenting matters, but I don’t want my career to depend on knowing this month’s favorite one.

The skills I want to keep practicing are slower to change: understanding systems, breaking down problems, evaluating results, and owning software in production.

AI may help me write more code. My goal is to get better at knowing which code should exist, why it should work, and how to tell when it doesn’t.