📊 Is AI really making developers ship faster?

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

Last month, together with Justin Reock, Deputy CTO at DX, we published a thorough commentary on the Q2 Report on the state of AI impact in engineering.

In case you missed it, it includes a lot of interesting insights. For example:

• PR throughout – increased 37% year-over-year, but

• PR size – nearly doubled in the same window

So more code is moving through the pipeline, but does that translate into more delivered value? It seems… not! You can find the full report below 👇

Read the report

Final reminder that today at 17:00 CET we are having our monthly live community mastermind. You can find more info, including how to join, here.

🗂️ Your knowledge needs a lifecycle

Since I released Tolaria and Portent, a lot of people have asked me about team knowledge bases and how to organize them.

Most questions I receive are about how to organize content: folders, types, and so on, while very few are about the lifecycle of such content. When is new content created? By whom? When is it updated or moved? When is it finally archived?

A knowledge base without a proper lifecycle slowly becomes a junk drawer.

Everything is saved with good intentions, but if every item stays equally visible forever, the useful material eventually disappears inside the pile.

In Portent, and for myself, I use a simple three-step lifecycle: capture, organize, archive.

1) Capture quickly

Save the link, write down the rough thoughts, or simply store the meeting notes.

This stage should just be fast, even at the expense of being a little messy, because the goal is to make information available before it disappears.

2) Organize deliberately

Now ask yourself two questions:

• What is this?

• What should it help me do?

The first gives the note a type, or simply a destination. The second connects it to projects, responsibilities, topics, or useful pieces of context.

If a note cannot be attached to anything meaningful, it may not be worth keeping. So capture optimistically, organize pessimistically.

3) Archive without deleting

Completed projects, stale notes, and obsolete context can still be useful. They just should not compete with their current work every day. Archiving is how you keep them available without leaving them in your way.

So, the system works because each stage has one job: capture ensures speed, organize creates purpose and meaning, and archive protects attention.

I wrote more about this in the full piece on Portent 👇

Refactoring

Introducing Portent ☘️

Today it’s almost one month since I released Tolaria, and during this time I have spoken with many people and teams that are trying to use it to create and manage internal knowledge bases…

Read more

3 months ago · 64 likes · 7 comments · Luca Rossi

2) 🍀 Increase your luck surface area

Most often, we tell career stories as if every good outcome followed from a careful plan. In reality, many opportunities arrive through chance: a person may notice your work, remember something you shared, and reach out at exactly the right time.

You cannot control luck, but you can increase the surface area where it can find you.

And to increase such surface, the idea is simple: 1) do more of the work you care about, and 2) tell more people about it.

Doing the work builds expertise: you make things, solve problems, contribute to projects, and become better at something useful. But good work can only create opportunities if it doesn’t stay invisible.

Sharing the work is what creates the most connections: write about what you learned, contribute to a community, publish a small tool. Help people see what you know and what you care about.

This does not guarantee the lucky break, but it’s a way to make luck less passive: more doing × more telling == more luck.

My friend Umberto Nicoletti wrote more about this, and his career experiences behind it, in the full essay below 👇

Refactoring

Lessons learned from 25 years in tech 🔭

Hey, Luca here! This is a guest article written by my friend Umberto Nicoletti, Director of Product and Engineering at Proemion…

Read more

8 months ago · 28 likes · Luca Rossi and Umberto Nicoletti

📚 Weekly Readings

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

🥇 The People Who Will Thrive in the AI Age

15 min • by David Brooks

When intelligence is abundant, the advantage shifts to people who still want to think hard.

David calls them “mental marathoners”: people who use AI to stretch their abilities rather than avoid effort. I loved this framing. It also explains why the same tools can make one person sharper and another more passive.

🥈 Middle management roles are also a trap

2 min • by Will Larson

Middle management teaches you to balance pressure and operate organizational process. Will argues that it can also pull you away from some of the skills executives need most: domain expertise and driving execution.

A good warning for anyone assuming that every step up the management ladder prepares you for the next one. It’s not always the case.

🥉 “Code was never the hard part” is an insult to all programmers

6 min • by Senko Rašić

Senko makes a strong case against the “code was never the hard part” phrase that you see everywhere these days. I half-agree with him.

I mean, understanding users, deciding what to build, and translating that into requirements is hard. But writing good code is hard, too. The difficulty level depends a lot on the company you work for: there are companies in which coding is extremely hard, and others where it’s easier. But I don’t think this is a useful debate anyway, let’s just agree coding is hard in general.

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

Our next Mastermind 🧠 is on Monday, August 17th at 5:00pm CET. We’ll be discussing the topic: making holidays and time off work for you and your team.

We’ll be covering questions like:

• How do you prepare before you go on holiday?

• How to protect your downtime while you’re away?

• How to make re-entry feel less like a disaster?

• What does good holiday coverage look like across a team?

This is an excellent opportunity to learn from the experiences, insights and perspectives of the Refactoring community.

The Mastermind is a monthly online session for members of the Refactoring community where people can ask questions and share challenges about the topic, and support one another in finding solutions by sharing our experiences, insights, and perspectives.

The Refactoring Community, including our Monthly masterminds, are exclusive to paid members of Refactoring. Subscribe today to get access 👇

Subscribe now

You can learn more about the community here.

Thank you!
Luca

It goes like this: since AI can approximate well what a junior engineer is able to produce, there is no point in hiring anyone who is not senior. In fact, senior engineers are the only ones capable of steering these tools.

From what I can see, this story is real, in the sense that many people believe it. I know many companies who have frozen junior hiring, and others who are explicitly steering towards small, senior-heavy teams.

I believe this is a mistake. And I don’t mean it from an ethical angle (the poor junior engineers!) — I mean from a practical, business one.

It’s also a mistake I have seen being done many times, well before AI, pretty much based on the same arguments. If anything, AI supercharged some of the same fallacies that have been around for decades.

Also, I am not alone in this. If you have been following Refactoring, you know the junior engineers topic is a recurring one both in the newsletter and in podcast interviews. Over time, I discussed it with Chris Lattner, Charity Majors, Meri Williams, and more.

So today I will put everything together and make the definitive case for hiring junior engineers on your team in 2026! Here is the agenda:

1. 🏋️‍♂️ Juniors are required to do more now — let’s acknowledge where this is all coming from.

2. ⚖️ Junior vs senior engineers — the difference is messier than you think

3. 🔭 First vs second-order effects — thinking of your team as a system when it comes to process, hiring, and growth.

4. 🌱 How to make it work — because juniors just don’t turn into seniors automatically.

Let’s dive in!

🏋️‍♂️ Juniors are indeed required to do more now

Let’s start by acknowledging the obvious: all engineers, not just junior ones, are required to do more now.

More of what? For junior engineers, the job looks qualitatively very different, and requires a lot of things from them *earlier* in their careers than it used to.

Think of:

• Code reviews — because of AI, junior engineers need now to review code from the get-go. Which in turn requires more... 👇

• Critical thinking — engineers need to constantly question the why and how provided by AI.

• Systems thinking — people are given bigger pieces of work from the start, which requires them to employ non-obvious design chops.

This is what many people see and makes them say: “yeah, junior engineers are screwed”.

I don’t think that’s the case, because there’s more to junior engineers than coding 👇

⚖️ Junior vs senior engineers

Anyone who has worked for some time in teams with mixed levels of expertise knows that the frontier, or boundaries, between a junior and a senior engineer is not clear-cut. It’s jagged.

Engineers do not grow linearly, simply becoming more capable over time. As humans, we also lose things over time. In my experience, there are things at which senior engineers are, on average, worse than junior engineers.

Many senior engineers are, vs junior engineers:

• More resistant to change

• More biased towards doing things the “old way” (tech choices, processes, you name it)

• Less energetic and hard-working

• Less willing to do the boring but necessary work that exists in all teams

Conversely, junior engineers may lack part of what is needed to steer AI towards quality and safety, but are often better at using it as a whole. They have no bias and adapt faster because, simply put, they have less to unlearn.

They have an easier time keeping their intuition up to date about how to use agents, orchestrate them, and create autonomous loops. Are these loops designed for quality and sustainability? Probably not! But, on the contrary, I know many 15-years-of-exp developers who simply refuse to build loops at all, because they want to retain control over every single LOC, which is wrong just as well.

That’s all to say that the comparison between juniors and seniors is complicated, and is wildly dependent on individuals.

Furthermore, so far we have only talked about production — the things that engineers actually make. But that’s only the immediate, first-order output of your team.

Team success is also driven by processes, cost, hiring & retention, individuals’ growth, and all kinds of system-level factors that are often neglected in this conversation.

What is your team going to look like one year from now? What about two years? How does that change based on the level of seniority mix you design your team for? I know companies that are more or less intentionally refusing to plan for longer than a quarter, because of AI uncertainty and all. But I don’t think that can be an excuse. As Eisenhower said: “Plans are useless, but planning is indispensable”.

So let’s try to loop all of this in 👇

🔀 Second-order effects of mixing seniority

Out of the various parts of your team life that are “not coding”, there are three that are particularly relevant when it comes to seniority levels, and it’s process, hiring, and growth.

1) Process

In my experience, the teams that are best at designing and enforcing good dev process are those with a healthy mix of seniority. In fact, both extremes are often bad:

• Junior-heavy teams — often would love good process, but don’t know what it looks like.

• Senior-heavy teams — know what good process looks like, but they can bridge gaps with individual experience and knowledge, so have less incentive to make things explicit and robust.

Mixed, diverse teams have both the senior folks who can design process, and the junior ones to benefit.

Needless to say, process, guardrails, devex, and all that jazz today is 10x more important than in the past, because that’s also how you scale AI work (the “harness”!).

2) Hiring

Senior engineers are hard to find and hire: you are competing for a limited pool of talent, and the pipeline is long and expensive. No way around it.

Conversely, junior engineers come from predictable, controllable hiring channels, like universities, bootcamps, and the likes. They are both cheaper and faster to hire.

3) Growth

Junior engineers can grow into the specific mix of duties and skills that your company needs, often compensating for the lack of experience with this special fit that is hard to replicate by hiring a senior. Even worse, a senior engineer who is already invested in a set of technologies and practices may have little interest in steering towards how your team does things.

Junior engineers are also easier to keep engaged, growing, and happy for a long time, simply because the bar for work that makes them grow is lower than for a senior. In any company there is a ceiling to what an engineer can learn, and senior folks just leave when they stop growing. In a healthy mixed team, senior departures are compensated by juniors who have risen through the ranks, and eventually replaced the former.

🌱 How to Make It Work

So, as Martin Fowler put it on the podcast, one of the most important qualities of junior engineers is to eventually turn into senior engineers. That said, this doesn’t happen automatically.

While there exists, indeed, a dream scenario in which junior engineers grow, become senior, and *rotate* your headcount to compensate other senior departures, in circle-of-life fashion, there is also a nightmarish scenario in which juniors are thrown in the trenches, abuse AI in ways they don’t understand, nobody checks on them, and the product and tech eventually goes to shit.

When this cycle breaks, it’s because junior engineers don’t have enough feedback loop to 1) ensure their work is high quality, and 2) learn and grow from doing it.

The way to create this feedback loop, to me, looks like two-fold:

• Invest in an amazing harness — create guardrails, rules, gates, and encode everything that can ensure quality automatically. This benefits just about everyone: senior engineers, AI, and junior engineers who can learn from those same rules.

• Pair juniors with seniors — let young folks experiment and work fast, but pair them with seniors to provide judgment and systems thinking. It’s still early days for this and everyone needs to find their own formula, but e.g. I loved Rick Clegg’s talk about what they do at Wise about it.

📚 Resources

I got plenty of resources about this if you want to deep-dive more:

• Scaling Juniors in the AI Era — the aforementioned talk by Rick Clegg from Wise about using automate guardrails to let junior engineers ship faster with AI.

• You Don’t Hire Juniors to Do Menial Chores — great piece by Frederick Van Brabant about how juniors help innovation: they bring fresh takes to many things, and stress-test your assumptions because they have not yet learned all your bad habits.

• Diversity, AI, and Junior Engineers — my interview with the awesome Meri Williams, where we talked a lot about growing engineers.

• In Praise of Normal Engineers — the incredible article that Charity Majors wrote for Refactoring, where she argues we should hire the “right” people instead of the “best” ones, and invest in 10x teams, instead of 10x engineers.

📌 Bottom line

And that’s it for today! Here are the main takeaways:

• ⚖️ The junior vs senior frontier is jagged, not linear — engineers don’t simply get better at everything over time. Seniors gain experience but often become more resistant to change and harder to keep engaged, while juniors adapt faster, have less to unlearn, and are often better at embracing AI workflows.

• 🔄 Mixed-seniority teams build the best processes — senior-heavy teams have less incentive to make knowledge explicit and systematic, while junior-heavy teams don’t know what good looks like. You need both. Also, robust, explicit process is exactly what scales AI work.

• 💰 Junior hiring is cheaper, faster, and more sustainable — instead of competing for a scarce pool of senior talent, you can hire juniors from predictable channels and grow them into the specific shape your company needs, creating a circle-of-life rotation that compensates senior departures.

• 🛡️ Invest in the harness, not just the horse — the way to make junior engineers thrive is to build amazing guardrails (automated quality gates, rules, standards) and pair them with seniors who provide judgment and systems thinking.

• 🔮 Refusing to hire juniors is a bet against your own future — if you only hire senior engineers today, you are optimizing for short-term output while starving the pipeline that will sustain your team for years to come.

See you next week!

Sincerely 👋
Luca

📖 42: The AI Builder’s Stack

This newsletter is brought to you by Eltex!

The guys at Eltex run a great engineering studio and just released 42: The AI Builder's Stack, which is the practitioner's guide to the toolchain they run on: Claude Code, MCP, agents, AI IDEs. They covered what worked, what failed, and what the vendors will not tell you.

The book includes a companion Claude Code setup that is free and MIT-licensed: 42 subagents, rule packs, and a commit guard that blocks force-pushes and staged secrets. Trimmed versions of every chapter are free to read.

Get the book

“A hands-on guide that speaks the language of real developers building real systems.” — Richard Cave, ex-Apple Engineering Manager.

🏁 Starting is easier and finishing is harder

AI makes it incredibly easy to start more work.

Engineers are opening more branches, touching more PRs, and getting to something that looks close to done much faster than before.

But shipping is another story.

In the Faros report I covered recently, the most interesting pattern was how AI made the last mile worse: teams have a lot more stalled work, more restarts, and often times… fewer deployments overall!

This shouldn’t be surprising if we look at the classic WIP equation:

So if AI increases WIP but throughput stays the same, the system just accumulates more unfinished work.

To avoid getting stuck in this, we should inspect our dev process as a whole, measuring how much more valuable work actually reaches users. Otherwise, we may just be making the queue longer.

I wrote more about this in the full piece on the acceleration whiplash 👇

Refactoring

Acceleration whiplash 📉

Hey! Luca here — welcome to a new edition of Refactoring…

Read more

2 months ago · 41 likes · Luca Rossi

🔺 Product engineering is the ceiling

If your team already has good DevEx and good AI workflows, building things gets faster. But that still does not guarantee you will ship a lot more valuable work, because engineers spend only a small slice of their week actually writing code.

The rest is coordination: meetings, waiting, handoffs, status updates, and all the small negotiations that happen before something reaches users.

So, to unlock more time (and more gains) we should ask ourselves: can an engineer spend more time coding and less time coordinating? Which pretty squarely translates into: can one engineer own a larger slice of the product loop? This is what product engineering is about.

Not every engineer should and will become a PM and a designer at the same time, but if they can safely own more context, make more local decisions, and move with fewer handoffs, the whole system becomes lighter.

Also, to make it work, product engineering requires infrastructure available to everyone: product context, design platform, tight feedback loops to intercept mistakes, and in general tooling that makes this broader ownership easy and safe.

We should continuously strive to reduce the coordination tax that keeps good work stuck between roles.

I wrote more about this in the full piece on the new pyramid of software engineering 👇

Refactoring

The New Pyramid of Software Engineering 🏔️

There are a lot of opinions around these days about the future of software, including of course my own…

Read more

5 months ago · 55 likes · Luca Rossi

3) 📚 Weekly Readings

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

🥇 The Conductor Developer

4 min • by Rachel Laycock

Rachel is CTO at Thoughtworks and has a good frame for what AI is doing to software development. The developer becomes more like an orchestra conductor, who needs to keep the whole system in their head while many agents play different, specialized parts. This feels directionally right to me, which makes me forgive that the article itself feels a little bit AI-generated :)

🥈 LLMs Reward Expertise

4 min • by Sean Goedecke

Sean’s take matches my own experience: when working with AI, the better you know the domain, the better questions you can ask, the harder you can steer the model, the faster you can spot weak answers, and so on. In other words, AI massively rewards expertise.

🥉 Don’t Be a Meat Proxy

1 min • by Niklas Gruhn

If you use AI in a team, your job is to read, check, compress, and contextualize what AI gives you, before you pass it on to other people. Otherwise, people might as well talk to the model directly.

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 episode is brought to you by: Notion

Learn more about Notion’s Developer Platform today at https://ntn.so/refactoring

Today's guest is Charlie Guo, developer experience engineer at OpenAI.

With Charlie, we explore the evolution of AI coding tools, how this is affecting team organization, and the future of AI integration in software development. Charlie shared strategies and tricks to leverage AI effectively, and how this is all transforming the workflows that we all know and love.

🥇 Interview Summary

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

It’s the 5-minute, handcrafted 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. 🏗️ Inside the Codex team at OpenAI

2. 🔄 The evolution of AI coding tools

3. 🧩 Sharing AI workflows across teams

4. 🎨 Design, models, and practical AI workflows

5. 💰 The economics of AI coding

Let’s dive in 👇

Read more

Once a month I publish an article about how I develop Tolaria, including an overall recap plus the latest updates, and some useful resources.

I consider part of my work (combined between Tolaria & Refactoring) to always try the latest and greatest, and work at the frontier of what’s possible, so you will only get thoughts that come from real usage and experiments.

Also, this is the first month since we launched the Tolaria Alliance, which has been a huge success so far! This is what allows Tolaria to stay free and open source, and this series (and the whole development of Tolaria) is made possible by the great tools I use everyday, which are:

• CodeScene — to guarantee great code health across the codebase.

• Codacy — to guarantee code quality and security.

• Unblocked — to help agents (and myself) fetch information across the codebase, ADRs, Github issues, and commit history.

• CircleCI — to allow fast and scalable local validation, and remote CI (migrated this month!)

That said, here is the agenda for today:

• 🔄 Workflow recap — for those who missed the previous episodes.

• 💧 Tolaria updates — what happened on the product side.

• 🔀 Forking open source — and the future of it

• 🚏 Creating custom gates — to give agents stricter constraints.

• 🤖 On using GPT 5.6 — and the latest models

Let’s dive in!

🔄 Workflow recap

First of all, if you missed the previous editions, here are some pointers:

• Product management — how I do traffic control between issues, PRs, and product requests, and orchestrate the overall product backlog.

• AI Coding — my own approach to scaling coding with agents, via guides, gates, and guards. Mostly remained unchanged from last month.

• Tools I use — a deeper dive into how I use the tools from the alliance, and others, too.

• ADRs, and more — in the initial workflow article I discussed how I do docs, which has scaled nicely so far.

Now on to the new stuff, but first... product updates. Because what is my workflow worth if you don’t see what I shipped with it?!

💧 Tolaria updates

This month Tolaria has followed a bit of a barbell strategy, where the two extremes are:

• 🔨 Basics — hardening performance and quality of life features for the editor, which remains the most crucial experience to nail.

• 🌚 Moonshots — trying (possibly overly) ambitious ideas, and see what sticks.

I will talk more in detail later about performance, because I have thought a lot not only on what to do about it, but also how to create a mini workflow so that it doesn’t degrade over time.

1) Basics 🔨

Basics include small features like block selection and navigation (a-la Notion), and the ability to collapse any heading and list item (a-la Bear). I constantly “borrow” features from other editors and note apps I love, but at least I credit them 😄

Of course, you will also find a long tail of more improvements, like being able to open vaults in separate windows, more MCP tools, more granular controls for AI agents, and just a lot of stuff!

2) Moonshots 🌚

Talking of moonshots, you can now create HTML blocks inside Tolaria.

This wouldn’t be that ambitious, if not for the fact that you can also reference properties from any note inside the HTML, and use a simple set of formulas to render lists, format values, and more.

This builds on the same system that allows spreadsheets to reference note properties, which was working well, so I said why not?! It plants the seeds for making Tolaria a platform where you can build mini apps that take information in real time from your notes.

It’s very cool if you ask me, and I am eager to see what you will build with it!

As I anticipated, though, what I am the proudest of is our performance work, which deserves a separate chapter 👇

⚡ Performance & forking open source

Read more

🔍 Can you prove your AI is working?

This newsletter is brought to you by Unblocked!

AI is firmly in your engineering workflow. But while the token spend shows it, the throughput doesn’t. Humans are very much still in the loop, and that’s likely a context problem.

Our friends at Unblocked will hold a free webinar on Aug 19 to cover:

• How to track AI productivity

• How context maturity affects where teams stall

• What it takes to get real value from your agents

They know what they are doing and I personally use Unblocked everyday for Tolaria! Recommended.

Join the free webinar

🚦 Separate bugs from feature requests

When a product grows, feedback starts arriving from everywhere.

In my case with Tolaria, it comes from GitHub issues, support emails, community threads, crash reports, the Canny board, random DMs, and of course, my own ideas.

It is tempting to put all of this into one giant backlog, but bugs and feature requests create very different kinds of work.

• A bug mostly needs reproduction, prioritization, and a fix. If it is real, there is usually not much product strategy to debate. The job is to understand what is broken and make it not broken anymore.

• A feature request is different. It needs deduplication, discussion, roadmap judgment, planned / in-progress states, and possibly a place where users can follow what happens next. It also benefits from users voting on actual proposals, so you can use that for broad prioritization.

If you collapse these channels into one, like many teams I know actually do, the system can get noisy very quickly, like:

• Users filing feature requests as bugs

• Bugs appearing in product boards

• Duplicates multiplying everywhere

• Engineers spending time routing work manually

About all of this, what works for me is explicit traffic control. Route people to the right place when they submit feedback, and then run an intake workflow that moves misplaced items, closes duplicates, and turns valid work into tasks 👇

I wrote more about this in the full piece on how I run Tolaria as a big open source project 👇

Refactoring

How I Run the Tolaria Project

Hey, Luca here! As you probably know by now, two weeks ago I launched Tolaria, a desktop app for Mac, Linux, and Windows, to manage markdown knowledge bases — for humans and AI…

Read more

3 months ago · 53 likes · 2 comments · Luca Rossi

🎤 Prepare the three stories every behavioral interview needs

Behavioral interviews can feel vague because there is no clear and immediate feedback. You say something about your career, someone nods, asks for a follow-up, and you leave the call wondering whether the answer was any good.

In my conversation with Austen McDonald, former hiring committee chair at Meta, he gave practical advice to reduce this ambiguity: most behavioral interviews eventually orbit around three questions.

1. 🙋‍♂️ Tell me about yourself

2. 🗃️ Tell me about a project

3. ⚔️ Tell me about a conflict

This does not mean you should memorize three canned answers and recite them everywhere. The point is to understand your own career and adapt the same strong stories to many different questions.

• For “tell me about yourself”, Austen suggests three parts: who you are, your greatest hits, and why this specific role makes sense as the next step. The goal is that, if the call drops after your intro, the interviewer will already want to talk again.

• For a project story, you should guide the interviewer toward the best material before time runs out. So you should signpost the important moments upfront (e.g. the architecture choice, the difficult implementation, the launch tradeoff) and then go deeper where the signal is strongest.

• For conflict, Austen says the most common mistake is skipping the actual resolution. Interviewers do not only want to hear that there was disagreement. They want to understand what you did: did you go directly to the person? Did you use Slack, a meeting, a doc? Did you show empathy for the other side? What changed afterwards?

Good behavioral prep is about taking your real experience and making it legible for your interviewer.

You can find the full conversation with Austen here 👇

📚 Weekly Readings

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

🥇 The Productivity-Experience Paradox

11 min • by Annie Vella

A very useful counterweight to the usual AI productivity discourse. Annie shows that engineers can feel more productive while their actual experience gets worse, especially around flow state. An interesting second-order effect leaders should watch before declaring victory.

🥈 You Don’t Hire Juniors to Do Menial Chores

3 min • by Frederick Vanbrabant

Short and sharp argument against one of the laziest takes of the AI era: that we do not need juniors anymore. Frederick acknowledges the “succession” point, but counterbalances it with the innovation one: juniors bring fresh takes on many things, and stress-test your assumptions because they have not yet learned all your bad habits.

🥉 The Motivation

1 min • by Michael Lopp

Tiny Rands post about why writing matters: because writing is a way of building. I love this framing. In a world where we can generate more words and more code than ever, the most valuable part is still the thinking you force yourself to do before you publish or ship.

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

When I write about AI coding, you can typically find three types of articles:

1. Commentary on recent research — as we did several times recently.

2. My own experiments — these days, mostly about building Tolaria.

3. Case studies — about how other teams work.

The third type is the hardest to write. There are very few companies that accept to put themselves out there and talk about practices, not just tools or tokens. That is why I was happy when I met Rahul and the team at TRM Labs, and they agreed to share how they are redesigning their product development workflow.

For context, over the last few months, I have argued that AI is changing the cost structure of development. So, since coding is now cheaper, we need to find a way to make everything else cheaper too.

TRM reached the same conclusion and did something interesting: they rebuilt their shipping workflow and encoded it into a custom internal harness called Cortex, which they are now open-sourcing.

Today we’ll explore how they have been thinking about it. So here is the agenda:

• 🏁 Inner loop vs outer loop — a useful mental model to translate faster coding into actual faster delivery.

• 🔀 From handoffs to outcomes — how TRM redesigned its product workflow around the work rather than the roles.

• 🧰 Cortex as a harness — how reviewable artifacts, deterministic gates, and repository context make the workflow reliable.

• 🧪 Starting small — how TRM moved from a greenfield experiment to a regulated production system.

• ✅ Healthy code and healthy people — why increasing automation doesn’t mean removing human judgment.

Let’s dive in!

I want to thank Rahul and the team at TRM Labs for partnering on this piece. You can learn more about their work below:

Learn more about TRM Labs

🏁 Inner loop vs Outer loop

Most AI coding tools optimize what we call the inner loop: you describe a feature, watch the agent write the code, and get something working a few minutes later. This is where AI has delivered the most visible improvements, but it’s just a small part of how software gets shipped.

Other than the inner loop, there is an outer loop, that covers the broader cycle: deciding what is worth doing, shaping and reviewing the solution, releasing it, and learning from production.

As of today, it’s been obvious how AI can help with the inner loop, but much less so with the outer loop. And if you don’t do both, constraints move to other parts of the workflow, like:

• 🔍 Reviews — agents create more PRs than people can reasonably inspect.

• 📋 Shaping product — the team can build faster than it can decide what good work looks like.

• 🎯 Customer signal — shipping the wrong thing faster is still waste.

At a small scale, this is the same acceleration whiplash I have experienced with Tolaria. Starting work is cheap, but my ability to review it, decide what is good enough, and create the next piece of work does not scale at the same rate.

To fix this, the TRM team stopped treating engineering speed as the goal and started looking at end-to-end throughput instead 👇

🔀 From handoffs to outcomes

Like most companies, TRM had a product shipping framework. This can be more or less formalized, but chances are your team has a shared language for how an idea moves from customer feedback to production.

At TRM, such a framework had nine stages and was mostly organized around roles. A Product Owner prepared the spec, a Technical Product Manager helped translate it; a Technical Anchor owned the implementation, and various artifacts moved from one person to another.

The process was designed around the assumption that every artifact had to be created by one specialist and handed to the next.

AI weakens that assumption. For example:

• A PM can now explore technical feasibility and create a working prototype.

• Or, on the other end, an engineer can investigate the customer context and draft a product spec.

Does this mean the intermediate artifacts disappear? I don’t think so. If anything, specs, plans, or decision records can become even more important when agents do the implementation, to trace execution and record history. But it’s likely that individual artifacts no longer need to belong *exclusively* to an individual role.

So, TRM rebuilt the framework around six outcomes, organized into three groups:

1. 🔭 Sense and Decide — collect signals, understand the problem, and decide whether it is worth solving.

2. ✏️ Shape and Make — turn the problem into a reviewable direction, then build it.

3. 📣 Communicate and Learn — release the change, observe its impact, and feed what was learned into the next cycle.

These are broad areas that change the job of the people involved:

• 🎯 PMs and EMs expand their scope — they can test feasibility and prototype ideas without waiting for engineering capacity.

• 🧑‍💻 Engineers get closer to the problem — they can retrieve customer signal, shape solutions, and work across more of the stack.

• 🎨 Specialists turn judgment into platforms — designers, security engineers, and other experts create rules and constraints that make good decisions easier for everyone else.

I really care about the last point, and I think it’s how specialist work is evolving today. Deep specialists are more and more an overkill for regular production tasks — they have a bigger impact when they bottle their taste into design systems, components, security policies, workflows, and platform in general.

So TRM laid down the process and then created a harness around it 👇

Read more

💸 AI spend is outrunning returns

This idea is brought to you by today’s sponsor, DX!

Last week I published my own commentary on the Q2 AI Impact report by DX, which among other things, showed how quarterly median AI spend grew 28x year-over-year!

My expectation is that this AI honeymoon will not last forever, and tech leaders may already face tough budget conversations in the back half of 2026. That’s especially because it doesn’t seem that such spend is leading to outrageous outcomes so far.

But we’ll see! You can find the full report below 👇

Check out the full AI impact report

🌱 Build relationships before you need them

Especially in tech, networking often gets framed in a very transactional way. You meet people because one day you may need a referral, an intro, a customer, or a job.

I think this is exactly the wrong way to look at it.

I have found that the best relationships are created before there is any immediate need attached to them. You build rapport around common interests, you understand what the other person cares about, you are helpful when you can, and you do not keep score.

Long-term, this is both 1) the better behavior as a human being, and 2) the better strategy.

Because you never really know who will be able to help you in the future, or how. Opportunities often come through weak signals, second-order connections, and people who simply remember that interacting with you was... pleasant. Before it was any useful.

So my advice is simple: do not wait until you need something to show up.

But how?!

It can be anything, really. Share useful material (”I read this article today and thought you might like it”). Make intros. Reply thoughtfully. Follow up when someone is working on something interesting. Be generous in small ways that compound over time.

I wrote more about this in this full piece on growing your network 👇

Refactoring

How to Grow your Network 🍻

For as long as I can remember, a good share of the people I admired have recommended me to grow my network…

Read more

4 years ago · 21 likes · 2 comments · Luca Rossi

🔧 Automate the copy-paste (not the judgment)

A lot of team process work is not actually process work. It’s copy-paste disguised as process.

Raise your hand if you ever updated a project management ticket because the real status lives elsewhere. Or you asked an engineer for a delivery date because the current dashboard is stale and can’t be trusted.

In my conversation with Antonia Scheidel, Director of Engineering at Duolingo, I liked her distinction between two kinds of information:

1. Information that already exists somewhere

2. Information that only exists in people’s heads

The first kind should usually be automated. E.g.:

• If an experiment was launched on the appropriate experimentation platform, humans should not have to copy that into Jira.

• If a stakeholder needs to know that a step is ready for review, the system should notify them.

The second kind, instead, still needs people.

In normal teams’ workflows, there are plenty of judgment calls that cannot be reliably inferred from a tool, and that’s where you want to direct human attention. Things like delivery estimates, blockers, timeline changes, tradeoffs.

So, the shape of good automation looks like:

1. Connect the systems of record

2. Remove the glue work

3. Ask people for the (remaining) information that genuinely requires their judgment.

Antonia built this successfully at Duolingo, and you can find the full interview here 👇

📚 Weekly Readings

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

🥇 We 3.5x’d Our Pull Requests with AI: Now We Catch Fewer Bugs

5 min • by Pawel Brodzinski

A detailed, real-world write-up about the impact of AI on an engineering team’s code reviews. PRs went from 200 to 800 lines on average, and reviewers inevitably started missing more things. Worth checking out.

🥈 American AI is locked down and proprietary. It’s losing.

3 min • by Ben Werdmuller

Ben makes a sharp argument that open models may win for the same reasons open infra usually wins: distribution, portability, and permissionless innovation. I am not sure the geopolitical framing is the whole story, but I really like the business point.

🥉 Reverse-engineering is cheap now

1 min • by Simon Willison

Tiny post, big ideas. Agents make throwaway code extremely cheap, so entire categories of “not worth it” automation suddenly become worth trying. Simon makes the example of reverse-engineering home devices, which I have tried myself many times! If AI makes weird small projects viable, I am all for 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

One of the things I like the most about the DX team is that they run an incredible amount of research. They run surveys all year round, and keep a pulse of where the industry is going around several topics — especially AI and developer experience.

They recently released the Q2 2026 AI impact report, the latest in a quarterly series tracking how AI is reshaping engineering teams. I regularly check out these reports, and one thing I noticed is how they gradually moved from discussing adoption to discussing impact.

The feeling is that AI is everywhere now, and the main challenge for engineering leaders is not to spearhead adoption anymore, but rather justify the exponentially-increasing AI budgets, by demonstrating what AI is actually delivering.

I got preview access to the report, and today we will comment on a few key highlights.

So here is the agenda:

• 📊 Speed is real but uneven — what 500+ teams reveal about where AI gains concentrate, and who’s being left behind.

• 🧱 Orgs are not multiplying AI output — developer experience is declining even as velocity climbs.

• 🔬 Code is easier to change but harder to trust — a surprising divergence between maintainability and confidence.

• 🚶‍♂️‍➡️ Spend is outrunning returns — AI budgets are up 28x, but innovation ratio is flat.

• 🧭 What this means for engineering leaders — how to shift from tool adoption to system optimization.

Let’s dive in!

I want to thank Justin and the DX team for partnering on this! I am a big fan of their work and you should check out the full report here.

Download the full report

📊 Speed is real but uneven

Across the 500+ respondents, over 50% of the code is now generated by AI. This metric has accelerated rapidly, increasing from 34% in Q1 2026.

Median weekly throughput rose 37% over four quarters (1.42 to 1.94 PRs/eng/week), and deployment frequency is up double digits across most segments. However, gains are concentrated among small organizations (less than 100 engineers) and tech-sector teams, pulling away from larger and traditional-industry teams, and the gap is widening.

This echoes what we have seen in other reports recently, from the Acceleration Whiplash, to the State of Software Delivery earlier this year.

The speed at which the tools keep improving makes gains compound for teams who invest into AI workflows, so the distribution of team productivity becomes a steeper and steeper power law, with the top percentiles pulling away from the pack.

🧱 Orgs are not multiplying AI output

DX measures developer experience with a proprietary index called DXI (we talked about it with Abi Noda), which, over the last four quarters, has dropped on average from 67 to 65.

Again this is not an even drop: AI is improving some aspects of the devex (docs quality, code maintainability, onboarding speed) while making others worse: larger PRs, slower reviews, less incremental delivery. In aggregate, the net effect is negative.

Median PR sizes have nearly doubled during the same period — and of course increases in PR size are an early proxy for technical debt, bugs, review friction, and all kinds of nasty stuff.

So, velocity metrics alone will tell you things are improving, but devex metrics will tell you that the system (and developers) are strained, and we are far from a sustainable, positive flywheel.

My personal feeling about this is that so far we have mostly tried to slap AI onto the existing steps of the dev process, while running them the same way we always have. This might bring incremental gains, and even work well for some of the steps, but it completely breaks others, like code reviews.

It’s obviously foolish to think that AI can make developers write code 3x faster (as it already does), while assuming we’ll need to keep reviewing every single LOC manually.

Read more

Brought to you by our friends at Atono!

You hand off a story to an agent. The code works, it ships, but it’s not what you meant.

As agents move faster, the decisions that shape what gets built need to travel with the work. Most teams haven’t systematized this yet, so the result is correct implementations… of the wrong thing!

Atono just published their From Intent to Production at Agent Speed guide, showing how product knowledge becomes your leverage point for keeping decisions intact, even at agent speed.

We’ve previously collaborated on pieces like The State of Product Development 2026 and The AI Productivity Paradox — this guide goes deeper into product delivery for agentic workflows 👇

Download the guide

1) 🏗️ Agents are great scaffolding

A mistake I see more and more with AI workflows (including mine!) is using AI for everything, even for parts that would be better done in other ways.

That’s easy to fall into, because when you are automating a new recurring task, an agent is often the fastest way to start. You can give it the goal in natural language, let it run the process end to end, and observe what happens. This is not only quick to do, it’s also useful because, at the beginning, you often do not know the real shape of the work yet.

So the agent helps you discover things like:

• which steps repeat every time

• which data is missing or messy

• where approvals are needed

• which parts require actual judgment

• and more

Once the workflow becomes clear, though, the boring parts should be extracted into something more deterministic: scripts, APIs, cron jobs, workflow definitions, or whatever tool fits the job. That makes the workflow faster, cheaper, and easier to observe and debug.

These days I try to keep AI where flexibility is valuable (e.g. judgment calls), and replace it where determinism is cheap. Most often, it’s a progression: I start with an agent because it is fast, observe where the task repeats, harden the stable steps, and leave the ambiguous parts to AI.

I wrote more about this in the full piece on orchestrating AI workflows 👇

Refactoring

How to Orchestrate AI Workflows

Hey, Luca here! Welcome to a weekly essay from Refactoring…

Read more

3 months ago · 60 likes · 1 comment · Luca Rossi

2) 💬 Giving feedback should be ordinary

Feedback is often treated like a special event. It’s the performance review, or the difficult conversation we should have had long ago, or the moment when something went wrong enough that somebody has to say something.

The problem is that, if feedback only appears in those moments, people learn to associate it with danger. They hear “can I give you some feedback?” and brace for impact.

In my conversation with Jean Hsu and Cate Huston, two professional coaches, Cate shared a better habit: every time someone does something good, tell them.

When people receive frequent, specific positive feedback, they learn that you are paying attention to their work as a whole, not only waiting for mistakes. Then, even when you eventually need to say something corrective, it lands differently.

You can also spread this beyond yourself. When someone praises a colleague privately, ask: “have you told them?” Over time, feedback stops being capital-F Feedback and becomes normal signal in the system.

You can find the full interview with Jean and Cate here 👇

3) 📚 Weekly Readings

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

🥇 The Tower Keeps Rising

3 min • by Armin Ronacher

I really like the Babel analogy applied to how we cooperate as humans and, ultimately, software. For the first time, “construction” can keep going even after humans have lost the shared language needed to reason about the system. Food for thought.

🥈 Generated and Suppressed Demand

3 min • by Will Larson

A useful mental model for why fixing a struggling team can feel like nothing improved. Sometimes the team gets better, and the reward for it is... more work! All the previously hidden demand finally shows up. Great management advice, as always from Will.

🥉 Control the Ideas, Not the Code

6 min • by Salvatore “Antirez” Sanfilippo

Antirez makes a clear point that many engineers are still resisting: if AI writes more code, reviewing every line is probably the wrong use of your time. You have more leverage when you focus on ideas and design.

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 episode is brought to you by:

Unblocked is the context layer for modern engineering teams. Get a free three-week trial at getunblocked.com/refactoring

Today's guest is Anush Elangovan, VP of AI Software at AMD.

With Anush, we talked about how he thinks about open source as a key strategic driver in the AI era, and how his team is able to stay super fast while ensuring quality by combining their internal work with their external contributions.

And then we got into a rabbit hole about how to get big companies ready for AI, how to think about human capital, and how Anush personally spends his time. And spoiler alert, he is back to doing IC work for up to 40% of his time.

🥇 Interview Summary

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

It’s the 5-minute, handcrafted 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. 🔓 AMD’s open-source AI stack

2. 🤖 Navigating AI-generated code contributions

3. ⚡ Speed as the only moat

4. 🏗️ Getting legacy systems AI-ready

5. 🧠 Why leaders should get their hands dirty

⠀Let’s dive in 👇

Read more

That’s because I write a lot about my AI workflows with Tolaria, but many people (rightfully) tell me that things are more complex on a real team.

So I invited the team at Augment to share how they transformed their own engineering org, redesigning their main dev workflows. It’s free for everyone and you can RSVP below!

Learn more and RSVP!

Hi there! A lot of people these days ask me what AI models I use for coding, which I usually explain in my monthly recaps.

Some people also ask me “why” I use one model vs another, and that’s a way more complicated question to answer. AI models are hard to evaluate, because there are several factors to consider, and because, despite what public benchmarks say, each team situation is unique.

So today let’s try to think from first principles about how you should choose what LLM to use for coding, factoring everything in. Also let’s try to find some durable angles, so that you can create a mental model for yourself that stays valid for more than a couple of weeks.

Here is the agenda for today:

• 🔺 Accuracy / Speed / Cost — the three dimensions of model selection. But they are messier than you might think.

• 📊 Public benchmarks are not enough — you can’t trust leaderboards, and how your codebase discipline sets your floor.

• 🧪 How to evaluate AI models — a maturity path from “just don’t” to building your own eval.

• 🔀 Model routing — not all tasks are equally hard, so stop paying frontier prices for all of them.

• 🏠 Self-hosting: almost never — cloud-hosted cheap models beat your own hardware, every time.

Let’s dive in

🔺 Model Selection 101

With some degree of simplification, today you have three macro choices:

1. Top frontier models — e.g. Fable 5 or GPT 5.6

2. Large open weights models, hosted in the cloud — e.g. GLM 5.2 on OpenRouter

3. Smaller open weights models, self-hosted — e.g. see DeepSeek 4 Flash via DwarfStar by Antirez

These choices are actually more nuanced than this, because e.g. within frontier models, you may tweak the level of reasoning, or intentionally pick a smaller model that is cheaper and faster, because you feel it is a better fit for your task.

In fact, when judging models, there are three dimensions to consider:

• 🔬 Accuracy — % of times the AI gets the thing right

• ⚡ Speed — tokens per second

• 💸 Cost — cost per 1M tokens (multiplied by tokens required)

To make things even messier, these dimensions are not orthogonal. For example:

• A model with higher accuracy may translate into fewer round trips, which may translate into fewer tokens being used.

• With many models you can reduce the amount of reasoning to improve speed while reducing accuracy.

So, in most cases, performance is tricky to evaluate. Top frontier models guarantee max accuracy, but do you really need it?

Most people have anecdotal experience of small tasks for which fast + cheap models delivered the same level of accuracy. But how do you recognize them?

Also, it’s trickier than that, because even for bigger tasks you might find that a faster model, while less accurate, iterates faster over mistakes, leading to a lower cost overall. That’s what Jamie Turner, founder at Convex, was already saying last year:

We optimize for fast feedback loops over perfect output. It’s better to get 80% correct code in 2 seconds than 95% correct code in 2 minutes.

Jamie made the case for optimizing for a quick feedback loop, so that developers don’t lose their train of thoughts while waiting for slow responses, even at the expense of a few more errors.

This is even more compelling when you factor in that with the current crop of LLMs, accuracy and cost are not in a linear relationship: a model that is 80% as accurate as the top frontier one might cost 1/10th of it.

Two good examples are GLM 5.2 and Grok 4.5. They both score pretty close to the top OpenAI and Anthropic models, while costing a small fraction of them.

Looking at these numbers is a good way to start some kind of quantitative reasoning around models, but I don’t think it’s enough 👇

📊 Public benchmarks are not enough

I have grown skeptical of public benchmarks, for two reasons:

Read more

🪜 The 8 Levels of Context Maturity

This is brought to you by our friends at Unblocked!

The token spend shows that AI is in your engineering workflow, but the throughput doesn’t!

Raise your hand if you can relate. A lot of the times, this is a context problem. I personally invest a lot in making sure AI gets good context about past decisions, what exists, and what needs to do, and I get a lot of help from Unblocked about this.

On July 23rd, the Unblocked team is running a free webinar that maps the 8 levels of context maturity: where most teams are stuck, what the ceiling looks like at each stage, and what it takes to make the most out of your agents.

Very recommended 👇

Join live July 23rd (FREE)

1) 🗳️ Anticipate exec questions

Whether you are an engineer or a manager, one of the most underrated skills you can have is making your ideas easier to approve!

This is often tricky, especially when presenting to executives, who may be removed from our work and don’t understand technical details. In this case, you can put yourself in their shoes and *anticipate *many of their questions, like:

• How much will it cost?

• What do we get for the money?

• Why now?

• What happens if we do nothing?

• What other options did we consider?

• How will we measure success?

• What are the risks, and how do we reduce them?

• Who owns delivery?

• Which other teams or business areas are affected?

Some of these will feel annoying or nitpicky, or even not really applicable to your situation, but you may get asked them anyway! The more senior someone is, the wider their span of responsibility becomes, and the less time they can spend understanding any single problem. Expect broad, sometimes even off-topic questions.

So your job becomes to compress the important context for your interlocutor, translating complexity into things like trade-offs, outcomes, risks, and timing.

A good proposal should make the obvious executive questions boring, because they are already answered. That is how you turn a good technical idea into something the business can actually say yes to.

I wrote more about this in the full piece with Anna Shipman on the Engineer → Executive Translation Layer 👇

Refactoring

The Engineer → Executive Translation Layer 🔀

Hey, Luca here! Today we are hosting a fantastic new article by Anna Shipman, CTO at Kooth…

Read more

9 months ago · 31 likes · Luca Rossi and Anna Shipman

2) 🎧 Quiet leadership prevents noisy emergencies

Tech culture loves the person who saves the day.

The engineer who stays up late to fix production. The heroic intervention that makes everybody clap.

These days I rewatched my first conversation with Rands, and I love how he pushed back on this instinct. Rands simply says: if someone saves the day, the first question should be “why did the day need saving?”

A lot of good leadership is invisible because the bad thing simply never happens. It’s when:

• You act on a yellow flag before it becomes a red flag.

• You give feedback early, before resentment piles up.

• You listen long and hard enough to understand what is actually going on, instead of rushing to action.

Nobody claps when nothing explodes, but that’s how it works.

To make this possible, Rands stresses over the importance of listening as an active leadership tool. You need to be collecting the weak signals, the small patterns, which lead to equally small (but crucial) interventions every day.

You can find the full interview with Rands here 👇

3) 📚 Weekly Readings

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

🥇 Viability of Local Models for Coding

9 min • by Birgitta Böckeler

A useful reality check on local coding models. The short version is they are getting much better, but the constraints are still very real: RAM, speed, context, tool calling, and reliability all matter. Great piece by Birgitta who we also interviewed last year.

🥈 In Defense of AI Mandates

4 min • by Charity Majors

I love how Charity frames AI mandates as a funding device. This means. if leaders want people to learn a new way of working, they have to make room for the temporary slowdown, the annoyance, and the mess. Charity was also one of the very first guests of our podcast.

🥉 We should be more tired than the model

2 min • by Vicki Boykis

An interesting take that I largely do not agree with, but gave me something to think about. I love the idea of using LLMs in a way that I can *grow *(as opposed to my skills atrophying here and there), but I don’t see myself going back to writing code manually in order to do that. That’s too big of a tradeoff. But will look for ways to make this more palatable!

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 episode is brought to you by:

Unblocked is the context layer for modern engineering teams. Get a free three-week trial at getunblocked.com/refactoring

Today’s guest is Geoffrey Litt, Design Engineer at Notion.

With Geoffrey, we talked about malleable software, a type of platform that kind of always existed, but is now getting new meaning and opportunity thanks to AI.

We also discussed how Notion itself changed its place in the ecosystem, with the AI agents first, and now with the new developer platform, where you can ship code directly inside Notion. And finally, we talked about how Notion builds Notion, design as shipping code to production, internal prototyping, feature flags, and more.

🥇 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 malleable software?

2. 🚲 The nightmare bicycle and progressive disclosure

3. 🤖 Notion’s AI agent platform and developer tools

4. 🎨 Design engineering and shipping code to production

5. 🔮 What’s next for Notion

⠀Let’s dive in 👇

Read more

Every week I write an article to 170K+ engineers about how make good software together, and interview a world-class tech leader. I also build and maintain Tolaria in the open, publishing my workflows and learnings here.

Subscribe now

I happen to know many startups who develop B2B products for large companies. I worked in one, invested in another one, and have friends who work in others.

An evergreen problem about these products is organizing work in a way that successfully takes into account:

1. Roadmap / long-term product strategy

2. Impromptu requests from key customers

This is tricky from all points of view: business, tech, and team organization. I have thoughts about this, so let’s start from first principles. Really the very basics.

We build tech to solve problems to customers, that pay us in return for it. At any given time we can have many of such customers. Based on this, the type the work we can do to solve such problems lays on a spectrum from bespoke to one-size-fits-all:

• 100% bespoke — is consultancy work. You just solve the problem, IP is of the client, zero reuse.

• 100% one-size-fits-all — is product work. You develop features that can be used by all (or many of) the customers of your product.

These types of work are very different but, fortunately, in most real-life situations it’s obvious where your work should land on the spectrum.

First of all, a lot of the ambiguity is cleared up upfront, by deciding the type of business you want to build. Knowing that you want to build an agency vs a B2B SaaS takes a lot of cards off the table:

• If you run an agency, the problems you solve change all the time, and there is most often not a clear path to building reusable pieces.

• Conversely, if you ran a B2B SaaS with e.g. thousands of customers, any of these customers might want something custom, but it’s obvious that it’s not worth to build it just for them.

About the latter, though, what if these customers are not thousands, but hundreds — or maybe just tens — and each of them is very valuable to you?

That’s where things get messy. Welcome to enterprise B2B SaaS.

So here is the agenda for today:

• ⚖️ Customer work vs product work — why enterprise B2B creates a unique tension between different types of work, and how you should think about them.

• ⁉️ Is it worth to do bespoke customer work? — the right questions to ask yourself before committing to custom work for a single customer.

• 🎽 How to design team structure — use dedicated roles like solution engineers of FDEs to shield your roadmap from customer requests.

• 📏 How to design tech strategy — empower solution engineers with great platform, so they move fast and build things close to product shape.

• 🔀 How to converge — treat customer work as validated product input, and create avenues to merge it back over time.

Let’s dive in!

⚖️ Customer work vs product work

If a customer of yours is paying you $100K for a yearly contract, instead of e.g. $2K, and you have, say, only 12 of those customers, all of a sudden their requests, however absurd, look... different.

This customer has leverage — and you have probably spent a lot to acquire them, so it can make complete business sense to do something specific to make them (and only them) happy.

We said this is a spectrum, but for the sake of simplicity let’s call this type of work “customer work“, as opposed to more general “product work“, which is done in the service of everyone.

The problem with customer work vs product work is that they have completely different shapes, when it comes to fundamental factors like:

• When and how such work spawns

• How urgent it is

• How big it is

• How it fits your overall strategy

One of the goals of your standard product workflow is to control for these factors, in order to normalize them. So items you plan for are: comparable in size, planned in timely fashion, all fit your strategy, and so on.

Customer work spawns, by definition, from external forces, which makes all of the above out of your control. It also doesn’t land with the same level of discipline that you might put into your product process, so it’s work that is often: urgent, big, and unrelated to your plans.

This leads to questions:

• When is it worth to do these things?

• How should I design my company accordingly? Speaking of team, tech, and process?

Let’s start with the first one.

Read more

🎟️ Join our webinar on how to become an agentic engineering org!

On July 22nd I will host an exclusive webinar together with the team at Augment Code!

Most teams adopt coding agents and see a 20% lift at most, and then plateau. The most common reason is that the bottleneck moves, and you should lift your whole dev process, not just coding.

In this session, the Augment Code team shares how they transformed their own engineering org by redesigning one workflow at a time, and demos two of them live on a real codebase: agentic code review and automated incident management, where agents now resolve the majority of incidents end-to-end.

You’ll leave with a playbook for finding your org’s current bottleneck and a workflow you can replicate with your team this week 👇

Learn more and RSVP!

1) 🧹 AI makes code hygiene enforceable

I have written many times about this recently, but I’ll keep hammering on this point because it is so important, and I believe many people haven’t fully grasped it yet.

Good code hygiene is, at once, 1) something everybody agrees with in theory, and 2) quietly and often sacrifices in practice, because it’s hard to maintain.

Things like good test coverage, small files, high cohesion + low coupling, low cyclomatic complexity, have all historically needed people who care enough to push for it, review for it, and absorb the cost of fixing it.

For the first time, AI allows to turn hygiene into a system that can be enforced at almost no additional cost. You can give agents rules about how to write tests, keep files small, or refactor before adding new behavior.

Many of such rules can also be enforced by gates: coverage checks, code health thresholds, linters, static analysis, and more. Guidance tells the agent what the floor looks like, and gates make such floor non-negotiable. And you can design these checks to run early, so the feedback arrives while the work is still cheap to fix.

The #1 concern of engineers about AI coding is still code quality, but you can actually use AI to increase the code quality of your team. I wrote more about this in the full piece on the compounding software factory 👇

Refactoring

The Compounding Software Factory 📈

Hey there, Luca here…

Read more

4 months ago · 58 likes · 2 comments · Luca Rossi

2) 🪞 Find a broader identity for yourself

A lot of the anxiety around AI is really about who you are (and who you are going to become) as a professional, rather than about tools.

Based on your sense of identity, AI can feel either like an opportunity, or a threat.

If you define yourself narrowly — e.g. “I am a backend engineer who is great at algorithms”, or “I love the thrill of solving puzzles with code” — then AI might feel like it is walking into your house and stealing furniture.

Earlier this year I talked about this with my friend Thiago Ghisi, who had a long engineering leadership career, and then used his sabbatical to step back and look for broader patterns in his life and work.

He is now studying clinical psychology— and sure, if you frame him only as a Director of Engineering, this might look like a strange detour. But if you frame him as someone who helps high-achieving people grow, you can suddenly connect more dots.

I think this is a useful exercise for engineers too. Instead of thinking in terms of skills, ask yourself:

• Why do I do what I do?

• What is a broader version of my role?

• What kinds of problems do I actually care about solving?

A broader identity makes you more adaptable, and opens up more opportunities. You can find the full piece below 👇

Refactoring

Finding yourself in the AI era ✨

Hey, Luca here! This is a ✨ bonus free essay ✨ from Refactoring. Based on our schedule it should have been a paid one! But I really care about this topic so I decided to make it free for everyone…

Read more

7 months ago · 77 likes · 6 comments · Luca Rossi

3) 📚 Weekly Readings

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

🥇 The Cost YAGNI Was Never About

4 min • by Kent Beck

I love how Kent reframes YAGNI for the AI era. The cost has never been writing the actual code, but rather spending optionality too early, and pulling investment forward before the feature can pay you back. Great article everyone should read.

🥈 The Wrong Abstraction

4 min • by Sandi Metz

This is a great segue to the Kent’s article above. Duplication is usually cheaper than the wrong abstraction, because the wrong abstraction eventually collects all kinds of bad stuff — parameters, conditionals, and sunk-cost arguments. Sometimes the fastest way forward is going back, but this is usually very hard to do.

🥉 AI and Liability

4 min • by Bruce Schneier

Including this great piece by Bruce even if it’s not properly about software engineering, because it’s so relevant today. Companies should be liable for what their AI agents say and do, just like they are for employees or published content. If your product presents an answer with your logo on it, you should own it, and not use “the model said so” as an escape hatch.

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

By now, developing Tolaria is a big chunk of my working time (about 40%, to be precise). I like this balance and I am happy I can regularly write articles about AI coding coming from my own experience, as opposed to pure research.

I also don’t want to end up writing only about that, and so far I have kept a schedule of about once a month. This feels like is a good cadence: it’s feel overwhelming for readers, and gives me time to produce actual updates to the workflow, as opposed to posting always the same things.

So, today I am covering a few workflow updates, but most of all I am introducing a new set of partnerships I am very proud of.

So let’s dive in!

💧 The State of Tolaria

First of all you may wonder: how is Tolaria doing? Pretty well, if you ask me.

From a growth perspective, it has now almost 18K stars on Github, 100K+ downloads, and thousands of daily active users.

From a product perspective, this month we delivered a ton of updates, including some massive ones, like the support for native spreadsheets.

You can now create and edit spreadsheets inside Tolaria with Excel-compatible formulas in a completely open and portable format, which is basically CSV with a frontmatter on top.

We also improved a lot of the editor experience, adding collapsible headings, block navigation, better spacing and typography, all while making everything faster than ever. If you haven’t tried it in a while, you definitely should!

I really enjoy developing (and using!) Tolaria, so the question recently has rather become: how do I make this work sustainable, while keeping everything free and open?

Enter our tech alliance!

🦸‍♂️ Creating our own Tech Alliance

The tools I use to develop Tolaria are no secret — you can figure out most of them by looking at the repo, the AGENTS file, hooks, and my own articles.

So, over the last month I reached out to the ones I use the most to figure out if we could work together to make the development of Tolaria more sustainable on my end via open source sponsorships, in return for me spreading the word about how I use such tools, and providing good feedback on how to improve them.

The result is an alliance that as of today includes four tools: CodeScene, CircleCI, Codacy, and Unblocked.

These partnerships allow Tolaria to stay free and open forever, and even give us the opportunity to accelerate by hiring a great product engineer (if you think you are a great fit, please reach out and say hi!).

So today I will tell you more about my workflow, which includes these tools — but first an ethical statement: I will only ally (and stay allied) with tools I personally use and believe are the best way to do what they do. As you will see these are non overlapping: each has its own job, so they really make for my tech stack. Over time we will also expand on this and create exclusive deals for Refactoring subscribers!

Before we talk about the tools, it’s worth refreshing how I think about controls for code written by AI. I have written about it in this recent piece 👇

In a nutshell, I steer AI output in three main ways:

• ↪️ Guides — instructions in the AGENTS file and skills. Not 100% reliable: the AI may or may not follow them.

• 🔄 Gates — deterministic checks that don’t let bad code move forward if some conditions are not met.

• ↩️ Guards — fallback procedures that typically run once a day to fix what goes through the cracks.

Out of these, the most important part is the gates, because they have the (deterministic) power to stop bad code, so the more I can express this way, the better. Most of the tools below are integrated this way.

So let’s go 👇

🩺 Code Health — with CodeScene

CodeScene probably needs no introduction because I have written about it many times here. I am a big fan of Adam Tornhill‘s work, which to me is about two big things:

• A proprietary algorithm to calculate code health, that considers 20+ factors.

• The “hotspot” approach, which looks at git history and suggests refactoring targets prioritizing files that are changed the most often.

I integrate CodeScene as a hard gate in local hooks: new code can’t be committed if it’s not a 10/10. For modifying old code, the AI needs to follow the boy scout rule: leave the code better than it found it. So it measures the code health before touching the file, and after, and the score needs to be the same or higher.

After any commit that improves the overall codebase health, the AI also increases the thresholds, to create a positive flywheel.

After four months working like this, now the code has perfect health, and the current threshold is literally 10/10!

🔒 Security and Quality — with Codacy

Codacy works on code quality too, but from a different angle: rather than scoring files, it surfaces individual issues.

Issues come with severity levels and belong to various categories, like security, performance, compatibility, code being error prone, and more.

Codacy has an MCP that I use to steer my Codex locally, and to implement an actual blocking gate before it pushes any code. All new code has to be issue-free, and when touching old code, the AI also needs to fix existing problems, other than making the business changes.

I am also working with the Codacy team on their new product Verity (you can join the beta for free here), that aims to steer agents’ work by creating a knowledge base of past decisions.

This is interesting to me because I do that with ADRs, and would love to create more reliable controls against code that violates them. Verity is promising about that, and should also track token efficiency and a bunch of process metrics that I am interested in improving over time.

✅ Validation — with CircleCI

A few months ago I made a change in how I run our test suite, creating local hooks with Husky so that AI agents can immediately see if controls fail, instead of waiting for the remote CI.

This was very effective at improving the agents’ work, at the expense of completely hogging my machine every time. Some parts of the test suite are particularly heavy (e.g. playwright), and running them in local means the whole thing takes time — about 15 mins — and parallelizing things is out of question, because resources are not enough. It’s tricky to run even just 2 worktrees at the same time: things sometimes literally crash.

I talked with Rob Zuber from CircleCI about this, and they implemented a great solution: local hooks that are run remotely, in what they call Chunk Sidecars.

Sidecars are preconfigured environments that run alongside your local workflow, and validate changes as they happen.

This allows to 1) free up your machine resources, and 2) make things faster by introducing real concurrency.

This way I have been able to reduce the suite run time from 15 to 4 mins, while also being able to spawn more worktrees safely. A massive win!

📖 Fetching knowledge — with Unblocked

Unblocked is a context engine: it takes information from several sources (e.g. Github, Notion, Slack, Datadog, ...) so you can ask questions about it.

I have known Dennis, Claire, and the team at Unblocked for a long time, but didn’t think of using it for Tolaria until just recently, because I thought that Unblocked would shine when you have many information sources, and we legitimately don’t have many.

I was wrong.

I plugged it about one month ago, connecting it to Github and Sentry. Sentry is useful to triangulate issues, but the Github connection would basically be worth by itself, because it indexes the code, the ADRs, and all the history of changes.

I have been asking questions about how we do this and that and checking side by side with Codex (which instead just greps and fetches things on the go) and the difference in speed and accuracy is just obvious.

Even more importantly, Codex itself uses Unblocked via the MCP to understand past decisions and fetch relevant ADRs.

Big props to the Unblocked guys because this was an easy win and largely plug-and-play!

🔭 What’s next

Now that Tolaria has sustainable funding, I am going to invest even more on it. Again, I am exploring hiring a strong product engineer, so if you think you can be a good fit, feel free to reach out and say hi!

As for future work, the most important thing ahead is the mobile version.

I already have a working prototype for iPad, but there are still a lot of rough edges. Also, the iPad version is the easy part: for smartphones we need to completely reinvent the UI — I have been working on it 💪

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

Sincerely 👋
Luca

1) 🧭 Organize information based on action

Most knowledge bases slowly become piles of uninteresting information. After a while everything starts looking the same: meeting notes, ideas, projects, living side by side and you don’t know exactly how and why.

I believe when you store a new piece of information, there are two questions you need to ask yourself:

• What is this?

• What is this useful for?

The second question is often overlooked, and it’s a core idea behind Portent, which I published last month.

Portent includes default types — which answer the question “what is this” — but also a set of default relationships (belongs to, related to, etc) to help you figure out how to connect notes together, based on what they should help you with.

So, a meeting may belong to a project, a procedure may belong to a responsibility, a resource may be related to a topic, and so on.

Connecting notes together is hard work, but it’s paramount work! Otherwise you easily get stuck: you optimize too much for memory, and not enough for motion.

The goal is to know what to do next, rather than remember more stuff.

You can find the full article below:

Refactoring

Introducing Portent ☘️

Today it’s almost one month since I released Tolaria, and during this time I have spoken with many people and teams that are trying to use it to create and manage internal knowledge bases…

Read more

3 months ago · 63 likes · 7 comments · Luca Rossi

2) 📊 Treat code health as a data product

Code quality conversations are often extremely vague.

Everyone wants cleaner code, fewer bugs, easier changes, but unless these things become visible and measurable, they remain mostly opinions.

One thing that I liked in my conversation with Stuart Caborn is that Loveholidays treated code health like a data product.

They collected signals, put them on dashboards, trended them over time, compared teams, and checked whether the numbers matched how engineers felt in sentiment surveys.

The AI angle makes this even more important. If code health data is available through tools and MCP servers, humans and agents can ask questions directly:

• How is my team doing compared with yesterday?

• Are there any areas that got worse this week?

• Where should an agent be more careful?

At that point code health becomes a feedback system that informs your dev process, and it’s exactly the kind of feedback AI needs. The better the codebase, the easier for agents to understand it, change it, and spend fewer tokens doing so.

You can find the full interview with Stuart here 👇

3) 📚 Weekly Readings

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

🥇 Earn Your Scepticism

10 min • by James Stanier

James makes a distinction I like a lot: scepticism as a conclusion vs scepticism as an identity. The useful version comes from actually using the tools, staying specific about what fails, and keeping your mind open as the evidence changes. This applies just as much to AI enthusiasts as to sceptics.

🥈 Expertise in the Age of AI

5 min • by Brian Kihoon Lee

Brian uses calculators as the analogy for coding agents: the tool removes a lot of mechanical work, but makes the underlying intuition even more valuable. I do not agree with every prediction in here, but the core point is sharp: skipping the struggle may leave you unable to judge the output.

🥉 Find a New Role - Worksheet

4 min • by Lara Hogan

Lara turns career decisions into four simple lists: must-haves, nice-to-haves, don’t-cares, and what you are optimizing for. This is practical and useful, especially when titles, prestige, and compensation make a role look more appealing than it really is.

Quick heads up! Joel and Melinda, coaches in residence at Refactoring, are part of a group offering full coaching scholarships to 29 engineering leaders from underrepresented groups in tech. Applications are open until the end of the day on 30th June.

Learn more and apply here

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 episode is brought to you by:

Unblocked is the context layer for modern engineering teams. Get a free three-week trial at getunblocked.com/refactoring

Today’s guest is Michael Lopp, better known as Rands, who is writer of several popular books about engineering management, including “Managing Humans”, which is a personal favorite of mine.

Live at LDX3, we discussed his lifelong writing habit, the importance of giving feedback through stories and the leverage of leadership experience in the AI era.

Quick heads up! Joel and Melinda, coaches in residence at Refactoring, are part of a group offering full coaching scholarships to 29 engineering leaders from underrepresented groups in tech. Applications are open until the end of the day on 30th June.

Learn more and apply here

🥇 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. ✍️ Writing as a lifelong habit

2. 🏷️ The power of naming things

3. 💬 Stories as a feedback tool

4. 🤖 AI and the return of the coding manager

5. 📖 Managing Humans, Managing Robots

Let’s dive in 👇

Read more