Every few months, someone announces that artificial general intelligence is either here, almost here, or waiting in the lobby while legal finishes the paperwork.
I remain unconvinced.
My test is neither philosophical nor especially complicated: AGI is not here until an AI—frontier model or open source—can replace my decision-making in software development.
Notice that I did not say “write my code.” AI can already write a remarkable amount of code. It can build components, draft APIs, find bugs, generate tests, explain unfamiliar repositories, and occasionally produce a solution so elegant that I feel both proud and professionally threatened. It is the most capable development tool I have ever used.
But typing code is not the same as directing software development.
The hard part is rarely producing another thousand lines of TypeScript. The hard part is deciding whether those thousand lines should exist.
The Ticket Is Not the Job
Coding agents perform best when the destination is clear. Give one a repository, a well-bounded issue, acceptance criteria, and a test suite, and it may look astonishingly competent. That is real progress. Benchmarks such as SWE-bench (opens in a new tab) measure exactly this kind of useful work: can an agent resolve a defined issue in an existing codebase?
Real projects are less considerate.
The requirement is incomplete. The customer describes a symptom instead of the problem. Two reasonable architectural choices create very different businesses six months later. A shortcut is either prudent prioritization or the first payment on a catastrophic technical-debt mortgage. Nobody knows which. The test suite is green because nobody wrote the test that matters.
This is where software development becomes decision-making.
A capable technical leader must decide what to build, what not to build, what to postpone, when to simplify, when to redesign, and when to tell everyone—including the founder—that the requested feature is a beautifully articulated mistake.
Current agents can offer options. They can summarize tradeoffs. They can even recommend a path with tremendous confidence, which is useful until you remember that confidence is also available as a formatting choice.
What they do not yet do reliably is own the decision.
Intelligence Lives Between the Instructions
The mythology of autonomous coding often assumes that human intent arrives as a clean specification. In my experience, a clean specification is usually what we produce after doing much of the thinking.
Before that, there is a fog of goals, constraints, intuitions, user complaints, market signals, budget limits, security concerns, and one Slack message from three weeks ago that quietly changes everything.
Human judgment operates inside that mess. We infer what matters. We notice contradictions. We recognize when a request is technically feasible but strategically foolish. We ask the awkward question before spending six weeks answering the wrong one.
AI agents still need much of that ambiguity converted into structure for them. We create the architecture document, define the tickets, establish the permissions, select the tools, provide the context, specify the tests, review the output, and redirect the agent when it wanders into the digital woods.
Then we congratulate it for being autonomous.
That is a little like drawing a racetrack, installing guardrails, choosing the car, filling the tank, programming the route, and declaring the vehicle independently discovered Indianapolis.
A Successful Patch Is Not a Successful Product
Software engineering benchmarks matter, but they are not the same as product responsibility. A benchmark can tell us whether an agent completed a defined task. It cannot fully tell us whether the task should have been undertaken, whether the surrounding system became more fragile, or whether the result will survive contact with customers, attackers, regulators, and the wonderfully destructive creativity of ordinary users.
Research on autonomous task horizons captures part of this gap. METR measures (opens in a new tab) how reliably frontier agents complete tasks of increasing human-equivalent duration. The important word is _reliably_. A system that succeeds half the time on a difficult task may be scientifically impressive and economically valuable. It is not ready to replace the person accountable for production.
In software, the last few percentage points are not decorative. They contain the outage, the exposed credential, the corrupted migration, the silent billing error, and the Friday-night deployment that teaches everyone new vocabulary.
The standard for replacing judgment cannot be “usually impressive.” It must be dependable enough that I can stop shadow-managing the work.
My Practical Test for AGI
I will take claims of AGI seriously when I can give an AI a business objective—not a pre-chewed implementation plan—and it can consistently do the following:
- Determine what problem is actually worth solving.
- Gather missing context and identify conflicting requirements.
- Choose an architecture that fits the product, team, risk, and economics.
- Break the work into sensible stages without being handed the decomposition.
- Change direction when evidence invalidates its original plan.
- Recognize when its own work is wrong, incomplete, insecure, or needlessly complex.
- Decide when the product is ready—and defend that decision after something breaks.
The seventh item is where the robot usually develops an urgent calendar conflict.
This does not require AI to become human, possess consciousness, or complain about meetings. It requires something more operational: sustained, context-aware, self-correcting judgment under uncertainty.
It must not merely execute decisions. It must make good ones.
The Honest Position
None of this is an argument against AI agents. I am building around them because their trajectory is extraordinary. They already compress development cycles, widen what small teams can attempt, and let founders work at a level of technical leverage that would have seemed absurd a few years ago. Open-source models add another important dimension: local control, customization, privacy, and the ability to build without renting every thought from a platform.
But useful is not general. Fast is not autonomous. And producing code is not the same as understanding why the code should exist.
Perhaps my threshold will be crossed sooner than I expect. When it is, I will not recognize AGI because a laboratory publishes a dramatic chart or a model writes a flawless demo in eleven seconds. I will recognize it when I can hand over a consequential software objective, with all its ambiguity and inconvenient reality, and the AI repeatedly makes the decisions I would have made—or better ones I failed to see.
Until then, the agents are brilliant collaborators, tireless implementers, and occasionally very confident interns with root access.
That is transformative.
It is also not AGI.