I also publish an original essay every Wednesday. Here is the one from last week in case you missed it:

🔨 Autonomous Software Dev for the Enterprise

This week’s newsletter is brought to you by our friends at Blitzy!

Blitzy is built for large, complex software projects that other coding agents cannot handle: large-scale refactors, scaled vulnerability remediation, and undocumented legacy systems.

Blitzy’s Sandbox lets engineers evaluate Bitzy on their own software estate, at their own pace. Eligible organizations can connect real applications, reverse-engineer up to 1 million lines of code, generate up to 25,000 lines of E2E tested code, and surface prioritized security vulnerabilities across their software estate.

Try Blitzy on your codebase

🌱 Grow juniors with guardrails and judgment

One of the most important qualities of junior engineers is that they can turn into senior engineers. But that does not happen automatically.

There is a dream scenario where juniors grow, become senior, and help rotate headcount when seniors leave. But there is also a nightmarish one where juniors are thrown in the trenches, abuse AI in ways they do not understand, nobody checks on them, and the product eventually goes to shit.

When the growth cycle breaks, it is usually because juniors do not have a tight enough feedback loop: 1) one that keeps the work high quality, and 2) one that helps them learn from doing it.

To me, the loop looks two-fold:

• Invest in an amazing harness — create guardrails, rules, and gates, and encode everything that can ensure quality automatically. This helps everyone: seniors, AI, and juniors who can learn from the same rules.

• Pair juniors with seniors — let young folks experiment and move fast, but keep seniors close enough to provide judgment and supply systems thinking.

There is no way around the fact that AI makes the junior path harder in some ways, because more judgment is needed earlier. But that is also why freezing junior hiring is such a fragile bet: you optimize for today’s output, at the expense of starving the pipeline that should produce tomorrow’s seniors.

I wrote more about this in the full piece 👇

📱 Most AI products are still “m.google.com”

When I spoke with Charlie Guo, developer experience engineer at OpenAI, we walked through three eras of AI-assisted development.

First came models that could autocomplete snippets, which became tools like GitHub Copilot. Then came AI-native IDEs like Cursor, where the model sat inside the editor. Now we are entering a third phase: standalone apps that orchestrate agents, and move beyond the text editor entirely.

Charlie believes most products are still stuck in the middle of that transition:

The m.google.com of AI was (or is): take this product and cram a chat box on the sidebar, and then chat with it on the side while you’re doing stuff in the app.

That’s similar to when the iPhone arrived: companies took desktop websites and mostly squeezed them into a vertical layout. It took nearly a decade to invent native mobile products: Uber, DoorDash, things that could not really exist on a desktop.

We are in that same messy middle with AI. A chat sidebar is not necessarily bad, but it’s just an easy retrofit. Native agent experiences are still being invented.

You can find the full conversation with Charlie here 👇

📚 Weekly Readings

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

🥇 What psychological costs does AI adoption create for engineers?

4 min • by Lizzie Matusov

Lizzie covers a case study from a large Danish software company, one year into an org-wide AI rollout. Regular engineers feel “accountability anxiety” and “craft identity disruption” as tools take over work, while architects (more augmented than replaced) barely show the same costs. Interesting research, worth looking into.

🥈 De-Brainrot Vacations

4 min • by Daniel V.

This piece by Daniel really resonated with me. He noticed that after years of engineering, plus AI and phone dopamine, his thinking got slower and lazier. So he used a countryside vacation to reset his brain by reading hard books and doing math and physics as a hobby. This is peak mental marathoners!

🥉 The Internet Is Kind of a Predatory Cesspit Now

8 min • by Stephen Diehl

Stephen argues that, over the years, “predation” moved from the periphery of the internet to its very core, and that a lot of ordinary people have been (often unwillingly) conscripted into it. I have less of a bleak view about this, but I see where Stephen is coming from and I don’t necessarily disagree. Worth reading!

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 also publish an original essay every Wednesday. Here is the one from last week in case you missed it:

🔒 Autonomously secure your software estate!

This week’s newsletter is brought to you by our friends at Blitzy!

Security teams don’t need another list of alerts: they need to know which vulnerabilities are reachable, exposed, and safe to fix!

Blitzy understands your entire software estate and, through Proactive Insights, surfaces known and previously undiscovered vulnerabilities in your codebase, and remediates them autonomously.

It traces each finding through execution paths, identifies dependencies, and validates remediation. Then it turns prioritized risks into batches of tested PRs for engineers to review.

The result is less alert noise, faster remediation, and confidence that each fix is safe. Find risk in context and remediate it securely at enterprise scale!

Try on your codebase today

⚔️ Match quality controls to the risk

Next week I will be in New York to attend the LDX3 conference, which made me think about the best ideas I got from last year’s edition in London.

One that particularly resonates with me, especially now that I work on Tolaria, is about quality controls.

The most common approach to software quality is to treat every change the same. Everything goes through the same QA process, regardless of what it touches or what happens if it fails. This is simple to setup, but it tends to push teams toward one of two bad extremes:

• Too much control — every release becomes slow and painful, even when the change is small and reversible.

• Too little control — the team moves fast until failures pile up and you end up spending most of your time cleaning up.

At LDX3, Christine Pinto argued that the confidence you need before shipping should be proportional to two things: customer impact and technical risk.

A tiny change with a narrow blast radius does not need the same process as one about payments or critical infra. The farther a change moves up and to the right on those two dimensions, the stronger your evidence should be before you release it.

I also liked Christine’s framing of quality as a maturity journey:

1. 🦸 Crusader — one person champions quality and convinces others that it matters.

2. 🪴 Coach — that person teaches the team and turns individual judgment into shared principles.

3. 🌳 System — those principles become processes that no longer depend on a hero.

The goal is to build the right level of confidence for the risk at hand, then make that judgment part of how the team works all the time. I wrote more about this in the full piece 👇

Refactoring

My Favorite Ideas from LDX3 🎟️

Last month I spent two days in London for the LDX3 conference…

Read more

a year ago · 27 likes · 3 comments · Luca Rossi

🎙️ Storytelling is built through reps

When I spoke with Stephanie Wong, Head of Technical Marketing at Google Cloud, she told me that people often ask how she makes explaining complex topics look so natural.

Her answer is not super glamorous: what people see is the result of 10,000+ hours of practice.

Her story is especially useful when it comes to storytelling, because for some reason that’s often treated like a personality trait. Some people supposedly have it, while engineers who struggle to explain their work assume they are simply not storytellers.

Instead, Stephanie’s method looks much more like product development:

1. Understand the audience — know what they need and give them something concrete and hands-on.

2. Iterate — move through ideation, prototyping, testing, and releasing, like you would do for a product, instead of waiting for the perfect explanation.

3. Stay consistent and authentic — always bring your own perspective, then learn from what lands and what does not.

Technical audiences are particularly wary of fluff. Credibility comes from knowing the subject, but relatability also matters, and that comes from making your personal take visible. You need both.

So, don’t wait until you feel naturally good at communication: explain one thing, notice where people get confused, rewrite it, and tell the story again. Over time, the rough edges disappear and the result starts to feel effortless.

Natural is a feeling the audience should have, but on your side, it is reps!

You can find the full conversation with Stephanie here 👇

📚 Weekly Readings

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

🥇 Breaking Claude Code Opus 5 Auto Mode

9 min • by Johann Rehberger

A reminder that even the most powerful models are still extremely vulnerable. A website asks Claude Code to summarize some content, nudges it from WebFetch to curl, and then turns the model’s own Python decoder into an exploit. Food for thought if your agents are touching untrusted content.

🥈 Selling Out

15 min • by Sean Goedecke

Sean’s title is provocative, but the thesis is very important: professionalism is a role, and playing it well doesn’t have to consume your life. Everyone chooses how much integrity to trade for wealth and career success, and that’s mostly ok, things are not black or white. A sharp essay about work and personal identity.

🥉 Small Models Have Arrived

3 min • by Calvin French-Owen

We spend so much time looking at the smartest models that it’s easy to miss how far the cheap, fast ones have progressed. Calvin argues that this is (even more than frontier models) what makes many new products viable, because not every task needs a genius: most business work just needs something responsive, cheap, and that keeps the ball moving.

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

🏦 Invest in high-potential startups

This week’s newsletter is brought to you by Alumni Ventures!

Our friends at Alumni Ventures are giving Refactoring readers early access to high-potential startup opportunities, including some of today’s most exciting AI, deep tech, quantum, and cybersecurity companies, co-invested alongside top VC firms like Andreessen Horowitz and Y Combinator.

As a Refactoring reader, you get:

• A curated deal flow of high-potential AI startups

• AV already investing alongside elite lead venture firms in these deals

• No cost to see deals

• No obligation to invest

Check out the current deals

Back to this week’s ideas!

🎲 Consider the onboarding roulette

At Graphite, every day a random employee gets their account deleted.

So the next time they open the product, they go through the full onboarding flow again: link repos, tune settings, the whole thing. Greg Foster, Graphite’s CTO, calls it the onboarding roulette: basically everyone feels onboarding roughly once a month.

They do this because onboarding is often a massive product blind spot. You test it once, maybe two years ago, and then never again, while new users keep hitting it every day.

Instead, when the team has to onboard regularly, rough edges show up fast, and get easily polished.

Greg said it got love and hate when he first introduced it, but now it’s mostly love, and the whole onboarding now only takes about three minutes.

Of course, your mileage may vary: you probably should not delete accounts if you are building a hospital system! But the principle holds: whatever your users do frequently, your team should do frequently too.

Maybe that is:

• Signing up with a fresh account once a quarter, or

• Going through your own support flow when something breaks, or

• Using your mobile app on a slow connection

The point is to design a process so the team feels the same friction users feel, regularly.

I wrote more about this in the full piece 👇

Refactoring

How Graphite Ships 🚢

It’s a weird time for engineering teams…

Read more

10 months ago · 18 likes · Luca Rossi and Greg Foster

💡 Make everyone share an AI surprise

When I spoke with Lara Hogan a couple of months ago, she introduced me to what she calls AI “Aha” meetings.

Every week, or every other week, the whole team shares something they learned about AI. A win, a failure, a surprise, or just something weird. And everybody has to share, managers included: nobody gets to skip.

In spirit, this is similar to a postmortem, just lighter and more often. People share knowledge, figure out patterns, and learn what works and doesn’t work.

Frequency matters because what someone figures out this week about an AI tool can become stale next week. If the team does not have a tight loop, people keep working from last month’s outdated instincts.

I loved this idea and we have even implemented our own version in the Refactoring Community, called the AI Club.

You can find the full conversation with Lara here 👇

📚 Weekly Readings

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

🥇 Fences, not Sandboxes

13 min • by Steve Yegge

Steve spent ten weeks running ~50 agents on Fable-class models to ship his game, and... they grew a legal system! This is a very interesting write-up, as always with everything Steve writes.

🥈 Stealing Blame

3 min • by Aviv Ben-Yosef

Do you steal blame? When a project blows up, the easy move is to explain why it wasn’t your fault. Great leaders, instead, look for their share of blame. That buys you the truth: people talk more when they know someone has their back. Great short piece by Aviv.

🥉 PostgreSQL for Everything.

7 min • by Raphael Bauer

Gentle reminder that we don’t need fancy tech for most stuff. Postgres can do an awful lot these days, and most people are not aware of 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

If you are finding this newsletter valuable, subscribe to the full version!

Make your team ship faster!

Learn more about the benefits of the paid plan here.

🏭 Does your team have a software factory?

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

Most engineering teams are using coding agents today, but many aren’t seeing the productivity gains they expected. Developers are moving faster, but work still gets stuck in planning, review, and deployment.

Our friends at Augment Code put together a new guide that looks at how teams can move past the plateau by building a software factory one loop at a time.

It includes practical examples for PR to merge, ticket to PR, and alert to resolution, plus the foundation those loops need to work at scale.

Check it out below 👇

Learn more and get the free guide

🧠 Outsource knowledge & protect reasoning

When people talk about AI being “smart”, they usually mash two skills together.

• Knowledge — is what you should know about the problem domain.

• Reasoning — is applying that knowledge to the task in front of you.

AI already knows more stuff than any person ever will, while I find that people are still better at the actual reasoning. Most work needs both, so it’s easy to get sloppy about which one you hand off.

My heuristic is: outsource the knowledge, protect the reasoning.

So I ask myself: am I using AI because I genuinely do not know something, or because I do not want to think it through myself?

I feel that looking up things I do not know is ok. I even learn some of them as a byproduct. But using AI as a thinking partner, every time, is where my “cognitive workout” disappears, and I fear that some of my brainpower atrophies.

Also this is not black or white. Some days I have more work to do than energy, and letting AI cover a piece I would have skipped anyway is a good call. I just try to keep the part that actually trains my brain.

One thing that works for me: I write the first draft myself, then ask AI to produce the same artifact from scratch, without looking at mine. That flips the usual anchoring. I keep the reasoning, and I still get AI’s wider knowledge as a second pass. AI is also pretty bad at disagreeing with you, so a blind rebuild beats “please review this.”

I wrote more about this in the full piece 👇

Refactoring

AI & Cognitive Debt 🧠

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

Read more

a year ago · 79 likes · 13 comments · Luca Rossi

🛠️ Get your hands dirty, even as a VP

In my recent conversation with Anush Elangovan, VP of AI Software at AMD, he said something that stuck with me: at this moment in history, because of how fast things are changing, you cannot stay one layer away from the work. You need to be in the trenches and understand how such work... works.

Anush has generated more code in the last four months than in the previous four years combined, and he is a VP. His target is 40% of his time hands-on, usually starting around 9:30 PM after the day job and family time are done.

Reading articles and forming opinions is fine, but you also need to get the ground truth by yourself.

So, instead of scheduling four status meetings to understand a problem, he can hook it up to Claude Code, spend three to five hours debugging, and come back with a concrete assessment plus a unit test that, if passed, would fix the issue. A few hours with the actual problem replaces a week of coordination.

If your job is to make the team faster, some of that speed has to come from you still knowing what the work feels like.

You can find the full conversation with Anush here 👇

📚 Weekly Readings

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

🥇 Ordinary Abundance

7 min • by ordinaryabundance.com

An ordinary apartment is full of things that used to be miracles: electric light, clean water, refrigeration, vaccines, anesthesia, washing machines, instant communication. Each one was once astonishing, or unavailable to almost everyone. A great reminder to be grateful for all the small things we stop noticing everyday.

🥈 Landing the plane

10 min • by James Stanier

Recently I wrote about how finishing a project seems to have become the hardest part of it. That last stretch is where scope creeps, energy drops, and human reviews bottleneck everything. In this great article, James argues that landing is a skill. You plan for it the same way you plan for the start, especially now that AI makes kicking things off so cheap.

🥉 How I use LLMs to learn complex topics

2 min • by Laurentiu Raducu

Instead of asking an LLM to explain a hard topic, Laurentiu asks it to build a little simulation of it, like a low-poly Rollercoaster Tycoon for a chip fab. I loved this! You learn by poking at a model of the thing, which I like more than asking for a summary.

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

📊 Is AI really making developers ship faster?

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

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

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

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

• PR size – nearly doubled in the same window

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

Read the report

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

🗂️ Your knowledge needs a lifecycle

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

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

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

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

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

1) Capture quickly

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

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

2) Organize deliberately

Now ask yourself two questions:

• What is this?

• What should it help me do?

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

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

3) Archive without deleting

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

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

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

Refactoring

Introducing Portent ☘️

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

Read more

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

2) 🍀 Increase your luck surface area

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

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

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

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

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

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

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

Refactoring

Lessons learned from 25 years in tech 🔭

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

Read more

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

📚 Weekly Readings

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

🥇 The People Who Will Thrive in the AI Age

15 min • by David Brooks

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

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

🥈 Middle management roles are also a trap

2 min • by Will Larson

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

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

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

6 min • by Senko Rašić

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

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

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

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

Make your team ship faster!

See you next week!
Luca

📖 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

3 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

7 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

5 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

4 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

10 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

5 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

8 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

4 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

5 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

4 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

8 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

6 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

10 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

6 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

7 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

8 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