Stephen Poletto

Is batched deployment making a comeback? (Just like waterfall, er, spec-driven development?) An engineering leader told me his team's CI/CD bill shot up after they adopted agents. Engineers relied on the pipeline to check both their own changes and the agents' changes, and build costs rose with it. Then, after a talk I gave, someone who works on the developer platform at a big tech company told me they're discussing batching changes again. That means bundling 10, 20, or 30 changes into a single build because CI can't keep up. My first reaction was that this is a step backward. We spent a decade moving from batch releases to continuous integration. But continuous integration won because automated tests made fast feedback possible. It assumes a certain volume of changes, and that assumption is breaking. At scale, the problem isn't only build cost. Rolling out to tens of thousands of servers can take hours. Ship enough changes and a user can hit a different version of your product on back-to-back page loads. Batching may be what keeps the experience consistent. If agents are writing more code, the question changes from "how fast can we write it?" to "how fast can we check it and ship it?" How are you evolving CI/CD in the agentic era?

For decades we’ve talked about the “10x engineer.” And for decades, it’s mostly been a myth. Sure, great engineers were better. They had sharper judgment, made fewer wrong turns, and wrote cleaner systems. But everyone hit the same ceiling: there are only so many hours in a day, and one person can only type, review, and hold so much in their head. The “10x engineer” was usually a 2–3x engineer plus a lot of folklore. That ceiling is gone. With AI, the bottleneck isn’t how fast you write code anymore. It’s knowing: → what’s actually worth building → how to break a problem down → what “good” looks like → when the AI is confidently wrong An engineer who has that judgment, and the drive to use it, can now run several workstreams in parallel, prototype multiple approaches before lunch, and ship in a day what used to take a sprint. AI is an amplifier. Amplifiers don’t shrink the gap between people. They make it bigger. The 10x engineer is finally real. The question for every engineering leader is whether you know who they are on your team, and how you’re hiring for it going forward. Agree or disagree? 👇

What are you assuming your engineers know that they don’t? An engineering leader at a large consumer tech company told me he was shocked by shadowing some engineers recently. Three engineers had been working together for 20 minutes. The agent kept doing dumb things, and they were getting frustrated. He asked one of them to share his screen. Within seconds he spotted: → A weaker model selected → Thinking effort at the lowest setting → A personal account instead of the company's enterprise plan, which explained the model choice Nobody had checked the model picker. He then shadowed a different team. One engineer wanted the agent to QA its own work and didn't know the tool had a built-in browser. Another didn't know you could steer the agent while it was still responding. Would you have thought to ask these questions in a survey? Probably not. Two lessons for anyone running AI enablement: 1. Watch people work. A 15-minute screen share teaches you more than an adoption dashboard or a self-reported survey. The gaps are in places you'd never think to look. 2. Teach the "obvious" stuff out loud. Your power users have a curse of knowledge. Features they stopped noticing months ago are brand new to a big part of your org. By the way, collecting agent traces (which Span does!) can also help you spot these types of issues. Let’s chat if that’s interesting to you!

What does the most AI-native engineer's desk look like? I got a glimpse this week. One engineer at a large tech company has stopped using a keyboard and mouse entirely. Instead: a Stream Deck with up to 32 agent sessions mapped to its keys, plus a microphone. Each key's icon shows whether that agent is thinking, executing, or needs a human. When one needs input, they tap it, read the output, talk back, and move to the next. All day. This re-enforces a pattern we’ve seen at Span - the most productive engineers are highly effective at parallelizing multiple streams of work. They have an ability to make good decisions quickly. Are any of your engineers working this way?

What does a healthy engineering culture look like when everyone has an AI agent? I asked an engineering leader I respect how he'd asses a team he was about to inherit. He gave me three questions: 1. How differently do people use AI? Some engineers have sophisticated workflows and others barely touch it. That gap tells you where to start. 2. How good is what comes out? This isn't about how much code gets written. It's about whether the product works. Customers don't care whether an agent wrote it. 3. Are people learning from each other? Or has everyone retreated into a private conversation with their agent? The third question is where I see things go wrong most often. In a lot of the organizations I talk to, engineers have stopped talking to each other and started talking to their agents. Velocity looks great this quarter. But the team loses the debate, the shared understanding, and the water-cooler ideas that make it good and fun to be on the team. Here's what healthy looks like on the teams I've seen get this right: → Every code review comment becomes a lesson for the whole system, such as a lint rule, an automated check, or a shared markdown file, rather than a one-off fix. → There's a shared knowledge base that people and agents actually use. → Engineers still own the judgment calls. Engineers want to stay engineers. Take that away and you lose more than their sense of identity: you lose people who understand the system from end to end. → AI workflows are visible, so good practices spread instead of living on one person's laptop. AI should make your team smarter together, not just faster on their own.

Ramp, Stripe, Harvey, and Shopify have all moved development work off their laptops. Why can’t you? Agents that pick up a task from Slack, a Linear ticket, or a failing CI run, work in a cloud sandbox, and come back with a PR. All while you’re in a meeting, asleep, or working on something else. To me, this is the logical next step of the AI coding journey: from suggestions → to pair-programming → to asynchronous delegation. I’ve been surprised by how many companies have decided to build this themselves. Why not buy it? 1. Avoiding vendor lock-in. The best model for a given task (and its price) changes every few months. Teams want the optionality to route work to whichever model wins on quality or cost, and the last few months (SpaceX buying Cursor, then OpenAI moving to pull its models from it) showed what happens when you can’t. 2. Deep integration with internal tools and systems, including tons of intellectual property. 3. Keeping code and credentials away from third parties. But many orgs don’t have the in-house team to build and maintain this layer. An architect at a large consumer tech company put it this way: “These agents are like contractors we’re bringing on board. We’ll be dumping tons of intellectual property into them, and building a lot of IP into the processes through which we work with them. That creates a tremendous amount of stickiness, and it erodes our pricing power. But honestly, the money we’re losing sitting on our hands waiting for the perfect solution probably outweighs what we’d overspend by tying ourselves to one provider, at least for the next year.” I put together a map of the space. What did I miss? Which layer will you build vs. buy?

It’s weird to be at an arm’s length from the greatest wealth creation event in human history, but not participating in it. Some of my close friends and former colleagues are getting very wealthy right now, working at the center of AI. Others are building companies and wondering whether a model provider will wipe them out next quarter. It can feel like you're either making it or standing an arm's length from the people who are. It's hard not to feel FOMO, and I do. But I keep coming back to what the research on money says. Money matters. More income does tend to make life better, and pretending it doesn't is its own kind of privilege. But money can only take so many problems off the table. It can't give you more years. It doesn't decide how you spend your hours, whether you're present with your family, or whether your health holds up. Harvard's study of adult development, which has run for more than 80 years, points to relationships, not net worth, as what matters most. Last year I moved from the Bay Area to Colorado after 15 years. Leaving my community was hard. But now I have seasons, a bit more balance, and a better sense of what normal looks like outside the tech bubble. When I step back, I like my life. I like the work, the people I get to geek out with, and how I spend my days. FOMO tells you someone else's life is the one worth wanting. Most days, I'm learning to answer that I'm happy with mine. Anyone else working through this?

This was a fun conversation at @sfelc_ . Thanks for being an excellent podcast host @grinich! Shared my learnings from working with dozens of engineering teams on what's making some teams more effective with AI.

73% of engineering leaders cite code review as a top pain right now. I've spent countless hours with frontier AI teams understanding how they're navigating the problem. Human review of every line of code is quickly getting replaced by new techniques.

Posting about the new bottleneck is the new bottleneck.

How I AI: Next time you need to write a strategy memo, write it in the style of a WSB DD reddit post. People will actually read it because it's entertaining, and you'll be forced to reduce your thinking into simple terms (not business jargon).

Everyone is talking about graph engineering. In simple terms, it means designing how several specialized AI agents hand work off to each other, instead of making one agent do everything in a single loop. This feels very similar to designing how a team works. Roles and responsibilities, handoffs between functions and teammates. Once you've designed the graph, you implement different sub-agents to do different "jobs" / parts of the workflow. Writing a PRD or a tech spec probably requires frontier intelligence (Opus 5, etc.). Once the tech spec is broken down into granular tickets, a smaller, cheaper model probably works (Sonnet 5, or Haiku 4.5 for the really mechanical stuff). Time for review? If it requires security review, you probably have a dedicated security review agent again using frontier intelligence, or even better, a fine-tuned security focused model. The analogy to team design is almost one to one. The PM does the PRD, the Tech Lead does the tech spec, the L1 new grad implements simple tickets, the security team does sensitive security review. If this is how software is developed in the future, you can pin specific model versions to different sub-agents / nodes in the graph. If you want to, you can run the same task through different "versions" of the graph with different models (A/B test) and eval which hits the cost/quality tradeoff you're comfortable with. Won't this be more powerful than using a model router that has no knowledge of your graph?

I really enjoyed this talk by @zachlloydtweets (starts at 4hrs55min): youtube.com/live/htM02KMNZnk… [1] I agree with his thesis - Software Engineering will become Factory Engineering. I'm seeing this with leading teams across the industry. [2] There's no technical jargon in this talk - it's super approachable for non-technical folks who want to understand how the discipline of software engineering is changing. [3] I love that they're building their factory in the open so you can see what it looks like in practice, even if still in early form.

The AI coding debate is focused too much on model selection - just see all the model router launches this week - Ramp, Cursor, etc. We studied 103 engineering teams and found big levers are also on the dev platform and human side: • +1 pt prompt clarity → ~27% lower token cost per merged AI line • +1 pt environment readiness → ~88% higher turn yield • +1 pt quality stewardship → ~39% fewer review cycles Prompts, environments, and stewardship shape every task and are things you can coach your team to improve today. Full report + a practical field guide below. Would love to hear what matches or contradicts your experience. span.app/research/agent-effe…

Well said. The moat is the memory & harness, not the model. "A company should be able to switch out a 'generalist' model without losing the 'company veteran' expertise built into their learning system. This is the key 'test' of your control and sovereignty in the era ahead."