Where/what is my value as an engineer today?

There are two camps right now on engineers using agents. One says agents can already do everything, you just define what you want, they build it, you manage them and review what comes back. Human attention is the bottleneck (as we are probably tired of hearing), so put yours on what to build and let the agents figure out the how. The other camp doesn't trust any of it.

I don't think we have a norm for responsible AI usage in engineering yet. You're either balls deep or very skeptical, and there isn't much in between.

The closest thing to a norm I've seen is Mitchell Hashimoto's "whiteboard defense":

I should be able to pull you aside at any moment and ask you to explain any customer-facing system you've shipped. You should be able to clearly explain how it works and defend the decisions you made. This is my benchmark for responsible AI usage.

He doesn't expect line-level familiarity, you don't have to remember the function name. But if he asks "why did you do X instead of Y?" or "where does this fail?" you should be able to answer.

I fully agree with that. My value as an engineer now is a deep understanding of what is happening and why. I don't need to remember the method name, the variable name or the file. The agent probably writes better code than me line by line anyway. But for me that's the floor.

# Owning the shape

A lot of people say engineers become product people now. I think there's still a clear distinction. Product is the what, and many times the why. Engineering is the how, but also the why, and the why goes hand in hand with the how. Why this module owns that state, why that thing sits behind an interface.

When the agent starts deciding the shape of the code (how big things are, where they live, how they connect) and it doesn't line up with what I would have done, I'm not engineering it anymore. I'm just product owning it.

And you can pass the whiteboard test the whole time. You read what the agent built, you understand it, you can explain it to anyone who pulls you aside, and you're still stuck with a shape you never chose.

I like my modules deep, a lot of behaviour behind a small interface. I wrote my own skills describing how I want codebases designed, and it works, somewhat. It never gets it fully right.

Agents are very knowledgeable but lazy. They take shortcuts, a bolted-on fix here, a special case there, and each one looks fine on its own. I've let them run wild, then wanted to make a change later on and had to refactor almost the entire codebase because of one wrong turn the agent took that I wouldn't have taken.

Every project already has constraints, from scratch or established. I don't want another one that only exists because of whatever the agent happened to write first. Building things that are extensible and easy to pivot without making them overkill is a judgment call, and agents don't have that judgment yet. Once I lose the how and the why, every incremental change and every pivot gets harder.

# The spaghetti argument

The strongest pushback I know goes like this: "If agents are the ones reading the code, who cares if the modules are deep or it's spaghetti? Tests pass (I also have opinions around ai gen tests), it works, and when it gets messy an agent refactors it in an afternoon."

That's true if you could trust them blindly. I don't think we're there, and maybe we won't be for a while. Human eval is still needed, at least for now.

And I'm still the one responsible for what I ship. I own the engineering side and the codebase, so I should be able to jump in and apply what I know line by line if needed. That's a lot harder in a codebase shaped by someone else's shortcuts. And agents get way more useful when you understand what's happening at a deep level anyway.

# Where I don't care

Ephemeral work is different. A script to do something once, a prototype, a quick automation to make a process easier one time. I don't care how it's done, I just need it to work, so I fire and forget. Hashimoto draws the same line: "For PoCs, demos, experiments, whatever: I don't care. Generate 100% of it and understand none of it."

# If you're all in

Slow down a bit. Look at the code, at least at its shape. Decide where things go before the agent does, write it down somewhere it will read, and step in when it bolts something on. Being AFK on the how is fine for a while, until it is not.

# If you're skeptical

Speed up. Let them type and keep the design yours, and for ephemeral stuff don't even look at the code.

# Where this goes

I don't know what happens as models get better. Maybe they get the shape right and this post ages badly. Right now there's a gap between how an agent shapes a codebase and how I would, and that gap is where my value is.

I don't think agents are replacing us yet, but you never know, so adapting is key.