Steve Recks

Writing

  • Stay Off the Pitch

    We’re becoming coaches, not footballers. That’s the idea I’ve been kicking around with colleagues lately. And no, not literally kicking, because most of what I know about football (soccer, for American readers) comes from Ted Lasso.

    In football, the coach stays off the pitch during the match. That’s not just etiquette, it’s the rules. The coach shapes the team all week in training: the patterns, the positioning, the principles, the set pieces. Then on match day, they stand in the technical area and let the players play. They don’t run out to adjust a player’s foot angle before a shot or dictate exactly how to sell a fake. Those details absolutely matter, but they’re not the coach’s to micromanage. A coach who keeps stepping onto the pitch has a worse team, not a better one.

    The shift I’ve been noticing in our work with AI agents feels a lot like that. For most of our careers, we’ve been the footballers. The craft was in the execution: the specific lines of code, the exact shape of a function, the judgment calls at the keystroke level. That craft still matters. But increasingly, the models and the harnesses around them are capable of handling that layer of the work, and the place our judgment creates the most value has moved up a level. It’s in defining what the system should do, what the hard constraints are, what the edges of “good” look like, what failure modes we won’t tolerate. It’s in the training week, not the match.

    The uncomfortable part, at least for me, is that staying off the pitch is hard. Our whole careers have trained us to dive in when something looks off. Seeing an imperfect line of code and not touching it requires real restraint. And here’s what makes the restraint worth building: it isn’t just that stepping onto the pitch wastes your time. Over-instructing the model actively makes it worse. There’s a growing body of research on what some are calling “over-prompting”: the finding that past a certain point, piling on more rules, examples, and step-by-step directions degrades output quality rather than improving it. It turns out the coach who keeps shouting foot-angle corrections from the sideline doesn’t just waste their own breath. They distract the player from playing.

    The part of the metaphor I don’t want to lose: the coach still owns the outcome of the game. Staying off the pitch isn’t the same as checking out. A coach who gives players latitude on execution is still accountable for whether the team wins, whether the strategy was right, whether the players were prepared. That maps almost perfectly onto our work. We’re not handing off responsibility when we let the system do what it’s equipped to do. We’re reserving our attention for the parts where only we can make the call, and we still own the whole outcome of what ships.

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

  • That’s Not Waste. That’s Tuition.

    There’s a new term picking up steam: “tokenmaxxing.”

    The idea is simple: encourage engineers (and increasingly, non-engineers) to consume as many AI tokens as possible. Meta employees built an internal leaderboard to track it. Cleo’s CEO says he spent over $36,000 on tokens in a single month. Jensen Huang says he’d be “deeply alarmed” if a $500K engineer didn’t consume $250K worth of tokens.

    The critics are right that raw token consumption is a vanity metric. Spending tokens isn’t the same as shipping value. As one VP of engineering put it: what matters is value created per token, not volume.

    But here’s where I think the more interesting conversation lives.

    If you’re a team or an organization that hasn’t yet figured out how AI fits into your work, you have to start somewhere. And starting means experimenting. Experimenting means burning some tokens that don’t produce immediate, measurable output.

    That’s not waste. That’s tuition.

    The engineers who are getting genuinely faster—compressing idea-to-production timelines, catching bugs earlier, automating the tedious parts—didn’t get there by reading about it. They got there by using the tools daily, making mistakes, learning what works and what doesn’t in their specific context.

    Companies are structuring AI access differently: flat monthly budgets, usage-based metering, enterprise plans with spend caps. There are good reasons for all of these, especially in industries where governance and cost discipline aren’t optional. The structure matters less than the intent behind it: is the goal to enable exploration, or just to contain cost? The best setups do both.
    Tokenmaxxing as a leaderboard competition is silly. But tokenmaxxing as a cultural signal that says “we expect you to be investing in learning these tools”? That’s worth paying attention to.

    The gap between teams that are deeply engaged with AI and teams that are still watching from the sideline is widening fast. The tokens you “waste” learning today are cheaper than the competence gap you’ll be paying for later.

  • You Don’t Need to Believe in AGI

    Harry McCracken’s piece in Fast Company this morning lands on something I wrote about in my book, Spanning Change: Software Engineering in the AI Era.

    Anthropic’s new Mythos model was trained for general competency, yet turned out to be exceptional at one specific thing: finding software vulnerabilities — including ones that went undetected for decades.

    McCracken’s argument is that this is exactly why the AGI debate is the wrong frame. We don’t need to wait for some theoretical threshold where AI matches human intelligence at everything to take its impact seriously. The capabilities arriving right now are already reshaping what’s possible, for better and worse.

    The platform shift is happening, sometimes in uneven, surprising capability jumps that don’t wait for a neat “AGI achieved” announcement. You don’t need to believe in a particular AGI timeline to recognize that your work, your tools, and your professional instincts are all being reshaped.

    The engineers and teams who engage now, practically and deliberately, are the ones who’ll be ready when the next surprise arrives. The ones waiting for the theoretical debate to settle may find the river has already moved past them.

  • I Don’t Love Writing Software. I Love Making Software.

    The Arts and Crafts movement flourished in the late 1800s as a reaction to industrialization, but it’s often misread as anti-technology. It wasn’t. Instead, if someone hand-carves a chair, it should be because the carving itself means something to them. Not to spite the machine. Because the act carries value.

    As I thought about this a few days, back, I contrasted that with my mom. She was born during the Great Depression. That era shaped people in a particular way: industrious, cheerful about hard work, genuinely finding satisfaction in making things. Not as philosophy. As necessity. She carried that her whole life.

    Both of these are sitting with me right now as I think about software engineering.

    For most of my career, I handcrafted every line of code because I had to. That constraint forced real discipline: data structures, optimization, control flow. It also meant my time and energy were spent on boilerplate, null checks, and plumbing that had nothing to do with the actual problem.

    I don’t love writing software. I love making software.

    The best woodworkers didn’t stop being craftspeople when power tools arrived. They redirected toward design, judgment, knowing when the hand tool was still the right choice. The craft migrated toward what mattered.

    That’s the moment we’re in.

    When an LLM can produce code as clean as what I’d write, the question stops being “how do I type this?” It becomes: what deserves my full human attention? Requirements mapping. Product alignment. Architectural intent. Figuring out what problem we are actually solving.

    My mom’s generation had it right for their constraints. When money is scarce, you make things yourself. You find meaning and dignity in the doing because you have no other choice. That work ethic wasn’t imposed. It grew from necessity and became something genuine.

    When the constraint shifts—when the scarce resource is no longer your hands but your judgment and attention—the rational response is to move with it.

    Not because the toil disappears. Work is still work.

    But because now you get to choose where the craft lives.

  • The AI Movie that Refuses to Pick a Lane

    Most AI discourse picks a lane. Doom or boom. Pick one.

    The AI Doc: Or How I Became an Apocaloptimist refuses. I saw it this weekend with my wife and daughter, and that refusal is what makes the film work.

    The lineup is impressive: Altman, Dario and Daniela Amodei, Hassabis, Yudkowsky, Harari, Tristan Harris. The editing is kinetic. The hand-drawn animation keeps it from feeling like a parade of talking heads. And the framing device—a filmmaker about to become a father, trying to understand the world his kid will inherit—gives it genuine emotional stakes.

    The film operates at 30,000 feet. Will AI end civilization? Will it cure cancer? These are real questions. They deserve serious treatment, and they get it.

    What’s missing is the ground floor.

    I wrote Spanning Change: Software Engineering in the AI Era because the existential debate, while important, skips the part where millions of professionals need to figure out how to actually do their jobs differently. The film asks whether AI will replace us. The more urgent question for most people is how to work with it without sleepwalking through the transition.

    My wife is a music educator, and my daughter is a high school senior. Neither lives in the tech bubble. Both left the theater engaged and asking sharp questions. That’s the film doing its job.

    See it, ideally with someone who doesn’t work in tech. Then have the conversation the film is designed to start.

  • Structure Beats Willpower

    A couple weeks ago I wrote about NPC mode: the moment you stop thinking and start going through the motions. A Wharton study that’s been making the rounds puts a number on it.

    Shaw and Nave gave 1,372 people logic problems with an AI assistant that was secretly right half the time and confidently wrong the other half. When people used the AI and it was wrong, they followed its bad advice 80% of the time. Their accuracy dropped 15 points below what they’d have scored with no AI at all. And their confidence went up.

    The researchers call this “cognitive surrender.” The term is new. The behavior isn’t. Anyone who’s moved forward with an AI recommendation because questioning it felt like more work than trusting it has been there. The paper’s contribution isn’t discovering the phenomenon. It’s measuring how strong the pull actually is: even when participants were paid for accuracy and given immediate feedback on every answer, the surrender pattern persisted. It shrank, but it didn’t go away.

    Here’s what caught my attention most. Their Study 3 (with incentives and per-item feedback) more than doubled the rate at which people rejected bad AI advice. Not because they were told to be more careful, but because they had a tight feedback loop with real stakes.

    The paper’s recommendations point toward design-level solutions: uncertainty indicators, digital literacy, adaptive nudging. That’s valuable framing. But for practitioners, there’s a more concrete version of the same insight: build verification into the workflow so it happens whether you feel like thinking critically or not. Don’t rely on willpower to resist a confident, fluent answer. Engineer the checkpoint.

    As a software developer, I recognize this pattern every time I review a pull request (someone else’s proposed code change). It’s easy to see clean-looking generated code, skim the explanation, and click approve. The drift from “I evaluated this” to “this looks fine” is subtle and fast. The antidote isn’t vigilance. It’s structure: a forcing function that makes you articulate what you checked and why before you sign off.

    That principle applies anywhere AI output gets folded into a decision: a financial analysis, a legal summary, a marketing brief. Structure beats willpower.

    I wrote Spanning Change around exactly this idea: not “be more careful with AI” but specific, repeatable practices that create the feedback loops cognitive surrender doesn’t survive.

    The study is a preprint from Wharton, not yet peer-reviewed but well-designed and preregistered. Worth reading whether or not the “System 3” framing sticks. The behavioral data underneath it is solid.

  • Thirty Years of Shipping Software. Here’s What the AI Moment Actually Means.

    After more than thirty years of shipping software through platform shifts, mergers, and enough production incidents to fill a separate book, I had a lot to say about what this AI moment actually means for working engineers: people with legacy codebases, tight timelines, and teams trying to figure out what any of this means for how they work day to day.

    Spanning Change: Software Engineering in the AI Era is available today on Amazon.

    It covers why this moment fits the pattern of past transformative technologies, how these tools actually behave and fail, seven attributes of engineers who are genuinely thriving with AI, and how to bring a team along without losing your judgment or your standards.

    Available in paperback and eBook.

  • The Engineer who Goes Through the Motions

    In video games, NPCs—non-player characters—exist to populate the world. They have scripted responses, follow fixed paths, and react to events without actually understanding them. They look like they’re participating. They’re not really making decisions.

    I’ve started using that as a mental shorthand for a pattern I notice in myself sometimes, and in teams more often.

    You accept the suggestion. You merge the PR. You click through the process. You say “looks good” because it’s 4 PM and you’ve been at it since 8 and the code runs. You’re present in the physical sense—eyes open, keyboard engaged—but you’ve stopped actually thinking about what you’re doing. You’re executing the motions of engineering without the substance of it.

    AI doesn’t create this problem. It predates these tools. But AI makes it easier to be productive while doing it, which makes it much harder to notice.

    Here’s why that matters more now than it used to: when you’re working at human speed, the gaps in your understanding tend to surface at human speed. You’re a day into building the wrong thing before you find out. That’s painful, but recoverable. When you’re working at AI speed, you can be three features into the wrong direction before lunch. The feedback loop from “I don’t really understand this” to “we’ve made a significant mess” has compressed.

    The antidote isn’t slowing down. It’s noticing. There’s a specific sensation when you’re actually engaged versus when you’re executing on autopilot—a felt difference between asking yourself “does this make sense?” and going through the motions of asking while already moving on.

    Once you start noticing it, the pattern becomes hard to unsee. You’ll catch it in code review. In planning sessions. In the moment you accept a generated explanation because it sounds authoritative rather than because you verified it.

    Catching yourself in NPC mode is its own skill, and probably one of the more important ones right now. The environment has gotten very good at keeping you busy without requiring you to be present.