I did that to solve my own problems and to get my hands dirty with AI coding. In other words, I wanted to walk the talk, and then write about it here on Refactoring.

Little did I know this would feel more like speedrunning the talk.

Tolaria has now several thousand daily users, 10K stars on Github, and last week it was the 10th fastest growing repo… in the world, as measured by Star History.

To put things in context, there are only about ~5K repos in the world with more than 10K stars, out of ~30M.

This is of course, incredibly flattering and energizing, but I also joked with friends that I have been glued to my chair non-stop for these two weeks, because all this interest also posed very real operational problems.

Users, in fact, who are mostly engineers, contributed hard — and I am glad they did! As of today, Tolaria has received:

• 200+ issues on Github

• 150+ PRs

• 150+ feature requests on Canny

So I had to create workflows to help handle all of this: to ensure issues would be fixed fast and people would get feedback about ideas and contributions.

Fast forward to today, I am pretty happy with how it is going, and as I write this, we are down to:

• 15 open issues

• 11 PRs

• 81 feature requests

Today’s newsletter covers all these workflows and how I “survived” these two weeks, while only working part-time on Tolaria, and the rest of the time on Refactoring — in the meantime I also had to publish 4 newsletter editions and 2 podcast episodes.

So here is the agenda:

• 📥 Inputs — mapping and normalizing sources and channels.

• 🗃️ Backlog — turning everything into a single prioritized list from which agents can take work.

• 🔍 Validation — is it the one true bottleneck, as everyone is fond of saying these days?

• 🚀 Release — making work available to everyone and updating all the input sources.

• 📊 Analytics — tracing what happens in production.

Let’s dive in!

📥 Inputs

I have never maintained a sizable open source project before, so you’ll forgive me if some of what I am about to say will sound trivial to you.

At any given time, there are several types of inputs Tolaria receives, that can spawn work to be done:

1. Bug reports from users

2. Feature requests from users

3. PRs from contributors

4. Crash reports from telemetry (Sentry)

5. My own ideas (hello 👋)

These are all separate channels but, with some degree of simplification, they spawn two types of work: bugs and features.

More specifically:

• #1 and #4 spawn bugs

• #2 and #5 spawn features.

• #3 (PRs) can spawn either, but mostly features.

#1, #2, and #3 originally all lived in Github Issues, but bugs and feature requests have different needs and deserve to live in separate places. In fact:

• Bugs — only need to be replicated and squashed as soon as possible. I am a strong believer in a zero-bugs policy: catching bugs as soon as they are reported, and fixing them all ASAP. All in all, there is very little to decide about bugs.

• Feature requests — are another story. They benefit from being voted on (you want to see how many people want something), are generally bigger, so you may want to flag things as planned or in progress so users are notified, need to be specced, and, of course, you don’t want to build those that don’t match your vision. That’s a lot more to decide.

From a workflow standpoint, bugs are easy, features are not — which is why today we are down to only 15 open bugs out of 200, but still 80+ open feature requests out of 150.

The way I manage this is by keeping bugs on Github Issues, and feature requests on a separate product board on Canny.

To make people understand this, I created a rich “contribute” panel inside Tolaria where you are routed to different places based on how you want to help:

Still a lot of things go wrong all the time:

Read more

Stop babysitting your agents! 🙅‍♂️

Today’s newsletter is brought to you by our friends at Unblocked!

Agents can generate code, we know it.

But getting it right for our system, conventions, and past decisions is still the hard part — we waste time and tokens in correction loops. Patching many MCPs together may give agents access to information, but not necessarily understanding.

That’s why I am a fan of what Unblocked is building with their context engine — giving agents exactly what they need to understand things and succeed. Join their webinar on May 6th (free) to see:

• Where teams get stuck on the AI maturity curve

• How a context engine solves for quality, efficiency, and cost

• Live demo: the same coding task with and without a context engine

Learn more and register!

💡 Personal leverage is now unlimited

A couple of months ago I wrote about my experience with OpenClaw — what I do with it, what procedures it runs automatically, and so on.

I also argued that the story of OpenClaw itself seems to point to the idea that a good solo engineer can now achieve… pretty much anything. Look at the progression of AI assistants and coding tools:

1. At first, it was VS Code + Copilot. Created by Github/Microsoft, which is a big tech.

2. Copilot was surpassed by Cursor, created by a team around 1/100th its size.

3. Cursor was then surpassed by Claude Code, which has been created literally by 2 engineers inside Anthropic, and whose team to this day is ~20 engineers.

4. OpenClaw has been created by Peter Steinberger. That’s it.

In my (very small, comparably) experience with Tolaria, I am seeing this as well. If you are equipped with the right set of ingredients, it’s hard now to see the limits of what a single engineer can do. But what are these ingredients? To me it’s:

1. 🔧 Tech skills — you still need these! Especially to steer a sizable project. E.g. Peter is first and foremost a world-class engineer.

2. 🧑‍🍳 Taste — your personal taste for what good looks like, your domain expertise, how knowledgeable you are about the problem you want to solve, your product senses — these are the things that AI is not going to replace anytime soon, if ever.

3. 🏃 Drive — above all, the drive and discipline needed to put something out there. I know an awful lot of people who have the first two ingredients, but kinda miss this one.

My OpenClaw article is one of the most popular pieces I have ever written, you can catch up with it below 👇

Refactoring

My experience with OpenClaw 🦞

Hey, Luca here! This is a 🔒 weekly essay 🔒 from Refactoring! To access all our articles, library, and community, subscribe to the full version…

Read more

3 months ago · 53 likes · Luca Rossi

🎙️ Junior engineers will just be fine

Last month I interviewed the legendary Chris Lattner on the podcast. Chris created LLVM, Swift, led Tesla autopilot, brought TPUs to the market at Google, and more! He is now the founder of Modular, where he creates portable infra to work with GPUs.

Chris told me that, despite the industry-wide narrative that AI favors senior engineers, Modular is actively hiring a ton of new college grads and interns. Chris’ reasoning is based on two observations:

• 🧠 AI-native thinking — junior engineers bring a completely different expertise. They are native to the tools and adapt faster than many experienced engineers.

• ⚖️ Team balance — good teams need people at multiple levels learning from each other. All-senior or all-junior teams both fail in different ways. (we wrote about this also here!)

You can find the full interview with Chris below:

You can also find it on 🎧 Spotify and 📬 Substack

📚 Weekly Readings

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

🥇 The Last Software Engineer

10 min • by Kent C. Dodds

Fast forward to the moment right before AI takes over everything engineers do — what’s the last valuable thing left? I won’t spoiler! Fantastic article by Kent.

🥈 Why Sell Software If Anyone Can Make It?

2 min • by Clemens Adolphs

It’s not hard to make bread at home — even better than the one you buy at the bakery. Yet nobody really does it at scale. Don’t let the “everyone can code now” narrative scare you out of building a software business.

🥉 How I use AI to Code

19 min • by Chris Sherwood

A thorough, opinionated guide on AI coding, updated to April 2026. Covers both the mindset and the practical tools. I liked 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

Today’s sponsor is Intent by Augment.
Intent is a developer workspace built for orchestrating agents: it starts with the living spec that updates as agents make progress, so every task stays aligned with no manual coordination. Try it for yourself at https://www.augmentcode.com/product/intent

Today's guests are Jean Hsu and Cate Huston!

Jean and Cate are extremely experienced engineering leaders and coaches, accomplished authors, and have held leadership roles at companies like DuckDuckGo, Automattic, Medium and more.

They now run a program to help engineers and managers become directly responsible individuals for their careers, to navigate these complicated times.

With Jean and Cate, we talked about exploring what you want from your career, how to be intentional about it, how to use feedback to assess how you're doing, and how AI is changing and not changing the picture.

Also check out DRI Your Career — their course! If you use the code REFACTORING you get 15% off!

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. 🌪️ Why these times are uniquely challenging

2. 🧭 Figuring out what you actually want

3. 🔁 Feedback, accountability, and the power of coaching

4. 🤖 AI: Identity shifts and finding your way

5. 💡 Minimizing emotional work, maximizing outcomes

⠀Let’s dive in 👇

Read more

Today I am back with the third and last article in our Software Factory series, written together with my friend Rob Zuber, CTO at CircleCI.

Before this one we published:

1. The Era of the Software Factory

2. How to Grow your Software Factory

Why three articles? Because we like to work from first principles:

In the first article we established (with actual data) that teams that are getting far with AI are doing so thanks to good DX. The same teams that had good DX three years ago, are now winning the AI race: those at the 90th percentile are shipping >2x faster than before.

In the second article we said: ok, but once you have good DX, how do you create leverage with AI? And we laid out a plan in three steps:

1. 📋 Specs — start by writing good, detailed instructions about things to be done. E.g. “create a button that has the following specs […]”

2. 📚 Rules — turn specs into reusable rules for the AI to follow. This is when you can say to the AI: “create a button using our rules for creating buttons”.

3. 🧩 Modules — is the final stage, when AI can reuse code directly, instead of rules, and you can simply say: “create a primary button”

This seems good enough, so why a third article?

Because if you do all of the above right, your outcome will be: a solid dev process, in which AI produces good enough work to be shipped.

Now, while this seems like an ambitious target already, I still think we should aim higher.

To understand why this matters, we need to take a step back and reflect on engineering teams before AI. Here is the agenda for today:

• 📉 The default path is degradation — the uncomfortable reality of engineering teams so far.

• 🐛 What causes teams to degrade — talking about coding hygiene, capturing knowledge, and building the wrong things.

• 📈 How to get better instead of worse — how to invert the trend on each of these dimensions.

• 🎽 Empowering managers — this is peak manager territory. Let’s talk about what managers should really do today in the age of AI.

Let’s dive in!

As always, I want to thank Rob and the great CircleCI folks for partnering on this piece. I loved bouncing ideas off with them, and I am a fan of how they are trying to reinvent software validation for the AI era. You can learn more below 👇

Learn more about CircleCI

Disclaimer: in the article I only wrote my unbiased opinion about all practices and tools mentioned, CircleCI included

📉 The default path is degradation

Anyone who has worked in human software teams for years — teams that work on the same codebase over a long period of time, teams that grow, shrink, rotate, and do all the things that human teams do — knows that the default trajectory is not an improving one. It’s not even staying put.

Over time, the default is getting worse.

Codebases become a mess, large teams ship less than small teams (per engineer, but often as a whole), and products get shitty.

There are exceptions of course, but this is the reality of engineering for probably 90% of teams.

I think it’s exactly this bias, plus the fear of losing control over code, that makes us happy with AI just getting things right. Good enough. If we get moderately faster through this, and don’t degrade over time, that’s a victory already!

And that’s true, but what if we don’t stop there? What if the default becomes that things get better over time, instead of worse?

What if, for any change, instead of asking “is this good enough to ship?” we asked ourselves: “does this change make the next easier/safer/cheaper”?

In other words, a world in which, over time:

• The team gets faster — both individually and as a whole.

• AI gets more accurate — because tech and product get better understood.

• The codebase gets better — because of the aggregated understanding of the problem, the continuous refinement of the abstractions, and the collective time spent on making things right.

This has been discussed in recent times already, and often goes by the name of compound engineering — but it’s still unclear how to pull it off.

So today we are taking a stab at what real-world compound engineering might look like, based on the actual tools available, and our respective experience:

• Rob has the privileged vantage point of overseeing the workflows of tens of thousands of teams via CircleCI. CI is the crossroads through which most software activity has to go through, so it’s perfect to spot patterns, see what works, and what doesn’t.

• On my end, I have been building Tolaria for several months now (p.s. we got to 8K stars on Github!), have written 100K+ lines of code for it in over 2000 commits, and have developed strong opinions about the state of AI coding today.

🐛 What causes teams to degrade

I like to address problems by inversion, so to figure out how to make things get better, I like to start by reflecting on what makes them worse — and then avoid that!

We could spend weeks just debating this, but I’ll keep things simple and give you my top three candidates for what makes engineering teams (and products) degrade over time:

1) Coding hygiene

There is an obvious baseline of coding hygiene that helps keep things maintainable, like:

• 🔬 Good testing coverage — made of actual good tests (see Kent Beck’s desiderata)

• 🩺 Good code health — high cohesion, low cyclomatic complexity, small files, no bumpy roads, etc.

• 🧱 Good basic abstractions — that encapsulate domain language, instead of using language primitives all the time.

A key characteristic of coding hygiene is that it is largely domain agnostic. In fact, it can be easily evaluated by automatic tools that know nothing about your product.

It’s also, honestly, hard to maintain. Writing good tests is hard for a variety of reasons, they pose nasty tradeoffs and cause endless fights for time to market. Good code health is easier said than done, and even basic abstractions are often challenging.

So I empathize with teams that struggle with these — but nevertheless, these are the basics. What comes next is harder.

2) Capturing knowledge

If there is a single thing that compounds in life, it is knowledge. Knowledge is leverage, and teams are generally very bad at capturing and growing their collective knowledge.

First of all, they capture very little: no records of their decisions, no snapshots of what exists today (in whatever format), no vision/mission statements.

Also, most often no playbooks on how to do things: from designing features, to coding specific parts of the product, to operating systems in prod.

Again, I am not faulting anyone for this. Writing things down is hard, and keeping them updated is even harder.

3) Building the wrong thing

As a result of dubious knowledge + poor hygiene, we often end up building the wrong things.

And the more wrong things we build, the harder it becomes to steer a codebase, because of little residual design space (from bad abstractions), little confidence in changes (from little testing), and so on.

Again, these are all things that, by default, get worse with time. We know this from research. Large and old orgs, vs small and young ones, perform worse on all dimensions:

• Code health is worse.

• Institutional knowledge is less shared.

• Product moves slower.

So how do we not only stop the trend, but invert it? Let’s take on these one by one 👇

🔬 Improving code hygiene

As a result of AI writing the code, you can—and should—enforce it to write good code.

In my experience, you can do so by combining:

• Rules and skills — about what the agent should do (e.g. always write tests) and how it should do it (e.g. what makes for a good test?)

• Gates — agents often simply ignore rules, so you need gates that enforce these rules. Code health above X, test coverage above Y, and so on.

There are a ton of tools today that can automatically check for anything you can think of, and I am personally a fan of integrating them both in the CI (as usual), and as local hooks (e.g. with Husky), to shift things left and let AI find problems earlier. Rob believes this is where validation infra needs to go: creating environments fast enough, real enough, and context-aware enough for agents to validate against before code reaches shared infrastructure.

There is also hygiene work that comes from regular maintenance, after the code is in prod. This is classic KTLO, from updating dependencies, to fixing small bugs, investigating failures in logs, and more.

This is all work where today AI can give you an incredible hand. What used to be recurring grunt work for your team, can turn into recurring automations that lead to PR drafts. You can create some for:

• Proposing dependency updates

• Scanning for security vulnerabilities, from well-known online lists

• Fetch insights from Sentry and your instrumentation to auto-fix bugs before you are even aware of them

Personally, for Tolaria I have a hourly automation that:

• Scans Sentry logs and Github issues reported by users

• Investigates and tries to reproduce them

• When considered worth it, it creates tasks for the Codex/Claude queue

• Bug tasks (as opposed to features) are automatically taken in charge and a fix is drafted for me to review.

Is this perfect? No. Does it create duplicates, false positives, or simply interpret things wrong? Yes! But does it help reduce my cognitive load and effort on these? Absolutely!

📚 Capturing knowledge

AI is fantastic at summarizing, expanding, moving, and overall processing content — but only if you capture it first!

And today, frankly, you should capture just about everything, exactly because of how cheap it is to process and maintain such information.

So you should capture:

• Raw inputs — like meetings, brainstorming docs, things where you are diverging, not converging.

• Decisions — e.g. ADRs in tech, but also product insights, directions you decided to go, and all the whys that the AI can’t figure out by itself by simply looking at the what.

• What exists today — I call these recap docs, because I believe they should be built as summaries of smaller, atomic things. You can put together a big ARCHITECTURE.md doc as a combination of the ADRs, or the product version of it by combining PRDs and specs. This is 100% AI territory today: you provide human input about single features, but leave the plumbing around content orchestration to the AI.

All this stuff needs workflows to be created to capture data, process it, keep it in sync, and so on — but honestly, it’s all easy! We are engineers! And the leverage over time is incredible. So there is zero excuse not to do so.

🔨 Building the right thing

If you do the above right, the result will be building more right things, as opposed to wrong things:

• Things that build nicely on top of what already exists

• Things that are coherent with past decisions

• Things that work and do not degrade your codebase

Above all, things that actually improve your codebase — because they record more decisions, say no to the things that are wrong, and yes to those that are right.

And those no’s and yeses stay there to help make better decisions in the future.

Also, such compounding can and should happen in all of your environment, not just the codebase: build history, pipeline patterns, team context, baked in and available over time, so agents can validate more, debug better, assess if code runs, and, most of all, if they are building the right things.

🎽 Empowering managers

I want to close by spending a few words about managers, who are often neglected in this AI conversation.

“Managers are in trouble”, “AI is for builders”, “everyone is back to coding”, and so on.

Guys, all the stuff we discussed is peak manager work.

I have interviewed a lot of engineering managers on the podcast, and often asked them what’s the hardest part of their job. One of the common responses is: “the feedback loop is slow”.

Think about it. When you are an engineer, your feedback loop is: you write a feature, see that it works, if not you iterate, push it, possibly iterate on reviews, and it’s done. This is all extremely fast (even if it might not feel like so!).

Now compare it with the feedback loop of a manager who is trying to improve how sprint planning works. Or performance reviews. Or their team’s velocity. Any change you make to the process needs to be measured on a scale of several weeks, or months. And in many cases, what do you even measure?

Agent workflows are amazing for managers to operate because it’s like their normal work… on timelapse. Even if the agents are not that good, make mistakes, or trip over themselves, it doesn’t matter as long as they are fast and managers can course-correct quickly.

So if it is true that all engineers are becoming kinda like managers now, it’s also true that motivated managers can have some upper hand because, well, they are already managers!

And that’s it for today! I wish you a great week

Sincerely 👋
Luca

Reporting from Salesforce’s TDX event! 🧑‍💻

This week’s sponsor is Salesforce!

Our friend Conor Bronsdon was our eyes and ears on the floor at TDX last week, and wrote a full breakdown on Chain of Thought.

He says Agentforce is now Salesforce's fastest-growing product, and the signs were everywhere at TDX:

• 60+ new MCP tools in Headless 360

• Agent Script open-sourced on GitHub

• Agentforce Vibes 2.0 (their vibe coding tool),

• plus new Slack agent capabilities.

Salesforce went as far as publishing the full language spec, grammar, parser, and compiler for their agent-definition language.

They're betting an open agent ecosystem wins developer adoption, while enterprise-grade upgrade paths let businesses actually ship reliable agents to production.

Read the full TDX breakdown

💡 Coding is not solved, but bad code… kinda is

Last week I launched Tolaria, which by now is one of the fastest growing repos on the whole Github! It got 6000+ stars in less than a week.

Tolaria is a lot of code: 100K+ LOCs, 2K+ commits, 3K+ tests, 70+ ADRs. I publicly said many times I didn’t write any of it, which made some people think I believe coding is solved.

I don’t think coding is solved at large, but bad code feels solved. To understand what I mean by that, a useful way to think about tech debt is to split it into two kinds:

• Bad code

• Misaligned code

Bad code is basic hygiene failure: lack of tests, high complexity, tight coupling, duplication, outdated libraries. It is bad regardless of business context, and we know it increases lead time, outages, and maintenance cost.

As of today this kind of debt is largely avoidable if you choose to enforce quality. On Tolaria, AI-generated code must meet three gates: high test coverage, strong CodeScene health scores, and current library/docs usage. These rules live both in CLAUDE.md and CI, because agents still forget or ignore instructions. Once those checks are in place, the basics can be trusted without manually reviewing every line.

Misaligned code is harder, and is definitely not solved yet. Code may be clean, tested, and well-structured, but still wrong for the product direction you want. It’s code that is a good circle when you really needed a square: a leaky abstraction, an old design assumption, or a model that no longer matches intent.

Reviewing architecture and abstractions still feels supremely important, because they're the things that the AI model can’t figure out by itself, because they are about what you want to build in the future, and why.

I wrote more about this in my series of articles about my AI coding workflow:

1. My AI Coding Workflow (Feb 2026)

2. Updates to My AI Coding Workflow (Apr 2026)

3. Introducing Tolaria (last week!)

🎙️ Progressive disclosure of complexity

In May last year I interviewed Guillermo Rauch, founder and CEO of Vercel

Guillermo talked about the qualities of great technology, and one principle that stuck with me was what he called the progressive disclosure of complexity.

A defining feature of great tech is that’s approachable for beginners but powerful enough for enterprise needs.

This principle guides the design of Vercel, Next.js, and everything they do.

“I’m building a platform that should not be intimidating for your first line of code, and gives you the superpower that you could be one day a top 30 internet website with the same infrastructure, with the same tools, with the same access.”

Guillermo draws inspiration from products like the iPhone, which can be used by both children and the elderly while still serving business professionals with complex needs.

His approach to API design focuses on what he calls token minimization (not AI tokens!) — requiring minimal code to get started, then gradually introducing more sophisticated features as needed:

• 🏁 Low barrier to entry — a new Next.js project can be started with just a few lines of code.

• 🌱 Growing with users — complexity is only introduced when needed for specific requirements.

• 🔄 Same technology at all scales — the technology that powers a beginner’s first project is the same that can scale to handle millions of users.

Here is the full interview with Guillermo:

You can also find it on 🎧 Spotify and 📬 Substack

📚 Weekly Readings

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

🥇 My CTO Daily Driver

8 min • by James Stanier

I basically recommend all of James’ articles, and this makes no exception. He explains how he uses Claude Code to drive a personalized CTO workspace with memory. With custom slash commands tied to Linear, Notion, and BetterStack.

🥈 The Peril of Laziness Lost

12 min • by Bryan Cantrill

Laziness has always been a programmer’s virtue — it’s what drives us to build abstractions instead of doing the same thing twice. LLMs don’t have that instinct: you have to supply it to them. If you don’t, you lose the elegance, efficiency, and maintainability that comes from human constraints.

🥉 99% of Our Production Code Is Written by AI

20 min • by Peter Pang

Took a lot of ideas from this post. Feels a bit AI-generated at times, but the ideas around feature gates, self-healing feedback loop, and bug fixing are awesome. Peak “harness engineering”, as kids call it these days.

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

It went viral on X, got a ton of replies via email (sorry if I didn’t get back to everyone yet!) and an insane 700 stars on Github.

As a refresher, if you missed yesterday’s email, Tolaria is a free & open source desktop macOS app for managing markdown knowledge bases. It’s similar to Obsidian, …

Read more

Check out Tolaria 💧

What is Tolaria?

Tolaria is a desktop app for Mac for managing markdown knowledge bases. In a way, it’s my own version of Karpathy’s LLM wiki.

I have a close …

Read more

Read more

Today’s sponsor is Intent by Augment.
Intent is a developer workspace built for orchestrating agents: it starts with the living spec that updates as agents make progress, so every task stays aligned with no manual coordination. Try it for yourself at https://www.augmentcode.com/product/intent

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.

Read more

Read more

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

Read more

Today’s sponsor is Intent by Augment.
Intent is a developer workspace built for orchestrating agents: it starts with the living spec that updates as agents make progress, so every task stays aligned with no manual coordination. Try it for yourself at https://www.augmentcode.com/product/intent

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 more the result of good control systems and tight feedback loops, as opposed to individual brilliance.

Some will argue it has always been the case. Chasing 10x engineers has always felt like a dubious idea, with the healthy version being: let’s build a 10x team, instead.

Whether or not it felt true in the past, it certainly feels true now. The report showed that elite teams today — those that are getting the most out of AI — are exactly the ones who already had the best delivery infrastructure yesterday (i.e. 3 years ago). Today, these teams are both running their “factory” faster, and improving it faster. They are going faster than others, and accelerating faster, too.

So how do they do that? What does getting better look like? How do you even know it’s happening?

Let’s get practical and try to bridge this gap. Here is the agenda for today:

1. 🧮 DORA metrics are not enough — we need leading indicators of AI success

2. 📊 Specs, rules, and modules — a simple mental model for AI leverage in three steps

3. 🪴 Making things compound — how to make things happen on your team

Let’s dive in!

I am grateful to Rob and the CircleCI team for partnering again on this piece. You can learn more about CircleCI below.

Learn more about CircleCI

Disclaimer: even though CircleCI is a partner for this piece, I will only provide my unbiased opinion on all practices and tools we cover, CircleCI included

🧮 DORA metrics and LOCs are not enough

From the report above, we know there is a small group of teams leading the pack, with outrageous numbers like 2-3x throughput, and a large group of others that, on average, are getting nothing out of AI. Literally nothing. Zero. Nil.

And not because they are not trying! AI penetration with engineers is ~90% — basically everyone is using AI everyday for coding, but the median team is not getting any faster.

How do we know this? Because as of today, in 2026, we have a good understanding of how to measure the effectiveness of the software delivery process. For example, we can look at the DORA metrics. Whether or not you use AI in the dev process, we can track how long it takes for work to go through the pipeline, how many commits are made per day, what’s the success rate of these commits, and how fast you recover from mistakes.

These numbers give us a good idea of the health and effectiveness of the delivery process, and allow us to even venture into saying: “this team is doing better than this other team!”.

Sometimes they also allow us to say: this team is not doing any better than before — which is what CircleCI found on average in 2025:

• -6.8% commits in production

• -14% deployment success rate

DORA metrics are effective at measuring the impact of AI precisely because, counterintuitively, they ignore AI. They look at the output of the process, regardless of how the process is implemented.

This is both a blessing and a curse.

It’s a blessing because they stay close to where the value is, and it’s a curse because they are too high level to be directly actionable. Just like setting a goal of increasing business revenues by 10% doesn’t say much about what you need to do to get there, setting direct DORA metrics goals isn’t very useful, and can even backfire if you are not careful with it. E.g. it’s easy to increase the number of commits per day by splitting work into artificially small batches, and shipping just a few lines of code at a time just for the sake of pedaling faster.

So, DORA metrics are lagging indicators. They are good for assessing the production level of your factory, but they don’t tell you how to improve your stations. For that, we need leading indicators.

The most convincing leading indicator for the SDLC is developer experience. There is plenty of research today that shows that improving developer experience has outsized returns on the lagging indicators not only of the health of your engineering process, but of the business as a whole. This was already the core takeaway from Accelerate, exactly 10 years ago, and has only been confirmed ever since. About this, I particularly liked Frictionless recently, by some of the same authors of Accelerate.

Developer experience, though, doesn’t say much about how we are using AI.

What are the leading indicators of AI success?

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