We Do Not Just Write Code Anymore. We Direct Agents.
Software engineering is shifting from manually writing every line of code to directing AI agents, reviewing their work, and building stronger tests, context, and guardrails around them.
Something changed in software engineering, and I do not think we have fully named it yet.
For years, the job was mostly about writing code directly. Then autocomplete got better. Then chat-based coding assistants arrived. Now the workflow is shifting again: we describe goals, hand off chunks of work to agents, inspect their output, tighten the tests, and decide what gets merged.
That is not the same job with a faster keyboard. It is a different shape of work. I would call it agentic engineering.
The engineer is becoming a director
Agentic engineering does not mean the engineer disappears. If anything, it makes the engineer's judgment more visible.
A coding agent can read files, make changes, run commands, open pull requests, and iterate through errors. GitHub describes Copilot agent mode as a workflow where the agent can plan, edit, run terminal commands, and keep working until a task is complete. Google describes Jules as an asynchronous coding agent that can take a task, work in a virtual machine, and produce a pull request. Anthropic's Claude Code guidance talks openly about using multiple Claude sessions in parallel, giving agents clear context, and treating them like workers that need direction.
That is the shift. The engineer is no longer only the person typing every line. The engineer is also the person deciding what should be built, what constraints matter, how to verify the result, and when the agent is wrong.
Prompting is too small a word for this
People often describe this work as prompting, but that undersells it.
A prompt can be a single instruction. Agentic engineering is more like delegation. You define the task, provide the relevant context, set the boundaries, create checks, review the work, and decide the next move. If the agent goes in the wrong direction, the failure is not always the model's fault. Sometimes the task was too vague. Sometimes the repository had no tests. Sometimes the acceptance criteria lived only in someone's head.
This is why the best engineers in this new workflow will not simply be the fastest typists or the cleverest prompt writers. They will be the people who can turn messy intent into clear, testable work.
Tests and reviews matter more, not less
The uncomfortable part is that agents make weak engineering habits more expensive.
If a human writes a bad function, you review the diff. If an agent writes ten files, updates dependencies, touches configuration, and claims the tests pass, you need even stronger verification. You need good automated tests. You need small pull requests. You need logs. You need security boundaries. You need to know which commands the agent ran and why.
Martin Fowler's writing on generative AI and software development keeps returning to this point: the loop still needs humans, feedback, and engineering discipline. Thoughtworks has also been tracking agentic coding tools as a technique, but with the same basic warning underneath the optimism: these tools are useful when teams change the workflow around them, not when they blindly paste agent output into production.
I like the promise of agents. I use them. But I do not trust a confident agent more than I trust a clean diff, a passing test suite, and a reviewer who understands the product.
The new skill is context engineering
The phrase "context engineering" sounds trendy, but it points to something practical. Agents perform better when they have the right files, the right constraints, the right examples, and the right definition of done.
That means engineering teams will need to maintain better project knowledge. Not long documents nobody reads. Useful context: setup commands, architecture notes, testing rules, API contracts, known traps, and examples of good work in the codebase.
In the old workflow, undocumented knowledge slowed down new developers. In the agentic workflow, undocumented knowledge also confuses the agents. The hidden cost becomes visible.
Agentic engineering is still engineering
The hype version says agents will build everything for us. The cynical version says they only produce slop. Both are too lazy.
The more realistic version is this: agents are becoming part of the engineering team, but they are not accountable. We are. They can draft, refactor, investigate, generate tests, and chase errors. We still own the architecture, the tradeoffs, the product judgment, and the final merge.
So yes, the way we do engineering has changed. The center of gravity is moving from typing code to directing work. That is exciting, but it also raises the bar. A good engineer now needs to think like a builder, reviewer, tester, and manager of tiny software agents that never get tired and never truly understand the business unless we teach them.
That may be the next version of the job: less mechanical coding, more judgment per line shipped.
References
Thanks for reading! If you enjoyed this article and like this kind of content, you're always welcome to buy me a little coffee, but only if you'd like to. No pressure at all, and either way I'm truly grateful you stopped by. ☕
