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

a month 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

🎟️ Discover 8 levels of context maturity in AI engineering

This edition is brought to you by our friends at Unblocked!

AI shows up in 60% of engineering work. But only about 20% of it can be handed off without someone babysitting the output. That’s because agents are missing context.

This 8-stage context maturity model gives a real answer on why you haven’t seen meaningful productivity gains for all the tokens burned.

Join live June 24 (FREE) to learn:

• Why more MCPs provides agents access but not understanding

• What it takes to deploy agents you can trust without supervision

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

Learn more and register

1) 🔍 Is validation really the new bottleneck?!

So are the pundits (like myself) right? Is validation the new bottleneck? I think it depends, but for Tolaria I surely spend a lot of time on it.

Every task that gets completed by the AI is shipped in a new alpha version and moved to the “in review” section, where I review it against my production vault.

Here, a few things may happen:

• It’s good — I move the task to “to release”

• It’s ~90% good — I do the final tweaks from my MacBook’s Codex

• Needs work, but it’s still good progress — this is the trickiest to decide. If it’s incomplete but still useful, I have a bias towards progress and I release it anyway, creating a separate task for the improvements.

• Wrong or not usable — this is where the task is sent “to rework”, with a QA comment about what needs to be fixed.

I do a big batch of reviews first thing in the morning, for tasks that were done overnight, and then usually again after lunch, and before dinner, where I also try to make sure the AI has enough to do for the night.

So today validation feels like the biggest bottleneck indeed, also because I believe the right course of action most of the time is to keep specs light and let the AI figure out stuff by itself.

For most features, even when the first pass is not exactly how I wanted it, there is an argument to be made that if it’s good progress it should be released anyway, and have users chip in and give feedback. This has worked well many times, and evolved the product in the right direction faster than if I had waited for a perfect first version.

Of course nothing of this is exactly new thinking (MVPs, etc), but I think what’s changing here is the magnitude. I find that the right course of action is constantly to release a bit more control than what I am comfortable with, and this boundary keeps moving.

I wrote more about this in the full piece on how I run Tolaria as a 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

2 months ago · 50 likes · 2 comments · Luca Rossi

2) 🌍 Async vs sync comms at Todoist

Remote work debates often get stuck in a binary: async good, meetings bad, or the reverse.

What I liked in my conversation with Gonçalo Silva, CTO of Doist, is that their view is much more practical. Doist has been remote-first for more than a decade, long before the COVID era, and they have learned that async-first does not mean async-only.

Async is fantastic when people need focus, when the topic is well-bounded, and when a thoughtful written update is enough. Doist replaced a lot of status rituals with async threads: people write updates when it works best for them, and others consume them on their own schedule.

But some conversations are simply bad async candidates. Gonçalo’s heuristic is to look at the number of iterations you expect:

“If you’re disagreeing with somebody and you feel like you’re not quickly advancing towards convergence, that is probably a great prompt to just hop into a meeting. We settled a conversation that had been going on for multiple days in a call in 14 minutes.”

If the topic starts from a blank canvas, involves disagreement, needs multiple rounds of back-and-forth, synchronous chats are the faster tool, and should not be seen as a failure of async culture.

You can find the full interview with Gonçalo here 👇

3) 📚 Weekly Readings

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

🥇 AI Demands More Engineering Discipline. Not Less

12 min • by Charity Majors

When Charity writes, we listen. The real product of a software team is shared understanding, and AI-generated code makes that easier to destroy at scale. For this reason, discipline now matters more, not less.

🥈 Revised Rules of Engineering Leadership

8 min • by Will Larson

Will’s piece is a great attempt at updating classic engineering leadership rules and ideas for the agent era. A lot of great takes about migrations, domain expertise, harnesses, and more. Including practical examples!

🥉 Humans and Agents in Software Engineering Loops

7 min • by Kief Morris

This connects nicely with the loop-engineering conversation: humans should not micromanage every generated line of code, but design and improve the loop that lets agents build, test, and learn. Great article hosted on Martin Fowler’s blog.

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

📊 Engineering leaders don’t have a way to measure AI results

This newsletter is brought to you by our friends at DX!

DX has spent the last year studying what this measurement gap means in practice.

On June 18th at 09:30 PT, Distinguished Scientist Brian Houck and Deputy CTO Justin Reock are presenting their research on agent experience, AI readiness, and what the data says about productivity in an agentic world.

You can register for free below 👇

Register here for free!

1) 🧱 Keep deterministic plumbing outside AI

A lot of AI workflow demos make it look like the agent should own the whole process: understand the goal, decide the steps, call tools, and maybe even schedule the next run.

This is quick (and exciting!) when you are prototyping, but it is arguably a bad default for recurring work.

The boring parts of a workflow—routing, retries, scheduling, validation, etc.—need to be dependable, rather than “smart”. For things that I run regularly (e.g. all Tolaria procedures) I want to know which steps failed, what inputs they saw, whether they retried, and what state was left behind.

So the architecture I like more and more is hybrid:

• Orchestration owns the skeleton — when the workflow runs, what each step consumes and produces, how failures recover, and what humans can inspect.

• AI owns the messy parts — classification, summarization, judgment calls, and human-readable updates.

This does not make AI less important. If anything, it makes it more useful, because it stops wasting tokens and attention on plumbing that traditional software is a better fit for.

So, agents are a fantastic way to discover/prototype a workflow. But once the shape is known, the right move is to extract the stable pieces into code and keep AI where ambiguity actually exists.

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

2 months ago · 55 likes · 1 comment · Luca Rossi

2) 🌐 Open source in the age of AI

Last week Ladybird announced they are stopping accepting public PRs — the latest of a series of projects doing the same.

This made me think of my chat with Chris Lattner, where we discussed the impact of AI on open source.

Chris has spent a huge part of his career building massively successful open source projects — LLVM, Swift, MLIR, Mojo — and is concerned about the current state of things. As it’s now obvious, AI makes it much cheaper to produce contributions, but it does not make reviewing them equally cheaper.

“With AI tools, what’s happening is that a lot of maintainers are getting overrun. The contributor doesn’t have to do nearly as much work, but the reviewer has to do the same — at a bigger scale. I think it’s going to lead to new contributors not getting the attention they deserve.”

This is important because, in open source, patches have always been about mentoring and trust-building. Maintainers invest time in people, people learn the project, and some of them eventually become future stewards.

Chris also connects this to intellectual property. If agents can rewrite proprietary tools, translate GPL code into MIT-looking projects, then copyright and licensing become much harder to reason about. As it’s often the case, legal systems lag behind reality.

But the optimistic version is that this also pushes companies toward openness. If secrecy and proprietary headers become weaker moats, the better strategy is to build strong communities, move fast, and compete on innovation rather than control.

We should decide whether to see the glass half empty or half full!

You can find the full interview with Chris here 👇

3) 📚 Weekly Readings

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

🥇 Domain Expertise Has Always Been the Real Moat

3 min • by Aaron Brethorst

Short, sharp, and very true: AI makes writing software cheaper, but it does not make knowing what “correct” means any cheaper. The best engineers were always the ones building a model of the domain in their head, as opposed to simply translating tickets into code. That part is still a moat!

🥈 What Happens When the Coding Becomes the Least Interesting Part of the Work

8 min • by Obie Fernandez

I liked this because it frames AI coding less as “the machine writes code” and more as “the machine forces you to make senior thinking explicit.” If you care mostly about typing code, agents are annoying. If you care about judgment, tradeoffs, and intent, they free up the interesting part.

🥉 Changing How We Develop Ladybird

3 min • by Andreas Kling

Ladybird is stopping public pull requests and moving to maintainer-only code changes. The rationale is that, in the AI era, patch size is no longer a good proxy for effort or good faith. Open source maintainers are going to rethink trust, review, and responsibility a lot more than we admit. Thinking about this myself with Tolaria.

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

TRM is AI intelligence for public safety — and it’s hiring! 📣

This newsletter is brought to you by our friends at TRM!

TRM models turn petabytes of data into actionable intelligence across the threat landscape: ransomware groups, human trafficking networks, darknet markets, terrorist financing, and more!

Threats don't wait. And neither does the TRM team.

Engineers at TRM work at a scale most never touch: real-time graph traversal, petabyte-scale pipelines, and models that power investigations with real-world impact. If you want your code to catch criminals, this is where you build it 👇

Check open roles

🧮 Map and score devex problems

Most teams have structured ways to work on customer problems — which we call “product” — but do not apply the same rigor to developer experience issues.

Earlier this year I advocated to do a listening tour with your engineers to uncover devex problems. An important part of the tour is not to stop at the uncovering stage: you should map, score, and prioritize issues so you work on the right things.

Mapping means taking stories — situations where bad things happened — group them together into friction points, and map them to steps of your dev process.

You can reuse the story map format for displaying this, but you don’t have to necessarily do it that way. You can use a spreadsheet or anything else.

The outcome might be something that looks like a three-level investigation that includes steps, problems, and stories 👇

After you collect problems, it’s time to score them. To do that, the most useful coordinates I have found are reach and impact:

• Reach — how many engineers are impacted by this

• Impact — how much disruption it causes

If this makes you think of RICE, we are not including:

• Confidence — because it’s often tricky to figure out and I haven’t found it that useful in real life, nor

• Effort — because we are only talking about problems here, not solutions.

Also, I am a fan of using simple scores, like low-medium-high, or 1-5.

After that, you should focus on the one true bottleneck™ — I wrote more about that in the full article 👇

Refactoring

The Listening Tour 📞

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

Read more

5 months ago · 36 likes · 3 comments · Luca Rossi

🪜 Career direction starts with what you want

Career planning starts getting useful when you stop asking only what the ladder says and start asking what you actually want.

Many engineers sleepwalk through their careers by following the next obvious step: promotion, bigger scope, manager track, staff track, better company, higher comp. Those may be good goals, but they are not a substitute for knowing what kind of work makes you thrive.

Last month I interviewed Jean and Cate, two professional career coaches, and they told me they are a fan of asking two simple questions:

• What was a peak moment in your career?

• What does it look like for you to thrive?

They asked them to me and I had to think for a minute or so. These questions are designed to pull attention away from abstract “prestige“ and toward real-world evidence. When did work feel energizing? What kind of contribution mattered? What environment made you stronger?

Also, the answer does not need to become a ten-year plan. In uncertain times, an horizon of a few months may be more useful: try something, observe how it feels, adjust, repeat.

Career direction is built every day from good reflection and experiments.

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

Also on Spotify and Youtube

📚 Weekly Readings

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

🥇 Why Japanese Companies Do So Many Different Things

20 min • by David Oks

This is such an awesome article that goes deep into explaining how (and why) Japanese companies are wildly different from US (and Western in general) ones. So much food for thought from looking at things like lifetime employment, horizontal coordination, diversification, and more. A must read.

🥈 The Slide

5 min • by Rands

Putting this appropriately here after I interviewed Rands at LDX3 just last week, and asked him about stories and this article in particular. When someone keeps ignoring your feedback, don’t lecture harder — slide up next to them with a personal story about the time you struggled with the same thing.

🥉 Making a New Plan

2 min • by Cate Huston

An ever-underrated leadership skill is admitting you’re wrong and making a new plan when new information is available. Also, it’s easy to judge others for not doing that, until you realize we all do it from time to time. Short and sharp, as always in Cate’s style.

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

📋 Unblocked is the context layer for modern teams

This newsletter is brought to you by our friends at Unblocked!

Agents can generate code, but getting it right for your system, team conventions, and past decisions is the hard part. MCPs give agents access to information but not understanding – so you end up wasting time and tokens in correction loops.

For this reason, the teams pulling ahead use a context layer to give agents exactly what they need.

Unblocked is the context layer that turns code, docs, tickets, and conversations into actionable context, so engineers move faster and agents stay on track 👇

Learn more about Unblocked

1) 📈 Measure AI effectiveness by leverage

There are a lot of *bad* ways to measure how well your team uses AI, including counting lines of code, tokens spent, and more!

To me, we should measure effectiveness, which is a function of leverage: how much useful output you get per unit of human input.

This is different from measuring AI usage. E.g. a team can maximize AI-generated code by writing incredibly detailed specs that are basically pseudo-code. The AI may write the final syntax, but the human still did most of the hard work.

That is not real leverage!

So a better question is: how much context does a human need to provide before the AI can do the job well? Some of the prompt will always be task-specific. If you ask for a new button, the AI needs to know where the button goes and what it should do. But a lot of the prompt should not have to be repeated every time: design rules, product conventions, architecture patterns, testing style, existing components, release constraints.

So you can think at a scale that goes like this:

1. 🏜️ Negative leverage — people spend more time fighting the AI than doing the work themselves.

2. 🌱 Low leverage — the AI writes code, but only after humans write exhaustive instructions.

3. 🪴 High leverage — the AI can reuse enough context from the system that prompts become short and results stay good.

4. 🌳 Maximum leverage — the AI one-shots meaningful work from tiny prompts because the factory already knows how good work should be done.

I wrote more about this in the recent article series about the new software factory 👇

Refactoring

How to Grow your Software Factory

Last month I published The Era of the Software Factory, where I commented on the latest State of Software Delivery together with Rob Zuber, a good friend and CTO of CircleCI…

Read more

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

2) ⬆️ Bottom line up front

One of the most popular articles we published on Refactoring last year is from Anna Shipman, CTO at Kooth and one of my favorite authors.

She described the translation layer that is needed to make engineering understood by executives, and the article is packed with great examples and mental models.

One of the pieces of advice that stuck with me is to always lead your communication (spoken or written) with an executive summary that includes the most important information: what action you are looking for.

Or, as Anna calls it: bottom line up front.

An exec summary tells the reader in a few short sentences what this document is going to cover. If this is a presentation rather than a document, include an executive summary slide. If this is a conversation, set it up right by explaining first what the purpose of the conversation is. If you are asking for a decision, make sure you’ve included what the decision is.

Here are some example exec summaries.

For a document:

This proposal recommends consolidating our infrastructure onto a single cloud provider to reduce operating costs by 20% over three years, improve reliability, and accelerate feature delivery. The alternative is to retain our split between AWS and Azure. The work will reduce capacity of the platform team by 50% for six months, delaying completion of the work on pipelines until Q4 2026.

We request an additional budget of £50k for the engineering team to have access to an AI coding assistance tool. We have demonstrated in our trial that use of Cursor increases throughput of work by 25% meaning over a year we would deliver extra features equivalent to the salary of four additional engineers, therefore this would pay for itself by end Q1 next year.

In a conversation you might say:

“I want to propose we start upgrading our data handling now rather than in Q3 as planned because our latest planning session raised a flag that we may not hit the deadline. We’d have to pause the work on the new dashboards to do that.”

“There’s a strong business case for investing more in developer experience in next year’s budget. I can show you the ROI calculation we’ve done, but I would like your take before we move forward with the budget preparation.”

You can find the full article by Anna here:

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

8 months ago · 29 likes · Luca Rossi and Anna Shipman

3) 📣 What makes for a great talk

By the time you read this newsletter I’ll probably be in London to attend LDX3. This year I will interview the one and only Rands on stage, for a live episode of the Refactoring podcast.

So, while preparing for this, I thought about my interview with Meri Williams last year. Meri is the long-time host of LeadDev conferences, and every year they have to run through hundreds of talk submissions to select only a handful of truly great ones.

I asked them what makes for an amazing talk, and they said it’s three things:

1. 📖 Personal story — or a case study. Anyway, a real experience that grounds the content.

2. 🧠 Framework — the author abstracted their experience into a theory that can be applied broadly.

3. ⚡ Practical application — the story + framework combination has clear takeaways that the audience can implement.

You can find the full interview with Meri 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

🔀 Open-source workflow orchestration

This newsletter is brought to you by our friends at Kestra!

Last week I published this primer about workflow orchestration, together with the team at Kestra, which builds a great open source platform to scale AI agents into more deterministic and observable workflows.

I have been playing with it to replace some of my OpenClaw chaos cron jobs, and I am pretty happy with the result so far! Will probably write more about it in the future.

You can learn more about Kestra below 👇

Learn more about Kestra

💡 ADRs are the reviewable artifacts of AI coding

Last month I wrote that the most recent and most valuable addition to my AI coding workflow have been ADRs.

Since then, I realized they are especially valuable because they help turn design judgment into reviewable artifacts. What does it mean?!

I don’t want to inspect every line of code an agent writes, but I can definitely review a short decision record that explains the chosen approach, alternatives, consequences, and what would trigger reconsideration. This gives me a way better control point than reviewing code details in isolation.

ADRs also improve future agent work. Before making a structural choice, the agent can read past decisions, reuse the system’s current principles, and avoid debates that were already settled.

I especially like that ADRs are immutable. When a decision changes, the agent creates a new record that supersedes the old one, instead of rewriting history.

As of today, Tolaria has 120+ ADRs. Are they perfect? Not at all — but they don’t have to be. They are good enough to 1) make me understand key design choices, and 2) steer agent behavior to make it compliant with what exists.

You can find the full article below:

Refactoring

Updates to my AI Coding Workflow

About a month ago I wrote an article about my AI coding workflow, and it instantly became the most popular Refactoring article of all time…

Read more

3 months ago · 55 likes · 6 comments · Luca Rossi

🎙️ Use AI by default to learn its failure modes

Speaking of AI coding, last month I interviewed Stuart Caborn, Distinguished Engineer at loveholidays, and one of the few tech leaders I know that is really doing it at scale, documenting the process.

One of the things he told me is that teams do not learn how AI works by waiting for perfect use cases.

They learn by using it by default, even in moments where typing the code directly would be faster. This sounds inefficient locally, but the point is building the feedback loop, rather than optimizing the single task.

Stuart explains that every failed AI attempt teaches the team something: which instructions are missing, which docs are unclear, which conventions are invisible, where the agent needs guardrails, and so on.

Stuart cares about making failures public, instead of private, and for this, he creates pressure for the failures to surface. The team runs showcases, shares patterns, and even forces engineers to go through AI before asking for human support 👇

“At one of the platform showcases, the core engineering team said: we’re not going to support you if you have a problem with your Terraform, if you haven’t asked Claude to do it first. That was bold — but the reasoning was: we need the feedback now.”

You can find the full interview here:

📚 Weekly Readings

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

🥇 Sensors for Coding Agents

15 min • by Birgitta Böckeler

Great primer on using sensors — like ESLint rules and static analysis — as feedback loops for coding agents. The idea is that agents need guardrails to maintain code quality, and these automated checks act as their “senses” on the path to production.

🥈 Apple Silicon Costs more than OpenRouter

5 min • by William Angel

Yet another reminder that, for 99% of us, running LLMs locally makes absolutely zero sense. This time backed by numbers.

🥉 Not So Locked In

2 min • by Simon Willison

Programming languages used to be lock-in — they’re increasingly not. LLMs are making it feasible to port entire codebases across languages and frameworks, which changes how you think about tech choices, risks you can take, and more.

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

Every week I also write an article about how to ship good software fast, and interview a world-class tech leader on the podcast.

I also build and maintain Tolaria in the open, publishing my workflows and learnings here.

📋 Unblocked is the context layer for modern teams

This newsletter is brought to you by Unblocked!

Agents can generate code, but getting it right for your system, team conventions, and past decisions is the hard part. MCPs give agents access to information but not understanding – so you end up wasting time and tokens in correction loops.

For this reason, the teams pulling ahead use a context layer to give agents exactly what they need.

Unblocked is the context layer that turns code, docs, tickets, and conversations into actionable context, so engineers move faster and agents stay on track 👇

Book a demo today

🔍 Rate your team on the pyramid of engineering

A couple of months ago I argued there is a new pyramid in software engineering, made up of the areas you should take care of to get your team to their best potential.

These areas are Developer Experience, AI, and Product Engineering, and need to be nurtured exactly in this order.

To understand how you are doing about each of these, here is a short self-assessment you can run on yourself. Rate how much you agree, from 1 to 5:

1) Developer Experience

• 1.1 — It is easy to do work as a developer on my team

• 1.2 — Engineers on my team get enough focus time

• 1.3 — My team ships fast and often

• 1.4 — I have a good strategy to improve the developer experience of my team

2) Artificial Intelligence

• 2.1 — Engineers on my team make good use of AI

• 2.2 — We have a shared understanding of how to use AI as a team

• 2.3 — I have a good strategy to improve the impact of AI on my team

3) Product Engineering

• 3.1 — I am happy with the level of autonomy the engineers on my team work with

• 3.2 — Engineers on my team know what our customers’ problems are

• 3.3 — Engineers on my team know if a feature is successful or not

• 3.4 — I have a good strategy to make the engineers on my team more autonomous over time

You can find the full article below:

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

4 months ago · 50 likes · Luca Rossi

🎙️ The business impact of code quality

One of the interviews I keep coming back to is the one I did last year with Adam Tornhill.

Adam is the founder of CodeScene and one of the sharpest thinkers on software quality: he combines behavioral data analysis with code metrics to identify the parts of a codebase that actually hurt you.

The conversation centered on a question most engineering leaders struggle with: how do you make the business case for refactoring?

Adam’s team tackled it head-on with the Code Red study — a large-scale analysis of the correlation between code health and real development performance.

Their findings confirmed what many engineers know by heart:

• ⚡ Development Speed — healthy code enables teams to develop features more than 2x as fast as unhealthy code.

• 📉 Predictability — unhealthy code creates massive variance in task completion times, making estimation extremely hard.

• 💸 Hidden Costs — some tasks in unhealthy code can take up to 10 times longer than expected.

“Doing a task in unhealthy code can actually take up to an order of magnitude longer — 9 times, 10 times longer. And that translates into a bunch of undesirable side effects for the business.”

One finding that stuck with me is also that who makes the change matters enormously. Developers unfamiliar with the codebase take twice as long to work in unhealthy code. This is a hidden onboarding cost that nobody ever budgets for, but that compounds every time a team grows or rotates.

Here is the full interview with Adam 👇

You can also find it on Spotify and Substack

📚 Weekly Readings

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

🥇 Software Engineering May No Longer Be a Lifetime Career

6 min • by Sean Goedecke

Using AI to code means you don’t learn as much about coding itself, but refusing to use it puts you at a disadvantage today. So, is software engineering becoming more like professional sports? That is, a career with a finite window rather than a lifetime of compounding skill accumulation.

🥈 GitLab Act 2

19 min • by Bill Staples

GitLab’s CEO lays out their vision and plan for a major restructuring of the company around agentic AI and the future of software delivery. Interesting both as a product vision and as a case study in leading a public company through a platform shift.

🥉 Thin Harness, Fat Skills

6 min • by Garry Tan

By now we know that AI agents become far more productive by using purpose-built skills. It’s still unclear how all of this scales, but Garry’s mental model about growing skills instead of the general harness is solid, and I agree with him.

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

Become an investor in AI infra startups! ✨

Today’s sponsor is Alumni Ventures!

If you ever thought about doing some angel investing in AI products you like, you can do so via our friends at Alumni Ventures, that give you access to high-growth startup opportunities, co-invested alongside top VC firms like Andreessen Horowitz (a16z), Bessemer, & YCombinator.

You can signup for free and get:

• A curated deal flow of high-potential AI infrastructure startups

• Deals in which AV is already investing alongside elite lead venture firms

• No cost to see deals, and no obligation to invest

Join Alumni Ventures AI Infrastructure Syndicate Today →

💡 Never start from a blank page

A lot of people ask me how I take notes and write articles — even more so recently, since I shipped Tolaria.

I have often talked about this in the newsletter. I am quite opinionated about it, and a lot of these opinions made it into Tolaria.

One of these is about the (in)famous blank page.

There is this romantic view of writers sitting in front of a blank page and crafting their work through sheer inspiration. In reality, if you’re starting from nil, you’re doing it wrong.

About this, I love a famous quote from an Italian singer-songwriter, who once was asked how long it takes to write a song. He said:

“It takes me about 10 minutes — but only if I spend the rest of my life making sure that eventually it takes me 10 minutes.”

This applies to all knowledge work. Good writing is about connecting and refining ideas you already captured, rather than creating from scratch. The prep work is the work.

To make prep work easier, I am a big believer in dividing it into multiple steps:

• Capture — store the thought on a durable support.

• Organize — refine it, place it where you’ll need it, and connect it to other thoughts.

• Express — use it to do something larger.

These are different tasks, and are best done at different times. Conflating them leads to predictable failure modes:

• Capture + Organize leads to exhaustion (every note becomes a chore).

• Organize + Express leads to chaos (missed insights, no scalability).

• All three at once leads to writer’s block.

Luhmann’s Zettelkasten and Tiago Forte’s CODE system are both built around this separation. You don’t need to follow either to the letter, but the principle matters.

I wrote a full piece about note taking a while back 👇

Refactoring

How To Take Notes 🌱

Hey there! Last week we had our book club review of How to Take Smart Notes, by Sönke Ahrens…

Read more

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

🎙️ Principles for better decisions

One of the interviews I go back to the most often is the one I did last year with Annie Duke.

Annie is a former world-class poker player, author of Thinking in Bets, and one of the clearest thinkers on decision-making.

The conversation was packed with useful frameworks, and one that stuck with me was her four-principle checklist for high-quality decisions:

• Speed assessment — before anything else, decide how much time this decision deserves. Ask: how long-term is the impact, and how reversible is it? Spend time and effort accordingly.

• Make the implicit explicit — we often decide by “feel.” Annie’s view, instead, is to articulate what that gut feeling actually is. What are the real criteria? Making reasoning explicit helps you catch flawed logic before you commit, and makes it harder to rationalize a bad choice after the fact.

• Quantify qualitative opinions — instead of calling a market “great,” rate it. Even in a shallow way, e.g. on a scale from 1 to 10. This forces precision and, in teams, surfaces hidden disagreements otherwise masked by vague language.

• Collect opinions independently — never gather important input in a group setting. Anchoring bias and groupthink are real. Collect individual perspectives first, then compare differences without forcing consensus.

Here is the full interview with Annie:

📚 Weekly Readings

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

🥇 Sometimes Your Job Is to Get in the Way

5 min • by Rands

Good leaders know when to stay out of the way — but great leaders also know when to step in and draw a hard line. Fantastic story by Rands, about how a major Slack outage led to a complete transformation of their development process, driven by strong leadership.

🥈 Why Can’t They Just…

5 min • by Lara Hogan

“Why can’t they just…” is a phrase we all use when frustrated with other teams or roles. Instead of dismissing it, Lara explains how to use it as a signal to dig into the complexities behind decisions you don’t understand, and turn frustration into collaborative problem-solving. Loved it.

🥉 Contributor Poker and AI

6 min • by Loris Cro

Open source maintainers don’t bet on PRs, they bet on contributors. This is a great take by Zig and the best articulated thesis I have heard about banning AI-generated contributions. Worth a read.

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

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

5 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

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

Stop babysitting your agents 🍼

Today’s sponsor is Unblocked!

Agents can generate code. But getting it right for your system, conventions, and past decisions is the hard part — you end up wasting time and tokens in correction loops.

More MCPs give agents access to information but not understanding. The teams pulling ahead use a context engine to give agents exactly what they need.

Join our friends at Unblocked on April 23 (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

Register now!

💡 Developer Experience is your floor

By now we all largely agree that AI amplifies your existing dev practices — good and bad. I think what most people don’t realize is just how strong the amplification is.

Last month I commented on the recent State of Software Delivery report. With respect to one year ago, the median team sees:

• 📈 +15% activity on feature branches

• 📉 -7% activity on the main branch

• 📉 -15% success rate on the main branch

These numbers are brutal: the average team sees exactly zero impact from AI. Even negative in some cases, as displayed by activity on the main branch.

On the other end, if you look at the top quartiles, the reality is different. Top 5% teams are ~2x as fast, with the same success rate. Top 10% teams are +50% faster, and top 25% are +25% faster.

These are big numbers, and they come from the teams who were already at the top 3 years ago. So, paraphrasing the famous quote, the best time to invest in good devex was years ago, but the second best time is now.

Good devex is the floor that enables a team to profit from AI. I like the idea that good devex is enabled by three factors:

• 🧠 Balanced cognitive load — work is challenging but achievable.

• 🔄 Tight feedback loops — engineers are continuously informed that are going in the right direction.

• ⏱️ Enough focus time — engineers have enough uninterrupted time to do what they need to do.

When these three things happen, engineers can enter a flow state: complete immersion in their activity with extreme focus, productivity, and personal enjoyment.

Here are some questions you can ask yourself to assess where you at with these:

• Reduce cognitive load → What feels hard as a developer? How can I make it easier?

• Tighten feedback loops → What feels slow? How can I make it faster?

• Improve focus time → What feels wasteful? How can I reduce interruptions?

I wrote a full piece about DevEx, AI, and Product Engineering, and how these are 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

4 months ago · 49 likes · Luca Rossi

🎙️ Why did the day need saving?

Last year I interviewed Rands—one of my heroes—and we talked a lot about AI, engineering management, and things we are getting wrong in tech.

Rands believes, as an industry, we are too attached to hero culture that celebrates heroics and save-the-day moments.

“Good job saving the day. Why did the day need saving? We screwed up and you had to save the day so good job cleaning up your screw up.”

Rands believes in proactive prevention rather than reactive heroics: addressing issues when they are still yellow flags, instead of big red ones. Effective management goes unnoticed because teams function smoothly — but that should be a badge of honor.

Acts of prevention sometimes are hard because they go against your instincts, like giving early corrective feedback before problems escalate. It feels easy and innocuous to avoid these small-scale conflicts, but these are exactly what you need to prevent the big fuck-ups.

Here is the full interview with Rands:

You can also find it on 🎧 Spotify and 📬 Substack

📚 Weekly Readings

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

🥇 Who Will Be the Senior Engineers of 2035?

11 min • by James Stanier

Great article by James, who put together a lot of resources and ideas (also from different industries), and connected the dots to understand what may happen to the software engineering job market. Recommended read.

🥈 Open Source Isn’t Dead

3 min • by Alex Schapiro

Cal.com recently announced it’s going closed source, citing AI vulnerability scanning as the #1 reason. This piece pushes back, and I actually agree with it: closing source code doesn’t remove the attack surface — AI can still attack you black-box, at runtime. The better response is continuous AI defense (fire with fire!).

🥉 Agents as Scaffolding for Recurring Tasks

4 min • by Will Larson

Great practical pattern for introducing agents into your workflows: start by prototyping with agent-driven automation, then refactor some agentic parts away into deterministic code, keeping the agent only where it truly shines: navigating ambiguity.

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

How Augment Code is going AI-native

Today’s sponsor is Augment Code!

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

• How we hire AI-native engineers now

• Confidence is the new bottleneck

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

Check out the 5-min survey

💡 Just ask engineers

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

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

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

• How to get started with engineering metrics

• What’s next in measuring dev productivity

• You have metrics, now what?

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

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

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

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

Refactoring

The Listening Tour 📞

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

Read more

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

🎙️ Past behavior predicts future results

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

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

Austin breaks down what interviewers look for into signal areas:

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

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

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

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

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

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

In fact, companies exist on a wide spectrum:

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

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

• Google has traditionally leaned more technical.

Here is the full interview with Austen:

You can also find it on 🎧 Spotify and 📬 Substack

📚 Weekly Readings

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

🥇 The Git Commands I Run Before Reading Any Code

3 min • by Ally Piechowski

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

🥈 Feedback Flywheel

10 min • by Rahul Garg

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

🥉 The Human Weight of It

7 min • by Cate Huston

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

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

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

Make your team ship faster!

See you next week!
Luca

Make your team ship faster!

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

Build with Intent 🔭

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

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

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

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

Learn more about Intent

1) 🎯 In your AI context, share the why

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

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

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

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

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

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

• How much of this is written down?

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

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

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

Refactoring

How to Manage Context in AI Coding 📑

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

Read more

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

2) 🎙️ Functional vs cross-functional teams

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

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

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

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

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

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

Here is the full interview with Gonçalo:

You can also find it on 🎧 Spotify and 📬 Substack

📚 Weekly Readings

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

🥇 Every Layer of Review Makes You 10x Slower

11 min • by Avery Pennarun

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

🥈 The Middle Loop

7 min • by Annie Vella

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

🥉 Don’t Let AI Write For You

2 min • by Alex Woods

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

4) AI “Aha” Team Meetings

7 min • by Lara Hogan

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

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

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

Make your team ship faster!

See you next week!
Luca

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

Secure your mobile app and the APIs it interacts with

Brought to you by this week’s sponsor — Guardsquare!

What if your APIs are trusting the wrong mobile apps? Cloned apps. Repackaged builds. Instrumented devices. Automated fraud. Most attackers don’t break in—they just log in.

On March 31 we’ll unpack what mobile attackers are actually doing and why securing only the app or API is no longer enough 👇

Register now

1) 🧵 Tech Leadership Archetypes

In February we published a great guide by the one and only Pat Kua about the various CTO Archetypes. Last year we also published a similar one about Engineering Managers.

I like archetype articles, because I believe they are useful for many things:

1) Clarify expectations

Two people with the same title can have radically different responsibilities. Naming the archetype you’re operating in helps make explicit where you’re spending time and what you’re optimizing for.

2) Sense how the role evolves over time

Archetypes are not a personality quiz, also because people, orgs, and roles change over time. They are most useful as point-in-time references. E.g. as a company grows from startup to international brand, the CTO role might shift from Startup to Scale-Up to M&A. The same applies individually: a Group CTO might leave to found a company, becoming a Founder CTO.

3) Identify signals when hiring

Strong candidates use interviews to both sense and shape the role. Archetypes help you understand a company’s situation and spot mismatches early. If the role doesn’t align with your strengths, the model gives you language to say: “This is a valid role, but not the one I’m best suited for.”

4) Plan intentional career growth

Many tech leaders excel at one company but struggle at another. Archetypes explain why: they help you reflect on where your strengths play best and what you’d need to develop to grow into other archetypes.

You can find the full guides below 👇

2) 🎙️ The Perfect Team

At the end of last year I interviewed Rob Zuber, CTO of CircleCI.

At some point I asked him what his ideal product team looked like — I mean the atomic unit of <10 people building a product together.

His answer focused on a single quality: speed of learning. The fundamental question the team needs to ask all the time is: what’s the fastest way to get the information needed to make the next decision?

Granted, simply asking the question is not enough, because there exist plenty of *bad answers.*To get good answers, Rob believes the team needs three factors:

• 🎯 Clear business understanding — every engineer needs to understand what the business is trying to achieve and why

• ⚡ Rapid experimentation mindset — willingness to test hypotheses quickly rather than debate endlessly

• 🤝 High trust environment — team members can admit when they’re stuck and ask for help without fear. Build the trust needed for anyone to be able to raise their hand and say “I have no idea how to do this”.

Here is the full interview with Rob:

You can also find it on 🎧 Spotify and 📬 Substack

3) 📚 Weekly readings

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

🥇 Architecture Decision Record

8 min • by Martin Fowler

Maintaining ADRs is a great practice, which only got more useful with AI. Martin’s piece is a great primer for them, also linking to useful tools.

🥈 The 2028 Global Intelligence Crisis

25 min • by Citrini Research

I finally caught up with this viral imaginary report from 2028, that was published last month. Very useful to read to reflect on the second and third order effects of AI. It was a good test for my own beliefs: which predictions do I find reasonable? Which dubious?

🥉 Nobody Gets Promoted for Simplicity

8 min • by Matheus Lima

Tale as old as time — we most often reward complexity as a display of brilliance, and ignore simplicity. Engineers who over-build get a compelling narrative, while the ones who ship the simplest (and thus the best!) thing get… nothing.

4) Better, Faster, and Even More

10 min • by Rands

I am really enjoying Rands’ blog lately. It has become a blend of classic Rands’ management advice and occasional tales from his own AI experiments. This is one of the latter. I also love how practical he explains these — there are code snippets!

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

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 (in the style of what I have been doing with Hybrid Hacker).

This should turn this Monday email into a weekly brief that gives you some food for thought and also keeps you posted about relevant stuff that is published outside of Refactoring.

I will include a poll at the end where you can rate this edition so I know what you think about it!

Brought to you by Unblocked! 🔳

It’s not a secret that I am a big fan of what the guys at Unblocked are building — to me they are the authority about giving good context to AI agents.

I interviewed their founder last year and we also wrote a full guide together, which is one of our most popular articles ever.

Unblocked gives coding agents the organizational knowledge to generate mergeable code without the back and forth. It pulls context from across your engineering stack, resolves conflicts, and cuts the rework cycle by delivering only what agents need for the task at hand.

See how Unblocked works

1) 🧵 The rise of slave software

There are a lot of situations in which comparing LLMs to people makes for a good analogy. One way LLMs differ from humans, though, is that they’re perfectly fine doing boring, repetitive work. All day, every day.

This changes the scope of human work, but I believe also the scope of software itself.

There is an awful lot of automations and internal tools that are patched together with Zapier, n8n, custom code here and there, that I suspect just aren’t worth building anymore when you can tell an agent “every hour, go here, copy this, and paste it there”.

Granted, deterministic software would be more efficient for some of these tasks, but the cost of building it is dramatically higher than a one-line instruction in a chat. Even in the age of AI-generated software, nothing beats just telling a slave to do the thing.

Also, LLMs can handle ambiguity in a way that regular software can’t (even if written by AI). For a lot of tasks, they can just wing it, and things more or less work.

Example: I wanted to export my ~10,000-note Notion workspace to markdown files for years, but the complexity always stopped me. Earlier this month OpenClaw did it perfectly, writing scripts for API calls but also improvising the tricky parts, figuring things out on the go. Just like I would have done manually, except that would have taken me weeks.

So I believe there’s a growing class of problems for which we won’t write software anymore. We’ll just throw an AI slave at them.

I wrote more about my experience with OpenClaw and personal agents in this recent piece:

2) 🎙️ Be skeptical of polarities

Two weeks ago I interviewed Richard Hughes-Jones, a professional tech coach with 20+ years of experience.

One of the ideas that stuck the most with me is what he called polarity work: helping leaders see that what feels like an either/or choice is actually a both/and situation. A few classic examples:

• Empowerment vs directness — leaders may think they can either empower their teams or have strong opinions about what to do. In most situations, you can find ways to do both at once.

• Team’s needs vs business’ needs — seeing these two as being at odds is usually a limiting belief that prevents you from finding true good solutions.

You can find the full interview below 👇 and on Youtube and Spotify

3) 📚 Weekly readings

Here are the top three articles I have read:

Finding Comfort in the Uncertainty 🥇

8 min • by Annie Vella

Annie attended the future of software development retreat, hosted by Martin Fowler and Thoughtworks, and reported back on her thoughts, which I really enjoyed. I love the eight themes she extracted and how she framed them.

GNU and the AI Reimplementations 🥈

9 min • by antirez

Antirez implicitly comments on recent controversies about AI reimplementations (1, 2) by looking at examples from the past. I loved the historical perspective and also the new mental model he proposes: what matters now is design, novelty, and craft, not just the code itself.

Prioritize Relatively 🥉

2 min • by Boz

Super short post in Boz’s signature style, about how you should not prioritize things in isolation — but only prioritize them against each other.

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

🗳️ Fill out a quick research survey and win $100

This is sponsored by… a startup in stealth mode! 😅

Share your experiences about the alignment of Product and Engineering organizations in the quick survey below. 10 randomly selected participants will get a $100 Amazon gift card!

Fill out a 3-min survey

1) ✂️ Layoffs predictions are (probably) overblown

The recent brutal layoffs at Block have made headlines and reignited the conversation about the job market for engineers, AI, and so on.

The problem with headlines is selection bias: layoffs always make the news, but are they representative of the state of the market?

It doesn’t seem so.

On Indeed, for example, job postings for software engineers have steadily increased since mid last year 👇

And in our industry report from Q4 last year, we reported how Directors, VPs, and CTOs are skeptical about AI reducing our need for engineers. They actually think we’ll need more 👇

Here are a couple of revealing quotes from the survey:

As cost of delivery goes down, more use cases have positive ROI so demand goes up
— Director of Engineering

We will continue to grow headcount. AI will simply increase the productivity and output of that headcount
— Director of Engineering

You can find the full survey here:

Refactoring

The State of AI Adoption in Engineering Teams 📊

Hey! I am incredibly excited to finally release our industry report on how engineering teams are using AI…

Read more

9 months ago · 50 likes · 4 comments · Luca Rossi

2) 🔨 In the best teams, normal people do great work

When people talk about world-class engineering orgs, they often have in mind teams that are top-heavy with staff and principal engineers, or recruiting heavily from the ranks of ex-FAANG employees or top universities.

But I would argue that a truly great engineering org is one where you don’t have to be one of the “best” or most pedigreed engineers in the world to get shit done and have a lot of impact on the business.

It’s actually the other way around.

A truly great engineering org is one where perfectly normal, workaday software engineers, with decent skills and an ordinary amount of expertise, can consistently move fast, ship code, respond to users, understand the systems they’ve built, and move the business forward a little bit more, day by day, week by week.

Anyone can build an org where the most experienced, brilliant engineers in the world can build product and make progress. That’s not hard. And putting all the spotlight on individual ability has a way of letting your leaders off the hook for doing their jobs.

Instead, it is a huge competitive advantage if you can build sociotechnical systems where less experienced engineers can convert their effort and energy into product and business momentum.

We talked more about normal engineers and 10x teams in this amazing article written by Charity Majors 👇

Refactoring

In Praise of "Normal" Engineers 🛠️

Hey, Luca here! This is a new article from our brand new guest author program, where some of the best engineering writers in the world contribute to Refactoring with original pieces…

Read more

a year ago · 99 likes · 5 comments · Luca Rossi and Charity Majors

3) 🎙️ Your second brain with Claude Code

In January I interviewed Thiago Ghisi, who is first and foremost a good friend of mine, former Director of Engineering at Nubank, and now on a sabbatical!

During his time off Thiago got into an ambitious personal project, using Claude Code to analyze decades of personal data. He created what he calls a “second brain on steroids” by converting notes, emails, and data dumps from various services into a searchable repository of his entire digital life.

The project began with migrating 15+ years of Evernote notes to Obsidian, then expanded to include:

• 📧 Gmail data — 20 years of emails, parsed to extract meaningful communications and create daily activity digests

• 📱 Social media dumps — Twitter, LinkedIn data converted to searchable formats

• 📚 Kindle highlights — extensive parsing of Amazon data including Whispersync information

• 🎙️ Content creation — transcripts of podcast appearances and articles written

“I ended up with Claude Code, just reading those data dumps and extracting things in Markdown. For example, I got my Gmail dump... And I got Claude Code to parse all the emails that I ever sent.”

He shared the full story in the interview 👇

You can also find it on 🎧 Spotify and 📬 Substack

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

🗳️ Fill out a quick research survey and win $100

This is sponsored by… a startup in stealth mode! 😅

Share your experiences about the alignment of Product and Engineering organizations in the quick survey below. 10 randomly selected participants will get a $100 Amazon gift card!

Fill out a 3-min survey

1) 🎽 The Big Three Behavioral Questions

A couple of weeks ago I published my interview with Austen McDonald, former hiring committee chair at Meta, about behavioral interviews.

Previously we also published a guide together, where we explored 1) why behaviorals today matter more than ever, and 2) how you should prepare for them.

For the latter, there are three questions I’m very confident you will hear in some variation in any behavioral interview, so it’s worth preparing for them explicitly:

1.1) Tell me about yourself 🙋‍♂️

This is so ubiquitous it has its own acronym — TMAY (pronounced tee-may).

Your goal is to break the ice, leave a great first impression, set up context for the rest of the interview, and steer the conversation toward topics that showcase the best of your career. Here’s a structure that works:

1. Personal Summary — Start with a couple of sentences introducing yourself: your role, years of experience, and what you specialize in.

2. Accomplishments — Highlight 2–3 key achievements, ideally recent ones, that show strong business value and technical difficulty.

3. Forward-Looking Statement — End with a sentence connecting your past to the role you’re pursuing. Wrap it up and hand the conversation back to the interviewer.

This should take 1–2 minutes max.

1.2) Tell me about your favorite / most impactful project 🔨

This often comes right after TMAY, giving you the opportunity to double down on your impact. When picking what to talk about, choose the project with the most impact, scope, and personal contribution by you — regardless of how the question is phrased.

If you’re talking about a project of meaningful size, structure your response by grouping your actions around themes, then signposting those themes clearly as you speak. This makes a complex story easy to follow.

1.3) Tell me about a conflict you resolved ⚔️

For this, pick a story where the stakes were high and you were highly involved. The interviewer wants to hear about the behaviors you demonstrated — how you navigated the situation, not just what happened. And it goes without saying, unless you are really confident in your storytelling, pick a story where you ended up being right.

You can find the full guide below 👇

Refactoring

How to Master Behavioral Interviews 📞

Hey, Luca here! This is a new article from our guest author program, where some of the best engineering writers in the world contribute to Refactoring with original pieces…

Read more

a year ago · 36 likes · 1 comment · Luca Rossi and Austen McDonald

2) 🔨 AI should improve your code quality

Code quality is the #1 concern engineers have about AI. In fact, the dominant narrative is: AI will make you ship more code in less time, but you’ll have less control over it, and it’ll be riddled with bugs.

This can be true — but it’s not inevitable, and I don’t think it’s the best way to use AI.

What’s often overlooked is that AI is excellent at reasoning about existing code, which is at the core of reviewing and improving code. AI is fantastic at picking up code smells, security vulnerabilities, missing tests, and even team-specific issues like adherence to your own best practices and conventions.

What’s also interesting is that AI is shifting code quality further left. Many static analysis checks that previously lived in CI/CD are now real-time suggestions in the IDE. Some have even become MCP servers that can steer AI-generated code before you even save the file.

So, some of the best code quality tools, like CodeScene, Codacy, or Packmind, allow you to enforce code quality on standards possibly higher than how you would ever be able to on a 100% human team.

I also talked about this in relation to my own experiments, for which I am able to keep ~9.5/10 code quality, via CodeScene.

So, if you ask me, the future of code quality is bright — but only if you’re intentional about using AI for that purpose, rather than treating it purely as a code generator.

This is just one of the ways in which what’s good for humans is good for AI, which I explored in this article late last year 👇

Refactoring

What's good for humans is good for AI ❤️

It’s been a couple of months now that a lot of my attention has been focused on a single topic: how good engineering teams are using AI…

Read more

9 months ago · 29 likes · Luca Rossi

3) 🎙️ Standardization vs. flexibility

One of Rob Zuber’s biggest regrets as CTO of CircleCI was the lack of early standardization — which became extremely expensive to fix later. When we spoke a couple of months ago on the podcast, he drew a sharp line between decisions that are cheap early and expensive later, and those that remain cheap throughout.

So, a few things that should be standardized are:

• 💻 Programming languages — avoid the “auth service written in a language no one knows” problem.

• 🔧 Core infrastructure patterns — database connections, queuing, observability.

• 📋 CI/CD processes — critical for compliance, auditability, and as the main crossroads of your dev process.

What can stay flexible:

• 🖥️ Developer environments — IDEs, terminal setups, and dev stuff that is up to individual preference.

• 📅 Some agile practices — as long as business and stakeholder needs are met!

“If you’re good at providing the things that your stakeholders need before they know they need them, you’ll have all kinds of freedom to make your own choices. If you aren’t, people will come make choices for you.” — Rob Zuber

Rob argued that excessive standardization often emerges defensively, when engineering teams fail to communicate well with their stakeholders. So the real solution most of the time is not more rules, it’s just better communication.

Here is the full interview with Rob Zuber:

You can also find it on 🎧 Spotify and 📬 Substack

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

Make your team ship faster!

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

📖 Create a shared engineering playbook

This idea is brought to you by Packmind!

Most teams adopt AI coding agents without an engineering playbook. Standards live in people’s heads, Slack threads, PR comments, or scattered docs, so AI agents are left guessing.

Packmind helps teams create and maintain a shared engineering playbook, and automatically enforce it across repositories and AI coding agents.

Try Packmind Open Source

1) 🪴 Share your culture

Speaking of handbooks, culture is not just what you write in there — it is what happens every day in your org. But you still need to communicate it effectively, especially to people who are not yet part of your company.

How do you show, rather than tell, your culture? This came up in one of our recent mastermind sessions. Here are the things I have found most useful:

1️⃣ Map your touch points

Every interaction with candidates is an opportunity to demonstrate culture. The most important ones: your public presence (website, blog, open source work), job materials (descriptions, career page), and the interview process itself (how you communicate, what you ask, how interviewers behave).

Each step tells a story, and the strongest cultures are consistent across all touch points. Shopify, for example, sends candidates a culture handbook upfront — you can only move forward by explicitly accepting their principles.

2️⃣ Show, don’t tell

Instead of listing abstract values, share real stories.

Engineering blogs are perfect for this: they reveal how your team thinks and solves problems. Public post-mortems show how you handle failure. Behind-the-scenes content shows how people actually collaborate.

3️⃣ Write from your best performers

Do not write aspirational statements. Instead, observe your best engineers: what behaviors make them successful? Document those. Instead of “we value excellence,” write: “our best engineers seek feedback early and take ownership end-to-end.” Concrete behaviors are way more useful than abstract values.

We talked about this in depth in our article on generative culture 👇

Refactoring

Generative culture 🪴

A few weeks ago we wrote about engineering handbooks. From there, I got many emails with questions about culture, which is a similar but separate topic…

Read more

2 years ago · 38 likes · 2 comments · Luca Rossi

2) 🎌 Find your allies

Improving how a team works—whether it is culture, quality, or any other kind of change—is a two-part problem:

1. You have to identify what needs to change.

2. You have to make change happen.

The second part is much harder. Change is an uphill battle against tight roadmaps and already stressed-out people. So for long-term transformations, one of the most important things you can do is find your allies and recruit them.

Your allies are the people who care the most about this change — the ones who will not give up when pressure builds, and who keep others accountable. Lasting change is always a mix of top-down and bottom-up input, and the bottom-up part needs champions, especially at the start.

This reminds me of Christine Pinto’s three-step model for improving quality in a team. Quality processes do not appear out of the blue — they follow a messy progression:

1. 🦸 Crusader — one engineer acts as a hero, spearheading change largely on their own while influencing leadership.

2. 🪴 Coach — the hero teaches others, establishing principles and getting adoption.

3. 🌳 System — when critical mass is reached, individual efforts turn into team-wide processes.

The pattern holds for culture too. It never starts with a policy: it starts with a person. We talked more about this below 👇

Refactoring

How to Help a Struggling Team 📉

Last month we had a great mastermind session about how to raise the quality bar of your team…

Read more

a year ago · 25 likes · Luca Rossi

3) 🎙️ Static analysis is not enough for code quality

In my chat on the podcast with Adam Tornhill—author of Your Code as a Crime Scene and founder of CodeScene—one idea stood out to me: static analysis alone is not enough for code quality.

Traditional static analysis tools examine code at a single point in time, but Adam argues this misses the most critical dimension: impact and relevance.

“You can have the most complicated code in the world, but if it has been stable in production for five years, there is nothing urgent on the roadmap.”
— Adam Tornhill

Adam’s alternative is to analyze version control history to understand developer behavior patterns. This reveals a consistent finding across hundreds of codebases:

• 🎯 Extreme distribution — the majority of development work concentrates in just 2-3% of the total codebase.

• 🔥 Hotspot priority — technical debt in highly-active areas becomes exponentially more expensive.

This reframes how we should think about tech debt: do not fix the most complex code — fix the most active complex code.

Here is the full interview with Adam:

You can also find it on 🎧 Spotify and 📬 Substack

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

Make your team ship faster!

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

Product Methodology Survival Guide 📚

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

Planning gets messy when different teams work in different ways. One team runs sprints, another uses Kanban – leadership still needs to know what’s shipping next quarter.

Atono just published their Product Methodology Survival Guide, sharing how they made cross-team planning predictable inside their own engineering org – without forcing everyone into the same process.

We’ve also previously collaborated on pieces like The AI Productivity Paradox and How to Build a Product Engineering Culture, so if you’ve enjoyed those, this guide goes deeper into the operational side.

Download the guide

1) 📋 Keep backlogs radically short

Speaking of Atono, this reminded me of one of the ideas we discussed in one of our articles together: backlogs — and how much we hate long ones!

Shipping fast in a sustainable way requires discipline about what you actually build. Long backlogs are one of the biggest hidden anti-patterns in product teams:

• They demoralize the team — by removing the feeling of progress.

• They are ineffective at capturing priorities — because items stay there for a long time, becoming sneakily obsolete.

• They lead you to say yes to everything — counterintuitively, it is harder to reject feature requests when the backlog is already long, because “it’s just one more thing”. So you put it there, people get pissed when you assign “P3” to it, then you don’t touch it for six months, then it’s completely obsolete, then you delete it and piss the requester a second time.

Mary Poppendieck, Agile legend with 30+ years of experience, says “burn your backlog” every time she can, and that you should rather focus on flow:

Once you’ve established your current output rate, then you have to stop accepting anything beyond that rate. No backlog. If you can only do ten a month, you only accept ten a month. And you don’t accept work beyond a month or two.

— Mary Poppendieck

The Atono team only keeps 2-4 weeks of committed work, which means PMs and engineers reject work all the time. Small feature with unclear impact? Reject. Hard to reproduce bug on niche device? Reject. This discipline is what keeps them focused and fast.

You can find the full guide below 👇

Refactoring

How to Build a Product Engineering Culture 🪴

Hey, Luca here, welcome to a weekly edition of Refactoring! To access all our articles, library, and community, subscribe to the paid version…

Read more

10 months ago · 55 likes · 4 comments · Luca Rossi

2) 🔨 Interview methods for 2026

One of the obvious consequences of AI coding getting widespread is that the methods for interviewing engineers that worked just 2-3 years ago, are not working well anymore.

Last year I surveyed the community and ran a mastermind session with engineering managers to find out how they are adapting.

With some degree of simplification, there are three main things worth testing in any engineering interview: pure coding skills, system design ability, and how well someone works with others. The weight you give each depends on the role, but there’s a clear trend: with AI, pure coding matters less, while system design and collaboration matter more.

This reshuffles the classic methods.

LeetCode questions, long despised, have fallen further, as 90%+ can be solved with AI. Take-home assignments have a similar problem: open-ended + greenfield coding is just too convenient for models, making it hard to test real depth.

For replacing them, two methods stood out in the community:

• 🔬 Case studies — you bring a real problem your team worked on and ask the candidate to design a solution live. It tests system design, trade-off reasoning, and communication simultaneously.

• 🔍 Code review — give the candidate a PR to review. It’s faster than a take-home, generates rich discussion, and tells you a lot about someone’s taste and judgment.

Career highlight stories remain consistently useful at the end of any process, letting candidates show qualities that didn’t emerge elsewhere.

You can find the full guide below 👇

Refactoring

How to Interview Engineers 📋

Hey there! This article closes our series on hiring engineers. It’s our third piece — in the first two we covered respectively…

Read more

a year ago · 45 likes · Luca Rossi

3) 🎙️ Evergreen career advice for engineering managers

A couple of years ago I interviewed Camille Fournier, author of The Manager’s Path and veteran engineering leader. She offered four main pieces of advice for engineering managers looking to stay valuable and advance their careers, which are just as relevant today:

1) Focus on relationships 🤝

Camille emphasizes the importance of good relationships at all levels:

• Reports — people have to want to work for you

• Peers — people have to want to work with you (peers and other teams)

• Superiors — your superiors have to want you to work for them

2) Maintain technical credibility 💻

For technical leadership roles, Camille suggests maintaining enough technical knowledge to ask good questions and understand the work:

“I can ask people really good questions about what they’re doing and often understand what they say to me. And so […] because I work in pretty heavily technical areas, people like that.”

3) Represent the company well 🏢

She reminded managers that they are representatives of the company:

“You are representative of the company. You can influence the company culture. But a lot of the value and the expectations of you is like, if your boss says you have to do something or something has to happen, how good are you at driving that thing to happen?”

4) Learn continuously 📚

Camille encourages managers to stay curious and open to new ideas:

“You’ve got to challenge yourself to look outside of your own world, talk to managers at other places, make friends externally that are managers and hear about what they’re doing and just stay curious.”

You can find the full interview below 👇

You can also find it on 📬 Substack and 🎧 Spotify.

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

Make your team ship faster!

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

Agent-first development for your org 🤖

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

I am a fan of Warp, which I personally use, and I have been in touch with the team for a long time. We even wrote a piece together last year.

Their latest work is Oz — the orchestration platform for cloud agents.

The problem they want to solve is that engineers are shipping code faster than ever, but without good orchestration, individual productivity hits a ceiling fast. Gains don’t compound and leadership has 1) no visibility, and 2) no way to measure impact.

They just released a full report that explores this, where you can learn:

• Why 75% of companies fail at building their own agentic systems

• How teams save hours per engineer per day by using agent automations

• What makes 60%+ of PRs agent-generated actually achievable

Download the free report

1) 🔬 Most AI teams don’t need researchers

… they may not even need AI engineers.

In October I wrote this piece with Barr Yaron, who interviewed (and invested in) tens of founders of AI products.

She reports that many of the best, fastest-moving AI companies she has seen this year have zero papers, zero PhDs, and… zero guilt about it.

If you’re building applied AI products on top of foundation models from big labs, your team might look more like a modern software org: strong in prompt engineering, some MLOps, and good product intuition.

Nearly every applied AI initiative she has seen has started small, and from someone without a strong AI background: a hackathon project, a curious engineer, or an exec tinkering with a model.

Once an early demo proves useful, a small team is born. As organizations mature, many evolve into a platform-plus-product model: an AI platform team builds shared capabilities (evals, inference, data pipelines) and helps product engineers ship responsibly.

You can find the full article below!

Refactoring

How to Build AI into Tech Products 🔨

Hey! With all the AI craze happening right now, there are two questions tech teams usually ask themselves about it: 1) should we use more AI at work? and 2) should we integrate AI into our product…

Read more

8 months ago · 25 likes · 2 comments · Luca Rossi and Barr Yaron

2) 📚 I am reading in public, and it’s working

At the end of last year I reviewed my whole content creation workflow.

By looking at the various steps, realized that those I struggled the most with (good reading & research), are exactly those for which I didn’t have a build-in-public version.

So I tried two things:

• I made my reading list public and subscribable on Mailbrew — you can find it here

• I wrote an experimental digest email on Hybrid Hacker, our sister newsletter, containing the best articles I had read the previous week.

Both experiments were a huge success.

I shared my reading list on Linkedin and on the community, and as of today it counts ~150 subscribers, plus I got a lot of warm comments privately. This is not going to be a business whatsoever, so I am simply happy about it.

The digest emails are also getting a lot of great feedback, so I have kept writing them for the past 2 months or so.

Together, these experiments gave me incredible energy and provided the missing incentives to keep the underlying habits tidy. Now I feel a strong need to:

• Keep my reading sources relevant and up to date because there are others who depend on them, and

• Read more and better because I am responsible for identifying great pieces that I can recommend to readers.

The lesson I learned from this is to try to create practical incentives for the things that I want to keep doing! Full article here 👇

Refactoring

What I am reading in 2025 (and how) 📚

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

7 months ago · 47 likes · 4 comments · Luca Rossi

3) 🎙️ Driving AI adoption as a CTO

In October I interviewed Darragh Curran, CTO at Intercom, who famously went all-in on AI by:

• Setting a public target of getting the team to be 2x as productive

• Spinning off a completely separate AI product, Fin, instead of bolting AI onto Intercom as an afterthought.

I asked him how he drives AI adoption inside the team, and he replied with a four-step framework:

1. 🎯 Set ambition and tone — make it clear this isn’t optional or experimental, but essential.

2. 🚧 Remove barriers — be deliberately permissive about tool choice (Cursor, Claude, Copilot, etc.).

3. 🤲 Make hands-on experience — personally use the tools to understand the developer experience.

4. ⏰ Protect learning time — explicitly give engineers permission to invest time in learning new workflows.

He says the biggest challenge isn’t technical but cultural, and as a manager you need to navigate this through good conversations, plus implementing the steps above.

Many engineers also cite lack of time as the primary barrier to adopting AI tools, creating a tension between delivery pressure and the learning required for long-term productivity gains 👇

“The number one reason folks have said that they haven’t really got up to speed with the tools is they just feel like they don’t have time. So we’ve tried to make very clear to people and their managers that this is important. You can take time.”

Here is the full interview with Darragh:

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