Skip to main content

From Coding to Directing: How My Engineering Work Changed

·497 words·3 mins·

Over the last few months, my mental model for engineering has fundamentally shifted. It isn’t just that the tools got better at autocomplete; it’s that the “unit of work” has changed.

I’ve moved from 80% manual execution to 80% agent-driven construction. This is a transformation in how I solve problems.

Shipping Outcomes over Steps
#

In my role, I’ve always valued shipping outcomes over endless experimentation. Working with agents forces this discipline. When you program in English, you quickly realize that its essential to have clarity of the intent.

I now spend less time writing implementation details and more time defining what must be true when the work is done. You stop thinking in imperative steps and start thinking in declarative outcomes. If the success criteria are fuzzy, the agent will fill the vacuum with complexity. Precision in language has become the new high-leverage skill.

The New Failure Modes
#

The “bugs” I deal with now are different. Agents are relentless, but they can also be subservient. They will confidently build a 1,000-line abstraction for a problem that requires a 50-line utility if you don’t provide the right constraints. I’ve noticed a few specific patterns in this new workflow:

Over-engineering by default: Agents tend to bloat APIs unless explicitly told to favor simplicity.

Assumption drift: They make “reasonable” guesses that can lead to more work if not watched closely.

The “Discrimination” Gap: I’m noticing reading code and maintaining a high quality bar is now a more critical senior skill than ever.

Leverage Through Stamina
#

The most profound shift is the removal of friction. Problems we previously ignored because they were “too tedious” or required too much “boilerplate exploration” are now solvable in minutes.

An agent doesn’t get demoralized by a refactor that requires touching 40 files. It doesn’t get tired of chasing an edge-case bug. This infinite stamina changes the math on what projects are “worth it.” We can now approach codebases and domains that were previously blocked by the sheer manual effort.

The Senior Engineer’s Role in 2026
#

As execution becomes a commodity, the value of a Senior/Staff engineer shifts upstream. My responsibility hasn’t moved away from engineering; it has moved toward strategic architecture and constraint-setting.

My day-to-day is now focused on:

Hard Trade-offs: Deciding what not to build.

Defining Invariants: Setting the guardrails that allow agents to operate safely at scale.

Managing Abstraction: Preventing the “slopacolypse” of bloated, unmaintainable AI-generated code by enforcing a high bar for simplicity.

The Bottom Line
#

This isn’t a hype cycle; it’s a phase shift. The technology has outpaced our organizational habits. We are moving from a world of “line-by-line control” to a world of “system-level orchestration.”

I still care about the code. I still care about the craft. But I’ve learned that the highest leverage I can provide isn’t being the fastest typist in the room—it’s being the one who provides the most clarity.

Once you experience that level of leverage, there is no going back.