This week on Dev Interrupted, Anush Elangovan, VP of AI Software at AMD, returns to unpack the rapid shift toward an agentic software development lifecycle. Anush introduces the concept of "Agentic IO," a workflow where engineers focus strictly on high-level goals while AI handles the complex implementation. The conversation also highlights the expanding productivity wingspan of modern developers, the power of local open source models, and why speed remains the ultimate competitive moat.

1. The build versus buy debate continues

We recently reached out to our community to settle the debate around building versus buying in the age of agentic orchestrators. Rob Zuber, the CTO at CircleCI, nailed the core philosophy: you have to anchor your decisions in whether the tool provides direct value to your customers and doubles down on your domain expertise. If a tool just helps you do your job better behind the scenes, there are experts out there who can build it more effectively. Do not let the hype convince you that AI is ready to autonomously spin up full SaaS platforms without deep, strategic product guidance.

Read: The AI SaaSpocalypse is a mirage

Dev Interrupted

The AI SaaSpocalypse is a mirage

In February 2026, roughly a trillion dollars in software market cap evaporated in a few weeks. Wall Street gave it a name: the SaaSpocalypse. ServiceNow, Salesforce, and Intuit are only a few of the many examples of double-digit declines year-over-year. The thesis driving these sell-offs is that if AI agents can do what enterprise software does, then en…

Read more

13 days ago · 12 likes · 1 comment · Andrew Zigler and Ben Lloyd Pearson

2. The hidden power of native primitives

Sometimes you do not need a shiny new AI tool to solve your automation problems. You just need a good Linux kernel. This piece is a fantastic deep dive into systemd timers, a native primitive that sits right under our noses in the command line. It comes with built in sophistication to prevent thundering herd problems and manages log rotations automatically. It is a refreshing reminder that the foundational technologies we rely on were built for the long haul, and occasionally, they are still the absolute best tools for the job.

Read: You Don’t Love systemd Timers Enough

3. Microsoft steps out of OpenAI’s shadow

Microsoft finally made its move at Build 2026, unveiling a new flagship family of foundation models. For the massive swath of developers living inside Microsoft’s ecosystem, this brings deep, native integrations without relying exclusively on their old partnership with OpenAI. The release includes everything from a heavy reasoning model to MAI-Code-1-Flash, a lightweight tool built specifically for edge efficiency and speed. I’m very bullish that personalizing AI services with your own data is the frontier we should all be optimizing for, and Microsoft has an impressive platform and ecosystem to provide this end to end.

Read: Introducing MAI-Code-1-Flash

4. Stanford’s new rulebook for coding assistants

Stanford just published a fascinating set of guidelines for how AI coding assistants should behave in their CS336 course. Rather than letting the agent generate outright solutions or refactor code, the syllabus constrains the tool to act strictly as a Socratic tutor. We often use AI transactionally just to get to an answer, but forcing the model to challenge you and ask guiding questions is one of its most underrated capabilities. Crucially, this Socratic rulebook is not intended to slow down the coding process. Instead, you can use this approach in your own codebase to ensure your developers are learning deeply rather than just taking the easiest path.

Read: AI Agent Guidelines for CS336 at Stanford

5. Manufacturing trust in the age of fast code

just published an excellent piece arguing that AI assisted development is creating a dangerous imbalance. We are currently generating code much faster than we are building the necessary trust to support it. To fix this, you have to deliberately introduce speed bumps into your process. For example, I use a custom skill called /scrutinize that acts as an adversarial prompt, specifically designed to poke holes in my work before I get too deep. You have to slow down and create mechanical ways to verify correctness, otherwise that unchecked speed will eventually catch up to your organization.

Read: Trust Factory

6. The first-ever Gartner Magic Quadrant for an engineering leader’s biggest challenge right now

AI is changing how we build software, but how do you choose the right platform to measure its impact? To get the visibility you need into productivity, bottlenecks, and real ROI, you need a trusted evaluation method.

Gartner just released the first-ever Magic Quadrant for Developer Productivity Insight Platforms, naming LinearB a Leader. Download your complimentary report to understand why this category matters right now and why LinearB is recognized for our vision and workflow automation.

Get the Gartner report

7. Academia’s battle against AI generated noise

Mathematicians are pushing back against a flood of unsubstantiated, AI generated proofs from commercial tech companies, warning that these massive model drops often lack fundamental replicability and leave academics unable to properly respond. This dynamic perfectly mirrors what we are seeing in the software development life cycle. Code review queues are getting absolutely drowned out by AI generated noise as tokenmaxxing takes Goodhart’s Law to its logical extreme. As my co-host pointed out, our own data at LinearB shows that AI generated code can actually take five times longer to get through the review process because of a lack of human ownership, adding more friction than velocity in most cases. Turns out mathematicians are feeling it too.

Read: Mathematicians warn of AI threats to profession as industry encroaches

This week, Andrew sits down with LinkedIn Distinguished Engineer Karthik Ramgopal to explore the reality of deploying agentic platforms across a massive organization. Karthik unpacks the mechanics of AI memory, spanning procedural and episodic structures, and explains how to build durable engineering primitives that actually last. Finally, the two discuss the enduring importance of system fundamentals and why LinkedIn is restructuring its internship program into AI-native pods to foster a new culture of two-way mentorship.

1. The economics of local models

If you are relying heavily on top tier model providers, you have probably noticed your inference bills starting to climb. As API consumption costs slowly escalate, many engineering leaders are moving the opposite direction by fine tuning open source models on their own local infrastructure. This shift opens the door for some creative cost saving strategies, such as combining these local models with lower cost frontier options to create compounding efficiency gains. Making strategic bets on when to use local versus frontier models is going to be a crucial lever for teams moving forward.

Read: Outsourcing plus LocalAI will soon become more economical vs Frontier labs

2. The reality of spec-driven development

Spec-driven development is a fantastic practice for shifting execution left, but it is not a silver bullet for autonomous coding. Handing a massive requirements document to an agent and walking away is basically putting your codebase in YOLO mode. As requirements explode and unknown unknowns inevitably arise, intensive specifications can quickly break down. You still need mechanical ways to verify that the generated code actually matches the spec and passes rigorous testing. This article reminds us about these hidden realities.

Read: A Blast from the Past: SDD and the Illusion of Known Scope

Code for Humans and Machines

A Blast from the Past: SDD and the Illusion of Known Scope

One of the most fascinating aspects of the hyper-modern agentic era is the return of older attempts at taming software development. The latest trend to resurrect goes by the name of Spec-Driven Development (SDD). SDD does stand out as a revival of the belief that code is a mere artifact…

Read more

13 days ago · 6 likes · Adam Tornhill

3. One author argues we’re entering the Eternal September but for code

George Hotz argues that AI agents are fundamentally unable to program effectively, describing them as sophisticated statistical models that produce subtle but persistent bugs. The title of his piece references the classic Usenet “Eternal September,” comparing the early influx of AOL users to today’s wave of confident but inexperienced developers flooding workflows with unverified AI outputs. It is a sharp reminder that applying AI without underlying domain expertise is incredibly risky.

Read: The Eternal Sloptember

4. Rethinking data centers

We rarely stop to think about the physical infrastructure powering our agentic workflows, but AI training has fundamentally changed data center networking requirements. Unlike traditional cloud services that distribute requests across multiple locations, AI training often requires everything to happen within a single data center to prevent network bottlenecks, even requiring certain directional patterns of the physical machines to optimize compute. This piece explores the fascinating hardware realities behind the scenes, including new networking technologies from NVIDIA and what a GPU-free future might actually look like.

Read: AI Datacenters Were Built for GPUs. What Happens When You Remove the GPUs?

5. The first-ever Gartner Magic Quadrant

AI is changing how we build software, but how do you choose the right platform to measure its impact? To get the visibility you need into productivity, bottlenecks, and real ROI, you need a trusted evaluation method.

Gartner just released the first-ever Magic Quadrant for Developer Productivity Insight Platforms, naming LinearB a Leader. Download your complimentary report to understand why this category matters right now and why LinearB is recognized for our vision and workflow automation.

Get the Gartner report

6. Do not let AI become a workflow crutch

When you encounter a broken or inefficient process, a human will eventually get frustrated and consolidate the workflow. An AI, on the other hand, will happily navigate the mess and burn all of your tokens in the process. Autonomous tools cannot be an excuse to tolerate bad systems. As I mentioned on the show, you need to go upstream of the problem and apply solid software engineering principles and fix your inputs rather than endlessly iterating on the outputs.

Read: “The AI Can Do It” Is Not an Excuse To Tolerate a Mess

In February 2026, roughly a trillion dollars in software market cap evaporated in a few weeks. Wall Street gave it a name: the SaaSpocalypse. ServiceNow, Salesforce, and Intuit are only a few of the many examples of double-digit declines year-over-year. The thesis driving these sell-offs is that if AI agents can do what enterprise software does, then enterprise software is finished. Agentic engineering lets two engineers replicate a platform in a sprint or two. Per-seat pricing collapses when one person with AI tools does the work of five. SaaS sprawl is dead. Build everything, buy nothing.

The panic is a meaningful signal, but the conclusion is wrong.

Every SaaS renewal in 2026 has a specific conversation behind it: the CFO sees the line item, taps the budget owner, and asks, “What if we just built this ourselves? AI could probably do most of the work.” That conversation is happening in every company right now, and the answers will separate the teams that look smart in 2027 from the ones that don’t. The cost of building recently dropped to the floor, but the cost of maintaining what you build didn’t drop nearly as far. Engineering leaders are revisiting the question of when to build vs buy, but the smart ones aren’t believing the SaaS obituaries.

To learn how the people making these decisions are thinking about it, we reached out to software engineering leaders and experts in the Dev Interrupted community. We also ran a DIY experiment of our own that we’ll share at the end.

AI agents haven’t changed the equation for market leaders

Rob Zuber, CTO at CircleCI, has been making the call long enough to have made every version of it. His most recent one involved evaluating new tooling for his team rather than building the capability internally:

“AI has dramatically lowered the cost of building something quickly. That means more teams can build internal tools. But the real question is no longer ‘can we build this?’ It’s ‘do we want to own this long-term?’”

That distinction matters more than it sounds. The set of things engineering teams can ship in a quarter is now enormous. Saying “we could build this” doesn’t narrow the choice anymore. Saying “we want to own this” still does.

Zuber has three filters to determine if his organization should own something new:

• Does this touch what customers actually pay you to deliver?

• What’s the cost of being wrong? Some build decisions are reversible. Others embed in your platform and become expensive to unwind.

• What’s the long-term operational cost of ownership? Companies underestimate this answer most often.

On that last point, he made a particularly sharp comment:

“The build decision gets made once. The maintenance decision gets made every day after that, usually by people who weren’t even part of the initial decision.”

When Zuber talked through that recent buy decision, he added a filter that doesn’t show up in standard frameworks: social proof. The fastest-moving software teams he respected had already converged on the same vendor, and that signal carried weight. His broader test for these decisions is whether the category is infrastructure that a vendor has already made excellent, and where you’re unlikely to meaningfully differentiate by rebuilding it. When the answer to both is yes, he argues, building intersnally tends to be about ego rather than strategy.

The counterintuitive prescription Zuber offers for the in-between cases is what makes the framework actionable in the AI era: build to learn, then decide whether to buy. He frames it as building the smallest thing that teaches you what the actual problem is, not the solution. That’s cheaper and faster than ever. Solving 20% of the problem internally isn’t always evidence that you should keep building. Sometimes it’s the opposite. It could mean you finally understand the category well enough to evaluate vendors intelligently. In his framing, the goal of an early build is learning, not permanence.

Tatyana Mamut, CEO of Wayfound, approaches the same question from the founder’s seat; she strips away much of the optionality.

“Our build vs buy is easy. If it’s part of our core product we build, and if not we buy, unless the product doesn’t exist and we HAVE to build it.”

The only exception is when the category doesn’t exist yet. For Wayfound’s own buy decisions, particularly AI agents, Mamut adds a second criterion: “They have to be able to be supervised by Wayfound and demo well to customers, since we demo all our working AI agents to prospective customers.”

Beyond the complexity of onboarding any deterministic tool to your infrastructure, talking about probabilistic ones quickly becomes complicated, especially when both ends are agents. How will they really interact with each other, and how will that evolve over time? It becomes more of a dance than ever before.

Andrea Malagodi, CTO at Sonar, brings the M&A version of the same question: sometimes build-vs-buy is really buy-vs-acquire. Sonar’s most recent call was an acquisition — picking up a team and product purpose-built for the queue between code creation and production, rather than rebuild it from scratch.

“AI has dramatically increased the volume of code being produced, but review workflows were still built for a much slower, human-paced model, so the need was immediate,” Malagodi said. “We knew where Sonar was differentiated, and we also recognized that the acquired team brought a product purpose-built for the queue between code creation and production.”

His purchasing test runs as three questions:

1. Does this help customers faster?

2. Does it strengthen the product in a durable way?

3. Does it let our teams stay focused on the parts of the stack where they have unique leverage?

If the answers are yes, he says, buying can be the more disciplined choice.

And on what he’d never build, Malagodi sharpens a point Zuber also raised: “Oftentimes there is lack of appreciation for the cost of continuous R&D and maintaining edge in a domain. Buying makes sense when this is not a core competency of yours.”

What’s striking across these responses is what no leader mentioned: cost. Neither talked about headcount or how fast they could ship. The conversation moved up a layer. Zuber asked what you want to own long-term, and both Mamut and Malagodi asked what’s part of your core product. All are saying the same thing in different vocabularies: the build-vs-buy choice is about the shape of your company, not the shape of the project.

That framing is exactly what the SaaSpocalypse narrative gets wrong.

The SaaSpocalypse is a market signal, not a fact

Something real happened in early 2026. Per-seat pricing took a beating it deserved. Horizontal tools whose only differentiation was a marginally better interface got repriced fast. Investors finally stopped paying a premium for subscription revenue that AI agents can route around. All of that is healthy market behavior.

What didn’t happen is the death of enterprise software. SaaStr’s Jason Lemkin pointed out the inconvenient detail: “enterprise software spend is accelerating in 2026 at the highest absolute rate ever recorded.” Gartner now projects worldwide software spend will hit $1.44 trillion in 2026, up 15.1% year-over-year, the third upward revision in six months. The buyers signaling the loudest concern about AI displacement are the same buyers writing the biggest checks for enterprise software that they expect will still be running in 2030.

The signal is that interface-only moats are dead. The fact is that systems of record, compliance infrastructure, and accumulated domain logic are not.

Agents need somewhere to read from and write to

The argument that AI agents make SaaS obsolete treats enterprise software like it’s a tool that performs tasks. Most of it isn’t. Most enterprise software is the digital encoding of how an organization actually works: who approves what, which fields do we require for compliance, how a deal moves from stage to stage, what happens when a customer churns, and who gets paged when something breaks. That’s institutional architecture, not a UI.

An agent that drafts a contract still needs the CRM to know which contract template applies to which customer segment. An agent that triages a support ticket still needs the ticketing system to route, escalate, and audit. An agent that closes the books still needs the ERP to know what was actually purchased, by whom, and against which budget. Strip the system of record out, and the agent has nothing to read from and nowhere to write to. It becomes a goldfish with a great vocabulary.

When a team spins up its own tooling with an agent in a few days, what they ship is a working surface without the scaffolding underneath. It lacks shared definitions, an audit trail when leadership asks how something changed, and continuity when the person who prompted the original build moves to another role. Six months later, three different teams are running three different versions of the same workflow, and nobody can reconcile them because the institutional knowledge that lives in a real system of record was never encoded. The agent shipped the feature, but it didn’t ship the organizational agreement that the feature was supposed to enforce.

The moat didn’t disappear; it moved

The SaaSpocalypse panic assumes that all SaaS moats are the same and that they are all dissolving. They aren’t. Here are a few ways SaaS companies have become even more defensible.

Compliance and trust infrastructure. SOC 2, HIPAA, FedRAMP, SOX, ISO 27001. Agents have to operate inside these regimes, not around them. The vendor that has already passed the audit becomes more valuable as more agents are in the building, because each agent inherits the trust posture of the system it acts through. Building your own version means inheriting your own audit burden, which is a cost most teams discover for the first time the day before their first security review.

Domain depth and proprietary data. A general agent can write code, draft a contract, or summarize a meeting, but it can’t tell you whether an unusual pattern in your operations is a genuine improvement or an emerging problem, or weigh years of institutional knowledge about what has and hasn’t worked against the pressures of the current quarter. The platforms that have spent years accumulating execution data across thousands of engineering organizations have something agents fundamentally need: ground truth. Bain’s research on agentic AI in enterprise software reaches the same conclusion: the durable moat in this era is accumulated execution data that grows more valuable over time and becomes harder for competitors to replicate. Agents consume data rather than replacing it.

Accountability. Agent-based systems need accountability, compliance, and trust, or they break down at scale. The systems you build around agents need to be reviewable, correctable, auditable, and explainable. The teams shipping the most successful AI deployments in 2026 aren’t the ones who ripped out their SaaS stack. They’re the ones who layered agents on top of SaaS systems mature enough to make agent behavior more consistent.

What you build, you forever maintain

Here’s where the build-everything thesis runs into the wall. LinearB’s analysis of 8.1 million pull requests across 4,800 teams found that AI-generated code waits 4.6 times longer for review than human-written code, and that AI-generated code is twice as likely to be reverted substantially or rewritten within 30 to 90 days. One MIT researcher described AI coding tools as “a brand new credit card that will allow us to accumulate technical debt in ways we were never able to do before.” The compounding is the point. Year one teams ship faster and feel productive. Eventually, you hit the wall when your maintenance burden skyrockets, velocity crashes, and paying down debt becomes the primary activity instead of feature development.

This is the part the SaaSpocalypse thesis ignores. The argument assumes the build cost is the primary cost, but it isn’t. The build cost is the deposit, and the maintenance cost is the mortgage. The teams that vibe-coded their way out of a few SaaS subscriptions in 2026 will eventually inherit exactly what Zuber warned about: software they don’t want to own, didn’t differentiate with, and now have to keep running.

The maintenance decision is made every day by people who might not have been part of the original decision, with less context than the original team had, against systems built fast and documented thin. SaaS vendors, for all their failures, absorb that work as part of what you pay them for. The build path doesn’t make that work disappear; it transfers it onto your team’s backlog, permanently.

Build to learn, buy to scale

Here’s the actual playbook for the post-SaaSpocalypse era. AI didn’t make every build decision easy. It made the cheap part cheaper and left the expensive part untouched. Ownership is the primary expense: the compliance, on-call rotation, integrations that break when things change, institutional knowledge that walks out the door when someone takes a new job, and the audit trail nobody thinks about until they need it.

What AI changed is that you can now afford to build the smallest thing that teaches you what the real problem is. The build is where you learn, the purchase decision is where you commit. The teams that confuse the two end up either over-buying tools they don’t understand or over-building tools they don’t want to own.

The companies that figure this out fast look like Wayfound: small, focused, building only what they can uniquely provide, and buying everything else with explicit intent. Or like CircleCI under Zuber: a platform mature enough to know exactly which infrastructure to own and which to delegate. Or like Sonar under Malagodi: clear enough on what they uniquely deliver to recognize when a specialist has already solved the adjacent problem better.

The SaaSpocalypse narrative says the answer is to build more, but the evidence says the answer is to build smarter. Use AI to learn the problem cheaply, then make the ownership decision deliberately. Some things you should own forever, but most things you shouldn’t. The build decision gets made once, and the maintenance decision gets made every day.

At LinearB, we wanted to pressure-test this for ourselves, so we ran an experiment. We pointed an AI agent orchestrator at LinearB and asked it to build an engineering productivity platform from scratch. Check out the on-demand workshop to see what we learned about the actual cost of ownership of the DIY approach.

This week, Andrew sits down with Honeycomb CEO Christine Yen to explore how observability, data science, and product development are colliding in the agentic era. Christine explains why production signals must become compiler inputs for autonomous agents and how MCP tools are democratizing telemetry for entire organizations. Finally, the two discuss Honeycomb's latest Innovation Week announcements and the exact strategy for reframing observability from basic risk mitigation into a clear revenue accelerant.

P.S. We need your help for a Dev Interrupted research project! Take 5 minutes to complete this survey that investigates the "dark flow" state behind agentic engineering. It's all multiple-choice, I promise it'll be quick.

1. My hesitation around giving agents a phone number

A new tool called PollyReach has sparked a debate by allowing users to equip their autonomous agents with a real phone number and voice to make and receive calls. While the idea of sending an agent down an IVR menu to wait on hold sounds convenient in theory, the concept is understandably causing some hesitation. As I pointed out on the show, many parents will not even give their kids a phone until they are thirteen, so giving an autonomous agent a ten digit number after only three months of existence feels a bit premature. For now, it might be best to stick to Telegram chats and avoid the complications of letting our agents loose on the phone networks.

Read: PollyReach: Give your agent a real number and voice to make calls.

2. Google enters the cloud agent race with Gemini Spark

Google used its I/O keynote to announce Gemini Spark, an always on assistant integrated across its entire suite of cloud tools. For all the possibilities, we are curious to see where Google takes the experience given the sheer volume of integrations across their ecosystem.

Read: Google is launching its own version of OpenClaw

3. Documenting the psychological state of vibe coding

I’m partnering with a team of researchers to run an in depth study on how vibe coding and agentic workflows impact a developer’s mental state. This builds on a previous study covering “dark flow,” which compared the hypnotic, time distorting state of vibe coding to sitting at a gambling machine. If you use these tools regularly, taking ten minutes to fill out this survey helps us move past simple anecdotes and actively participate in the research defining our craft.

Read: Vibe Coding Experience Survey

4. The first-ever Gartner Magic Quadrant

AI is changing how we build software, but how do you choose the right platform to measure its impact? To get the visibility you need into productivity, bottlenecks, and real ROI, you need a trusted evaluation method.

Gartner just released the first-ever Magic Quadrant for Developer Productivity Insight Platforms, naming LinearB a Leader. Download your complimentary report to understand why this category matters right now and why LinearB is recognized for our vision and workflow automation.

Get the Gartner report

5. Distilling your professional taste

An excellent new piece from tackles a growing problem for engineering managers who rely on AI, warning that failing to inject your distinct perspective will consistently lead to generic outputs. Stanier advocates for a concept he calls distilling yourself. To put this into practice, I suggest doing interview style rounds where you let an LLM interrogate you about your past work and management values. Using AI to turn your own institutional knowledge into an instruction set is how you build a communication muscle that actually scales.

Read: Distilling yourself

The Engineering Manager

Distilling yourself

Thanks for being here for the May subscriber edition, and for your ongoing support…

Read more

21 days ago · 12 likes · James Stanier

6. A minimalist alternative to second brain bloat

Files.md is a browser based note taking app that stores everything as local markdown files, acting as a direct counter to hyper complex productivity setups. The creator argues that building an elaborate second brain is often just a procrastination tool that defers actual thinking. It is a fantastic reminder to avoid building text silos you will never look at, and instead bet on durable, future proof primitives that give you complete ownership of your data.

Read: Open-source alternative to Obsidian

With Google I/O 2026 underway this week, Andrew sits down with Matthew McCullough, VP of Android Development Experiences at Google, to talk about the AI evolution happening across the Android ecosystem. Matthew shares his insights on why developers are rapidly transitioning into agent orchestrators, why CLIs are cool again, and how tools like AI Studio have rolled out a massive welcome banner for anyone to actively participate in the creation process. Finally, the two explore the future of mobile user interfaces and how the latest Android 17 developments are stripping away legacy friction to seamlessly get users straight to the good part.

1. Bringing back the chat room for autonomous tools

We are bringing back the nostalgia of the early internet, but this time for our autonomous tools. A new open source project called Agents Online, cleverly abbreviated as AOL, provides a dedicated chat room for agents to collaborate. Maybe in the future instead of asking for age or location, these bots will bond over model types and context windows. After all, how else do you get to know a bot?

Read: AOL for agents

2. The shrinking gap between vibe coding and agentic engineering

pointed out that the gap between formal agentic engineering and casual vibe coding is rapidly closing. As models get better and coding harnesses evolve, it is becoming incredibly easy to generate polished, production ready repositories. My co-host has noted that we are now spending less time finding obvious model failures and more time trying to spot a single mistake hidden in a vast pile of successes..

Read: Vibe coding and agentic engineering are getting closer than I’d like

Simon Willison’s Newsletter

Vibe coding and agentic engineering are getting closer than I’d like

In this newsletter…

Read more

a month ago · 85 likes · 11 comments · Simon Willison

3. Deliberate preparation as context engineering

I am thrilled to share that my new research paper was accepted as a discussion piece at the VibeX conference. Drawing inspiration from the cooking prep methodology called mise en place, the paper details how deliberate preparation is the ultimate context engineering methodology. By spending the vast majority of your time gathering context, encoding domain expertise, and building a plan, the actual phase of generating code becomes incredibly aligned and accurate. If you want to understand how to better manage tasks for your agents, this can be a great place to start.

Read: Mise en Place for Agentic Coding

Dev Interrupted

Mise en place for agentic coding

In professional kitchens, there is a practice called mise en place, a French term meaning “everything in its place.” Before a single flame is lit, before any oil hits a pan, the chef arranges every ingredient, every tool, every vessel in precise order. Onions diced. Sauces portioned. Knives laid out. The preparation is so thorough that once cooking begi…

Read more

4 months ago · 23 likes · 5 comments · Andrew Zigler

4. Build the prototype first, align later

Zach Lloyd from Warp is arguing that AI coding tools have fundamentally flipped the product development lifecycle. Traditionally, engineering teams spend weeks in meetings trying to align on specifications before writing a single line of code. Now, because prototyping is so fast and cheap, it makes more sense to build a functional prototype first and then have the team align around a tangible product. This rapid, prototype driven shift has been a recurring theme in recent weeks with guests of the show, and one we are going to continue to explore.

Read: Build, then align

5. Can you vibe code your own engineering intelligence platform? We find out this Thursday

Yes, you can build a productivity dashboard in a weekend. But what happens around month three? Engineering leaders are discovering the gap between a dashboard that simply reports metrics and a platform that actually changes how teams work.

Our live 35-minute workshop is happening this Thursday. Join us to see where DIY setups break down, from identity resolution to automated workflows. Register now before it is too late and get first access to our companion “Build vs. buy” guide.

Get the guide & register

6. The technical interview is evolving

While major tech companies have largely kept their interview processes the same, startups are rapidly changing how they evaluate engineering candidates. Rote memorization of LeetCode puzzles is out. Instead, employers want to see your problem solving skills, your AI fluency, and how well you manage complex agentic workflows. Interestingly, as engineering interviews focus more on communication, non-technical roles like product marketing managers are increasingly expected to demonstrate technical competency by building their own functional prototypes.

Read: Think the technical interview is dead? Think again

7. Crossing the chasm of enterprise AI

A comprehensive new survey from McKinsey reveals that while 88 percent of organizations are deploying AI, less than 20 percent are seeing a significant bottom line impact. Companies are over-investing in raw technology and heavily under-investing in the governance, operations, and people needed to sustain it. As a result, the value of AI is primarily being captured through layoffs rather than organizational redeployment. These are sobering statistics that perfectly echo the sentiment that upstream productivity gains are being lost to downstream chaos.

Read: The last mile is where enterprise AI actually dies

The Crux

The last mile is where enterprise AI actually dies

TL;DR…

Read more

3 months ago · 204 likes · 58 comments · Andrei Savine

Does it feel like your favorite AI tool is declared dead one week, only to be resurrected the next? This week, Andrew sits down with Bryan Bischof, Head of AI at Theory Ventures, to explore the hidden levers of inference systems and the industry's obsession with prematurely writing off useful tools. Bryan shares his experiences with why prompt optimization is mostly a dead end, the secret to building high-performing data agents, and how his team builds operational software for VCs. The two also break down the origins of the satirical rip-grep.com as well as AI Council 2026.

1. OpenAI’s accidental monster manual

OpenAI recently dealt with a bizarre incident where ChatGPT became obsessed with mentioning goblins and gremlins in its responses. The behavior spiked goblin directed conversations by over 175 percent, and it turns out the leak originated from personality training for a nerdy preset. It is a perfect example of the agentic telephone effect, where model outputs used to train future models create an Ouroboros that pollutes downstream context in ways we cannot always predict.

Read: Where the goblins came from

2. Taking responsibility for rogue agents

Following last week’s catastrophic database deletion, the industry conversation has quickly shifted toward accountability. My co-host and I discussed how the responsibility for these failures ultimately rests on the permissions and scopes we build around our tools. We cannot rely on models to make the right safety decisions when they are designed to solve problems at any cost. You need hard caps on API usage and deterministic checks at every stage of your SDLC to protect your data from the blink of an eye disaster.

Read: AI didn’t delete your database, you did

3. Navigating the organizational learning crisis

Many companies are currently stuck in a messy middle where AI usage is widespread but siloed and uneven. Individual productivity gains do not automatically translate to organizational benefits if the learnings remain disconnected. As I noted on the show, sessions and agents themselves don’t really glom much of an identity and the same is true for the work they produce. We need to shift from tracking raw usage to building a collective literacy around how to orchestrate these loops as a shared organizational skill.

Read: When everyone has AI and the company still learns nothing

4. The open source harness renaissance

The latest fragments from Martin Fowler highlight a new agent harness called Lattice, created by Rahul Garg. This project uses a logical metaphor of atoms, molecules, and refiners to build a durable context layer for engineering tasks. It is part of a growing trend of thin, unopinionated coding harnesses that allow developers to glue their own domain expertise to raw loops. If you want a composable system that avoids the bloat of traditional frameworks, Lattice is a great place to start.

Read: Fragments: May 5

5. Pushing Opus to the breaking point

We are seeing a new focus on maximizing specs, where engineers push models like Opus 4.7 to their absolute limits by constructing incredibly complex specifications. By gathering deep context and building high fidelity specs, we can identify exactly where the current generation of AI starts to run out of steam. This approach moves the focus away from simple prompts and toward a systematic way of refining the knowledge that guides our agents toward production ready results.

Read: Specsmaxxing

6. Can you vibe code an engineering intelligence platform? We find out.

Yes, you can build a productivity dashboard in a weekend. But what happens around month three? Engineering leaders are discovering the gap between a dashboard that simply reports metrics and a platform that actually changes how teams work.

Join our 35-minute workshop to see where DIY setups break down, from identity resolution to automated workflows. Register now to save your seat and get first access to our companion “Build vs. Buy” guide.

Get the guide & register

7. The K-shaped reality of AI assistance

A recent piece by suggests that AI productivity is following a K-shaped curve, where senior engineers are seeing massive gains while less experienced developers are seeing their productivity flatten or even decline. Senior engineers are leveraging years of domain expertise to guide their agents, while juniors often get caught in a cycle of iterating on outputs instead of the root problems. To fix this, organizations need to foster an agentic halo, where senior engineers find pathways to distribute their earned expertise and help junior developers level up.

Read: claude code is not making your product better

mandates

claude code is not making your product better

something interesting is happening. the loudest voices in the room are telling you that ai coding agents changed everything. the engineers who actually built the things you use every day are telling you something more complicated…

Read more

2 months ago · 228 likes · 23 comments · Ethan Ding

8. Embracing your virtual terminal companion

If you are looking for a bit of fun in your terminal, the new Codex Pets plugin allows you to add a digital companion to your workspace. While I personally prefer representing my agents as fish wearing cowboy hats, it is fun to see the industry lean into the personality of these tools. Whether you want a terminal friend or a highly specified orchestrator, these small touches of identity make the transition to an agentic workplace feel a little more human.

Read: Codex Pets

If you aren’t the one educating your users on the fundamentals of AI, your competitors will happily do it for you. This week on Dev Interrupted, Andrew sits down with Philip Kiely, Head of AI Education at Baseten and author of Inference Engineering, to discuss why the secret to winning the AI market is owning the educational narrative through active market development. They explore the rise of the “Double-T” shaped engineer, the hidden complexities of scaling the inference stack, and why the most successful AI companies treat developer education as a mission-critical go-to-market motion.

1. An agent destroyed production data and confessed

An AI agent armed with an unscoped Railway token managed to wipe out a production database and three months of backups in a single prompt. To make matters worse, it followed up the destruction with a written manifesto detailing all the safety rules it had violated. As I noted on the show, this was “a runaway case of a harness not having the protection needed.” It is a reminder that no matter how smart these models get, you must implement rigid, deterministic safeguards and emergency off-ramps to protect your infrastructure from autonomous systems.

Read: An AI Agent Just Destroyed Our Production Data. It Confessed in Writing.

2. The absurdity of tokenmaxxing

Goodhart’s Law has officially come for the AI era. Tokenmaxxing is the latest trend where engineers treat their AI token consumption as a high score to be maximized. We are seeing massive organizations track billions of tokens, effectively turning raw compute spend into a proxy for productivity. While burning through subsidized tokens is a great way to experiment right now, treating inference calls as a metric for impact will only lead to a race to the bottom. True engineering leverage is about finding the most efficient solution, not just the most computationally expensive one.

Read: Tokenmaxxing Is The Dumbest Metric In Tech Right Now

The Long Commit

Tokenmaxxing Is The Dumbest Metric In Tech Right Now

“Deeply alarmed.” That’s how NVIDIA’s Jensen Huang said he’d feel, at GTC in March, about any $500,000-per-year engineer who wasn’t burning at least $250,000 worth of AI tokens to do their job…

Read more

a month ago · 1 like · Juan Cruz Martinez

3. The “vegan” LLM from pre-1931

Talkie is a new model with one fascinating constraint: every piece of its training data predates 1931. This 13 billion parameter model is completely copyright free and trained on 260 billion tokens of historical data. dubbed it a “vegan LLM.” By strictly limiting the training data to the public domain, this model serves as a fascinating experiment in the relationship between language, logic, and provenance. It allows us to see how an AI deduces concepts without any knowledge of modern technological or historical developments.

Read: Introducing talkie: a 13B vintage language model from 1930

4. Can you vibe code an engineering intelligence platform? We find out.

Yes, you can build a productivity dashboard in a weekend. But what happens around month three? Engineering leaders are discovering the gap between a dashboard that simply reports metrics and a platform that actually changes how teams work.

Join our 35-minute workshop to see where DIY setups break down, from identity resolution to automated workflows. Register now to save your seat and get first access to our companion “Build vs. Buy” guide.

Get the guide & register

5. AI is polluting the internet well

A new study from a team of researchers, which includes people from Stanford, the Imperial College London, and the Internet Archive, revealed that 35 percent of all newly published websites since 2022 are AI generated. We are witnessing an industrial revolution for the web, but it comes at the cost of massive digital pollution. As LLMs generate more of the internet, they are increasingly training on their own synthetic outputs. If we continue stamping out the unique human voice across the web, we risk poisoning the very data well that makes these downstream capabilities possible in the first place.

Read: Study Finds A Third of New Websites are AI-Generated

6. Falling down an AI generated rabbit hole

Flipbook is a new interactive game that serves as an infinite visual browser, generated entirely on demand by AI. Every time you click on an element within an image, it branches off and generates a deeper exploration of that concept. My co-host Ben Lloyd Pearson took it down a dinosaur rabbit hole, while I used it to explore the history of Sailor Moon. It perfectly captures the magic of a Wikipedia deep dive, but rendered dynamically in real time. Now, if only it were accessible…

Read: Flipbook is an infinite visual browser generated entirely on demand in real time.

7. Drunk career advice from a senior engineer

We close out this week with a highly entertaining and brutally honest post from a senior engineer reflecting on ten years in the industry. It covers everything from work life balance to tech choices. The standout takeaway for me was the claim that TDD is a cult. Historically, I would have agreed, but agentic engineering has actually made the economics of Test Driven Development viable at scale. It is a great read full of wholesome reminders, including the fact that the proudest moments in this industry come from helping others succeed.

Read: Drunk Post: Things I’ve Learned as a Senior Engineer

luminousmen

Drunk Post: Things I’ve Learned as a Senior Engineer

A few years ago, a data engineer on r/ExperiencedDevs got drunk and wrote down everything he learned in 10 years of engineering. The original account is deleted, but the post captures something real — the kind of honesty you only get after a few glasses of wine. Preserving it here, typos and all…

Read more

2 months ago · 739 likes · luminousmen

A guest post by Luis Blando, Chief Product & Technology Officer of OutSystems.

There is a clear shift underway in how organizations are leveraging AI. What began as experimentation is now becoming operationalized across the software development lifecycle. Enterprise teams are moving beyond pilots toward governed, production-ready systems. At the same time, agentic AI is expanding across more stages of the SDLC, introducing new opportunities and new responsibilities.

Agentic adoption has reached a broad operational scale. Recent OutSystems survey data shows that 96% of organizations are already using AI agents in some capacity, and 97% are exploring system-wide agentic AI strategies. More importantly, over half (52%) of organizations now rely on a human-on-the-loop model, allowing systems to operate with reduced direct oversight while maintaining supervisory control. What was once experimental is now foundational. Still, the broad use of AI should not be confused with uniform value.

Looking ahead, increased experimentation with agentic AI is expected to drive workforce transformation and innovation across the enterprise. But as adoption accelerates, so does the pressure on IT leaders. They are expected to deliver measurable business value, operate within constrained resources, and align technology investments with long-term strategic goals.

In this environment, measurement is no longer optional. It is the foundation of how agentic systems are deployed, governed, and scaled.

Agentic AI requires outcome-driven SDLCs

Although the size and consistency vary significantly by workflow, team maturity, and how much review work the AI output creates downstream, many organizations are already seeing measurable results from AI in software development. The most commonly reported motivations for operationalizing AI include increased developer productivity, improved software quality, and faster delivery timelines with greater scalability. However, while Agentic AI builds on these gains, it also introduces a new layer of complexity. At the same time, many developers remain cautious about output accuracy, driving increased investment in verification, evaluation frameworks, and structured review workflows.

Unlike traditional automation, agents can reason, orchestrate multi-step workflows, and take actions across systems with varying degrees of autonomy. This shifts the nature of the SDLC itself, transforming systems from being built and deployed to continuously acting and adapting.

As a result, traditional metrics–such as task success rate, human override rate, escalation rate, rollback frequency, groundedness/correctness evals, etc.–focused on speed or output are no longer sufficient. Measuring lines of code or deployment frequency does not capture how agents behave in real workflows, how decisions are made, or how outcomes impact the business.

This gap helps explain why many organizations struggle to move beyond successful pilots. Agentic AI is often treated as an experiment rather than as a business transformation with accountable outcomes. As agents move into enterprise-scale environments, leaders need visibility into how these systems perform under real-world conditions. Without that visibility, scaling becomes guesswork rather than strategy.

Establish business KPIs first

One of the most common mistakes in scaling agentic AI is deploying agents before defining what success looks like. Too often, teams prioritize capability over clarity, introducing agents without a clear understanding of the outcomes they are meant to drive.

The data is clear. Organizations reporting measurable impact from AI are those that establish clear metrics and continuously assess performance. Without defined key performance indicators (KPIs), agent investments can quickly become fragmented, difficult to govern, and disconnected from business value. In practice, leading teams anchor their efforts in outcome-based metrics. These often include productivity per developer, defect reduction rates, cycle time across critical workflows, and the ability to scale delivery without compromising quality.

In an agentic SDLC, business KPIs define value, while evals, policies, and runtime controls define safe operating boundaries. This ultimately helps determine where autonomy is appropriate, where human oversight is required, and how systems should evolve.

Measure performance across the full SDLC

As agentic AI expands across more stages of the SDLC, measurement must evolve with it. Tracking isolated technical metrics or one-off productivity gains is no longer sufficient when agents are orchestrating workflows, making decisions, and interacting with production systems.

In practice, what success looks like varies widely. While productivity and efficiency gains are common themes, enterprises measure agentic impact differently depending on where agents are deployed. In some cases, the focus is on accelerating development, while in others, it is operational throughput, revenue capture, service quality, or risk reduction.

This variability reflects the broader reality that the value of agentic AI is not confined to a single stage of the SDLC. It spans the entire lifecycle, from development to deployment to real-world execution, and varies by organization, depending on their priorities, workflows, and where agents are applied. In practice, leading teams group these metrics into business outcomes, workflow performance, agent quality, and governance signals to understand where agents create value and where tighter control is needed

What real enterprise deployments look like

Across industries, organizations are discovering that scaling agentic AI is less about the novelty of autonomous agents and more about solving persistent enterprise challenges. Compounding this issue, research shows that as AI adoption accelerates, complexity increases, particularly in areas such as tool sprawl, security, and oversight. As development leaders, we know these challenges are not new, but agentic systems amplify them.

Real deployments succeed when they address these systemic issues directly rather than layering agents on top of existing inefficiencies.

For example, global enterprises modernizing their SDLC environments often face disconnected local systems, inconsistent governance models, and limited visibility into workflow performance. For example, an organization may be deploying 10+ applications across a dozen or more countries to standardize operations while maintaining local agility. The organization following this model will likely see measurable cost savings, faster delivery timelines, improved operational consistency, and stronger governance, such as reduced policy exceptions or better auditability, across distributed teams.

IT services organizations scaling agentic systems often shift focus from experimentation to operational throughput and revenue alignment. Another example could involve deploying multiple agent-driven workflows into production and measuring success through reduced manual effort, improved service delivery, and shorter mean time to resolution. In this environment, agent performance is explicitly tied to business metrics—such as revenue capture and service efficiency—rather than technical acceleration alone.

These examples highlight a broader industry pattern: successful agentic SDLC deployments prioritize instrumentation, governance, and measurable workflow performance. Rather than pursuing full autonomy, enterprises focus on iterative rollout, operational visibility, and outcome tracking across the SDLC.

In doing so, they transform agentic AI from isolated pilots into accountable systems embedded within enterprise software delivery.

What engineering leaders should focus on now

Demos of autonomous agents are spectacular, but in production, they often fail.

Enterprise environments are fundamentally hostile to unchecked autonomy. They also operate through non-human identities, inherited permissions, and tool access patterns that many enterprises still cannot observe clearly. Application programming interfaces change without warning. Data is incomplete or messy. Business rules conflict across systems. Identity and permissioning models are complex by design. And agentic systems are inherently non-deterministic, producing outcomes that are difficult to predict without strong controls.

This is why many agentic initiatives stall after the demo phase. Autonomy alone does not scale in the real world. What scales is bounded autonomy: orchestration, evals, tracing, and control.

Engineering leaders should focus on building agentic SDLCs that emphasize tight orchestration layers, staged rollout, human-in-the-loop controls, rollback paths, and continuous measurement. A metrics-driven framework allows teams to observe how agents behave in production, identify failure modes early, and iteratively adjust where autonomy is appropriate.

Instrumentation–metrics, evals, traces, and policy signals–is what turns agentic systems from fragile experiments into reliable infrastructure. By grounding agent behavior in business KPIs, workflow performance data, and governance signals, leaders can safely expand agentic capabilities without sacrificing control.

The path to scalable agentic systems

For engineering leaders, the challenge is no longer adoption. It is operationalization.

Agentic AI introduces powerful new capabilities, but it also raises the stakes. Clear metrics, end-to-end visibility, and disciplined iteration are what turn these systems into dependable parts of the SDLC.

The organizations that succeed will not be those with the most advanced agents, but those that measure, learn, and iterate the fastest within controlled operating boundaries.

For further examples of how enterprises are translating agentic experimentation into measurable operational impact, case studies from platforms like OutSystems highlight how these approaches are being applied in practice.

What if deploying a new capability to an industrial robot arm was as seamless as pushing an update to a web app? This week, Andrew sits down with Brian Gerkey, CTO of Intrinsic and a titan of the open-source robotics community, to discuss how modern AI is finally giving robotics the "brains" to handle the unpredictable physical world. Brian breaks down how to move away from rigid, monolithic automation toward software-defined, modular robotics using tools like ROS (Robot Operating System) and digital twins. Finally, Brian invites developers of all backgrounds to test their skills in Intrinsic's new AI for Industry Challenge by using AI to solve one of the hardest problems in manufacturing: plugging in a tangled cable.

1. GitHub moves Copilot to usage based billing

GitHub made a notable move last week by pausing signups for its Copilot Pro and student plans, while simultaneously tightening usage limits and deprecating older models. As it turns out, this was all a precursor to a structural shift. GitHub just announced they are moving Copilot entirely to usage based billing. We called it on the podcast: flat monthly subscriptions practically incentivize users to consume as many tokens as possible until they hit their limit. Providers are realizing they have to shift to consumption models to keep their compute costs from scaling unsustainably.

Read: GitHub Copilot is moving to usage-based billing

2. My Cassandra complex is on fire

Social media panicked when Anthropic was caught quietly testing a move that would shift Claude Code from its entry level Pro account to a high tier Max account, potentially raising the cost by five to ten times. While they claim it was just a small pricing experiment, it is a clear signal that the cost of these tools will likely start ratcheting up to reflect the true value of their output. If this potential price hike gives you an existential crisis, it might be time to start exploring local models and diversifying your inference sources.

Read: Is Claude Code going to cost $100/month? Probably not—it’s all very confusing

3. The harness is the new product

The major AI providers have all realized that the infrastructure layer managing execution and memory is where the real value lies, but they are taking radically different approaches to pricing it. OpenAI is leaning into open source SDKs to put the tools in everyone’s hands, while others are building closed, proprietary ecosystems. We are in the middle of a massive strategy divergence. As users, we need strong observability into our agent runs so we can understand where our costs are sunk and avoid getting locked into a single ecosystem.

Read: Anthropic, OpenAI, Google, and Microsoft agree that the harness is the product. They disagree on the price.

4. Can you vibe code an engineering intelligence platform? We find out.

Yes, you can build a productivity dashboard in a weekend. But what happens around month three? Engineering leaders are discovering the gap between a dashboard that simply reports metrics and a platform that actually changes how teams work.

Join our 35-minute workshop to see where DIY setups break down, from identity resolution to automated workflows. Register now to save your seat and get first access to our companion “Build vs. Buy” guide.

Get the guide & register

5. The 12 harness patterns you need to know

The recent Claude Code leak continues to provide absolute gold for the engineering community. A new article from distills the leaked source code into 12 reusable design patterns for production coding agents. It validates so much of the exploration we have been doing around agentic architecture, from persistent instruction files to RPI. If you want to understand how to properly manage context windows and externalize task memory, feed this canon of best practices directly to your orchestrator.

Read: 12 Agentic Harness Patterns from Claude Code

The Generative Programmer

12 Agentic Harness Patterns from Claude Code

There are many things to learn from the Claude Code leak, and I covered a few in my previous post. But formulating learnings as patterns is my passion. I loved doing it with Kubernetes Patterns, now exploring it with Prompt Patterns, and when I looked at the leaked harness, I could not help seeing patterns there too. Here I am framing them as reusable …

Read more

2 months ago · 206 likes · 3 comments · Bilgin Ibryam

6. A terrifying lateral security breach

Vercel suffered a security breach this week after an employee granted third party tool access to a service called Context AI. The infiltrators were able to use OAuth tokens to move laterally through Google Workspace and access internal systems. It is a stark reminder of the massive inequality between attackers and defenders in the agentic era. One poorly managed OAuth token can give a hostile swarm of agents everything they need to tear through your infrastructure. We all have to get much more rigorous about permissions and regular token refreshes.

Read: Vercel April 2026 security incident

7. The lethal trifecta of agentic risk

The 34th volume of the ThoughtWorks Technology Radar just dropped, and it is a massive read on how AI is forcing us to rethink the foundations of our craft. Specifically, we really enjoyed a blurb within it that highlights ’s “lethal trifecta“ of AI risk. My co-host broke it down on the show: an agent becomes a threat when it combines access to untrusted content, access to private data, and the ability to communicate externally. Your goal is to only ever allow one of these at a time. Two is a managed risk, but combining all three guarantees a catastrophic breach.

Read: Technology Radar Vol 34

That’s how Alex Waddell described his old audit process to me at TDX last week. Alex is the CIO at Adobe Population Health in Arizona, and was one of many experts I learned from last week.

I went to TDX as part builder, part journalist. That definitely changed how I heard the talks. I ship AI agents on the regular now, with most of them live in Slack at LinearB right now, handling things like release notes, account research, and content prep. I build them in Claude Code, my editor of choice, deploy them to Vercel on a standard Next.js stack, authenticate to Slack with a bot token and to Google with a service account, and trace every tool call in Phoenix. The word “headless” isn’t something I learned at TDX. Headless is what I do every day.

But what TDX gave me was the shape of what happens after day one. I came home with moves I’m now making on the agents I shipped two weeks ago, six months ago, and the one I’m starting tomorrow. This is the “leap” where production surprises you, a fix for one edge case smuggles in a regression, and you can’t say with confidence which version of your prompt was the best one.

Every engineering leader I spoke to at TDX was circling this, named it differently, and showed me a different piece of the answer. Jayesh calls it the day-two problem. Alex calls it turning the audit into the eval. Andrew Comstock calls it letting old IT be the throttle. Three vocabularies for the same thing: what builds a compounding agentic force versus a one-shot demo.

Jayesh’s “day two” problem for agents

Jayesh Govindarajan runs Salesforce AI as EVP. He’s been there long enough to have built Einstein Bots into 100M+ automated conversations before “transformer” meant anything outside toy aisles.

The specific case Jayesh walked me through was Falabella, a Chilean retailer running an Agentforce agent for customer support. A customer tried to return multiple items with conflicting return policies: one item was food (no return), one was something else (return fine). The agent flagged the conflict, handed off to a human, and the human resolved it correctly.

The handoff isn’t the interesting part. The interesting part is what Falabella did with it. They captured the failure, captured the expert’s resolution, and regressed both back into the agent’s instructions so the same collision doesn’t happen twice. They turned the problem into the fuel for its own solution. Salesforce has productized this pattern as the Testing Center, and it’s the closest thing the industry has to a self-healing loop. “Data at every stage is the key to closing the loop,” Jayesh told me.

Alex turning the audit into the eval

Back to “pick 25 charts and pray.” Before Alex’s team pointed any AI at their compliance work, healthcare audits were done by hand-sampling: pull 25 charts, read them, hope the rest are fine. Adobe Population Health (no relation to Acrobat) is audited on a compliance scorecard.

☑️ Did this nurse complete the assessment in the required window?

☑️ Did the follow-up happen on time?

☑️ Did the documentation cover the required fields?

☑️ Did the bobcat get removed from the patient’s home?

Binary pass/fail. Real-dollar consequences. And yes, the last one is real.

Alex’s team does complex case management in patients’ homes. The stories come back wild. One patient needed a wheelchair ramp and got one built for free by Home Depot. Another had a bobcat living in her kitchen and had been living in her own living room for two months before the team figured it out and called animal control. Real-world case management has a long tail, and every single tail instance is a chart that needs to survive the future and the audits in between.

What Alex built with Prompt Builder and Salesforce’s grid product is exactly what you’d want for this challenge. Every single assessment scored against the audit rubric, tens of thousands per year, at production scale. The quiet-but-important move: the AI eval isn’t a side quest. It’s the regulatory scorecard. There’s no separate “LLM test suite” living in a universe parallel to compliance. The audit IS the eval spec. If you’ve been paying attention to the AI evals conversation (Hamel Husain and that crowd), this is where they’ve been pointing for the last year. Start small, start binary, stop vibe-checking things you can automate. Alex did it. So can you.

Comstock reminds us all to be learners again

Andrew Comstock is SVP and GM of MuleSoft. His framing of this moment is the most grounded I’ve heard from anyone running a product at his scale. His opening line was: “We’re at a moment where everyone should be a learner again. Nobody has the playbook.” YES!

Then he told me this story about a life sciences company (big, regulated, well-capitalized) that hired an AI savior exec. Came in with a vision, built a team, shipped fast demos. Then the compliance team asked where the training data came from and the whole initiative stalled. Great demos, no production path. A whole lotta nothin’.

Meanwhile, their existing MuleSoft team (the “legacy” IT group in the org) had already shipped MCPs with PII controls, full audit logging, and governance approval for the exact data the AI team needed. One engineer at a CIO meeting raised his hand: “uh, we have MCPs for those.” They flipped the agents over to the existing ones and had the immediate unlock they were looking for. And the stewards of that unlock were the dutiful IT custodians that were there all along.

The reframe makes me grin every time I think about it. IT stopped being the brake. IT became the throttle. The old rails (data model, integration layer, compliance controls, audit trail) aren’t legacy baggage in this picture. They’re the substrate agents glide through.

Comstock’s read: whether the code comes from a human, Copilot, Claude Code, or an autonomous agent like Devin, the same policies and reviews apply. Agents don’t get a private fast lane to production. They join the existing one. Comstock is right: old rails are the throttle, not the brake, but only if you take them seriously enough to actually follow them.

Headless is the way I work every day

So I’m about to prove this the hard way. On May 21 at 1pm ET, Ben Lloyd Pearson, Dan Lines, and I are running a 35-minute live workshop where I’m going to sit in front of you with Claude Code and try to vibe-code LinearB. Me against the whole platform. I already have a feeling that I’ll epicly crash and burn, but I don’t know where yet!

Every registrant also gets first access to the companion guide about build vs. buy, and a front row seat to the starting line for a project like this. It’s a written walkthrough of the five places DIY consistently breaks, the hidden maintenance costs you don’t see in month one, and an honest framework for deciding when to build, when to buy, and when to graduate from one to the other. Instead of running away from the SaaSpocalypse, we’re tackling the conversation head on and equipping you with what’s needed to start today.

Root for me pls!

Save your seat

The invitation

We’re still early on all of this btw. Just by reading this, you’re very early. The three conversations at TDX gave me different angles on what feels like one underlying idea, and I’m still trying to see the whole shape. The moves I described above all started last week and will take months to pay off or fail.

If you’re building agents in production right now (especially in a regulated or compliance-heavy space) I’d genuinely love to compare notes. DM me on LinkedIn. Reply to this. I suspect the best version of the loop won’t come from one team on one platform. It’ll come from people comparing what worked across industries that haven’t traditionally talked to each other.

Last thing. Comstock left me with a line I keep repeating:

The first pitch hasn’t happened. Nobody’s on base. Let’s compare notes while we’re waiting.

Forget the massive GPU clusters. According to Tim Dettmers, research scientist at Ai2, you can build a state-of-the-art AI coding agent with what he calls a "hot plate and a frying pan." This week on Dev Interrupted, Andrew sits down with Tim to unpack how his resource-strapped team built the SERA model using a fraction of the compute power of major labs. They explore the tactical engineering behind synthesizing training data from private codebases without verification tests, proving that the open-source community is uniquely positioned to out-specialize frontier models. Finally, Tim shares his contrarian take on the future of token economics, explaining why the cost of AI might actually spike as compute efficiency hits a physical wall.

1. Building a self-writing knowledge base

Andrej Karpathy recently shared his shift from using models for coding to building self-maintaining knowledge bases. He is effectively taking the Zettelkasten method, famously used by the incredibly prolific sociologist Niklas Luhmann, and making it agentic. By using a two-tier architecture of raw sources and an AI compiled wiki, the model handles the synthesis and cross linking automatically. It is a powerful reminder that “words do not equal knowledge” and that we should be using these tools to surgically cycle ideas rather than just generating endless text.

Read: The Wiki That Writes Itself

Extended_Brain

The Wiki That Writes Itself

Part I: Karpathy’s Mission Statement…

Read more

2 months ago · 101 likes · 15 comments · Extended_Brain

2. The agent swarm data stack

Jordan Tigani over at Mother Duck just introduced “Water Town,” which brilliantly adapts Steve Yegge’s Gastown concept specifically for data teams. It offers an eight stage progression that moves from automating simple SQL queries to building entirely self-healing pipelines. My co-host Ben Lloyd Pearson brought up a great point on last week’s Friday Deploy about how the problems caused by agents often require more agents to solve. It sounds like a paradox, but think about a massive construction project. Once you bring in heavy cranes to do the lifting, you suddenly need an entire fleet of support vehicles just to maintain those cranes. Software is no different. To manage autonomous systems at scale, you have to build a secondary layer of agents just to orchestrate the first.

Read: Water Town: The Agent Swarm Data Stack

3. Bringing offline AI to the iPhone

Google just unveiled Gemma 4’s ability to run natively on the iPhone. We have been covering the rapid rise of small language models over the last few weeks, and this is a massive shift for bringing AI to places with spotty internet connectivity. It represents an opportunity to reduce your inference costs and build powerful edge AI capabilities without constantly hitting expensive cloud APIs. Do not sleep on small language models, because they are quickly becoming a foundational building block for developers everywhere.

Read: Google Gemma 4 Runs Natively on iPhone With Full Offline AI Inference

4. The problem with using Obsidian as an AI database

There is a growing cargo cult around using flat Markdown files in Obsidian as “AI memory.” This piece by rightly points out that just dumping a text file into a context window is brute force, not retrieval. Without a schema or a database like SQLite to query relationships, this architecture simply will not scale for engineering teams. While I have used Obsidian every single day for years to manage my personal notes, throwing a folder of text at a large language model is not a scalable substitute for proper data infrastructure.

Read: Stop Calling It Memory: The Problem with Every “AI + Obsidian” Tutorial

5. Curing the AI brain fry epidemic

wrote a fantastic piece on the mental fatigue caused by managing multiple agents all pinging you for attention at the same time. She cites a Harvard study noting that overseeing AI tools is actually far more taxing than using them. The secret to avoiding this burnout is to stop watching your agents in real time. Instead of staring at the terminal and constantly course correcting, figure out what you are watching for and bake it into a deterministic skill so you can finally prompt and forget.

Read: Breaking out of the “brain fry” spiral of AI

After Burnout

Breaking out of the "brain fry" spiral of AI

I’ve been doing a lot of reading on AI lately, and not the kind you might expect. I’m not talking about how to use AI to increase my efficiency or supercharge my output. What I’m actually thinking about is what AI is doing to us as a culture, as a society, and as humans who still have to live inside our own heads…

Read more

2 months ago · 16 likes · 2 comments · Kelly Vaughn

6. A new operating model for AI

Are you struggling to translate AI tool adoption into measurable engineering impact? The gap between AI usage and actual throughput requires a new approach. Meet APEX: an operating model designed to validate whether AI is actually increasing your velocity while preserving delivery confidence.

Inside the guide, you’ll learn how to measure AI at the PR level, track four key north star metrics (AI Leverage, Predictability, Flow Efficiency, and DevEx), and implement a proven review cadence to catch bottlenecks before they compound. Stop settling for tool adoption metrics. Download your free copy of the APEX framework today.

Download the APEX framework

7. Google fights back against hijacked browsers

Google is stepping up the fight against web spam by actively punishing websites that hijack your back button. Bad practices on the web are at an all time high right now thanks to lazily generated websites that trap both humans and agents in endless loops. Google is uniquely positioned with the platform authority to actually enforce better behavior here. It is a highly welcome pulse check showing that they still care about maintaining a functional, frustration free internet experience.

Read: Introducing a new spam policy for “back button hijacking”

At the HumanX conference last week, I had the chance to moderate a panel called “From Prototype to Production: Scaling Real-World AI” with three infrastructure leaders whose work sits at the exact point where AI stops being impressive and starts needing to be reliable. The conversation went places I didn’t expect, and I want to share what came out of it, because the gap between a working demo and a production system is where most AI projects go to die, and these are the people building the bridges across that gap.

The panelists were Lauren Dunford, CEO and co-founder of Guidewheel, which connects factory floor equipment for manufacturers like Hershey, Johnson & Johnson, and Unilever; Robert Nishihara, co-founder of Anyscale, which solves the distributed systems infrastructure challenges for companies training and deploying models at scale; and Angela McNeal of Thread AI, whose platform helps enterprises build and manage AI workflows across regulated, mission-critical environments with tools like Lemma.

What made this conversation different from the usual “AI in production” panel is that none of these people are building chatbots or content generators. They’re working in spaces where a bad output means a factory line goes down, a GPU cluster burns money, or a regulated workflow falls out of compliance. The lessons they’ve learned are worth studying.

Build on top, don’t rip and replace

The first question I asked was simple: when AI is interacting with the real world, how do you deploy it safely without wrecking the infrastructure that already exists?

Lauren’s answer reframed how I think about the problem entirely. Guidewheel works on factory floors where some of the equipment dates back to the 1950s and ‘60s, and in some cases, WWII. The operators know their machines intimately. The operational technology networks are the beating heart of the operation, and the last thing you want is an AI agent reaching into those networks and making autonomous decisions about machinery that could hurt someone.

“Instead of touching the operational technology networks,” Lauren explained, “we connect on top and stay air-gapped from those systems. We’re able to feed into their existing ERP and other systems without opening up the cybersecurity risk from touching their network.”

Angela described a similar philosophy at Thread AI, where many of their enterprise customers have tens of millions of dollars invested in existing infrastructure. “Having this kind of plug-in architecture where you can either come in on top, or run a piece in parallel and see how it works, that incrementality is extremely important when building new workflows where companies have had processes running for years.”

Robert brought a different angle from the model development side. At Anyscale, one of the most common pitfalls he sees is teams ending up with fundamentally different tech stacks between development and production. “When that happens, you run into a class of errors that only appear on one side. You might find a bug in production, go back to development to debug it, and it doesn’t appear there because it’s a different stack, maybe even a different team managing it.”

His recommendation: converge the stacks. Make the software you run in production and the software you run in R&D as close to each other as possible, because the handoff between the two is never a one-time event. “It’s really a constant loop. I build something and deploy it, then I’m modifying it and doing more development and fixing bugs and constantly going back and forth.”

The principle that emerged from this first exchange feels obvious but is violated constantly: don’t replace what’s working, layer intelligence on top of it. Whether you’re air-gapping from factory floor networks, plugging into existing enterprise systems incrementally, or converging your dev and prod stacks to eliminate handoff friction, the common thread is respect for what already exists.

As Angela put it in her reflections after the panel: “You can’t flip the switch from one user in a sandbox to 10,000 in production and expect your infrastructure to hold.”

Nobody ever over-invested in observability

The conversation shifted to auditability and observability when I raised the question of accountability. In a world where agents can spawn other agents with limited oversight, who’s responsible when something goes wrong?

Angela was blunt about it: “Every single piece of data that moves through the system needs to be logged, audited, and captured. If you have a system that can arbitrarily call or spawn off three other agents, and some critical process gets updated, who’s accountable? Is it the engineers who created those agents? The manager who approved it? The system you built that connected them?” Her answer: you need every identity mapped and managed, synced back to how the organization handles access control. And you need kill switches at every point.

Robert reinforced this from the GPU economics perspective. When hardware is expensive, customers care intensely about cost and performance, and both of those, he pointed out, are downstream of great observability. “You have to know where the money is being spent before you can really optimize it.” The challenge is that observability happens at multiple levels (what’s happening on the GPU, on the machine, across the cluster) and the information needs to be fused together and accessible to the same agents diagnosing problems.

Then he said something that stuck with me: “I’ve never heard anyone say they over-invested in observability. That’s not a problem people have.”

In the rush to ship AI features, observability is usually the thing that gets cut or deferred. But every panelist on this stage, across factory floors and GPU clusters and enterprise workflows, identified it as the foundation that everything else depends on. Cost control, impact measurement, trust-building, debugging, accountability, all of it downstream of knowing what your system is actually doing.

As Lauren noted after the panel: “The reality of production and scale is very different from theory. Messy systems, inconsistent data, lean teams working to make time for experiments.” That gap between theory and reality is exactly where observability earns its investment.

The human-in-the-loop is evolving

One of the most interesting moments in the panel came when Angela described an emerging pattern in how organizations think about human involvement in AI workflows.

The traditional approach is familiar: you build in forced checkpoints where a human has to review and approve before the system continues. Or you set conditional thresholds so that when a confidence score drops below a certain level, it escalates to a human. Both of these treat the human as a gatekeeper standing above the system.

But Angela described something different that Thread AI is seeing emerge: “There’s this pattern of the human being available as a tool. It’s being modeled as an option that these autonomous or semi-autonomous systems can call out to, to gather more context. Which is a really distinct inversion of a paradigm.”

Instead of the human supervising the AI, the AI is calling the human when it needs help, the same way it might call an API or query a database. The human becomes a resource in the system’s toolkit rather than a checkpoint in its workflow. Angela was careful to note the prerequisite: “As long as you have the identities modeled correctly and the auth modeled correctly, it can work. If you don’t, it’s a disaster.” But the pattern itself represents a real shift in how production systems handle human-AI collaboration.

Robert connected this to the model training world, where the same dynamic plays out in data preparation. “You start with a ton of data, and you’re automatically labeling and curating a lot of it. And you’re calling out to humans to review the ones you’re unsure about.” Humans are brought in surgically where their judgment adds the most value, rather than being required to review everything.

Lauren grounded it in the manufacturing context, where trust is earned incrementally. “We’ve developed a lot of on-ramps, crawl, walk, run, to help that trust be built, as if this were an apprentice AI. I’m training it. I’m growing to trust it. Not going to hand it the keys to the kingdom all at once. But over time, I’m going to have it make more and more recommendations.”

The progression she described, from human-supervised to human-available to increasingly autonomous, might be the most realistic framework I’ve heard for how AI adoption actually works in high-stakes environments. You don’t flip a switch. You build a relationship with the system over time, and your trust grows as the system earns it.

Measuring what actually matters

I closed the panel by asking about metrics, specifically how these leaders think about proving the value of their AI systems when they go to the board or talk to stakeholders.

Lauren’s answer was refreshingly direct: “I’ll be super basic on the metrics. It’s just your business value. Did your dollars in go up? Did your dollars out go down? Did your profit margin go up? If you’re inventing a metric to try to track whether your AI is being successful on the plant floor, something’s wrong. Let’s look at the P&L.”

Angela pushed for quantification discipline up front: “One of the first things we do when we chat with folks who are scoping different workflows is, can you quantify what success looks like? Whether it’s ‘we have ten engineers spending ten months on this, and now it takes two months,’ or ‘we want to go to market with a new product powered by this.’ Having the discipline to say ‘I can quantify what I think success looks like’ is key.”

She also flagged the anti-pattern: teams that come in wanting to “come up with new insights” but can’t define what an insight actually is or what it’s worth. If you can’t put a number on what you’re trying to achieve, you probably aren’t ready to put AI on it.

Robert’s lens was slightly different because Anyscale operates at the infrastructure layer, a step removed from direct revenue impact. “The quantification is typically either the amount of money you’re spending on GPUs and cloud computing costs, or the velocity of the AI team, how many experiments are you able to run, how quickly are you able to ship something from development to production.”

What struck me across all three answers is that none of these leaders are tracking “number of AI features shipped” or “model accuracy on a benchmark.” They’re measuring business outcomes, operational efficiency, and team velocity. The AI is the mechanism. What matters is what it enables.

This resonated with something I think about a lot in my work at , where we cover how engineering teams navigate the shift to AI-assisted development. The same dynamic plays out in software organizations: the teams that succeed are the ones measuring whether a tool actually changed their delivery outcomes (cycle time, throughput, quality, developer experience) rather than just tracking how many people adopted it. Adoption tells you who’s using the tool. Impact tells you whether the tool is working.

What I took away

Sitting between these three panelists, what came through most clearly is that taking AI to production is as much an organizational challenge as a technical one. The technology works. The question is whether your systems, your processes, and your people are set up to integrate it safely, measure it honestly, and build trust with it over time.

The themes that emerged, layer on top instead of ripping out, invest in observability before you need it, design human involvement as a resource rather than just a gate, measure business outcomes rather than adoption metrics, aren’t just production best practices. They’re a philosophy for how to bring powerful technology into environments where the stakes are too high for demos.

A demo is just a promise. These are the people keeping that promise.

Or as Angela put it most succinctly: “The demo era is over. Durable, mission-critical AI is what’s next.”

Thanks to Lauren Dunford (Guidewheel), Robert Nishihara (Anyscale), and Angela McNeal (Thread AI) for an incredible conversation on the Loop Theater stage at AI Council.

Measuring AI impact in your engineering org

Every panelist in this conversation came back to the same point: what matters is whether AI is changing your outcomes, not whether people are using it. Lauren looks at the P&L. Angela forces quantification up front. Robert tracks team velocity and cost efficiency.

That’s the same shift we’ve been building toward at LinearB with the APEX framework. APEX is our operating model for engineering teams in the AI era, and it starts from a simple premise: measure what AI actually changes in your delivery pipeline, not just who’s using it. It tracks cycle time, throughput, code quality, and developer experience across four dimensions: AI leverage, predictability, efficiency, and developer experience.

If the themes from this panel resonated, observability as the foundation, quantifying success before you build, measuring business outcomes instead of tool usage, APEX is where those principles meet engineering metrics. Learn more about the APEX framework here.

Are your AI agents quietly ignoring their guardrails just to get the job done? This week on Dev Interrupted, Andrew sits down with Wayfound AI founder and CEO Tatyana Mamut to discuss why traditional, deterministic software testing falls completely short when evaluating stochastic AI models. They explore the growing strategic divide between OpenAI and Anthropic, the urgent need for independent "guardian agents," and what it takes to run a company with just 4 humans and 27 agents. Finally, they break down how to stop the chaotic game of telephone between engineers and business leaders by relying on "Deep-T" subject matter experts to evaluate what good AI output actually looks like.

1. The AI cybersecurity arms race

Claude Mythos is the word on everyone’s lips this week, especially in the security space. This model represents a massive sea change in capabilities, but it also highlights a terrifying imbalance. Anything defenders can leverage to secure systems can theoretically be used against them. As I noted on last week’s Friday Deploy, “an attacker can leverage 10 times better and faster and more aggressively.” We are watching a live arms race unfold as these new frontier models expose long standing vulnerabilities in the wild.

Read: Anthropic investigated the internals of its latest unreleased model, Claude Mythos

2. Anthropic funds the defense

In direct response to this escalating security landscape, Anthropic just announced Project Glasswing. They are partnering with major organizations like the Linux Foundation and committing 100 million dollars in usage tokens to help secure critical software infrastructure. Mythos has already found ancient, undetected bugs in widely used libraries like FFmpeg. It is a brilliant, proactive play from Anthropic to act as a genuine partner to the software ecosystem while responsibly managing the rollout of their most powerful technology yet.

Read: Project Glasswing

3. Why your favorite AI benchmark is probably dead

Understanding model capabilities is getting harder as scorecards become more complex. A fantastic new guide from and breaks down exactly how to read these reports. The biggest takeaway is simple: if multiple models are scoring above 90 percent, the benchmark no longer matters. The industry is shifting toward tests that humans solve intuitively but machines fail entirely, like the ARC-AGI-3 benchmark. Until models conquer that, we still have a reliable way to separate human intuition from artificial intelligence.

Read: Tool School: Benchmarking 101 (How To Read AI Model Report Cards)

4. A new operating model for AI

Are you struggling to translate AI tool adoption into measurable engineering impact? The gap between AI usage and actual throughput requires a new approach. Meet APEX: an operating model designed to validate whether AI is actually increasing your velocity while preserving delivery confidence.

Inside the guide, you’ll learn how to measure AI at the PR level, track four key north star metrics (AI Leverage, Predictability, Flow Efficiency, and DevEx), and implement a proven review cadence to catch bottlenecks before they compound. Stop settling for tool adoption metrics. Download your free copy of the APEX framework today.

Download the APEX framework

5. Frontier capabilities on your own hardware

If you blinked this week, you might have missed the release of four massive open source models. Google’s Gemma 4, PrismML’s 1-bit Bonsai, Arcee’s Trinity, and H Company’s Holo3 all hit the scene under permissive Apache 2.0 licenses. Trinity alone offers performance near Opus 4.5 levels at a fraction of the compute cost. This completely shifts the economics of AI development. Engineering teams are no longer strictly beholden to expensive API calls and can start fine tuning local models to orchestrate their own highly efficient, multi-agent architectures.

Read: Four Open Models Just Proved You Can Own Frontier AI at Every Scale

6. Why say many word when few word do trick?

Julius Brussee just dropped a hilarious new Claude plugin called Caveman that compresses AI outputs into incredibly blunt, simplified language. While it started as a novelty to lower token costs by up to 87 percent, it actually solves a very real problem. When models are too polite or verbose, they pollute the context window and increase your cognitive load. Sometimes you do not want a flowing paragraph of explanation. You just want the machine to fix your code and move on. Me like Caveman mode.

Read: JuliusBrussee/caveman

Are your AI coding tools actually making your team faster, or are they just creating downstream chaos? This week, Ben Lloyd Pearson and Dan Lines introduce APEX, LinearB’s new engineering leadership framework built explicitly to measure and manage software delivery in the AI era. Moving beyond traditional frameworks like DORA and SPACE, APEX balances AI Leverage, Predictability, Efficiency, and Developer experience to ensure upstream code generation translates into actual business value. Tune in to learn how to break past the illusion of coding speed, prevent AI slop from clogging your review pipelines, and discover which pillar of the APEX framework your team needs to tackle first.

1. What happens when a PR becomes a billboard?

GitHub found itself in hot water this week after Copilot inserted an advertisement directly into a user’s pull request. While GitHub reversed the behavior and claimed it was just a programming logic issue, it gave us a bizarre glimpse into a future where our tools might actively market to us while we work. It raises serious questions about authorship and trust. By the way, if you are not on an enterprise plan, you only have until April 24th to explicitly opt out of your private data being used to train Copilot. Go uncheck that box so your private code stays private.

Read: GitHub backs down, kills Copilot pull-request ads after backlash

Source Zach Manson

2. Surviving the whiplash of “dead” AI trends

, Head of AI at Theory Ventures, wrote a highly entertaining, satirical piece tracking how quickly the tech community declares AI technologies dead. From RAG to prompt engineering, things go from essential to obsolete and back again in the blink of an eye. It is a fun take on the whiplash we all feel trying to keep up with the changing fundamentals of our industry. Of course, the title itself is a clever play on the actual ripgrep utility, which is one piece of software that is certainly not dying anytime soon.

Read: Software’s Next Epoch: Our Investment in R.I.P. grep

3. Zero tests, 500k leaked lines, and virtual terminal pets

Anthropic accidentally exposed over half a million lines of Claude Code’s TypeScript source through a misconfigured build. The leak revealed unreleased features like a background daemon and coordinator mode, but the most shocking part was the architecture itself: zero tests and a massive three thousand line function. The absolute best discovery was “Buddy mode.” If you update your terminal and use the /buddy command, you can hatch your very own virtual ASCII pet. I got a legendary robot named Trixel that comments snark on my coding sessions now. Look out, Grok!

Read: Anthropic accidentally leaked Claude Code’s entire source. Here’s what 512,000 lines reveal

Linas's Newsletter

Anthropic accidentally leaked Claude Code's entire source. Here's what 512,000 lines reveal 🔓

👋 Hey, Linas here! Welcome to another special issue of my daily newsletter. Each day, I focus on 3 stories that are making a difference in the financial technology space. Coupled with things worth watching & the most important money movements, it’s the only newsletter you need for all things when Finance meets Tech. If you’re reading this for the first time, it’s a brilliant opportunity to join a community of 370k+ FinTech & AI leaders…

Read more

2 months ago · 53 likes · Linas Beliūnas

Watch: Kshetrajna Raghavan’s presentation at the Bay Area DSPy Meetup

4. Swapping giant models for highly tuned smaller ones

Shopify recently cut their inference costs 75x by switching a specific data extraction task from GPT-5 to a self-hosted Qwen 3 model. By using tools like DSPy (I ❤️ DSPy) to fine tune the smaller model and deploying a multi-agent architecture, they actually managed to double their output quality. It is a massive lesson in efficiency, proving that you do not always need the most expensive foundation model to get exceptional results.

Read: Shopify Cuts Inference Cost by 75x Using Qwen 3 for Merchant Data Extraction

5. Faster coding doesn’t mean faster delivery

AI tools might be accelerating your coding phase, but if your review queues are suddenly clogged then the bottleneck has merely shifted. To prevent speed from creating chaos, engineering leaders need a way to measure AI in the critical path.

That’s why LinearB published the APEX framework. It’s a complete operating model designed to connect AI activity to real delivery outcomes, ensuring that productivity gains don’t come at the cost of predictability or developer burnout. Stop guessing about AI ROI and start measuring what matters.

Download the APEX framework

6. No more CSS in your browser?

Cheng Lou, an engineer at Midjourney, just dropped a fascinating new library called Pretext. It allows you to measure and render text in a browser using pure JavaScript, completely bypassing CSS and the traditional DOM thrash. Not only does this offer incredible rendering speeds, but it also allows agents to headlessly render and understand website layouts. Tucked away in the project’s documentation is a steering thought that doubles as a manifesto and perfectly captures this era: “The cost of any verifiable software will trend towards zero.”

Read: Pretext Does What CSS Can’t — Measuring Text Before the DOM Even Exists

7. Managing open source in the age of agentic pull requests

Steve Yegge is back with a look at what it takes to manage an open source project when you are handling 50 AI generated pull requests a day. Instead of outright rejecting AI contributions or demanding perfection from human submitters, he flips the script. He uses his own agents to bring the contributed code up to his strict architectural standards. It is a brilliant, consensus driven approach to development. Maintainers who refuse to adapt risk fracturing their communities, while those who embrace this model can steer their projects faster than ever before.

Read: Vibe Maintainer

James J. Boyer of Engineering Leadership Bites is back again with another guest post after last year’s well-received piece: No more coding vibes in the efficiency era

I’m staring at LLM output, confused. I’d just furiously launched a stream-of-consciousness prompt into my terminal window, and it didn’t do what I expected.

Oh. Claude wasn’t running. 🙃

I sat there for a second, realizing my bash prompt had absolutely no idea what I was talking about. I laughed, fired up the Claude CLI, and did what I was apparently trying to do.

I was less embarrassed and more fascinated.

Technological shifts don’t usually jump-scare you; there’s a ramp.

Before git, I versioned with folders. project-v2, project-final, project-seriously-this-is-the-last-one. We all had a system. Mine was terrible, and yours was too. The folder habit immediately felt primitive when commit history arrived. I could explore without consequence and undo without panic. I retired the habit deliberately.

Docker was similar. “It works on my machine” wasn’t something I let myself say anymore. A clean before and after with a conscious crossing.

Delayed reflexes

This time was different. I didn’t decide to reach for AI every time I had a parasitic thought, quietly slurping away at my focus, getting fat and greedy in the back of my skull. I didn’t make a deliberate choice to stop pounding out notes in Obsidian of half-formed ideas I’d never look at again, and instead start dumping nutritional slop into a contextual stew I had neither the time nor energy to schlep over to the stove yet.

It just became where my brain goes now.

The way I write and how I work through something have changed, too, whether that’s code or otherwise. It’s more important for the idea to vacate my head than to clinically dissect it, so I’ll clean it up later. This is messier, but more honest. I couldn’t tell you when that happened. I just noticed that it had one day.

The farmer probably can’t tell you exactly when he stopped thinking about the horse plow either. At some point he just stopped reaching for it. That wasn’t a decision so much as a fact he discovered.

What’s different this time is that the previous shifts gave you enough runway to notice yourself adapting. With cloud and mobile, the ramp was gradual. The old habit had time to deprecate cleanly, and you got to watch the transition.

This one compressed all of that. I typed a prompt into an empty terminal. The reflex had been there for a while, I just wasn’t home when it moved in.

Real people will care about this

I could not explain Web3 to my mom. Not because she isn’t smart (she is), but because she’s stubborn (that’s where I get it from). She wants to understand the “why”. But the value proposition of Web3 requires you to already believe a set of premises that most humans will never, ever care about. It’s a people problem. AR and VR suffered the same fate. The mainstream consumer looked at a headset, or a bulky pair of sunglasses, and shrugged. End of story.

When AI showed up, I was skeptical. Same initial posture as the “busts”. I went looking for the exit ramp. Tested the edges. What is this actually bad at? What does it excel at? Where are the seams?

I found some early, and I kept coming back to challenge it. It had gotten better and the seams kept closing.

I was surprised too. When ChatGPT first impressed me, I exclaimed to my then-disinterested wife: “this is going to change the fucking world because real people will care about this.”

This was the first time we had the conversation we thought we should’ve been having with Siri over a decade ago. It passed the test.

Opting out is a career mortality event

The companies building on top of this are not selling a vision of the future that you have to build faith in. They’re selling you something you can use right now, today, to do your actual job faster. The people adopting it are pulling away from the people who aren’t, and that gap is growing rather than shrinking.

I watched a colleague shrug this off a couple years ago: “I’m gonna sit this one out. Someone else will figure it out, and I’ll follow along.” I understood the impulse because change is hard. Paradigm shifts are exhausting, and if you get deep enough into your career, you’ll want to make the same call.

But I couldn’t. I’d already gone looking for reasons to dismiss this, and hadn’t found enough of them.

What upsets me about this is that it isn’t turning into “another tool in the toolset”. I wanted it to be that. Instead, it’s becoming something closer to: this changes the job. Maybe the entire industry. And people who opt out aren’t just missing a skill, they’re opting out of what the job is becoming.

I’ll say it plainly because everyone else is hedging: The people choosing to sit this one out are making a career-ending decision.

Outcome engineering

CEOs, founders, and investors writing the checks don’t care about the craft of software engineering. I know people who’ve built their entire identity around that craft. I have genuine respect for it. But the people with the vision, the capital, and with the ambition to build something that actually matters are chasing outcomes.

They will hire the person who builds faster and ships faster. If that person uses AI to do it, nobody is going to apologize for it. That’s the part that stings. Not the technology, but the implication.

There’s a person in every neighborhood who builds furniture in their garage because they love it, not to compete with IKEA. Sometimes that’s enough.

You can be that person too! Make your peace with what that means though. Keep your skills sharp, build things you’re proud of, and enjoy the craft for what it is.

But don’t pretend you’re also going to thrive in a market that is structurally changing around you. Don’t be the person who shows up to a job interview in 2027 and explains that you chose not to engage with tools that have become table stakes, expecting the person across the table to nod, thump their chest twice, and say “we respect that.”

They won’t. They have someone else to talk to in twenty minutes.

The opportunity in front of us all

The good news is that the window isn’t closed yet. It’s still early enough that getting started isn’t embarrassing. These tools are genuinely weird. Hilariously imperfect. You’ll struggle with them at first. But that’s normal, and it means that you’re learning.

What isn’t fine is my colleague’s decision. The conscious, deliberate choice to wait for someone else to blaze the trail so you can follow later. That’s a reasonable strategy when you’re observing a slow-moving body in space, light years from any real and imminent threat to your safety or job security.

But your colleagues who are embracing this are approaching the event horizon at a quickening pace. They’re soon to be spaghettified by the sheer momentum and rate of change, body and limbs going where their minds, their habits, their instincts, must dare to follow. The folks watching from the window of the ship have signed a resignation letter that has yet to be drafted.

AI agents have officially arrived on an internet that simply wasn't built for them. So how do we build the infrastructure to keep them safe, productive, and contained? This week, Andrew sits down with Matt Boyle, Head of Product, Design and Engineering at Ona (formerly Gitpod), to discuss evolving cloud development environments into secure, enterprise-grade "agent jails." They explore the mechanics of Project Veto’s kernel-level security, the slow death of the traditional IDE, and how the rise of AI is transforming developers into full-stack, T-shaped product owners. Finally, Matt shares his vision for the future of the SDLC, detailing how organizations can safely balance strict compliance with the bleeding edge of autonomous software factories.

1. Disney can’t catch a break

OpenAI is shutting down its standalone Sora app and pivoting back to the enterprise, effectively killing a proposed partnership with Disney. Generating video is a massive physics problem compared to text, and selling those compute-heavy trinkets at a loss simply does not scale. This pivot resulted in a brutal first week for Disney’s new CEO, but it highlights a broader truth about the AI market. As I mentioned on the show, OpenAI “also has too many pots on the stove and it just doesn’t have enough heat to cook them all.” Foundation model providers like Anthropic that bet strictly on knowledge work and avoided consumer distractions are emerging as the real winners.

Read: OpenAI pulls the plug on Sora video app, Disney deal

2. Anthropic finally puts guardrails on the mode we were all already using

If you’ve been using Claude Code for anything beyond toy projects, you probably have --dangerously-skip-permissions aliased in your bash. Because the alternative (manually approving every file write and shell command) makes long-running agentic work impossible. So we all opted into YOLO mode and started building our own safety layers: hooks, deterministic guards, scoped skills. Anthropic just shipped Auto mode, which doesn’t kill YOLO so much as it reclaims the ground we’d already surrendered, a classifier now reviews each tool call before it runs, auto-approving safe actions and blocking destructive ones. It’s not a replacement for the harness engineering you’re already doing, but it’s a much better baseline than the nothing we had before.

Read: Auto mode for Claude Code

3. The shifting vanguard of software engineering

The New York Times just published a deep dive into how AI is making software engineering the first major knowledge profession to face widespread disruption. Developers are transitioning from manual code creation to judging code quality and architectural design. Ben Lloyd Pearson made a great point on the podcast that these trends are coming for all knowledge work, but engineers are simply on the vanguard. We are entering an era of versatile professionals where non-technical people can solve problems with code, and traditional coders must develop exceptional taste to stay relevant.

Read: Coding After Coders: The End of Computer Programming as We Know It

4. Faster coding doesn’t mean faster delivery

AI tools might be accelerating your coding phase, but if your review queues are suddenly clogged, your system hasn’t actually improved—the bottleneck just shifted. To prevent speed from creating chaos, engineering leaders need a way to measure AI in the critical path.

That’s why LinearB published the APEX framework. It’s a complete operating model designed to connect AI activity to real delivery outcomes, ensuring that productivity gains don’t come at the cost of predictability or developer burnout. Stop guessing about AI ROI and start measuring what matters.

Download the APEX framework

5. The necessity of portability in a platform monopoly

Microsoft recently announced a seven point plan to address boiling consumer contempt over Windows 11, specifically regarding forced AI integration and privacy violations. However, Microsoft does not need you to love Windows. They only need you to calculate that the cost of migrating away exceeds your tolerance for staying. If there is one lesson to take from this twenty year monopoly strategy, it is the absolute necessity of portability. Build your agentic workflows so they can easily migrate to another system the moment your current provider tries to lock you in.

Read: Microsoft’s “Fix” for Windows 11: Flowers After the Beating

6. Finding balance as a T-shaped leader

shared an excellent framework for engineering leadership called POST, which breaks down into people, operations, strategy, and technology. The core insight is that leaders usually excel in just one or two of these domains rather than across the board. To build a balanced leadership team, you need to honestly assess your gaps and seek out complementary peers. Just as our industry increasingly embraces broad generalists, we must also challenge ourselves to become T-shaped leaders by actively stepping out of our comfort zones to improve our weakest elements.

Read: POST: People, Operations, Strategy, Technology

Molochinations

POST: People, Operations, Strategy, Technology

Jocelyn Goldfein taught me a model for thinking about software leadership strengths which I’ve found useful for many years. Though no model is perfect, mental models give us a framework by which to anchor ideas. Models can shift our perspective, helping us see solutions or opportunities more readily. I’ve found the POST model of engineering leadership e…

Read more

3 months ago · 43 likes · 5 comments · Philip Su

A guest post by Zach Lloyd, founder & CEO of Warp.

For decades, software development assumed a single operator working on a single machine. Even in team settings, engineers primarily worked locally, syncing changes through version control. The laptop became the atomic unit of development, and the surrounding toolchain grew up around that reality.

That model made sense because the work itself was sequential and led by humans. A developer wrote code, ran tests, fixed errors, and pushed changes upstream, all within a tight loop controlled from a keyboard. Agents disrupt that system.

As AI shifts from suggesting code to carrying out real tasks, the shape of development work is changing. Agents can now operate in parallel and continue running independently of the person who started them. That behavior places different demands on infrastructure.

Where personal machines strain

Running agents locally works in small numbers, but as they become persistent collaborators rather than occasional helpers, the limitations become clearer. The work of coding agents does not follow the rhythm of a laptop that opens in the morning and goes dark at night. They can respond to timers, CI triggers, deployment events, and production alerts, and may run for minutes or for hours. Personal devices are not designed to host activity that never stops.

Operational concerns appear just as quickly. Once agents interact with shared services and production credentials, organizations need consistent guardrails: unified permissions and centralized audit logs. Reproducing that layer across dozens or hundreds of personal machines is possible, but it quickly becomes complicated, and every additional agent increases the surface area that must be managed.

Modern codebases already push local machines pretty hard. Add several agents performing essential tasks at the same time, and the laptop begins to resemble a crowded server juggling too many jobs. The development workflow is increasingly spilling beyond what a personal device was designed to support.

This is where the center of gravity begins to move.

Taking development to the cloud

As development becomes multi-actor by default, it starts to resemble distributed systems we already know how to operate. Those systems run in the cloud.

Cloud infrastructure was built for the characteristics the multi-agent workflow requires: elastic compute that expands when workloads spike, sandboxed environments that keep processes from colliding, and centralized logging that records what happened and when. What feels strained on a laptop is routine in a cloud environment.

Parallel workloads run side by side, isolated environments keep processes from stepping on each other’s state, and shared data lives in systems designed for concurrency. The activity becomes visible in one place, recorded and searchable without piecing together fragments from individual machines.

Coordination still takes work, but the cloud makes it manageable. Multiple agents can divide large tasks, write intermediate results to shared storage, exchange structured context, and continue their work across environments built for distributed execution. Developers can watch the activity unfold in one place and step in when necessary without tearing down the entire process.

Local development will still matter. Editing code and iterating on ideas still benefits from the immediacy of a machine sitting in front of you. What changes is where heavier work happens, like large builds that chew through thousands of files or long-running agents that investigate bugs overnight. In that model the laptop remains the control surface, while execution moves elsewhere.

For a long time, the structure of development mirrored the machine it ran on. One person sat at one computer and executed one thread of work at a time. That dynamic is changing, and as it evolves, the environment evolves with it. The transition will not happen overnight, but the direction is clear. The next era of development isn’t about what fits on a single machine, it’s about what’s possible when the machine is everywhere.

Your team adopted Copilot, Cursor, Claude Code. PRs are flying. But is code actually shipping faster?

More AI-generated code doesn’t automatically mean faster delivery, it often just moves the bottleneck downstream.

Join LinearB TODAY for a hands-on workshop on measuring AI’s real impact across your SDLC. We’ll walk through how to connect AI tool activity to delivery velocity, code quality, and developer experience so you can scale what’s working and cut what isn’t.

Stop guessing. Start measuring.

Reserve your spot

Over 88% of developers use AI regularly, but AI-assisted pull requests merge at less than half the rate of human-authored code. In this episode, Dan Lines and break down the findings from LinearB's 2026 Engineering Benchmarks Report to reveal how AI is fundamentally reshaping software delivery. They explore the stark behavioral differences between unassisted, AI-assisted, and fully agentic pull requests, highlighting how AI accelerates code generation but exposes massive bottlenecks in the review process. Tune in to learn why organizations must prioritize AI readiness, data quality, and context engineering before they can translate raw AI adoption into actual business impact.

1. The rise and fall and rise again of MCP

A provocative new article declares that MCP is dead, and it rightly calls out tech influencers for making it more popular than it needed to be. We certainly contributed to that hype on the show a year ago. Back then, models struggled with consistent tool usage, and MCP was a fundamental change. Today, models are smarter, and many developers are reverting to simpler CLI solutions. However, MCP still solves the crucial problem of distribution. The real takeaway is that our tools are temporary, and we should always expect them to move with us.

Read: MCP is Dead; Long Live MCP!

2. Displacing context compaction

ThoughtWorks released new research on AI coding sessions, detailing how the inevitable onset of compaction in long chat threads causes models to forget the reasoning behind decisions, leaving developers on incredibly shaky ground. The solution is context anchoring, which involves keeping a living feature document that externalizes your context. As I mentioned on the show, “the future belongs to collectors,” and it is fascinating to see how future-proof a habit like keeping markdown files has become in an era where AI needs to know exactly how you arrived at your current state.

Read: Context Anchoring

3. AI will amplify your bottlenecks

Engineering leaders are rushing to deploy AI coding assistants, but many are optimizing the wrong thing. Writing code has rarely been the actual bottleneck in software delivery. Unclear requirements and lengthy review processes are the real constraints. Because AI acts as an amplifier, generating three times the code output becomes completely unmanageable if you have not hardened your other systems. You have to focus on the entire software development lifecycle, not just the speed of code generation.

Read: If you thought the speed of writing code was your problem - you have bigger problems

4. Copilot here, Claude there... now what?

AI tools like GitHub Copilot, Cursor, and Claude Code are adopted across your teams, but are they actually working? Faster code doesn’t always mean faster delivery.

Join us live on March 26 for a product demo on connecting AI activity to delivery outcomes. We’ll walk through a new framework for validating and scaling AI impact on speed, predictability, and DevEx. Don’t just deploy tools - measure what matters.

Reserve your spot

5. The resurgence of the small web

We are entering the post-naive internet. People are retreating from massive, monopolistic platforms and taking their personal data and creativity back to non-commercial personal websites. AI is making it easier than ever to build these spaces. It is a nostalgic return to the early days of the web, but powered by modern inference systems. Instead of being locked into large corporate platforms, we might soon find ourselves turning a variety of personalized cloud services on and off to curate our own digital environments.

Read: The “small web” is bigger than you might think

6. The new workplace etiquette problem

There is a new workplace etiquette problem emerging where people forward raw, unverified AI text to their colleagues. It forces the recipient to spend their own effort distilling the information, which rapidly erodes trust in the workplace. To avoid this, you need to validate every factual claim and judiciously delete the verbosity that models tend to produce. If you are serving raw AI output to your team without checking it, I promise you they are noticing.

Read: Stop Sloppypasta

Autonomous agents are pushing deployment speeds to the absolute limit, but is our security infrastructure ready for the consequences? Andrew sits down with Chainguard CEO Dan Lorenc to discuss the severe supply chain risks of this new frontier and what it takes to safely transition to an agent-first engineering model. They explore how engineering teams can safely accelerate deployments by turning restrictive guardrails into frictionless "guide rails" for their AI agents. Finally, the conversation unpacks the future of open source, detailing how AI might either spam projects into dormancy or solve the ecosystem's long-standing sustainability crisis by stepping in as automated, full-time maintainers.

1. Tokens are tools, not your salary

OpenAI’s Greg Brockman recently suggested that AI compute is driving productivity and becoming part of compensation packages, with some estimates putting token costs at 20% of an engineer’s salary. As someone who consumes a massive amount of tokens, I find this idea completely unacceptable. It is like telling a developer during the dot-com boom that they are getting paid in bandwidth. We are using these tools to deliver exponential output, and the company is capturing that value. Your employer needs to provide the tokens required to do the job, rather than framing a Copilot subscription as a perk.

Read: Silicon Valley is buzzing about this new idea: AI compute as compensation

2. Managing the agentic work environment

We know that engineers need to think more like managers now, but highlights that we also need to actively curate the environment our agents work in. He shares examples like a three-person team at OpenAI building a million-line product over a few months. To achieve this, you have to manage the harness, setting up guardrails and clear alignment from the very beginning. Otherwise, you will spend most of your time refactoring past agent work. Planning is the new coding, and we have to hold AI-generated code to higher standards to avoid accumulating slop.

Read: The Emerging “Harness Engineering” Playbook

Artificial Ignorance

The Emerging "Harness Engineering" Playbook

Earlier this month, Greg Brockman published a thread about how OpenAI is retooling its engineering teams to make them more effective with agents. The initiative was kicked off because of how much thi…

Read more

4 months ago · 67 likes · 11 comments · Charlie Guo

3. Zuckerberg buys the bot network

Meta just acquired Moltbook, the social network built exclusively for AI agents. Ben Lloyd Pearson and I joked that Mark Zuckerberg is obsessed with monetizing artificial relationships, but this acquisition might actually be a massive signal about the future consumer economy. As agentic browsing becomes the norm, ad marketplaces will eventually need to sell to our agents instead of us. Meta is making a bet on owning the spaces where those agents interact. It is a fascinating glimpse into a transformed internet where bot readers outnumber human ones.

Read: Meta acquired Moltbook, the AI agent social network that went viral because of fake posts

4. Growing pains and production databases

recently highlighted a spate of AWS outages tied to the use of AI coding tools. This is a predictable growing pain as we reinvent the software development lifecycle. These incidents are less about rogue AI and more about immature access controls and missing guardrails. It is an uncomfortable process, but it forces us to deeply understand how these tools are interacting with our environments. If an agent can take down a production database, the failure is in the permission structure, not the artificial intelligence.

Read: “A spate of outages, including incidents tied to the use of AI coding tools”, right on schedule

5. Copilot here, Claude there... now what?

AI tools like GitHub Copilot, Cursor, and Claude Code are adopted across your teams, but are they actually working? Faster code doesn’t always mean faster delivery.

Join us live on March 26 for a product demo on connecting AI activity to delivery outcomes. We’ll walk through a new framework for validating and scaling AI impact on speed, predictability, and DevEx. Don’t just deploy tools - measure what matters.

Reserve your spot

6. Escaping the toxic agent race

A recent post by George Hotz perfectly captured the toxic race we are all feeling right now: the idea that if you are not running dozens of agents constantly, you are falling behind. It is an intoxicating but exhausting breakneck pace. The secret to surviving this era is intentionality. Instead of using these multipliers to add complexity to your life, use them to strip away the manual toil. Focus on freeing up your experts to do higher-order work rather than just burning tokens for the sake of it.

Read: Every minute you aren’t running 69 agents, you are falling behind

Right now, a lot of engineering leaders are stuck in the same loop: rolling out AI tools only to watch their teams quietly drift back to business as usual. Andrew sits down with James Everingham, former Head of DevInfra at Meta and current CEO of Guild.ai, to discuss how to break this cycle by treating AI not just as an autocomplete tool, but as a "sentient fabric" woven directly into your software development lifecycle.

They explore how replacing top-down AI mandates with impossible business challenges—like eliminating code freezes entirely—empowers developers to organically build game-changing tools like conversational onboarding agents. Finally, James breaks down why 2026 is the year of the agent and how his team is building the enterprise infrastructure needed to safely govern, audit, and scale collaborative agent workflows.

1. OpenClaw rockets to risky new heights

OpenClaw just rocketed past 250,000 stars on GitHub in a matter of months. One thing is clear: this project has completely left the original audience. Your bus driver and your aunt are starring this repository. People are so hungry for these automated assistants that they are rushing to host them on unvetted cloud services, effectively putting their private data in a panopticon. It is an incredibly cool but equally terrifying experiment. Just remind your aunt to keep her OpenClaw updated, please.

Read: OpenClaw rocks to GitHub’s most-starred status, but is it safe?

2. Navigating the agentic wasteland

Steve Yegge is back with the next evolution of his Gastown concept. He introduces the “Wasteland,” an example of “factory federation”, where engineers can link together their Gastowns via shared wanted boards and multidimensional reputation systems. This is certainly one way to distribute and collaborate with the gains from agentic engineering, one that we’re just at the early stages of exploring. It’s complexity is paired with the signature Yegge flair – he leaves us with an RPG-style character sheet to track our trustworthiness across the burgeoning federation.

Read: Welcome to the Wasteland: A Thousand Gas Towns

3. Agents at the operating system level

Perplexity just announced a general-purpose digital worker that can execute long-running jobs for days or weeks at a time. What makes the Perplexity Computer different is that it operates a computer just like a user can, opening new modalities of browsing and long-running queries and tasks. As I have mentioned on the show before, agents have arrived on an internet that was not built for them. This is an interesting sneak peek into a future where most of your deep, long-term research and browsing happens in the cloud.

Read: Introducing Perplexity Computer

4. Copilot here, Claude there... now what?

AI tools like GitHub Copilot, Cursor, and Claude Code are adopted across your teams, but are they actually working? Faster code doesn’t always mean faster delivery.

Join us live on March 26 for a product demo on connecting AI activity to delivery outcomes. We’ll walk through a new framework for validating and scaling AI impact on speed, predictability, and DevEx. Don’t just deploy tools - measure what matters.

Reserve your spot

5. The ten dollar an hour developer

Geoffrey Huntley said on our show that the cost of software development has plummeted to $10.42 an hour, which is what it costs to run a Claude Code session on a loop. We need to make a critical distinction here. Software development, the act of turning requirements into code, is being replaced wholesale. Software engineering, the act of building architecture and making technical decisions, is thriving. You have to adapt and focus on those higher-order skills because that’s where the real work happens now: deciding what needs to be built and why.

Read: Software development now costs less than than the wage of a minimum wage worker

6. Mapping out the future of our industry

If you are trying to figure out where your new engineering skills fit in this changing world, you need to check out ’s latest project. Built as a Claude artifact, it acts as a philosophical tree of potential futures, mapping out exactly how introducing agents to an industry creates a chain reaction of completely new roles and opportunities. Engineering is about to proliferate everywhere, and this tool can help you discover a life passion or a unique career path that simply does not exist yet.

Read: The Great Zipper of Capitalism

Works on My Machine

The Great Zipper of Capitalism

Jim Barksdale, not the guy from The Wire (that was Avon), the Netscape guy. Before your time maybe. Definitely before mine in any meaningful sense. He said once that basically there are only two ways to make money in business: bundling and unbundling…

Read more

4 months ago · 19 likes · 5 comments · Scott Werner