There is an episode of The Simpsons, King-Size Homer, that feels uncomfortably familiar today.
Homer starts working from home and discovers that a significant part of his job consists of sitting in front of a computer and repeatedly pressing the Y key.
For Homer, this is fantastic. He has found a job he can apparently do with almost no thought at all.
Then he finds a way to make it even more efficient: he realizes he does not actually need to be there.
He leaves a drinking bird in front of the keyboard to press Y for him while he goes out.
The bird keeps approving things.
Until it doesn’t.
Three decades later, it is hard not to think about that scene when watching how some engineering teams are adopting AI agents:
The agent wants to execute this command. Allow?
Yes.
The agent wants to modify these files. Allow?
Yes.
The agent wants to install this dependency. Allow?
Yes.
Continue?
Yes.
At some point, we should ask an uncomfortable question:
Are we paying software engineers to become Homer’s drinking bird?
The problem is not delegating work to AI. That is what it is for.
We should use it. We should probably use it much more.
I use these tools every day. They can explore repositories, understand dependencies, propose solutions, write code, generate tests, investigate failures, refactor systems and complete tasks in minutes that once took hours.
The problem begins when we delegate our judgment along with the work.
The most expensive approval button in the company
Imagine a fairly ordinary engineering task.
A developer receives a new feature and gives the requirement to an agent.
The agent explores the repository, identifies the relevant components, proposes a plan, modifies several files, creates tests, finds failures, fixes them and runs the suite again.
Everything is green.
The agent produces a summary.
The developer takes a quick look, approves a few actions and opens the pull request.
From the outside, it looks perfect.
Something that might have taken two days now takes two hours.
But ask a few questions.
Why did we modify those components?
Why was this design chosen?
What alternatives were considered?
What assumptions does the implementation make?
What can fail?
What did those tests actually prove?
How does this change affect the rest of the system?
If the engineer responsible for the feature cannot answer clearly because, in practice, “the agent did it,” then we have a problem.
We did not create a 10x engineer.
We may have created the most expensive approval button in the company.
And that is not the agent’s fault.
While the agent learns the system, the team may stop doing so
Before agents, entering an unfamiliar codebase usually forced an engineer through a certain journey.
Search the repository. Read existing code. Trace dependencies. Understand how data moves. Find strange-looking decisions that begin to make sense only after discovering why they exist.
It was not necessarily efficient. And it did not mean everyone fully understood the product.
But there was an important side effect: changing the system usually required acquiring some context about it.
Agents can change that relationship.
The agent reads the repository.
The agent traces the dependencies.
The agent builds the context.
The agent makes the change.
And the human may simply wait for the result.
The paradox is hard to ignore:
While the agent gains context about the system, the team may be losing it.
We know how to talk about technical debt. We have tools for vulnerabilities, complexity, dependency problems and low test coverage.
But what dashboard tells a CTO that the people responsible for a product are gradually losing their understanding of how it works?
The code may compile.
The tests may pass.
Velocity may increase.
And six months later, we may have a team that has made hundreds of changes to a product no one can confidently explain anymore.
I think of this as comprehension debt.
Unlike many forms of technical debt, it can grow quietly.
Until production forces us to pay it back.
You cannot own what you do not understand
For me, this is one of the fundamental principles of AI-assisted engineering:
Execution can be delegated. Accountability cannot.
A developer can delegate code generation.
An architect can ask an agent to explore alternatives.
QA can use AI to generate scenarios and search for edge cases.
Product teams can use it to analyze requirements.
A CTO can use an agent to challenge an architecture, investigate an incident or evaluate a technical decision.
None of that removes professional responsibility from the person making the decision.
When production fails, “the agent did it” is not an answer.
Someone accepted the change.
Someone allowed it to reach production.
Someone should be able to explain why.
Real ownership requires understanding.
We cannot meaningfully approve something we do not understand or defend a decision we never evaluated.
Being “human in the loop” does not mean being in control
Many AI adoption strategies include a reassuring sentence: there will always be a human in the loop.
Good.
But a human clicking Allow is technically in the loop too.
Homer was in the loop.
Human presence, by itself, is not a control. Human judgment is.
And that distinction will matter more as agents become more autonomous.
Agents will investigate, modify code, run tests, create pull requests and complete increasingly long workflows with less constant intervention.
Responding by adding another manual approval every thirty seconds is not governance.
It is turning the engineer into the bird.
More autonomy should not mean less accountability. It should require greater maturity around that autonomy: better boundaries, verification, observability, controls and ownership.
We learned something similar with CI/CD, infrastructure as code and operational automation.
Automation never removed accountability for the operation.
AI will not remove engineering accountability either.
The engineer’s role has to evolve
There is another conversation that may be even more uncomfortable.
If agents can write more code, faster, and with increasingly better results, then the value of simply translating a requirement into syntax will inevitably decline.
That does not make software engineers irrelevant.
It moves their value.
Toward understanding the business problem.
Challenging requirements.
Designing systems and evaluating trade-offs.
Recognizing a bad solution even when it compiles.
Thinking about security, failure modes and maintainability.
And, above all, standing behind the decisions that ultimately reach production.
AI reduces the relative value of producing code and increases the relative value of exercising engineering judgment.
That should be good news.
It gives us the opportunity to move engineers away from mechanical work and toward higher-value activities.
But the organization has to redefine what it expects from an engineer.
Roles change.
Responsibilities change.
Review processes change.
The way we train junior engineers changes.
The work of tech leads and architects changes.
And the way we measure productivity has to change too.
Be careful what you call “productivity”
It is easy to say:
“We need everyone using AI.”
“We need more velocity.”
“Why does this story still take three days?”
“How much code are we generating?”
“How many additional pull requests are we producing?”
And then act surprised when the team discovers that the easiest way to improve those numbers is to let the agent do more and review less.
People optimize for the system we build around them.
If we reward output, AI will give us extraordinary amounts of output.
More code.
More commits.
More pull requests.
More tickets closed.
But companies do not create value because their repositories grow faster.
The question should be:
Are we delivering more business value, faster, without increasing risk or losing control of the system?
Then different things matter: defects, rework, security, maintainability, stability, recovery time and how much product knowledge the team retains.
A team delivering twice as fast while understanding half as much about its own system may show excellent productivity numbers while quietly building a serious future problem.
Perhaps we are not gaining productivity.
Perhaps we are borrowing it.
Your organization has probably already adopted AI
The debate over whether software teams should use AI is largely over.
They are using it.
Officially or unofficially.
With company-approved tools or personal accounts.
To write code, investigate incidents, create tests, understand repositories, document systems and design solutions.
The interesting question is no longer whether AI will enter the software development lifecycle.
It already has.
The question is:
Did your organization intentionally design how AI should be used, or did its adoption model emerge on its own from hundreds of individual decisions?
Those are very different situations.
Mature adoption is not simply a matter of choosing a tool, and it is not solved by publishing a corporate AI policy.
It forces us to answer harder questions.
How much authority should an agent have?
What does a person need to verify before accepting its work?
How do we know the person approving it actually understands it?
Which decisions can be automated and which require a different level of control?
How should engineering roles evolve?
Which indicators tell us the organization is improving rather than simply producing more?
And perhaps the most important:
How do we increase agent autonomy without decreasing human accountability?
Not every organization is ready for the same level of autonomy.
And that may be one of the most common mistakes: assuming that adopting a more capable tool automatically means the organization is ready to use all of that capability.
Agent maturity and organizational maturity are not the same thing.
The Y Test
There is a simple test I like because it brings us back to where we started.
The next time someone approves an action proposed by an agent, mentally remove the agent from the conversation and ask:
Can you explain what you just approved and why?
Not line by line.
Not from memory.
But clearly enough to defend the decision as a professional.
What changed?
Why?
What are the consequences?
What can go wrong?
How do you know it works?
If the person accountable for the change cannot answer, then we probably did not have meaningful human-in-the-loop oversight.
We just had a human pressing Y.
Agents should do more work.
Much more.
That is a large part of the opportunity in front of us.
The future of software engineering cannot depend on humans manually writing every line of code.
But it should not become humans blindly approving every line written by machines either.
The organizations that navigate this transition well will be capable of delegating increasingly more execution without surrendering understanding, judgment and accountability.
Because the competitive advantage probably will not come from having access to the best agent.
Access to extraordinarily capable agents will quickly stop being a differentiator.
The difference will be less visible:
how prepared the organization is to use them.
Perhaps the next conversation about AI adoption should not begin with:
“Which agent should we buy?”
Perhaps it should begin with something more uncomfortable:
Who is pressing Y, and do they actually know why?