📖 42: The AI Builder’s Stack

This newsletter is brought to you by Eltex!

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

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

Get the book

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

🏁 Starting is easier and finishing is harder

AI makes it incredibly easy to start more work.

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

But shipping is another story.

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

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

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

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

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

Refactoring

Acceleration whiplash 📉

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

Read more

2 months ago · 41 likes · Luca Rossi

🔺 Product engineering is the ceiling

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

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

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

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

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

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

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

Refactoring

The New Pyramid of Software Engineering 🏔️

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

Read more

5 months ago · 55 likes · Luca Rossi

3) 📚 Weekly Readings

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

🥇 The Conductor Developer

4 min • by Rachel Laycock

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

🥈 LLMs Reward Expertise

4 min • by Sean Goedecke

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

🥉 Don’t Be a Meat Proxy

1 min • by Niklas Gruhn

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

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

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

Make your team ship faster!

See you next week!
Luca

🔍 Can you prove your AI is working?

This newsletter is brought to you by Unblocked!

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

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

• How to track AI productivity

• How context maturity affects where teams stall

• What it takes to get real value from your agents

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

Join the free webinar

🚦 Separate bugs from feature requests

When a product grows, feedback starts arriving from everywhere.

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

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

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

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

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

• Users filing feature requests as bugs

• Bugs appearing in product boards

• Duplicates multiplying everywhere

• Engineers spending time routing work manually

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

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

Refactoring

How I Run the Tolaria Project

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

Read more

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

🎤 Prepare the three stories every behavioral interview needs

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

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

1. 🙋‍♂️ Tell me about yourself

2. 🗃️ Tell me about a project

3. ⚔️ Tell me about a conflict

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

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

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

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

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

You can find the full conversation with Austen here 👇

📚 Weekly Readings

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

🥇 The Productivity-Experience Paradox

11 min • by Annie Vella

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

🥈 You Don’t Hire Juniors to Do Menial Chores

3 min • by Frederick Vanbrabant

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

🥉 The Motivation

1 min • by Michael Lopp

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

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

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

Make your team ship faster!

See you next week!
Luca

💸 AI spend is outrunning returns

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

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

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

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

Check out the full AI impact report

🌱 Build relationships before you need them

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

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

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

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

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

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

But how?!

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

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

Refactoring

How to Grow your Network 🍻

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

Read more

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

🔧 Automate the copy-paste (not the judgment)

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

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

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

1. Information that already exists somewhere

2. Information that only exists in people’s heads

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

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

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

The second kind, instead, still needs people.

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

So, the shape of good automation looks like:

1. Connect the systems of record

2. Remove the glue work

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

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

📚 Weekly Readings

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

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

5 min • by Pawel Brodzinski

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

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

3 min • by Ben Werdmuller

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

🥉 Reverse-engineering is cheap now

1 min • by Simon Willison

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

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

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

Make your team ship faster!

See you next week!
Luca

Brought to you by our friends at Atono!

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

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

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

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

Download the guide

1) 🏗️ Agents are great scaffolding

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

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

So the agent helps you discover things like:

• which steps repeat every time

• which data is missing or messy

• where approvals are needed

• which parts require actual judgment

• and more

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

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

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

Refactoring

How to Orchestrate AI Workflows

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

Read more

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

2) 💬 Giving feedback should be ordinary

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

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

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

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

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

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

3) 📚 Weekly Readings

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

🥇 The Tower Keeps Rising

3 min • by Armin Ronacher

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

🥈 Generated and Suppressed Demand

3 min • by Will Larson

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

🥉 Control the Ideas, Not the Code

6 min • by Salvatore “Antirez” Sanfilippo

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

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

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

Make your team ship faster!

See you next week!
Luca

🪜 The 8 Levels of Context Maturity

This is brought to you by our friends at Unblocked!

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

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

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

Very recommended 👇

Join live July 23rd (FREE)

1) 🗳️ Anticipate exec questions

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

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

• How much will it cost?

• What do we get for the money?

• Why now?

• What happens if we do nothing?

• What other options did we consider?

• How will we measure success?

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

• Who owns delivery?

• Which other teams or business areas are affected?

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

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

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

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

Refactoring

The Engineer → Executive Translation Layer 🔀

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

Read more

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

2) 🎧 Quiet leadership prevents noisy emergencies

Tech culture loves the person who saves the day.

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

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

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

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

• You give feedback early, before resentment piles up.

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

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

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

You can find the full interview with Rands here 👇

3) 📚 Weekly Readings

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

🥇 Viability of Local Models for Coding

9 min • by Birgitta Böckeler

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

🥈 In Defense of AI Mandates

4 min • by Charity Majors

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

🥉 We should be more tired than the model

2 min • by Vicki Boykis

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

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

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

Make your team ship faster!

See you next week!
Luca

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

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

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

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

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

Learn more and RSVP!

1) 🧹 AI makes code hygiene enforceable

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

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

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

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

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

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

Refactoring

The Compounding Software Factory 📈

Hey there, Luca here…

Read more

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

2) 🪞 Find a broader identity for yourself

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

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

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

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

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

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

• Why do I do what I do?

• What is a broader version of my role?

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

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

Refactoring

Finding yourself in the AI era ✨

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

Read more

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

3) 📚 Weekly Readings

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

🥇 The Cost YAGNI Was Never About

4 min • by Kent Beck

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

🥈 The Wrong Abstraction

4 min • by Sandi Metz

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

🥉 AI and Liability

4 min • by Bruce Schneier

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

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

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

Make your team ship faster!

See you next week!
Luca

1) 🧭 Organize information based on action

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

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

• What is this?

• What is this useful for?

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

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

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

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

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

You can find the full article below:

Refactoring

Introducing Portent ☘️

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

Read more

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

2) 📊 Treat code health as a data product

Code quality conversations are often extremely vague.

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

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

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

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

• How is my team doing compared with yesterday?

• Are there any areas that got worse this week?

• Where should an agent be more careful?

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

You can find the full interview with Stuart here 👇

3) 📚 Weekly Readings

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

🥇 Earn Your Scepticism

10 min • by James Stanier

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

🥈 Expertise in the Age of AI

5 min • by Brian Kihoon Lee

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

🥉 Find a New Role - Worksheet

4 min • by Lara Hogan

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

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

Learn more and apply here

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

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

Make your team ship faster!

See you next week!
Luca

🎟️ 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

3 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

3 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

7 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

4 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

9 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

4 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

5 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

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

6 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

5 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

7 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

9 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