Hey!

Chris here. Welcome to Blueprint—the newsletter to help you build a winning engineering team.

The way software got built for the last few decades—someone has an idea, a product manager writes it up, it gets scheduled, weeks pass, and eventually a developer receives a version of that idea that's already lost something in transit—that model is dying. I'd go so far as to say it's mostly dead already.

Engineers aren't going with it, though.

The gap between what someone with deep technical understanding can do with these tools and what someone without that background can pull off is significant. And it's not closing.

I've been working through what that means for how I deploy my own team. This week I think I landed on something, and it gave me a whole lot of relief.

Let me explain. 👇

📒 DEEP DIVE

Stop Fixing the Output. Start Fixing the System.

The difference between 1x AI usage and compounding leverage is what you do after the agent gets it wrong.

The 1x Problem

Here's what I told my engineers recently: your job is to refine the system that fixes things and creates features. The thing that handles all of that well, consistently, without anyone having to babysit every step.

To put that into practice, I started giving some of them super admin access to the agents we've built for our clients. A peek into the live infrastructure behind them. I wanted to see how they'd operate with that framing.

Most of them are still in what I'd call phase 1.

Phase 1 looks like this: the agent does something unexpected, the engineer adjusts the prompt, they iterate, they keep nudging until the output is close enough, and then they move on.

That approach has a ceiling. You got the thing done. But the system is no better than it was before.

The shift I'm pushing my team toward is asking why. When the agent misbehaves—when it does something you didn't expect—the question that needs to become automatic is: what in the system caused this, and how do I fix it so it never happens again?

Diagnose it. Fix the root cause. Now the system does the right thing for everyone, every time, without you having to be in the room.

A Concrete Example

One of my engineers added a feature this week. The code worked. But they bypassed the established workflow in the system to move a little faster.

The feature worked fine. The problem was that nothing went into the changelog. And our changelog feeds a pipeline that automatically generates release notes for clients.

Run through the workflow properly, and those release notes are generated automatically—without anyone having to think about it. Go around it, and someone has to reconstruct it manually after the fact.

That's the whole point of building the system right. The work that has to happen correctly every single time—the system should handle all of that. The engineer's job is to make sure it keeps doing that. When someone finds a shortcut that breaks something downstream, they’re responsible for fixing the system so the shortcut isn't possible.

What the Job Is Now

The engineers I want building with me are the ones who look at how people are actually using a system and notice the gaps.

When a client tries to do something and the agent handles it poorly, that's context.

Valuable engineers see that moment and immediately think: Is there a workflow built for this? If there isn't, they use the tool to write one, test it, and move on to the next gap.

Those engineers build the workflow into the system. Make the right things happen automatically. And when they don't—when users hit situations the system doesn't handle well—they fix it.

The goal is that non-technical people—clients and their staff—can sit down and use these agents without waiting on anyone. The environment already understands their business and their systems. They just go.

And the engineers are the ones making sure the whole thing keeps working the way it's supposed to.

Some engineers are going to hear this and not want that life. I understand it—some people came to this work because they love the deep craft of writing code, and this shift feels like a loss.

That's a valid reaction. But the work is changing regardless.

The engineers who adapt to thinking about the system as the product—who care about it working correctly every time, without them needing to be in every instance—are the ones who’ll build what comes next.

BEFORE YOU GO…

The next time an AI agent does something you didn't expect, resist the urge to just fix it in the moment and move on.

Ask why it happened, then go fix the underlying cause in the system.

Do that consistently, and you stop trading hours for outputs and start building something that compounds.

Talk soon,

Chris.