Steve Recks

Category: Systems and Tradeoffs

  • Costs You Couldn’t See

    The data center conversation has stopped being abstract.

    From the International Energy Agency’s April 2026 update: global data center electricity demand grew 17% in 2025, more than five times the rate of global electricity overall. In the US, data centers accounted for about half of all new electricity demand last year. Consumption is projected to double globally by 2030.

    The water picture is similar in shape. Bloomberg analysis found that about two-thirds of new data centers built or planned since 2022 are sited in regions already under high water stress. The pressure shows up in local water systems and consumer utility bills before it shows up in any national debate.

    I left these issues out of my book because they deserved more than I could give them in a single chapter. They’re getting harder to leave aside.

    Some of the alarm should be calibrated. New data center deals fell more than 40% between the third and fourth quarters of 2025, and only about a third of announced capacity is actually being built, according to the Information Technology and Innovation Foundation, a tech policy think tank. The pressure on power and water is real, but the scale is showing up smaller than the headline projections suggested. Smaller, not small.

    For engineers, this matters in a specific way. The cost of an AI feature has, for two years, been mostly invisible to the people building with it. The vendor was eating the gap between subscription price and actual compute cost. That subsidy era is ending: Copilot has moved to usage-based billing, and other vendors are walking the same path. The layer below the bill—power, water, regional load—is becoming visible at the same time.

    The trade-offs are happening. The question is whether engineers stay informed enough to make decent choices when they intersect with their work. Choosing a frontier model over a lighter one isn’t only a cost decision now. Caching isn’t only a latency decision. Reaching for an agentic workflow when a static rule would do isn’t only a complexity decision.

    The infrastructure isn’t going away, and neither is the conversation about what it costs. The engineers who have at least a working sense of both sides will make better calls than the ones who don’t.

  • Remediation, Not Resolution

    The wrapper around the model is real engineering, and it can do a lot. There’s still a line it can’t cross: anything that happens inside inference itself.

    Harness engineering, wrapper engineering, context engineering: different names for the same idea. The discipline of designing what surrounds the model—prompts, tools, retrieval, validators, memory features, observability—is where a lot of practical AI value gets produced. Treating it as serious work is overdue.

    But the wrapper sits outside the model. It controls inputs, routes outputs, manages context. It cannot change what happens inside the inference engine. There’s a class of overclaiming in the AI engineering community that blurs that boundary, and the blurring is starting to cost credibility.

    A few examples of how the line gets crossed.

    “Models can remember.” The wrapper is storing selected facts and re-injecting them into context on each call. Useful, not memory.

    “Models can learn.” The model is frozen, and the original training run took months and billions of dollars. What looks like learning is curated re-prompting plus pattern-matching on what got injected. Real learning architectures are being explored in research, but not in the products making the claim.

    “RAG fixes hallucination.” The literature is consistent that RAG mitigates rather than eliminates. The mechanism—the model’s internal weights overriding retrieved context—sits inside inference, where the wrapper can’t reach.

    “Long-context handling is solved.” Recent models have improved markedly on simple retrieval, but multi-hop reasoning across long contexts is still uneven, and “lost in the middle” remains a documented failure mode that wrappers route around rather than remove.

    None of this means harness engineering doesn’t matter. It does. The constraints, the validators, the retrieval pipelines, the budget controls, the observability: that’s all real work, and the gains are real.

    What it means is that the wrapper is remediation, not resolution. Pattern completion at scale resembles reasoning closely enough that it’s genuinely useful. This isn’t autocomplete on steroids. It also isn’t reasoning, and the gap between resemblance and substance is where the wrapper’s reach ends. I spend a lot of my book, Spanning Change, on this distinction. It feels like hair-splitting until you’re trying to debug a system that’s confidently wrong.

    If a wrapper claims to solve memory, learning, hallucination, or long context, ask which one. Then ask how.

  • The Shape of the Work

    I sat down to judge how well Claude Fable 5 writes code. The code turned out to be the smallest question it raised.

    Last night I gave it an ambitious app idea and a long evening in Claude Code. About an hour describing what I wanted, two hours watching it work, and a final hour sorting out what it had actually built. I expected a rich, complex application. What I got was an elegant, stable MVP: it had scoped that idea down on its own, a reasonable first move and a judgment call I met after the fact.

    Ethan Mollick published a piece this week describing the same shift. His old metaphor for working with AI was a wizard casting a spell. With this model he feels more like a patron: he sets the direction, pays for the work, and judges what comes back. I had read him before I got access and went in to check it, heavy on specifics where he stayed open-ended, and landed in the same place. My little experiment last night didn’t prove anything broader.

    A week ago I wrote about the first wave of AI gains, where teams drain a backlog faster than it refills. Fable sharpens that picture rather than changing it. It did in a multi-hour session what would take a person days, and I have no doubt it is a large productivity gain. The shape of the work is the part that is new.

    We spent twenty years learning to make work small, and those years wishing our tools could take on more. Agents like Devin enlarged the unit, but what they hand back is usually still a ticket or a feature. Fable handed back a working application, closer to a waterfall-sized deliverable than a user story.

    The reasons we kept units small still hold: each increment was easy to validate, and short cycles left room for the pivots that show up over weeks as product owners and users react. A model writing the whole thing in a day does not remove those pivots. It turns them into refactors after the fact, and a deliverable you did not watch get built takes more verifying. Those costs are real, but they are an offset, not a reversal: the hours saved dwarf them.

    None of this settles what people do now. Mollick looks at all this and sees a case for more engineers. Others look at the same thing and see a case for fewer. The honest position is that we haven’t settled what role, or roles, humans play in this work on an ongoing basis. These aren’t confident predictions. Working through them shows what the uncertainty looks like, which beats waiting for it to settle.

    Fable surprised me less by how much it did than by how it did it. The shape of this work isn’t done surprising us.

  • Fracking for Ideas

    The first wave of AI productivity gains came from one place: accelerating execution against known work.

    Every team has a backlog: bugs nobody has time for, refactors that keep getting punted, integrations tagged for “next quarter” for three quarters in a row. Output is increasing because the constraint is hands, not ideas. Some of the work has been queued for years. Some of it has been waiting long enough to lose its value entirely.

    Backlogs don’t empty. Business partners keep generating new work: new products, regulatory shifts, competitive pressure all refill the queue. What changes is the relationship between arrival rate and execution rate. When AI-assisted teams can work through new work faster than it arrives, the pump that ran continuously to stay ahead of the flood now runs intermittently. The flow didn’t change. The pump’s capacity did.

    Once execution stops being the bottleneck, what’s missing becomes obvious. Most backlogs are incremental: another column on the report, another tooltip, another preference toggle. None of them ask whether the underlying product is still solving what the customer actually needs. Bolted-on parts let teams defer that question for years. AI lets teams bolt on parts faster than ever, which means the deferral continues faster too—until something breaks.

    What the next phase looks like in practice isn’t subtle. Teams running forced ideation under deadlines that weren’t there before. Customer research compressed into weeks instead of quarters. Strategic bets made with less data because waiting costs more than guessing wrong. Cross-functional debates over product direction that used to happen once a year, now happening monthly.

    There’s a name for this in energy: fracking. When the easy reservoirs are tapped, you don’t stop drilling: you switch to harder techniques that extract under pressure. The gains come slower, cost more, and produce disruption the easy phase didn’t. You don’t have to like fracking for oil or for ideas to accept the prediction. Extracting novel ideas under competitive pressure is coming whether we like it or not, and like its energy counterpart, it’ll be aggressive and produce consequences nowhere near where we expect.

    Two responses are possible from here. One treats AI as a way to do the same work with fewer hands, with productivity gains absorbed into cost reduction. The other treats it as a way to do more ambitious work with the same hands, with productivity gains channeled into work that wasn’t possible before. Both are valid choices, but competitive pressure will favor the more ambitious one.

    The first wave was clearing the queue. The second is harder, costlier, and unevenly distributed. The companies set up for it will pull ahead. The companies hoping it’ll go away will spend the next year arguing it isn’t real.

  • The Subsidy Era is Ending

    On June 1, GitHub Copilot moves to usage-based billing. The era of subsidized AI is ending, and the path most teams have been on is closing with it.

    The change is straightforward in shape. Premium request units are out; token-based billing is in. Each plan includes a monthly allowance of AI Credits, with overage available at API rates. GitHub’s own announcement said the previous model “is no longer sustainable.”

    This isn’t a one-vendor story, but it isn’t every vendor either. The shift is concentrated in subscription-priced coding assistants: tools that, like Copilot, have been billed as flat-rate seats while the actual cost of inference scaled with usage. Anthropic restructured enterprise pricing in April along similar lines: lower seat fees, mandatory consumption commitments, and the removal of long-standing volume discounts. Tools that were already priced against usage from the start, like Devin, aren’t making this transition because they were never on the subsidy. The pattern is specifically about flat-rate subscriptions that obscured cost.

    For the past two years, attractive pricing gave organizations room to adopt at their own pace: pilot, evaluate, expand carefully, or hold back until the tooling matured. The vendor was absorbing the gap between subscription price and actual cost, and that gap was what bought everyone time. The vendor isn’t going to keep absorbing it.

    That leaves teams with two coherent paths.

    The first is concentrated, disciplined deployment. A smaller group of users gets access to the frontier models, doing the kind of high-leverage work that justifies the per-token cost. Heavy use, narrow scope, real output to point at.

    The second is thinner, restrained adoption. Lighter models, tighter prompts, less reliance on agentic workflows that burn tokens fast. Lower ceiling, lower cost, broader access.

    What disappears is the third path: premium tools used casually across the whole team. That was the path most organizations were on by default, and it stops being economically defensible the moment the subsidy ends.

    Neither of the two real paths is wrong. They’re different bets about where the value lives: concentration of capability versus broader access to a smaller capability.

    The two paths aren’t equally risky in every direction, though. In my book, I write about the engineer’s version of this: the temptation to sit out a platform shift and wait for it to settle. History isn’t kind to that bet. Even disruptions much smaller than a general-purpose technology—a change in banking regulation, a shift in retail logistics, a new manufacturing standard—have been enough to redraw which companies still exist and which became case studies. Restraint looks prudent in the moment. The cost shows up later, in markets you didn’t realize you were ceding.

    The pricing isn’t the inflection point. The pricing is the forcing function for a decision teams have been deferring.

  • Where Harness Engineering Earns Its Keep

    Every time an AI agent fails, harness engineering asks a blunt question: what could we encode so this class of mistake can’t happen again?

    That habit is the most distinctive thing I see in this new discipline, and it’s worth unpacking what it actually looks like in practice.

    For anyone who hasn’t run into the term yet, a harness is everything around the model: prompts, constraints, documentation, tools, feedback loops, and architectural rules that shape how an agent behaves. Harness engineering is the discipline of designing all of that deliberately. Strip away the new label and a lot of the mechanics are familiar. Orchestration loops are workflow engines. Sandboxed execution is containers plus capability security. Linter-enforced constraints are evolutionary architecture. Observability for agent runs is SRE practice wearing a new hat. None of it would surprise a senior engineer.

    So where does the rename actually earn its keep? A few places stand out.

    Legibility as a design goal. You’re structuring code, docs, and processes so a probabilistic reasoner can navigate them in one pass. The operational rule is blunt: if the agent can’t see it in context, it effectively doesn’t exist, regardless of whether it lives in Slack, a Google Doc, or someone’s head.

    Context as a first-class resource. What the agent can see, in what order, with what priority directly determines what it will do. Hand it a 1,000-page instruction manual and you crowd out the task itself.

    The compounding loop. When a human teammate keeps making the same kind of mistake, the mature engineering move is to add a lint rule or a CI check, not to send a reminder every Monday. Harness engineering takes that instinct and makes it central. Every time the agent fails, you ask what rule, doc, tool, or test would make that class of failure mechanically hard to repeat, and then you encode it. Each fix compounds across every future agent run. Treating each failure as a gap in the environment rather than a gap in the model is, I think, the working habit most worth adopting from this discipline.

    What stands out to me is the inversion of the job: you’re writing less of the code and more of the constraints, feedback loops, and legibility that govern the thing writing the code. That’s the piece the rename actually captures.

    Curious whether others are noticing this shift in their own work. When your agent-assisted workflow gets better, is it mostly from better prompts, or mostly from better everything-around-the-prompts?

  • The Wrapper Grows Up: On Harness Engineering

    Please tell me I’m not the only one who stopped, re-read, and squinted a little the first time “harness engineering” showed up in my feed.

    New vocabulary is a constant in generative AI. Some terms name something genuinely new. Others look like little more than a fresh coat of paint on an old wall. Most of the time, they sit in the middle: familiar engineering practice underneath, with a real AI-specific twist that earns the rename.

    At a high level, a harness is everything around the model: the prompts, constraints, documentation, tools, feedback loops, observability, and architectural rules that shape how an AI agent actually behaves. Harness engineering is the discipline of designing all of that deliberately, because in agent work the environment around the model is often doing more of the heavy lifting than the model itself. (I’ve tended to describe this same layer as the “wrapper” around the base model. A harness is that idea with sharper edges for agent-era work.)

    A recent example made the point concrete: LangChain moved a coding agent from the Top 30 to the Top 5 on a standard benchmark without swapping the model. They just rebuilt the harness. That’s a bigger lever than most of us were giving this stuff credit for, and a useful reminder that even if frontier models plateaued tomorrow, the tooling and infrastructure wrapped around them would keep producing real gains for years. That is, on the nose, how general-purpose technologies tend to work.

    The practical implication: a good harness is what turns additional compute and tokens into real outcomes. That changes what’s worth investing in at the architecture level, and where the next round of real differentiation between teams is going to come from.

    Is harness engineering showing up as real discipline on your teams yet, or is it still mostly breakroom and online chatter?

  • A One-Page Spec: How You Keep Good Thinking From Evaporating

    The most expensive part of AI-assisted work is not the first draft.

    It’s the second Tuesday.

    You have a great working session. The model helps you explore options, sketch a design, generate a starter implementation. You feel momentum.

    Then time passes. Context evaporates. Someone asks, “Why did we do it this way?” and you realize the reasoning never made it out of the chat.

    That’s wherea lightweight one-page spec earns its keep.

    Not a 12-page design doc. Not process theater.

    This one-page artifact captures the minimum needed for continuity:

    • Purpose: what problem we’re actually solving
    • Constraints: performance, security, interfaces, deadlines
    • Decisions: what we chose and what we rejected
    • Acceptance criteria: how we’ll know it’s done
    • Risks / unknowns: what could bite us later

    If you’re using AI as a thinking partner, a spec is how you keep authorship.

    It turns a productive session into a durable decision.

    Without it, you don’t have a design.

    You have a vibe.

  • Context Windows Explained (Without the Math)

    People talk about context windows like they’re mystical. Measured in tokens. Measured in miles. Measured like horsepower.

    Bigger is better, right?

    The important part isn’t the number.

    It’s the constraint.

    A context window is simply how much the model can hold in working memory at once.

    Think of it like your own working memory: you can juggle a handful of thoughts, but you can’t keep the entire encyclopedia active at the same time.

    LLMs work the same way.

    They don’t “know” everything at once. They load what’s relevant, then reason from that slice.

    And when the window fills, something has to go.

    Not because the model is weak, but because reasoning requires focus. Breadth dilutes clarity. Detail competes with detail.

    The real skill isn’t feeding everything in.

    It’s deciding what belongs inside the window.

    When you treat context as a budget, a few things change immediately:

    • Prompts become architecture, not requests
    • Relevance becomes a performance feature
    • Retrieval becomes your external memory

    The tool didn’t get smarter when you pasted more in.

    You got smarter when you chose what mattered.