Steve Recks

Category: Career and Craft

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

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

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

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