A16z just published on the State of AI and one of their points is “ideas used to be too big, now they are too small”. While this seems obvious to me, some of the leaders speak with still cannot “see” it. I explain to them that what AI is doing to product and engineering is not merely scaling productivity and shortening development and feedback cycles, it is doing so by orders of magnitude unprecedented in human history.
My work includes exploring ways accelerate ways to solve complex problems with AI. With AI, this increasingly means building custom applications from scratch to solve a very particular problem, within local, secure environments. When giving these demos and describing the process, what AI is capable of building, and the trajectory of product design, development, and feedback loops, I watch the eyes of the leaders to see who understands what is actually happening. Some ask questions, some poke holes, but some understand that the paradigm shift that is happening - traditional constraints are evaporating and making the previously unthinkable possible.
The studies coming out of McKinsey, Google, and others show that those that see AI as cost-cutting operational efficiency are struggling while those that see AI as scalable opportunity are capturing the value. AI is sorting leaders into those who can see what has become possible and those who are still evaluating tools. The difference is not talent. It is a practice, and it can be built. Seeing is not a personality trait, and it does not correlate with technical fluency. I have watched deeply technical leaders miss it completely and non-technical operators catch it in a sentence. Once one sees the shift, it opens entirely new worlds of possibility. It requires new questions and one is “what did we rule out that we should now reconsider?”
Vanishing Constraints
The question most organizations are asking is a productivity question: how much faster are our developers with AI? It has generated an impressive amount of measurement. Pull request counts, acceptance rates, self-reported time savings, the share of the codebase now machine-written. Every one of those metrics describes the same thing. How efficiently we execute work we had already decided to do. The more consequential question sits upstream of all of it: what is now worth building that was not worth building eighteen months ago, and is anything in our operating model designed to notice?
Here is the thesis. The constraint on ambitious projects was rarely imagination. It was the cost of being wrong. AI-augmented software engineering has lowered that cost unevenly across the portfolio, which means a specific set of previously unthinkable projects has already crossed the viability line while our judgment about them stayed frozen at the old threshold.
The mechanism
Every build decision, formal or not, resolves three variables.
Cost to build. Engineering hours against expected return.
Cost of being wrong. What we lose if the assumption underneath the project fails: sunk build, opportunity cost, reputational exposure, a production incident.
Time to learn. How long before reality tells us which it was.
AI-augmented software engineering compresses all three, but not equally, and the unevenness is the whole story. Google Cloud’s DORA team modeled the return for a 500-person engineering organization in ROI of AI-Assisted Software Development, published in May: roughly 39% first-year return, payback in about eight months. Underneath that headline sits the more useful finding. Productivity gains of 35 to 40% on straightforward work, and 10% or less on complex legacy code. Same tool, radically different return depending on where you point it.
That asymmetry is a map. Categories where the dominant cost was writing net-new code have moved a long way. Categories where the dominant cost was understanding an existing system have moved less than the vendors imply, though they have moved in a direction that matters more than speed.
These gains are real and having a direct impact on leaders thinking about the build vs. buy question. The McKinsey 2026 State of AI report says that “Nearly a third of respondents (32 percent) report that their organizations have decided against buying one or more software products or features because they could be built internally with agentic coding tools.” For high performing companies that number is 50%.
Six categories that just became thinkable
1. Markets too small to serve. The economics of custom work have always ruled out the long tail: the segment of 400 customers with a workflow nobody would build for. When the marginal cost of a variant falls far enough, “too small to serve” becomes an artifact of an old cost structure rather than a fact about the market. Watch for competitors arriving underneath you at price points that used to be impossible.
2. Products too uncertain to fund. Sequential bets are a rational response to expensive builds. You fund one thing, learn, then fund the next. When the build is cheap and fast, a portfolio can shift from few and sequential to many and parallel. McKinsey’s business-building research found the time for new corporate ventures to reach meaningful revenue fell from 38 months in 2023 to 31 months in 2025. In a venture portfolio that is not a rounding error. It is a different asset class.
3. Questions too expensive to ask. The most underrated shift is in customer testing. For thirty years we validated with decks, surveys, and clickable prototypes because working software was too expensive to throw away. It no longer is. The unit of customer research can now be a functioning system, used by real customers on real data, and discarded on Friday. Organizations still testing opinions against opinions are leaving the largest available advantage on the table.
4. Systems too dangerous to touch. Legacy modernization has failed for decades for a reason that is not technical: nobody knows what the system does. Documentation rotted, the authors retired, and the risk of an incomplete migration exceeded the cost of continued maintenance. The real change here is not machine-written code. It is machine-assisted comprehension, the ability to reconstruct behavior, dependencies, and business rules from a codebase no living person can read end to end. That changes the risk math on migrations that were permanently deferred. It also carries DORA’s warning label, because this is precisely the complex-legacy category where measured gains are smallest and the temptation to overclaim is largest.
5. Services too labor-heavy to productize. PitchBook’s Q1 2026 analyst note argues that software is shifting from selling seats to selling outcomes: from a product that helps a person work, to a system that performs the work. Sit with the structural consequence. Software spend stops competing with the IT budget and starts competing with payroll. Every service line inside your business that was too labor-dependent to package is now a candidate. So is every service line you currently sell.
6. Internal work too small to justify. The quietest category and possibly the largest. Every organization runs on manual workflows that would cost $40,000 to automate and save $30,000 a year. They never get built, and the accumulated drag is enormous. That threshold has moved. Most companies have no mechanism for surfacing sub-threshold work, because for thirty years there was no reason to build one.
What leaders should actually be watching
Four changes matter more than the tooling decisions consuming most technology agendas right now.
The bottleneck has moved. Yuval Harari describes the shift in constraints in a recent talk: “in a world where intelligence has become very cheap, abundant, you can solve anything. What’s the bottleneck? The bottleneck becomes the question, okay, what do I want to solve? “ This connects directly to real operating shifts in product development. CloudBees’ 2026 State of Code Abundance, a survey of more than 200 enterprise technology leaders, reports that AI now writes or assists 61% of the average enterprise codebase. In the same population, 81% saw increased production issues tied to that code, while 92% remained confident in their production readiness. Writing code is no longer the constraint. Reviewing, testing, governing, and deciding what to build are. Speed up the one part of the system that was never the limiting factor and you convert a code shortage into a review shortage, then call it progress.
Decision latency is now the binding constraint. If a working prototype takes two weeks and funding approval takes eleven, your product cycle is a governance artifact rather than an engineering one. This is the change most likely to be missed, because no dashboard measures it and no function owns it. The world is faster and requires the breaking down of archaic systems (check out Destruction and Creation for some help here).
Unit economics are inverting. Engineering cost has been a headcount problem for forty years: predictable, annual, fixed. It is becoming a consumption problem that is variable, per-task, and hard to attribute. Gartner projects that by 2028 AI coding costs will exceed the average developer’s salary, and notes that token discipline will not arrive through developer choice, because developers optimize for speed. CloudBees found organizations can attribute only about a third of AI spend to a specific business outcome. Both facts point at the same gap, and it is a finance gap before it is a technology one.
Portfolio shape changes before headcount does. The right response to cheap builds is not a smaller engineering organization. It is a different bet structure: more bets, smaller, with kill criteria written before funding. Most governance processes exist to protect large commitments through milestone review. They are the wrong instrument for a portfolio of reversible experiments, and they will strangle the opportunity while looking responsible doing it.
Cultivating the ability to see
This is where the advantage is won or lost, and it is behavioral before it is technical. Four shifts, none of which happen on their own.
From estimating effort to estimating value. Engineering leadership spent a generation getting good at estimating how long things take. That skill is depreciating. The scarce skill is estimating what something is worth and how confident we are in the estimate, and most teams have never been asked to practice it out loud.
From specification as documentation to specification as craft. When execution is abundant, the quality of the intent handed to the system becomes the quality of the output. Spec-driven work is not paperwork. It is the job, and it deserves the scrutiny we used to reserve for architecture review.
From reviewing code to verifying intent. The reviewer’s question changes from is this written correctly to is this the right thing, does it do what the spec claimed, and how would we detect it if it did not. That is a harder skill, taught almost nowhere, and it now sets the throughput of the entire system.
From enthusiasm to calibration. This one deserves some discomfort. METR’s randomized trial of experienced open-source developers found they completed tasks 19% slower with AI assistance, and estimated afterward that they had been 20% faster. A 39-point gap between perception and measurement, in skilled practitioners, on their own work. Self-reported productivity is not productivity. Any transformation program running on enthusiasm as its primary signal is flying on an instrument we know to be wrong.
Seeing clearly and feeling optimistic are different capacities. The organizations that get this right will be the ones whose people can hold a strong hypothesis and a real measurement in the same hand.
How to measure progress
Start by retiring the metrics that feel like progress and are not: lines of code, pull request volume, seat licenses deployed, percentage of code AI-generated, self-reported hours saved. Every one of them can rise while the business gets nothing. That is not hypothetical. It is the reason McKinsey reports 80% of workers report AI productivity gains while only 37% of organizations can find any EBIT contribution at all and that number did not move in the last 12 months.
Measure three things instead.
Decision throughput. Time from idea to a testable artifact in front of a real customer. Hypotheses tested per quarter. The ratio of ideas killed on evidence to ideas killed on opinion, which may be the single most diagnostic number available to you.
Reintegration cost. Change failure rate, rework rate, and review latency, tracked before and after. DORA’s own model shows instability consuming a real share of the modeled return. If velocity is up and change failure rate is up, you have not improved the system. You have moved the cost somewhere your dashboard does not look.
Reactivation. What share of the archive of no has been formally re-examined this year? How much revenue came from work that was not on last year’s roadmap? What is your cost per validated learning, and is it falling?
Then keep one calibration metric: predicted benefit against measured benefit, reviewed in public. It is the cheapest available defense against the METR gap, and the most uncomfortable.
What this means
For technologists, the center of gravity moves upstream. Tool fluency is table stakes within a year. The durable skills are problem framing, specification, verification, and the judgment to say this is not the right thing to build while holding a system that can build almost anything.
For organizations, the work is not tool selection. It is rebuilding the decision layer, how bets get proposed, funded, killed, and counted, so it can operate at the speed the build layer now runs at. Left alone, governance becomes the bottleneck and the returns land on someone else’s income statement.
For markets, expect the competitive threat from an unfamiliar direction. Not the large incumbent, but the small entrant serving a segment your own business case correctly ruled out three years ago.
None of this is predetermined, and none of it is reserved for people with unusual vision. The executive who ends the meeting with a list is not smarter than the one who ends it with an evaluation. She is asking a different question, and it is a question any leadership team can learn to ask on a schedule. A changing world will require a shift in perspective and imagining what’s possible with fewer constraints.
If you want help doing that with rigor: I work with executive teams on exactly this question. What has actually changed, what it means for this business rather than the industry, and whether the organization could act on the answer if it had one. Connect to start the conversation or grab a free AI Readiness Snapshot.