Steve Recks

Author: steve@recks.com

  • The Forecast You Can’t Live On

    I used to wish I could see the future. Now I’m grateful I can’t.

    Look at any decade of your life: even the chapters that turned out well had moments inside them that would have terrified you if you’d been shown them ahead of time. Lived in sequence, with what came before and after, they fit. Handed to you in advance, without that context, they’d have wrecked you.

    I’ve been thinking about that while reading the wave of forecasts on AI and jobs. A recent Economist piece argues AI-driven mass unemployment would be unprecedented in history. New technology has never spread fast enough to put a lot of people out of work for long, and the jobs data right now doesn’t look like the start of a collapse. The economists have a strong case. They probably have it right.

    “Probably” doesn’t help you sleep well at night.

    The country’s job numbers can hold steady while your particular role gets reorganized underneath you. A historical pattern can be reassuring while your specific quarter is rough. A forecast that averages across millions of workers isn’t a plan for the one career you have. Even if you could see exactly how the next twenty years played out, most of the data points along the way would be unsettling without the context of how they resolved.

    Build the practice. Use the tools deliberately. Stay close to the work as it changes shape. Keep the skills that compound regardless of which scenario lands. Those engineers will be fine if the forecast holds and better positioned if it doesn’t. Engineers who wait for the forecast to settle will get clarity—but too late to act on.

    Forecasts are useful for the people running policy. For the rest of us, the work is the same either way.

  • 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 Engineer Behind the Engineering

    May is Mental Health Awareness Month, and seems a great time to talk about the engineer behind the engineering.

    As a software engineer, I patch system vulnerabilities the moment they’re announced. I tune slow queries and refactor legacy code. Yet when it comes to the engineer using all of that, we tend to run untended for years.

    Anxiety, resentment, cynicism, burnout: these affect the work you do as tangibly as a hardware failure. They show up in subtle ways. A nodded-through review. A decision passed up because it wasn’t worth the argument. A bug closed because the energy to chase it wasn’t there.

    The work product carries the operator’s state, whether or not the operator notices.

    When you catch yourself thinking “this is stupid”—about the codebase, the requirement, the meeting, the change—pause. That phrase is a red flag, not insightful analysis. Try a recalibration: “This is challenging, and there’s something here worth learning.” Not fake optimism: a deliberate swap of one thought for another that maps the situation more accurately.

    Reframing is a skill, and like any skill, it can be practiced. The instinct to resist change is human, but change isn’t optional. The work ahead will ask for abstraction, adaptability, and the mental capacity to engage with the unfamiliar. You can’t bring those if your internal monologue is talking too loudly.

    Patch yourself the way you patch your systems.

  • Make Space for Real Thinking

    Several times a day, I’m typing in an AI prompt box before my brain has finished formulating the question. It’s of the quickest habits I’ve ever picked up.

    Hit a confusing error message, paste it in. See a vague requirement, ask for clarification. Feel a bit stuck, “generate me five options.” Connect it to Jira, hand it your next work ticket, and ask for an implementation plan. None of those is wrong, each reasonable in isolation.

    But if you never sit with a problem yourself, you atrophy the mental muscles that are the part of engineering that comes before the answer: the capacity to form a hypothesis before testing it, to feel which option is wrong before you’ve articulated why, to recognize that the actual problem isn’t the one you were asked to solve. None of that comes from prompting. All of it comes from sitting with the problem long enough for your own pattern recognition to fire.

    The model is excellent at giving you answers. It’s structurally weaker at the work that happens before the question is well-formed.

    So, carve out small protected pockets where you reason without the model. Fifteen minutes on a hard problem, alone, before you ask anyone—model or human—to weigh in. Sketch the shape. Try the wrong answer. Notice what doesn’t fit. Then, if you want, hand it to the model: “Here’s where I got. Critique my reasoning.”

    When you bring a half-formed thought to the model, you’re treating it as a collaborator. When you bring a blank prompt, you’re treating it as a script: fill in the blanks, return the output. The second mode produces faster results. The first mode keeps your judgment alive.

    You don’t need to do this all day. You need to do it sometimes, deliberately, on the problems that actually matter.

  • Nobody Has Infinite Hit Points

    In the early 2000s, EverQuest introduced a boss with so many hit points (the game’s measure of health) it was meant to be functionally unkillable.

    The math seemed airtight: no realistic group of players would ever coordinate long enough to chew through the health bar. They’d give up before they made a dent. Nearly two hundred players, fighting for almost three hours in a coordinated attack, proved the assumption wrong. The “unkillable” boss died.

    The lesson shows up in systems engineering. At internet scale, “one in a billion” stops being hypothetical. With enough traffic and enough time, tail risks become real incidents.

    The same thing happens with people.

    From a distance, some people look invulnerable. Calm, reliable, always “fine,” laughing along when the team piles on. It’s easy to treat them like they have infinite hit points. They can take it.

    Then one day they don’t. Someone burns out. Someone quits without warning. Someone has an out-of-character reaction and everyone says, “I thought they were fine.”

    Nobody has infinite hit points. Not the rock on your team, not the most stoic manager, not you.

    As AI tools make it easier to look fine—ship more, respond faster, always online—capacity gets harder for others to see and harder to track in yourself. The visible signal stays bright while the meter drops.

    You don’t have a health bar. You have warning signs. Am I more irritable than usual? Am I rubber-stamping changes I don’t fully understand? Am I avoiding conversations because I feel overloaded? Each one is a reading you can take, if you stop long enough to look.

    This works in two directions. For others: be careful what you pile on people because they can take it. For yourself: be honest about your own capacity before it runs out.

    In games, you step away from the fight and let your health regenerate. In real life, that’s sleep, a walk, a conversation that isn’t about work. None of it counts as productivity. All of it counts as capacity.

    There is no badge for enduring alone.

  • 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.

  • The Cost of Coaching

    AI is supposed to make the work easier. The data so far says it isn’t.

    A February Harvard Business Review piece by UC Berkeley researchers, based on an eight-month study at a tech company, found AI intensifies the work rather than reducing it: employees took on more tasks, filled former breaks with prompting, and extended work into more hours of the day. Boston Consulting Group coined a phrase for the cognitive cost, “AI brain fry,” with self-reported productivity dropping for people running four or more AI tools at once.

    The hours are only part of it. The shape of the work has changed in a way that hits harder.

    The tools compress the mechanical part. What’s left is the part only you can do: judgment, verification, deciding what’s actually safe to ship. That used to be threaded through hours of typing. Now it’s most of the shift.

    Sustained judgment has a real cost. A 2022 study put participants through six-plus hours of demanding cognitive control tasks and measured glutamate buildup in the part of the brain that does that kind of work. (Glutamate is the chemistry of focused thought — neurons release it when they fire, and the brain has to clear it to keep working.) The high-demand group ended the day with elevated levels and made more impulsive, low-effort choices afterward. The metaphor people reach for is that the fuel runs out. The mechanism is closer to exhaust accumulating in the exact circuits doing the work, and rest is how those circuits clear.

    For AI-augmented engineering, that lands somewhere specific. If you’ve moved up a level — coaching the system, owning the call, defining what good looks like — you’ve moved into the work that runs those circuits hot. Producing 10x the output doesn’t mean working 10x harder, but it does mean a higher ratio of your day is the thing that fatigues fastest.

    The tools are still worth it. But it changes the math on what a sustainable shift looks like, and “just sleep less” is a punchline, not a plan.