Switching from doing to directing

Sun, 12 Jul 2026 00:00:00 +0000

We are already in the era of AI-assisted software development. In that world, I think software engineers need to spend less time only doing and more time directing.

I work with young, sharp, deeply motivated colleagues. Many of them are already strong builders. What I want to encourage is not less ambition or less hands-on work, but a shift in where more of their thinking goes. Not just into writing code, but into setting direction, shaping context, and taking responsibility for the outcome.

I use the word “directing” very intentionally.

It means setting direction: sketching the architecture, defining standards, and establishing working patterns.
It means shaping the script: building the context, boundaries, and guardrails that guide the work, then refining them as the solution evolves.
It means owning the result: understanding what is being pushed to production and avoiding comprehension debt later, when the system needs to be supported, changed, or debugged.

I had this on my mind already, and then over the weekend I read Addy Osmani’s article The Agent-Era Career. He touches several parts of how software engineering is changing in the agent era. The part I want to stay with here is simpler: directing is not about stepping away from the work. It is about being more deliberate about where human judgment is still needed most.

For me, that starts with how much autonomy I give the tool. I do not think this should be treated as a fixed setting. If the task is small, easy to review, and easy to roll back, I am comfortable giving an agent more room. If the change affects production behavior, data quality, or something painful to unwind later, I want a much tighter loop.

It also made me separate two skills that are easy to blur together. One is being clear enough about the task that the agent has a fair chance of doing something useful. The other is checking the output properly. Those are not the same skill. A clean instruction does not remove the need for verification, and fast output does not mean safe output.

That is why I keep coming back to ownership. If agent-assisted code goes to production and causes trouble, the real issue is not who typed it first. The issue is whether the engineer behind it understood what was being shipped well enough. That is the standard I think we should keep.

I am curious how this is handled in your team. Are experienced engineers still mainly expected to do more themselves, or to direct, verify, and own AI-assisted work more deliberately?

Career Growth on Peter Fulop

Switching from doing to directing