Today's guest is Stuart Caborn, Distinguished Engineer at Loveholidays, an online travel agency with millions of customers worldwide.

Stuart's team is doing AI coding for real:

• Each engineer deploys to production more than 80 times a month

• Over 60% of production code is written by AI

• All while maintaining an elite change failure rate under 1%, and perfect code health.

If you like the podcast, please give us a rating on your platform of choice! It means a lot to us — that’s how other people discover the show! ⭐⭐⭐⭐⭐

🥇 Interview Summary

If you are a 🔒 paid subscriber 🔒 you will find my own summary of the interview below.

It’s the 5-minute takeaways of what we talked about, with timestamps to the relevant video moments, for those who don’t have time to sit through the 1-hour chat.

Here is the agenda for today:

1. ✈️ The complexity of online travel

2. 🏥 Code health before AI

3. 🤖 Becoming an AI-first engineering team

4. 🛡️ Guardrails, reviews, and trusting the machine

5. 🔄 How AI is changing the development process

⠀Let’s dive in 👇

Read more

These are going to be monthly online gatherings where people can share wins and learnings from using AI, ask questions, and stay up to date about what works.

Join our AI Club 🪄

So today’s post is to explain 1) why I am starting it, and 2) how it works.

🎯 Why I am starting an AI Club

By now AI has taken over most of the online conversation about software engineering.

As I wrote last week, I think this is… largely correct. AI coding is so big and meaningful that figuring it out feels like the #1 priority for us as an industry. I don’t think we are misguided on this.

However, we are also in this very confusing stage where everyone is just trying things for themselves:

• Most teams have little-to-no shared practices / artifacts / ceremonies about AI.

• Opinions online are all over the place, and it’s hard to know who to trust.

• Most of us have very little time to try things out, and zero dedicated time at work to do so.

All of this against a backdrop of anxiety, layoffs, FOMO, and doomsday predictions.

Yay!

AI is also changing how I think about my responsibilities with Refactoring. It is changing the topics I cover, how I spend my time (I am back to coding, a lot), and the type of conversations I have with people.

So, Refactoring should help you run better engineering teams, and a big part of that now is about using AI well — together, as humans.

So I want to host good conversations about it, where people share what they are learning: the exciting wins, the humbling failures, and everything in between.

Sharing things with others not only makes us grow faster together — it’s also great to fight back against anxiety, impostor syndrome, and all the pressure that comes with the push for AI adoption.

So let’s use the Refactoring community as your extended team, where we compare notes and learn things together.

ℹ️ How it works

Here is the gist:

• Monthy 1-hour chat, hosted in the Refactoring Community.

• As with all-things-community, it’s for paid Refactoring members. We gate this to keep people committed and ensure high quality.

• Like our monthly mastermind, it’s facilitated by real engineering coaches, Joel and Melinda.

• I always join the call personally and share the things I have learned throughout the month

• Everyone who joins can share their own “aha” moments — a win, or just something that genuinely surprised them — ask questions, and get to know other community members

• Takeaways from the conversation are shared afterwards in the community in written form, for those who are not able to join.

• Finally, for paid Refactoring subscribers, in the newsletter I will also publish monthly AI updates that combine my own experiments with things that surfaced in community calls.

All in all it’s very simple. We’ll host the first one on May 8th, and we’ll always have them on the first Friday of the month, at rotating times to allow everyone to participate.

🔒 About the Refactoring subscription

Allow me a quick paragraph about the Refactoring subscription, which you might be considering joining.

It’s $15/month, or $150/year, to access the Refactoring community, all of our archive (300+ articles) carefully organized by topic, plus our weekly original long-forms about the latest and greatest engineering practices.

The community has bi-weekly events, professionally run, that alone would cost >$100 to join — each!

So if Refactoring helps you make just one better decision, thanks to something you read, or learned from someone in the community, chances are the subscription repaid itself for the full year.

I would love to have you onboard! 1500+ engineers have joined this already 👇

Join our AI Club 🪄

And that’s it for today!

Sincerely 👋
Luca

How Augment Code is going AI-native

Today’s sponsor is Augment Code!

The guys at Augment have been documenting how they are transforming their engineering team to be AI-first, in several great blog posts:

• How we hire AI-native engineers now

• Confidence is the new bottleneck

They would also love to hear from other leaders going through the same thing, and have been running a quick survey for this. You can find it below 👇

Check out the 5-min survey

💡 Just ask engineers

By now, as of 2026, there is solid consensus that good developer experience is upstream of how your engineering team performs as a whole. And good devex is, in turn, mostly about removing friction from the daily work of engineers.

To remove friction you first need to know where it hides. What are the biggest blockers for your team? What is slow, hard, or simply a waste of time?

As engineers, we have a natural bias towards telemetry — quantitative data taken automatically from our processes, so we can debug it as if it were software. This is increasingly backed by research, from Accelerate onwards, and I have written extensively about it:

• How to get started with engineering metrics

• What’s next in measuring dev productivity

• You have metrics, now what?

To summarize what I think about metrics: they are good, but they are not enough. Most metrics are cues that something is (or is not) working, but they don’t tell you what the problem is. They are lagging indicators: to find the actual blockers, you need to dig deeper.

How? The answer is usually deceptively simple: ask engineers. They know.

If you combine qualitative signal from engineers’ opinions with quantitative data from your systems, you’ll be unstoppable. But counterintuitively, most managers find it harder to do the former—have good conversations to identify problems—than the latter.

So, I am a fan of doing the so-called Listening Tour, whose name I lifted from Frictionless, but whose execution I tweaked based on my own experience. I wrote a full piece about it at the start of the year, and I still stand by it 👇

Refactoring

The Listening Tour 📞

For the last month I have been running a program for CTOs and VPs of small to mid-size companies to help them make their engineering teams ship faster…

Read more

3 months ago · 35 likes · 3 comments · Luca Rossi

🎙️ Past behavior predicts future results

With tech chops getting a bit diluted by AI, behavioral interviews have recently gotten into the spotlight as a crucial way to select good engineers. Always have been? Probably — but today, even more so.

I recently talked about this on the podcast with Austin McDonald, former hiring committee chair at Meta. Austin said behavioral interviewers are essentially forecasters: they study your past performance to predict your future results. And, with people, this generally works (unlike with financial portfolios!)

Austin breaks down what interviewers look for into signal areas:

• 🎯 Scope & ownership — how large a project can you handle, and do you drive it forward without being asked?

• 🌫️ Ambiguity & perseverance — how do you navigate unclear situations and push through setbacks?

• 🤝 Conflict resolution, communication & leadership — how do you handle disagreements, convey ideas, and rally teams?

These signal areas map closely to most company values, but not always one-to-one. Newer AI companies like Anthropic, for instance, look for safety-oriented signals about thinking through the implications of building AI.

So Austin recommends combining general areas with company-specific research—their website, recruiter conversations, YouTube talks—to build a complete picture of what you’ll be assessed on.

“Every question they ask has this kind of thing behind it. Especially follow-up questions. People often forget — when they get a follow-up question, they just think the person wants more information. Instead, think: why are they asking me this?”

In fact, companies exist on a wide spectrum:

• Amazon sits at one extreme end with 16 rigorously enforced leadership principles.

• Meta is in the middle with five structured behavioral areas.

• Google has traditionally leaned more technical.

Here is the full interview with Austen:

You can also find it on 🎧 Spotify and 📬 Substack

📚 Weekly Readings

Finally, here are the best articles I have read this week:

🥇 The Git Commands I Run Before Reading Any Code

3 min • by Ally Piechowski

Great piece that makes you understand the power of version control history. There is so much you can understand about a codebase (and a team) by running simple git commands. Hotspots, bus factor, bug clusters, crisis patterns — all from git history.

🥈 Feedback Flywheel

10 min • by Rahul Garg

I really liked this article — it’s very practical and proposes some novel angles to AI feedback. Every AI interaction generates signal: prompts that worked, context that was missing, patterns that failed. Rahul proposes a structured practice that takes learnings from AI sessions and feeds them back into the team’s shared artifacts.

🥉 The Human Weight of It

7 min • by Cate Huston

Can Claude replace coaching? Cate has been experimenting: using AI for structured issues, but keeping her human coach for the messier stuff. AI is great when you need structure and validation. But when you need to feel seen, you need the human weight of someone else’s confidence in you. I loved it.

And that’s it for today! If you are finding this newsletter valuable, subscribe to the full version!

1700+ engineers and managers have joined already, and they receive our flagship weekly long-form articles about how to ship faster and work better together! Learn more about the benefits of the paid plan here.

Make your team ship faster!

See you next week!
Luca

I received a lot of private comments, most of which can be organized into two categories:

• People wanting to learn more about the coding workflow itself.

• People wanting to learn more about the note-taking app I am building.

Both types of comments motivated me a lot, to the point where I decided to make all of this an official part of my Refactoring work, as follows:

• I am going to build this app for real, make it free and open source for everyone, and keep working on it as an ongoing effort.

• I am going to report my learnings about AI coding as part of the regular writing schedule, let’s say once a month or so.

I am convinced this is the right thing to do because, frankly, getting AI coding right is the #1 problem in software engineering today, and it’s not even close.

The economics of software are changing so much that there is no part of the process that is safe. Code reviews, QA, planning, staffing, traditional management — everything feels up for grabs and downstream of what happens with coding.

Also, while I love doing research and talking with others (e.g. on the podcast), opinions are so scattered across the board that I feel the strong need to try things myself, and do so in a serious, ongoing way.

So here is today’s agenda:

• 💧 Building Tolaria — a personal knowledge management app for the age of AI.

• 🦞 OpenClaw vs Claude Code — how I use them, and to do what.

• 🔧 Coding workflow — what changed vs one month ago, and what stayed the same.

• 📑 ADRs — the best recent addition to my coding.

• 🎨 Product workflow — how I create specs.

• 💸 How much I am spending — because I know y’all want to know that.

• 🤖 CLAUDE.md — bonus: my current Claude file, attached in full.

Let’s dive in!

💧 Building Tolaria

In the last article I said that what I was building didn’t matter much, well now it kinda does, because you are going to hear a lot more about it in the future.

Tolaria is a personal knowledge management app, extremely opinionated and tailored for my own personal use, but I hope it can be useful to others too.

It’s worth noting that this is not a particularly original idea. There exist plenty of tools in this space — Notion, Obsidian, Craft, Roam, and more — and most of them are very well made. Still, I know plenty of smart people who lately have been experimenting with weird setups.

Just last week, Karpathy wrote a viral tweet exactly about that.

Why such a renewed excitement around knowledge management? Because everyone who tries to work seriously with AI agents eventually understands that this is a core problem to solve: continuously supplying agents with reliable, up-to-date information about your life and work, and creating a good collaboration surface on these.

I suspect this still feels a bit abstract, so I’ll make a few examples from my own work:

• An agent should periodically fetch meeting summaries from tools like Fathom or Fireflies, create a note for the meeting with the summary and action items, and link the note to individual attendees (each of whom should have a page for themselves). If there are attendees who are new, the agent should create individual notes for each of them, enriching my personal CRM.

• An agent should receive voice notes from me and turn them into long-term notes and tasks, and connect them to the relevant existing pages.

• An agent should take every new article I write and split it into atomic evergreen ideas, connect them to similar ideas I have already saved in the past, and better organize my knowledge base so that it’s easier to write new articles in the future.

• An agent should suggest new article topics and podcast guests based on my recent readings and how these connect to things I have written in the past and interviews I already did.

In terms of intelligence required, most of these tasks are trivial. But they need a good collaboration surface 1) for agents to fetch the relevant info and 2) for me to work well with them.

Tolaria is my attempt to build this for myself first, and hopefully for some others too.

It will be completely free and open source, so that it also works as a visible artifact of my understanding of how to create products with AI, for other people to inspect.

At any given time, if you want to know e.g. what I write in my CLAUDE.md, or how I write docs, or what types of tests I write and which I don’t — you shouldn’t just trust my articles, you should be able to go to the repo and see for yourself.

This way, the ideas you read on Refactoring become the result of three things:

• 📚 Research — I read and collect experiences from others.

• 💬 Conversations — I go deeper by running community events and 1:1 podcast interviews.

• 🔧 Personal work — I do coding and product development myself to stress-test these beliefs.

All of these elements are meant to be public: you can get weekly digests of what I read, listen to the podcast conversations, join the community to chat with me (and others), and inspect the Tolaria codebase (soon!) to see how I write code.

Tolaria is not ready yet but it will be in a couple of weeks!

So where are we today? Here is an exec summary. Since I started working on it around mid Feb, here is what I got:

• 1526 commits — that is ~30 commits/day on average

• ~70K LOCs — about 45 lines / commit

• ~3000 tests — about 85% coverage

• 9.5/10 code health — as measured by CodeScene

• 40+ ADRs — to track our core tech choices, plus three summary docs for Architecture, Abstractions, and Getting Started.

That’s 2.5x the amount of code we had last month (we were at 20K LOCs), with better code health (9.5 vs 9.3), and better docs. I am still not writing any code, and I am still reading very little of it.

The product also got way better to the point where, by now, I have fully replaced my Notion workspace. It still feels surreal to say that out loud, after 6+ years of really intensive Notion usage, but here we are.

So let’s get into how I work on it, starting with coding 👇

🦞 OpenClaw vs Claude Code

In last month’s post I said that basically I acted as CEO, OpenClaw worked as a PM, and Claude Code worked as a team of designers + engineers.

Has any of this changed? Yes, and no. Roles are still kinda the same, but I am not using Claude Code strictly together with OpenClaw anymore, in the sense that the latter directs the former, but more in an async way. This change has been driven by three reasons:

• 💸 Cost — the initial workflow in which OpenClaw steered CC all the time was wildly inefficient in terms of token spend.

• 🎓 Capabilities — CC has caught up with a lot of OpenClaw stuff. Most of all, it has loops now.

• 👮‍♂️ Legal — most recently, Anthropic has explicitly banned this type of usage, but to be fair I had stopped it already.

So by now my OpenClaw and Claude Code work on separate things, in a completely asynchronous way:

• OpenClaw turns my inputs into product specs, checks on the general status of things, brainstorms new ideas, and in general does the work that benefits from broad context.

• Claude Code does all the technical work, including coding, writing ADRs and docs, and, crucially, QA, that was done by OpenClaw before.

OpenClaw doesn’t interact with Claude Code anymore, but it periodically checks that it doesn’t get stuck or crashes (which can happen for a variety of reasons). In that case, it restarts it.

🔧 Coding workflow

This article is largely meant to work as a delta vs my original AI coding article to highlight things that have changed, but it’s also worth noting the good stuff that has not changed.

The highest leverage parts of the AI coding workflow are still probably the CI gates on code health and test coverage. These gates exist in two places:

Read more

Make your team ship faster!

Resources: 🏛️ Library • 💬 Community • 🎙️ Podcast • 📣 Advertise

Build with Intent 🔭

This is brought to you by today’s sponsor, Augment Code!

It is no secret that I am a fan of what Augment Code is building, and I am especially a big fan of Intent, their developer workspace where agents are coordinated via live specs.

Intent was created by Amelia Wattenberger, with whom I talked on the podcast last month about what comes after the IDE. We also wrote an article together about what it means to translate specs at different altitudes, from the original product intent (pun intended) to the final code. We called it: the telephone game of software 👇

You can learn more about Intent, Augment Code, and Amelia’s work below.

Learn more about Intent

1) 🎯 In your AI context, share the why

Most of the conversation about how to create good AI context for coding focuses on tactical parts, like PRDs, tech specs, or dev process conventions.

These are obviously important, and basically cover what should be done, and how.

There is a third category of context, though, that feels a bit underrated today, which is about the why.

Let’s say you are not simply developing a new feature, but you want to get help from the AI to find architecture improvements, refactoring opportunities, or make some product strategy. To do that, the what is still up in the air, and the how is largely not relevant yet. Instead, you need context on why something would be valuable to have.

Why context can be evergreen (e.g. your principles, values, the business domain), about the future (e.g. your quarter goals), and about the past (e.g. your past goals, ADRs).

This stuff is not always important to perform some task, but in cases where it is, it is invaluable. So, before you even think about AI, you can ask yourself questions like:

• How much of this is written down?

• Has everyone access to it? Do they know where it is?

• Do people think it’s important? What does it happen if they ignore it?

I wrote a full guide about context engineering earlier this year 👇

Refactoring

How to Manage Context in AI Coding 📑

Last month I had the privilege to keynote at the CTO Craft Conference in Berlin, where I tried to paint a broad picture of how engineering teams are using AI today…

Read more

5 months ago · 57 likes · 1 comment · Luca Rossi

2) 🎙️ Functional vs cross-functional teams

A couple of months ago I interviewed Gonçalo Silva, CTO at Doist.

Among other things, Gonçalo told me Doist organizes engineering into functional teams (Android, iOS, Frontend, Backend, …) rather than cross-functional product teams, because it allows them to create a culture of deep expertise and passion:

“When we hire for our Android team, we go after people who are really passionate about Android, and then we put them in an Android team where they own the Android apps. When you pair control and passion, usually you get a lot of taste back.”

To ship features, they assemble temporary squads each quarter, staffing them based on project needs. This creates flexibility: e.g. when COVID hit, they were able to pivot almost the entire company to work on Twist within four weeks.

The flip side is that continuity can suffer. A feature might launch, but two months later when interesting feedback arrives, nobody’s actively working on it anymore. So there’s no perfect system, and Doist intentionally optimizes for agility over long-lived domain expertise.

Their product team is also extremely lean: just four people (including the head of product) supporting about 30 engineers working on product-related work. Engineers are expected to be autonomous and opinionated: they dogfood their own products daily, so everyone has informed perspectives on what to build next.

Here is the full interview with Gonçalo:

You can also find it on 🎧 Spotify and 📬 Substack

📚 Weekly Readings

Finally, here are the best articles I have read this week:

🥇 Every Layer of Review Makes You 10x Slower

11 min • by Avery Pennarun

Awesome piece that many many people I know need to read. Every layer of review makes your process exponentially slower — and AI can speed up the coding part, but it does nothing against the time spent waiting for others to do stuff. Reducing reviews is less about AI and more about building a culture of quality and trust.

🥈 The Middle Loop

7 min • by Annie Vella

AI is shifting engineering work from creation to verification: Annie calls it the middle loop, sitting between the inner loop (writing code) and the outer loop (CI/CD, deploy). A useful mental model for how the day-to-day of engineering is evolving.

🥉 Don’t Let AI Write For You

2 min • by Alex Woods

Writing is fundamentally about structuring your thinking. Producing text is simply a (nice) byproduct of it. So, using LLMs to write for you undermines both your credibility and your ability to reason deeply. Use them for research and brainstorming, but the final words should be yours.

4) AI “Aha” Team Meetings

7 min • by Lara Hogan

There’s a growing gap between engineers who are thriving with AI tools and those who feel left behind. Lara held many interviews to learn more about how teams work today. She proposes regular team meetings where people share their AI aha moments: tips, tricks, and even mistakes.

And that’s it for today! If you are finding this newsletter valuable, subscribe to the full version!

1700+ engineers and managers have joined already, and they receive our flagship weekly long-form articles about how to ship faster and work better together! Learn more about the benefits of the paid plan here.

Make your team ship faster!

See you next week!
Luca

Today’s guest is Chris Lattner, one of the most important engineers for modern computing. Chris invented key compiler infrastructure tech like LLVM and MLIR, but he’s also the inventor of the Swift language, a key contributor in bringing Google TPUs to market, and a lot more. Today he’s the founder and CEO of Modular, where he’s reinventing AI infrastructure to make software portable across GPUs and platforms.

With Chris, we talked about his vision for AI and computing. We talked about how Modular’s mission makes us closer to a future where AI is open and portable. And we talked about open source, how AI is both empowering and straining contributors, how it’s changing intellectual property, and what workflows we need to change as engineers.

Finally, we discussed how AI is changing software craftsmanship, how he’s bullish about junior engineers, and a lot more.

If you like the podcast, please give us a rating on your platform of choice! It means a lot to us — that’s how other people discover the show! ⭐⭐⭐⭐⭐

🥇 Interview Summary

If you are a 🔒 paid subscriber 🔒 you will find my own summary of the interview below.

It’s the 5-minute takeaways of what we talked about, with timestamps to the relevant video moments, for those who don’t have time to sit through the 1-hour chat

Here is the agenda for today:

1. 🔧 Modular’s mission and the GPU accessibility gap

2. 🌐 Open source in the age of AI

3. ⚡ AI and software craftsmanship

4. 👩‍💻 Junior engineers, manager thinking, and team building

5. 🏗️ Best practices under pressure

Let’s dive in 👇

Read more

In that piece we argued that software engineering was undergoing a transformation from craftsmanship to factory work, with the gap between elite and average teams being more and mor…

Read more

I am repeating last week’s experiment of adding the best articles I have read last week, other than the classic weekly ideas. Let me know if you like it!

To access all our articles, library, community, and support my work, subscribe to the full version of Refactoring.

Subscribe now

Read more

In some cases, we even invented words we didn’t use before, like context, or, one of my favorite lately, intent. These words are abstractions—our bread and butter as engineers—and are born out of the necessity to discuss ideas, understand what’s going on, and improve how we work.

The intent concept is both important and, AFAIK, quite novel. These days you may hear it in sentences like “making sure PMs’ intent is captured into specs”, or “AI code should reflect the engineers’ intent”.

This angle frames software engineering as a translation act between something you want to achieve and what gets actually captured in artifacts like specs, UI design, up until code. If we continue this analogy, translation happens at every step, with different steps following different rules. Many engineering practices exist essentially to reduce the error rate of such translation.

So, seen through this lens, software development becomes an elaborated version of the telephone game. You win the game if the message is passed properly and ends up in… production.

That said, what the steps of the telephone game are (or should be), or what the best winning strategy is, frankly, it’s all up for discussion today. Should we write big specs beforehand? Should we keep human code reviews? Who should do this and that, and when, and how often?

Today I want to explore this, taking from what I have personally learned from my recent coding efforts, and ideas I bounced off with Amelia Wattenberger, who I interviewed last week on the podcast, and is joining me today on this piece.

So here is the agenda for today:

• 🔀 From intent to code — the journey of translating what you really want to do

• 🧱 Creating good platform — for each step of the journey, so AI doesn’t mess things up.

• 🛫 Staying at the right altitude — evolve your artifacts to match what you want to inspect

• 🔬 Using product to improve understanding — not just to implement it.

Let’s dive in!

Disclaimer: Amelia works at Augment Code and created Intent, a developer workspace with strong opinions about all of this. Augment is a long-time partner of Refactoring, I use it, I am a fan, and I am happy if you check it out.

Learn more about Intent

However, we are not here to promote Augment today, but rather compare notes about problems and try to predict where the puck is going. (The puck, Luca? In a telephone game? Yes)

🔀 From Intent to Code

Starting from something you want to achieve on the product you are building, then it’s a long way to encode that into, well, code.

Intermediate steps may vary based on your process, but you probably have some version of these:

1) Product intent

A high-level, one or two-sentence version of what you want to build. It may only live in your head.

Making an example from my own experiments (I am building an editor), let’s say I want to add split panes, like many editors have. In my head, that’s it. I don’t think about it a lot more.

2) Product specs

Product intent needs to be turned into a spec, like a PRD, which needs to stay faithful to my original intent, while deciding a lot more things.

How is this triggered? Is there a button? What does it look like? What about keyboard shortcuts? What happens if I drag a tab from one pane to the other? And more.

Some of these are just additional detail, but some might derail the feature in a direction I didn’t intend. For example, a legitimate interpretation might be to open up the tab in a new window, which is not what I want.

3) UI/UX design

Product specs are turned into design specs. What it looks like, how it behaves, where it lives.

4) System design

Product and design specs inform the strategy to implement this with code. Abstractions that should be reused or created, data structures (when relevant), migrations, instrumentation, testing, rollout and rollback, and more.

5) Code!

Finally, there’s code! All of this turns into a bunch of LOCs, to be pushed, reviewed, and released in prod.

Phew. That’s a lot of work.

Of course YMMV and you may skip creating actual artifacts for some of these steps, based on the complexity of the work at hand, and your team's workflows. But there are at least decisions to be made about all of these, even without the artifacts:

• Every step adds details that the previous kept implicit or simply did not consider.

• Every step can act as a lossy translation of the original intent. It can miss important details or interpret them incorrectly.

What is our goal with respect to this process? The ultimate goal is always to ship value to customers as fast as possible, so you can get feedback and iterate.

To ship fast you want to avoid rework: you want to reduce the misunderstandings between the various steps and the mistakes that would make work move backwards instead of forwards. You want code abstractions that match the PRD, a PRD that matches the product intent, and not getting to the point where a review fails and some of this gets back to the drawing board.

This angle is relevant with humans, and especially relevant with AI. AI models today are really good, and it feels most of their mistakes now come from not understanding what you wanted, rather than e.g. bad coding skills.

So how do you get good at this? The most convincing way, to me, is:

• Creating good platform for each step — which acts as guardrails and helps you minimize the amount of intent you need to encode into specs.

• Use specs as active collaboration surface — updating it with more details as the work progresses, so it stays at the right altitude all the time. Kudos to Amelia for making me think about this.

Let’s explore both 👇

🧱 Create good platform for each step

Read more

To celebrate this milestone I want to experiment with some tweaks. Instead of our classic three ideas, today I am going to post:

1. 🧵 One idea from a recent article I wrote.

2. 🎙️ One idea from a recent podcast interview we did.

3. 📚 A small digest of the best articles I have read this week…

Read more

Today’s guest is Amelia Wattenberger, former principal research engineer at GitHub and now Partner at Sutter Hill Ventures.

But she’s also a Product Lead at Augment Code, where she developed Intent, a developer workspace for orchestrating AI coding agents and delivering complex work. So this is a fascinating chat into the future and the present of software development with someone who has clearly been at the very frontier of this for many years.

If you like the podcast, please give us a rating on your platform of choice! It means a lot to us — that’s how other people discover the show! ⭐⭐⭐⭐⭐

🥇 Interview Summary

If you are a 🔒 paid subscriber 🔒 you will find my own summary of the interview below.

It’s the 5-minute takeaways of what we talked about, with timestamps to the relevant video moments, for those who don’t have time to sit through the 1-hour chat.

Here is the agenda for today:

1. 🧩 What is Intent and why rethink the IDE

2. 🤖 Orchestrating agents and smart defaults

3. 📋 The living spec as a control plane

4. 🚀 How AI multiplies (or doesn’t) different engineers

5. 🔮 The changing shape of roles and specialization

⠀Let’s dive in 👇

1) 🧩 What is Intent and why rethink the IDE

The IDE has been around for nearly half a century, and every single pixel in it is devoted to reading and understanding code. But as AI agents get better at the nitty-gritty of code comprehension, Amelia argues our role as developers is shifting toward higher levels of abstraction — and our tools haven’t caught up.

Intent is Augment Code’s take on what comes after the IDE. Its core primitive is the workspace: for any piece of work, you spin up an isolated environment that bundles a copy of your codebase (with its own branch and Git worktree), a set of agents, rich markdown notes, terminals, and a spec. You can run multiple workspaces at once, switching between tasks without the mental overhead of juggling Git branches or remembering scattered chat conversations.

“Every single pixel in the IDE is devoted to reading and understanding code. And it feels like as agents get better at the nitty-gritty, our role as developers has changed, where we’re working more at higher levels of abstraction, where we have more leverage.”

Amelia describes how we’ve essentially “hacked” AI into existing primitives — chat in the IDE, chat on the command line, chat on GitHub — without rethinking what the interface should look like when developers spend more time on intent and planning rather than writing individual lines of code. Intent is an exploration of that question.

2) 🤖 Orchestrating agents and smart defaults

One of Intent’s most opinionated design choices is how it handles agent orchestration. By default, the app ships with specialist personas — a coordinator that delegates to implementers and verifiers — but everything is tweakable through natural language settings.

Amelia explains why splitting agents into focused roles works better:

Read more

Read more

Last year we explored AI adoption, while …

Read more

Read more

Today’s guest is Richard Hughes-Jones, a professional executive coach with more than 20 years of experience.

With Richard, we talked about:

• how to coach tech leaders through uncertainty;

• everything that’s going on with AI, how to navigate it, how we should think about our role, and what it means to step outside of the framework;

• how to leverage AI for coaching, how to blend human and AI advice to get the best of both worlds.

If you like the podcast, please give us a rating on your platform of choice! It means a lot to us — that’s how other people discover the show! ⭐⭐⭐⭐⭐

🥇 Interview Summary

If you are a 🔒 paid subscriber 🔒 you will find my own summary of the interview below.

It’s the 5-minute takeaways of what we talked about, with timestamps to the relevant video moments, for those who don’t have time to sit through the 1-hour chat.

Here is the agenda:

1. 🧭 From strategy consulting to coaching tech leaders

2. 🌀 Leading through uncertainty and complexity

3. 🧱 Going post-framework

4. 🪞 Inner work, polarities, and safe-to-fail experiments

5. 🤖 Leveraging AI for coaching

Let’s dive in 👇

Read more

If you run an engineering team, though, most of these opinions won’t feel useful to you. In fact, when I talk with people about e.g. some AI workflow, I usually get two types of objections:

1. Volatility — the advice may become obsolete in just a few months, or weeks.

2. Applicability — the advice doesn’t seem to apply to their team, because of X, Y, Z.

These problems often come together. I’ll give an example.

One of the recent trends about how to work with AI, on which there is more consensus, is Spec-Driven Development. There exist plenty of articles and frameworks to work with it, even created by prominent companies like Github. So it’s not a total consensus, mind you, but it’s about as much as you can get in these messy times.

Still, as a CTO, you may have legitimate worries:

• Is this worth investing in? Or may the AI tomorrow (i.e. next month) just figure out more of the specs by itself?

• Is this a good fit for our team? How do we harmonize it with how we have been creating PRDs and design docs up until now? Is there a way to work with AI that leverages how we already work, without the need to migrate to a different workflow?

These questions are 100% valid, and the result is often analysis paralysis: teams underinvest in AI because no approach feels durable or authoritative enough to graduate from individual experiment to team practice.

I believe the main problem is that most ideas are just tactical. They may work, but need to be placed within a bigger strategy — a wider map of how to think about our teams, AI, and how to work together.

So today I want to write about the ideas that feel the most durable to me, and on which I am confident we can create good foundations.

These ideas come from many places:

• My own experiments — as you saw last week.

• Talking with 100+ tech leaders — this year alone in 1:1s, masterminds, and community threads

• Our own industry report — where we surveyed 350+ teams and which we’ll release in March

• Our cohort program — where I work with a small group of ~10 CTOs and VPs to help their teams ship faster.

All in all it’s like a small think tank, and I am here to report findings!

These findings are actually quite simple (like all good models!), and are about three areas:

1. 🔧 Developer Experience

2. 🪄 AI

3. 🎨 Product Engineering

In my experience so far, these areas work like layers of a pyramid. Each layer creates value only if what’s beneath is taken care of. Think of it like Maslow’s pyramid of software engineering.

So let’s explore them one by one, recap what we know about them as of today, and how they work together for good.

🔧 Developer Experience

Read more

Make your team ship faster!

Resources: 🏛️ Library • 💬 Community • 🎙️ Podcast • 📣 Advertise

Read more

And it’s not random teams: it’s usually the best ones. If you don’t trust my anecdotal evidence, just look at recent reports. The very best teams, who had the best DX and code quality before AI, are the same who are getting the most out of AI today.

Still, it’s not 100% clear how these teams work with AI. The internet is full of opinion pieces and people sharing their CLAUDE.md files, but these feel tactical at best, and dubious/fake at worst.

I don’t want to add more of these. The proof is in the pudding, so I said to myself: if I want to write about AI coding, I need to build something.

So here we go.

For the last 17 days, I have been working on a personal project for a macOS app. Scope and complexity are daunting enough to force me to think architecture, buy vs build, performance, rich UI, and everything I would need to cover in a real—not toy—software project. And needless to say, I would never be able to pull this off without AI.

Before I give you more details, let’s start with what I got today so far:

• 772 commits in 17 days, for ~20,000 lines of code overall.

• 90% test coverage — via 500+ unit, integration, and E2E tests.

• 9.3/10 code health — as measured by CodeScene.

• A clear, hierarchical set of docs — to navigate architecture, abstractions, and codebase structure.

• A perfectly usable MVP — which I am, in fact, using every day.

I figured out and improved various parts of the workflow over time, so that now I am comfortable with:

• Not writing any code.

• Not reading almost any code. Say I read ~5% of it.

• Not providing UI design for ~90% of the features.

• Managing most interactions async via voice notes.

• Having AI work autonomously for long stretches of time, so I can do something else in the meantime.

So let’s dive into all of this, in detail. Here is what I am going to talk about:

• 🖥️ What I am building — because nothing else matters.

• 🎨 My product workflow — how I work as a PM.

• 🔬 How I keep tech quality — how I work as a CTO, without reading the code.

• 💰 How much I spent — the numbers nobody shows.

• 🔮 What’s next — my takeaways so far, and some obvious predictions.

🖥️ What I am building

Read more

Make your team ship faster!

Resources: 🏛️ Library • 💬 Community • 🎙️ Podcast • 📣 Advertise

Read more

Today’s guest is Austen McDonald, former hiring committee chair at Meta, and author of the book, “Mastering Behavioral Interviews.”

Austen, in his career, conducted more than 1,000 interviews and coached more than 200 engineers, and is here today to tell us everything about why behavioral interviews are more important than ever and how to run them right, as a candidate and as a recruiter.

So let’s dive right into the action.

If you like the podcast, please give us a rating on your platform of choice! It means a lot to us — that’s how other people discover the show! ⭐⭐⭐⭐⭐

🥇 Interview Summary

If you are a 🔒 paid subscriber 🔒 you will find my own summary of the interview below.

It’s the 10-minute takeaways of what we talked about, with timestamps to the relevant video moments, for those who don’t have time to sit through the 1-hour chat.

Here is the agenda for today:

1. 🎙️ Why behavioral interviews matter more than ever

2. 🔍 The question behind the question: signal areas

3. 🎯 The big three questions & how to nail them

4. 🛠️ Building your story catalog & delivery framework

5. 🤖 AI’s impact on hiring and what interviewers look for now

⠀Let’s dive in 👇

Read more