Category: Book Notes

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

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

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

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