Heads up: this one is for power users. It assumes you already build with coding agents like Claude Code every day and are comfortable with CI, merge queues, and feature flags. If you're earlier in your AI journey, bookmark it for later. The posts in Operate are a better place to start.

Two weeks ago, I changed how I build software. Since then I've merged 562 PRs, and honestly, I spent four of those nights hiking in the mountains.

In the video I walk through exactly how I work now. Below is the written companion: the setup, the prompt, the numbers, and the things to try this week.

If you're still reviewing every line your agent writes, this one's for you.

The whole workflow in four lines

1. Set the intent. Plan with the agent until you agree on what's being built and why.

2. Set the guardrails. Tests, CI, and review bots that an agent can't get around.

3. Set a goal. One session, one coordinator agent, sub-agents doing the work.

4. Let it merge in small pieces. Auto-merge, feature flags, verify, repeat.

What changed

The models changed dramatically in the last few weeks, Opus 5.5 especially. A couple of weeks ago, I wouldn't have told anyone to work this way. I always felt I had to check the work. Is the quality good enough? Should this get merged?

Now I feel an agent can work through a whole plan on its own, as long as two things are set up right: the right intent, and the right guardrails to make sure that intent is actually met. Get those right and you can let it really run.

Most of this work went into Sightline, our internal operations platform at Spare. It's where I try everything first.

Guardrails are the real work now

AI code is non-deterministic and has risk. But human code is non-deterministic too, and it has the exact same risk. We built SRE systems so humans don't make mistakes. Now we need those same systems, way more beefed up, so agents don't make mistakes.

Same blameless culture we use for incidents: when an agent makes a mistake, don't blame the agent. Ask what guardrail was missing, and build that.

This doesn't mean quality stops mattering. Agents make messes too. That's exactly why the guardrails are the job. Here's what every Sightline PR goes through before it can merge:

• Unit tests

• End-to-end tests

• CI, Bugbot, Strix

• Mergify won't let a PR into the merge queue until all of the above pass

So when something's queued, I know it couldn't skip a single red flag.

The guardrails also guard themselves. We ask Bugbot to keep asking for more tests. Those feedback loops in CI are what let us go this fast without risking uptime. And when something slips through, we don't just fix the code. We fix the guardrail.

The workflow, step by step

1. Plan with the agent

Every session starts the same way. I open Claude and work out a plan together: how it's broken up, what the challenges are, what the risks are. I often ask for a UX preview too, so I can see what it'll feel like before anything gets built.

This is where I spend most of my time now. I review the plan, not the code.

2. Set a goal, with the same prompt every time

Once I'm aligned on the plan, I open a session and set a goal. This is the prompt I use, word for word:

Accomplish the plan. Ship code using auto-merge. You're the coordinator. Don't do work directly. Use sub-agents for everything, and parallelize when possible.

3. Keep the coordinator's context clean

The coordinator part helps a lot. The top-level agent only holds the plan and the status, so its context stays clean. Sub-agents do the heavy work and come and go as the plan gets built out.

4. Let it merge, in small pieces

I let it merge on its own, and honestly, it's fairly safe. These models are careful and don't want to break things. Ask them to feature-flag everything and they will. Because they can merge, they ship in small pieces: ship something, run end-to-end tests in staging or production, check that it works, ship the next thing. Multi-stage deploys, small increments.

A bit of a hot take: one big PR you're iterating on locally is probably riskier in the end than twenty small ones that each passed every check.

5. Review progress reports, not diffs

I come back and ask for a progress report. The agent builds an HTML report: what's done, what's next, and what it needs from me. That's what I review.

6. Let it run for days, and run several at once

Here's the part I think most people miss: let goals run overnight, for days if they need to. Our custom roles goal ran for over a day. I checked in periodically, read the report, nudged it when needed, and let it keep going until it actually hit the goal.

I usually have two, three, or four goals running at once, on unrelated features so they don't step on each other. That's what lets us rip through things really fast.

Ask bigger

Most of us still use these tools like a really fast engineer: implement this ticket, add this endpoint. That works, but it's thinking too small. With the goal workflow you can set much higher-level intent, ask open-ended questions, or hand it a whole business problem and let it figure out what needs to happen.

• Instead of "add a role editor," the goal was "make Sightline's permissions work like Spare's everywhere."

• Instead of "move OKRs into a package," it was "turn Sightline into a platform other teams can extend."

You can push it much further:

• "Our CI is too slow. Make it faster." That's it. Let it find where the time goes and fix it.

• "We're seeing low PPVH for one of our enterprise customers. Dig into five days of data and figure out how we can optimize it." That's a real business problem, not a coding task.

• "Our front-end UX is inconsistent across the admin panel. Find the inconsistencies and help us remove them."

Those aren't tickets. They're outcomes. The models are now good enough to take an outcome, break it down, and work toward it for a day or more.

Capacity: tokens become the bottleneck

Once you work like this, tokens become the bottleneck. Individual plans don't give us enough credits anymore, and the overages are super expensive.

What I've been doing is running multiple Claude accounts, about five at around $200 each, and switching between them with a tool called Claude Swap. It watches five-hour and seven-day usage on every account and switches automatically when one hits 90%, so everything keeps running in the background.

It's not perfect. When you switch accounts you lose things like Claude artifacts and remote control from the mobile app, and I'm constantly logging in again in the browser and on my phone. It wastes time. So this week I've been looking at tools that solve the same problem without the switching: Paseo, Orca, Superset, and a few others.

Where this is going

Our job is moving away from shipping individual things. It's moving to building the systems that evolve our product. We set the intent, and we build systems that self-heal toward it.

We're already doing it: automations that fix our bugs, automations for SRE work, agents that do vulnerability research, and early work on remediating those security risks automatically. Next are systems that find poor quality, performance issues in the database and rendering, and inconsistencies in our UIs, and agents that fix them. Agents that find gaps in test coverage and write the tests.

It's not us figuring out each individual thing. It's standing up guardrails that keep healing the system into a better place.

Three things to try this week

1. Stop checking the code on one real feature. Start with something low-risk. As you build confidence, try it on something bigger.

2. Give it a problem, not a ticket. See how far it gets.

3. Look at the surface area you're touching. What guardrail is missing so an agent can't get it wrong? What loop could fix things on its own?

I'd love to hear what's working for you. If you try this, hit reply or drop a comment with what happened. I'll be writing a lot more about how we're building with agents.

Alexey

From the first day I started building Spare, one question has shaped almost everything I do: how do we move faster?

Long before AI, we spent countless hours on it. Many of the changes looked small from the outside. We put all of our code in a single monorepo. We used TypeScript across the entire stack: back end, front end, and mobile. And we deliberately kept our resources tight, so we were forced to prioritize, cut scope, and do the most efficient thing rather than everything at once.

None of these decisions was dramatic on its own. Together, they let a small team move like a much bigger one. Finding efficiency in how we work has been the most important part of my job since day one.

Over 11 years of building Spare, from the first line of code to a post-Series B company, I've seen the same lesson play out again and again: the biggest results rarely come from working harder. They come from leverage.

Leverage beats effort

Effort scales linearly. Work twice as many hours and, on a good day, you get twice as much done. Leverage doesn't work that way. The right system or the right tool can multiply what a person produces by ten or a hundred.

The other default answer is hiring. When a team falls behind, the instinct is to add people. But more people is rarely the clean fix it looks like. Every new person means more management, more complexity, and more places for communication to break down. A bigger team is often harder to work with, not easier, and it rarely gets proportionally more done. That's why I've always looked for ways to make a small team more effective before making it bigger.

Most of my job as a CTO has been finding leverage: deciding what to build and what to buy, designing systems so a small team could support a growing business, and creating the conditions for good people to do their best work. Using one language everywhere meant any engineer could ship across the whole product. Tight constraints meant we spent our hours on what mattered most. Small decisions, outsized returns.

AI is the biggest shift in leverage I've seen

I've lived through cloud, mobile, and the rise of no-code tools. Each one changed what a small team could do. AI is different in scale. For the first time, leverage is available not just to engineers but to anyone who can describe clearly what they want.

A technical founder can now ship in a weekend what used to take a quarter. A non-technical founder can prototype a product, automate operations, and analyze data without waiting on an engineering team. The cost of trying an idea has collapsed.

What most people get wrong

Most of what I read about AI falls into two buckets: hype about what it might do someday, and lists of tools to try this week. Neither helps much.

The founders getting real results aren't the ones with the longest list of subscriptions. They're the ones who rethink how work gets done. They ask which parts of the job only a human should do, and redesign everything else around that. The leverage isn't in the tool. It's in the judgment about where to apply it.

That's also why the line between "technical" and "non-technical" founders matters less every month. What matters now is clear thinking, good taste, and the willingness to experiment.

What The Leveraged Mind will be

This is where I'll share what I'm learning, in three kinds of posts:

• Build: hands-on guides to the tools and workflows that actually work, tested on real projects.

• Operate: strategy for running and scaling a company when AI changes what a small team can do.

• Field Notes: what I'm building and learning in public, including the experiments that fail.

I'll write for both sides of the stack. If you write code, you'll get depth. If you don't, you'll get clarity without the jargon. Either way, I'll be honest about what works, what doesn't, and what's overhyped.

New posts every week, free.

One ask

Hit reply and tell me: what's one thing you wish AI could do for your work right now? I read every response, and your answers will shape what I write next.

If you know a founder who'd find this useful, I'd be grateful if you shared it with them.

Alexey