There is a recurring fear around AI and agentic automation:
If agents can eventually do most of the work, what is left for us?
I think this question starts from the wrong assumption.
It treats professional work as if its value comes primarily from performing individual steps.
Write this code.
Run this command.
Check this test.
Create this pull request.
Deploy this service.
But those steps have never been the whole profession.
The real value comes from knowing why those steps should happen, what good looks like, which trade-offs are acceptable, and when the result is safe to ship.
Agentic automation doesn't necessarily remove that responsibility.
It can actually make it more visible.
Automation changes where your skills are applied
Imagine an experienced software engineer using an agentic workflow.
The agent may:
- create an isolated worktree
- inspect the codebase
- implement a change
- add or modify tests
- run the test suite
- format the code
- analyze failures
- iterate on the implementation
- prepare the result for review
A significant amount of traditional implementation work can happen automatically.
At first glance, that sounds like the engineer is being removed from the process.
But look at what the workflow still depends on.
Someone needs to decide:
- What problem are we solving?
- Is this actually the right problem?
- What architectural constraints apply?
- What should the agent be allowed to change?
- Which existing behavior must remain compatible?
- What level of test coverage is sufficient?
- Which trade-offs are acceptable?
- What risks deserve additional review?
- Is the resulting implementation maintainable?
- Should this change actually reach production?
Those aren't incidental details.
They determine whether the automated work produces something valuable or merely produces something.
Execution is not ownership
This distinction becomes increasingly important as agents become more capable.
An agent can execute a task.
That does not mean the agent owns the outcome.
A compiler can compile bad architecture.
A CI pipeline can successfully validate the wrong feature.
An automated deployment system can deploy a perfectly functioning implementation of a bad product decision.
AI doesn't fundamentally change this.
It just increases the amount of execution we can delegate.
The professional still owns the context around that execution.
And that context often requires years of accumulated experience.
The engineer doesn't disappear. The engineer moves up a level.
For a long time, automation has pushed engineering work upward.
We stopped manually writing machine instructions.
We stopped managing memory addresses for most applications.
We stopped manually provisioning every server.
We stopped copying binaries onto production machines.
We automated builds.
We automated tests.
We automated infrastructure.
We automated deployment.
And software engineering did not disappear.
Instead, the abstraction level moved.
Agentic development is another step in that direction.
If an agent can handle more of the implementation loop, the engineer can spend more attention on:
Architecture
How should the system evolve?
Product understanding
What actually creates value for the user?
Constraints
What must never be violated?
Risk
What could go wrong, and how serious would it be?
Evaluation
How do we know the result is actually correct?
Direction
What should happen next?
Judgment
When is the machine technically successful but professionally wrong?
These are not secondary skills.
They increasingly become the job.
Full automation does not have to mean zero control
There is another false choice hidden in many conversations about AI automation.
Either:
- a human supervises every individual step, or
- the agent receives complete autonomy and we accept whatever happens.
Neither model is particularly attractive.
If I have to approve every command, I haven't automated much.
But if the system can freely publish packages, merge code, deploy services, or modify external systems without meaningful boundaries, I've probably automated too much.
There is a better model.
Automate aggressively inside well-defined boundaries.
Then require human judgment when crossing the boundaries that matter.
Execution permission is not delivery authorization
This is a principle I've been thinking about while building vincent.
An agent may need considerable freedom while working on a task.
For example, inside an isolated worktree it may be perfectly reasonable to allow it to:
edit files
run commands
execute tests
retry failed approaches
generate artifacts
inspect diffs
Requiring approval after every action would destroy much of the value of agentic automation.
But that doesn't mean the same agent automatically receives permission to:
merge the pull request
publish the package
deploy to production
close the issue
release the artifact
Those are different permissions.
I think of it as:
Execution permission != delivery authorization
The agent can be trusted to explore and execute within the task while the professional retains authority over whether the outcome crosses an important external boundary.
Human gates should be part of the workflow
This is why vincent has explicit manual steps.
A workflow can execute automatically until it reaches a meaningful decision point.
At that point it pauses.
The state of the task remains available for inspection: the branch, worktree, results, transcripts, and diff.
The professional can then decide whether to:
- approve and continue
- reject the result
- skip the action where appropriate
The important part is that the approval isn't an informal convention.
It is part of the executable workflow.
For example, conceptually:
steps:
- agent:
task: implement-feature
- command:
run: dotnet test
- manual:
message: Review the implementation before creating the PR
- command:
run: create-pull-request
Everything before the gate can run efficiently.
But the action that changes the outside world requires a deliberate decision.
Where you put the human matters
Simply saying "a human reviews AI-generated code" isn't enough.
Review timing matters.
Consider this workflow:
agent writes code
↓
tests run
↓
PR created
↓
package published
↓
deployment starts
↓
human reviews eventually
Technically, there is a human in the loop.
Practically, there isn't much control.
Compare it with:
agent writes code
↓
tests run
↓
results collected
↓
HUMAN DECISION
↓
PR / publish / deploy
Now the approval has meaning.
It defines a clear boundary:
Everything before this point may happen automatically. Crossing this point requires authorization.
That is much stronger than relying on someone to notice afterwards that automation made a poor decision.
Expertise becomes the input to automation
There is another reason I don't believe agentic development automatically devalues experienced professionals.
Good automation is built from expertise.
Consider two engineers asking an agent to implement the same feature.
One says:
Implement feature X.
The other provides:
- relevant architecture
- domain constraints
- compatibility requirements
- testing expectations
- security boundaries
- expected failure modes
- performance constraints
- acceptance criteria
They may technically be using the same model.
They are not going to get the same result.
The quality of agentic work depends heavily on the quality of the environment, constraints, workflow, evaluation, and decisions surrounding the agent.
And creating those things requires understanding the profession.
The valuable skill is increasingly knowing what to automate
There is an interesting inversion happening.
Previously, professional expertise was mostly demonstrated by performing difficult work yourself.
Increasingly, another form of expertise is becoming important:
Knowing which parts you no longer need to perform manually.
That means recognizing repetitive processes.
Turning implicit knowledge into explicit constraints.
Building reliable verification.
Separating reversible actions from dangerous ones.
Designing useful approval boundaries.
Creating workflows that can fail safely.
Giving agents enough autonomy to be useful without giving them authority they don't need.
That is engineering too.
Automation should amplify expertise, not erase it
I don't want an AI agent that needs me to press Continue every 30 seconds.
That isn't meaningful automation.
I also don't want an AI agent making every consequential decision simply because it technically can.
The useful space lies between those extremes.
Let agents do what machines are increasingly good at:
- repetition
- exploration
- execution
- iteration
- mechanical verification
- information gathering
And let professionals concentrate on what expertise is particularly valuable for:
- intention
- architecture
- judgment
- trade-offs
- risk
- quality
- accountability
The goal isn't to keep humans artificially busy.
It's to make sure human attention is spent where it has the highest value.
Our profession will change
I don't think software engineering ten years from now will look exactly like software engineering today.
It shouldn't.
Our profession has always changed as our tools improved.
Some tasks we currently consider fundamental may become almost entirely automated.
Other skills will become far more important.
We may spend less time writing individual implementations and more time designing systems in which implementations can be generated, evaluated, rejected, improved, and safely delivered.
But that is not the same thing as giving up the profession.
It is the profession evolving.
The engineer who understands the system, defines the boundaries, evaluates the result, and owns the outcome still matters enormously.
Perhaps more than ever.
The point is not to stay in the loop everywhere
It's to stay in the loop where your judgment matters.
That's the philosophy I'm trying to apply while building vincent: automate repeatable agentic workloads without forcing professionals to surrender control over their outcomes.
Agents can execute.
Automation can orchestrate.
But professionals still decide what success means.
And ultimately, that decision determines the outcome.
If you're interested in the implementation side of this idea, I wrote a shorter piece in the vincent documentation about explicit approval gates and separating execution permission from delivery authorization:
👉 Automation without giving up control
And if you're interested in vincent itself:
👉 vincent — durable local orchestration for agentic development
Top comments (0)