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

📊 AI sped up coding, but not reviews

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

AI tools sped up code authoring, but review and release systems haven’t kept pace.

DX’s newest AI Impact Report, based on data from 500+ engineering organizations, shows developers opening far more pull requests each week, each more than twice the size it used to be. As a result, PRs wait more than twice as long for a first review.

Download the full report to see where delivery friction is moving and where leaders should focus next to get the most out of their AI tools 👇

Download the full report

🤝 Ask hard questions before building for one customer

If you build a B2B product, sooner or later a big customer asks for something that only they need, and the request usually comes with some urgency attached: a deal to close, or a renewal at risk.

I don’t think there is a strict formula to decide whether this bespoke work is worth it, but there are good questions that help you look at the problem from more angles.

First, understand whether the work is for conversion or for retention. If it’s for conversion, can you make the customer pay for part of it, as a pilot? Or can you negotiate better terms in exchange?

Then ask yourself:

• How much is it going to cost, as a fraction of the customer’s LTV?

• How much evidence do you have that it’s really needed, and not just a random request?

• Is it valuable for other customers?

• Six months from now, will your product be better or worse because of it?

It’s also worth sitting down with the customer to figure out what they really need, because in my experience customers are most often right about the problem, and most often wrong about the solution.

I wrote a full piece about how to organize customer work and product work in B2B teams 👇

🧭 Stop trying to have all the answers

In March I talked with Richard Hughes-Jones, an executive coach who works with CTOs and founders of tech companies.

When I asked him about the most common challenges he sees in senior tech leaders right now, he didn’t give me a technical answer. AI is making everything move faster, but the underlying challenges are staying the same: ambiguity, complexity, uncertainty.

The problem Richard sees is that technical leaders are wired to have the answers, because that’s what got them promoted in the first place. But at the highest levels nobody has the answers, and pretending otherwise is counterproductive, especially now that nobody knows what the next couple of years will look like.

Richard also admits that telling someone to “get comfortable with uncertainty” is almost useless advice, because it’s abstract and doesn’t turn into action. So with his clients he works on sitting with the discomfort, and on designing small, safe-to-fail experiments: things you can try without damaging relationships or the business, that still give you real feedback.

You can find the full conversation with Richard here 👇

📚 Weekly Readings

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

🥇 Our organizations are being DDoSed from the inside

4 min • by Karri Saarinen

Karri argues that teams and agents now ship changes faster than leaders can understand them, so companies are losing the ability to steer. And just because something already works, it doesn’t mean it belongs in the product.

A honest piece from the CEO of Linear, and it pairs well with what I wrote last week about managers.

🥈 Software engineers don’t get to be Luddites about AI

5 min • by Sean Goedecke

Sean argues that engineers can’t really take the Luddites’ side, because in that story we are the mechanics who built the looms, and automating other people’s work has always been our job. A bit harsh, but hard to disagree with!

🥉 Practitioner Voice

27 min • by Jim Highsmith

Jim explores a way of writing where your authority comes from having owned the consequences of your work, instead of academic method or thought leadership polish. He also shares how he writes with AI since Parkinson’s changed how he processes language. Long one, but I loved it.

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

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

Make your team ship faster!

I wish you a great week.

Sincerely 👋
Luca

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

📊 AI sped up coding, but not reviews

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

AI tools sped up code authoring. Review and release systems haven’t kept pace.

DX’s newest AI Impact Report, based on data from 500+ engineering organizations, shows developers opening far more pull requests each week, each more than twice the size it used to be. As a result, PRs wait more than twice as long for a first review.

Download the full report to see where delivery friction is moving and where leaders should focus next to get the most out of their AI tools 👇

Download the full report

🚚 Treat process changes like migrations

At LDX3 in New York, Will Larson opened with a keynote about the delivery journey of his team at Imprint: from manual gates everywhere, to CI/CD, to agentic workflows.

What I liked most was that he framed each of these steps as a migration.

We know a lot about migrating code, and I believe most of the same logic applies to processes and workflows. Here is how Will approached it:

1. Understand people’s problems — there is a reason why people do things the current way, even when it looks flawed, and to build something better you need to understand those problems deeply.

2. Get buy-in — even with clear top-down direction, the implementation should be collaborative. When Will wanted to move from Jira to Linear, he started by involving the biggest Jira fans, because if he could address their concerns, the rest of the team would be easier to migrate.

3. Draw hard lines — inclusion matters, but once a direction is taken, resources need to support it. Will made Claude Code the recommended coding agent: people can still use something else, but they won’t get support from the platform team.

4. Sweat the details — every migration has a long tail of things to fix and edges to smooth, so keep working on it even when it seems that most of the work is done.

I wrote a recap of my favorite talks from LDX3 and ProductLab, including Will’s 👇

🧰 Treat skills like code

In August I talked with Charlie Guo, developer experience engineer at OpenAI, about how teams are building with agents today.

We spent a lot of time talking about the move from single-player to multi-player: how do you take the productivity gains of a few AI power users and spread them across the team?

Charlie’s answer starts from skills. He organizes them in three tiers:

• 🧑‍💻 Personal skills — live in your local folder, and are useful only to you.

• 📂 Project skills — baked into the repo, and shared with everyone working on that project.

• 🏢 Organization skills — hosted in internal repositories blessed by IT and security, that anyone in the company can browse and clone.

Skills follow the same lifecycle as regular code: they are version-controlled, discoverable, they have owners, and an update process.

But tooling is not enough. Charlie knows people who don’t share their AI tricks because they don’t want their boss to think they are cutting corners, or because they are stack-ranked on AI proficiency and want to keep their edge. So if you lead a team, you should start from the culture side, and make sure that sharing a good workflow gets rewarded and celebrated.

You can find the full conversation with Charlie here 👇

📚 Weekly Readings

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

🥇 Redesigning Source Control at Anthropic

14 min • by Anthropic

Anthropic went from about 2,500 merged changes per day in May to over 30,000 in September, and git couldn’t keep up. So they built Scion, a custom source control system designed around always-online agents, and moved the whole monorepo off git in five months.

They argue that other companies will hit the same problems soon, and I believe it.

🥈 Hunger Beats Tenure: Advice for Junior Engineers

5 min • by Felix Rieseberg

Felix is a hiring manager at Anthropic, and this month he stopped doing coding interviews, because Claude is better than candidates at them anyway.

He also argues that AI is good news for junior engineers: you can pick a business goal, build one bold idea over a weekend, and skip a lot of the usual red taping.

🥉 The Counting House

32 min • by Steve Yegge

Steve explores a pattern to address huge volumes of repetitive work: cheap models on very tight rails, one case type at a time, scored against the humans doing the same job. It’s the exact opposite of his own wide-open software factory. Long read, but worth 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!

I wish you a great week.

Sincerely 👋
Luca

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

Sponsored

Centralize VPC traffic inspection with Palo Alto Networks on AWS

Most VPC security stops at the perimeter. Traffic moving laterally between VPCs can be left uninspected.

With this solution template, you get a pre-configured Palo Alto Networks VM-Series environment with AWS Gateway Load Balancer across four VPCs, so you can:

• Three traffic flows, one inspection point: Route outbound, east-west, and inbound traffic through VM-Series via AWS Transit Gateway.

• Live threat simulation: A real-world exploit hits your demo app. Switch from alert to active blocking.

• App-ID in action: Identify SSH on a non-standard port and enforce rules by application, not topology.

Explore the full architecture, step-by-step walkthroughs, and a live threat simulation.

Get the solution template ›

---

Palo Alto Networks VM-Series Next-Gen Virtual Firewall

Try Palo Alto Networks VM-Series free in AWS Marketplace.

Get started ›

---

About AWS Marketplace:

Visit AWS Marketplace for help finding the best solutions for your use case and add new capabilities to your tech stack with your AWS account:

• Tools are designed to plug in to your AWS workflows and integrate with your favorite AWS services

• Evaluate fast with free trials and developer-tier pricing to support fast prototyping

• Avoid upfront license fees and pay only for what you use, consolidating billing with your AWS account

• A broad selection of tools across AI, data, observability, security and more can enhance how you build with AWS

🛝 Governance can make you faster

Many teams feel conflicted about putting real AI governance in place, because it looks like a brake at a moment where everybody expects you to accelerate.

I have a contrarian take: I believe good governance can be an accelerant.

In 2006, Peter Summerlin ran a simple study about kids in playgrounds. Teachers took kids to a playground with no fence, then to a comparable one with a defined border. Without the fence, the children stayed huddled around their teacher, afraid of leaving her sight. With the fence, they felt free to explore within the boundaries. So in playgrounds with fences, kids used more space.

People work the same way. Once they know where the fences are, they feel empowered to do more within them. But that’s only true if governance is good.

We already see this in coding. We talk about guardrails for AI coding all the time, and having strict guardrails is exactly what allows me to be more liberal with the tasks I give to my agents, and with what they can ship.

Data also seems to point the same way. A late-2025 Google Cloud / CSA study looked at agentic AI adoption by governance maturity:

• Full governance → 46% adoption

• Partial governance → 25% adoption

• Still in development → 12% adoption

Correlation is not causation, but it makes it hard to look at governance as just a tax.

I wrote a full guide about how to get started with AI governance, including what you should govern and how rules graduate from common sense to software 👇

Refactoring

Getting started with AI governance 🔒

Hey there, Luca here…

Read more

2 months ago · 30 likes · Luca Rossi

🚲 Put gears, not modes

In July I talked with Geoffrey Litt, design engineer at Notion, about malleable software, and he shared one of his favorite product design parables.

Imagine a bicycle whose gears are labeled not with numbers, but with modes like “gravel gear” and “uphill gear”. It sounds user-friendly, but it’s actually terrible. What do you do when you’re going uphill on gravel?

When you hide the underlying model behind labels, you take away the mental model people need to develop to handle new situations. And humans are smart! They can learn numbered gears, and then combine that knowledge creatively.

What malleable software means is having a smaller set of primitive components that can be reassembled to make anything, and doing a really good job introducing and teaching those components to everyone using the software, just like bicycle gears.

Notion is a good example of this. Every paragraph, heading, and image is a self-contained block you can drag, nest, and sync across pages. It’s a small learning cost upfront that keeps paying back over time, and now it pays back with agents too: they reuse the same primitives, so Notion agent instructions are just Notion pages.

You can find the full conversation with Geoffrey here 👇

📚 Weekly Readings

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

🥇 On the Death of Amazon’s Writing Culture

7 min • by Steve Huynh

Steve spent almost twenty years at Amazon, and he argues that its famous writing culture didn’t survive AI.

Bezos used to say you can’t write a six-page memo without clear thinking, and that is simply not true anymore, so a doc is no longer proof that someone has thought about the problem. Food for thought.

🥈 Someone Behind the Software

3 min • by Karri Saarinen

Karri argues that good products carry something of the people who make them, and that many products today feel messy because adding new capabilities is much easier than rethinking the existing ones. This is a great take, that I also needed to hear for Tolaria.

🥉 How to Be More Ambitious: A Tutorial for Humans With Models

9 min • by Felix Rieseberg

Felix works on Claude, and wrote a practical guide to using AI for more than doing the same work faster. He splits ambition into altitude, depth, and range. For example he went from asking Claude to fix single crashes to asking it to keep the apps crash-free, which first meant giving it crash reports and machines to reproduce bugs on. Lots of good prompts to steal, too!

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!

I wish you a great week.

Sincerely 👋
Luca

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

Sponsored

Connect real-time data pipelines across your AWS stack

Deliver real-time customer experiences without managing streaming infrastructure. Confluent Cloud provides a secure, fully managed Apache Kafka-based solution for event streaming — directly from your AWS account.

See how Confluent Cloud integrates with AWS tools, including Amazon S3, Amazon Redshift, AWS Lambda, and Amazon Bedrock, to:

• Accelerate development: Build real-time data pipelines connected across your AWS tools.

• Simplify operations: Offload event streaming management to Confluent Cloud.

• Scale in real time: Power event-driven and generative AI apps within your AWS environment.

Get technical details to start building — from step-by-step tutorials and Infrastructure-as-Code templates to a free trial.

Explore Confluent Cloud on AWS →

Try Confluent Cloud for free in AWS Marketplace

Get started in AWS Marketplace ›

🏃‍♂️ Make room for hard things

In Mental Marathoners, I wrote that a possible consequence of intelligence getting cheap, is that the edge moves to people who still want to stretch their own thinking.

What I don’t buy is that this hunger is just a trait — that you either have it or you don’t. I prefer to ask myself what makes me hungry in the first place.

There is a data point about runners that stuck with me. Regular runners (4+ hours a week) are unusually affluent and educated, even though running itself is cheap. This means the filter is not the cost of the hobby. To me, this looks more like Maslow: once basic needs are covered (i.e. you are affluent and educated), you free up mental space for harder challenges (i.e. running).

We become hungrier when the rest of our life is simple enough that a hard problem has room to be attacked.

So I think of energy like a jar. If you fill it with sand (chores, fake urgencies, a hundred open tabs), the rocks never go in. The stretch work is a rock, and in my experience, you should spend at least half your time on that.

I wrote more about mental marathoners and how to stay on the right track here 👇

Refactoring

Mental marathoners 🏃‍♂️

A couple of weeks ago, I read The People Who Will Thrive in the AI Age, by David Brooks…

Read more

2 months ago · 45 likes · Luca Rossi

📖 Use stories to deliver hard feedback

Earlier this year I talked with Michael Lopp (Rands) about the power of stories at work, and one part I keep coming back to is how he delivers hard feedback.

He told the story of a high-performing director who had only ever gotten top marks, then suddenly got a “C” after a promotion, and got furious. Instead of saying “pull it together,” Rands walked him through a personal story of going through the same experience years earlier.

This didn’t fix things overnight – it took weeks and months of continued support – but the story created space for the person to process the feedback on their own terms, instead of locking into defense.

Their job is to choose to decide whether they want to learn or not. It’s really important. If they don’t hear the story, if they don’t hear the lesson, they’re not going to do anything.

When coaching or managing people, we should assume they are capable and resourceful. In this context, stories can give just enough input to unblock someone, without spoon-feeding the answer. They get to own the conclusion, and that ownership is often what makes them actually act on it.

You can find the full conversation with Michael here 👇

📚 Weekly Readings

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

🥇 If Your Team Is Happy, Are You Doing a Good Job?

9 min • by Charity Majors

Charity goes back to the ZIRP-era belief that if your team is happy, you are doing a good job, and explains how psychological safety drifted from being about learning and performance to being about never feeling bad at work.

I agree with her that frustrating people and telling them no is part of a manager’s job, because growth is uncomfortable. Great read, and part of a longer conversation with Cat Hicks that is worth catching up.

🥈 Software’s Centaur Age May Last Decades

5 min • by Sean Goedecke

Sean argues we are living in the centaur age of software, where engineers paired with AI beat both unassisted engineers and unsupervised agents, and that this phase may last decades, like it did in chess.

I don’t know if he is right about the timeline (nobody really does), but I like his advice a lot: don’t jump ship early, and spend your energy figuring out what value humans still add.

🥉 How Do AI Coding Assistants Change the Shape of Eng Work?

4 min • by Lizzie Matusov

Lizzie covers a six-month study on how AI assistants reshape engineers’ days, and the results are mixed: perceived productivity held at 84%, but the share of engineers reporting a worse developer experience nearly doubled, from 14% to 27%.

Time moved from writing code to directing and checking AI output, and focus took the hardest hit. I liked the practical advice at the end, especially batching AI review into set blocks and keeping design work and hard debugging on separate, protected time.

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!

I wish you a great week.

Sincerely 👋
Luca

Hey, Luca here! Welcome to a new edition of the 💡 Monday Ideas 💡 — ideas and readings to start the week on the right foot.

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

Hyperscale Remediation: 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 the enterprise codebase and remediates them autonomously. It traces each finding through execution paths, identifies dependencies, and validates remediation. Blitzy then turns prioritized risks into batches of tested pull requests for engineers to review.

The result: 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

📚 Knowledge capture compounds engineering quality

In April, Rob Zuber and I wrapped up our software factory series with an article on compounding. We asked: how do teams actually get better over time, instead of just shipping more?

I believe knowledge capture is one of the few things in engineering that truly compounds.

Teams usually capture too little of it. They especially lose decisions, forgetting why systems work the way they do.

There is basically no excuse today for not getting this right, because capturing and processing information is much cheaper than before. Meeting notes, ADRs, product decisions, can all be captured, summarized, updated, and reused by agents.

So docs become an asset that improves the development loop, instead of a tax. And the more context the team captures, the more coherent decisions the AI can make on the next project.

This is especially important for building the right thing, as opposed to simply the next thing. A codebase becomes easier to steer when future work can see past decisions.

Read the full article here 👇

Refactoring

The Compounding Software Factory 📈

Hey there, Luca here…

Read more

6 months ago · 61 likes · 2 comments · Luca Rossi

🤝 Good engineering is an exercise in human relationships

Two years ago I had Kent Beck on the podcast, and we talked about Extreme Programming and TDD. I rewatched that interview recently to figure out what has changed (and what has not) since then, and a part that stuck with me is when he said good engineering is an exercise in human relationships.

This is easy to miss because you may just treat XP as a bag of techniques: short cycles, tests, pairing, reviews, and so on. But all of these only work if people communicate and give each other feedback.

This ties in with Kent’s idea that Agile goes largely against traditional power structures. Waterfall represents a fatal attraction for many teams because it replaces grassroots communication with a plan that gets transmitted down through hierarchy.

If the human relationships are missing, you can install the practices and still not have the actual engineering.

You can find the full conversation with Kent here 👇

📚 Weekly Readings

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

🥇 The Kids Are Alright

6 min • by Francisco Trindade

Francisco takes on the question of whether we should still hire junior engineers, and his answer is a strong yes. If the job of a senior becomes leading a project by orchestrating agents, the job of a junior will be to lead simpler projects in the same way. And if juniors have nothing meaningful to do on your team, that probably says more about your process than about them. I loved this one.

🥈 Software Factories Are a Local Maximum

3 min • by Aviv Ben-Yosef

Aviv makes a great point: agents can make us lose the healthy friction that made us think about why we were building something. I have written a lot about software factories myself, and I 100% agree with him.

🥉 How to Write an Effective Software Design Doc

15 min • by Michael Lynch

Michael wrote design docs at Google and Microsoft, and this is his full playbook on when a doc is worth it, what belongs in it, and what doesn’t. I feel this is even more relevant today, since a good design doc is pretty much the context you want to give your agents (or have them help you write anyway).

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:

🖥️ Coding agents need more than a fast loop

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

Coding agents have sped up individual tasks, but they haven’t solved the coordination, validation, and handoffs that determine how quickly software ships, especially the enterprise one!

Tomorrow join Sid, CTO and co-founder of Blitzy, for a live session on what changes when a system can hold context across an entire codebase—not just a single file or function.

He’ll walk through a real project in Blitzy, covering reverse engineering, tech spec generation, the Agent Action Plan, code generation, and PR Review, including where human review gates the process. There will also be a Q&A at the end 👇

Save your seat!

🚀 Create high-agency engineers

Out of the various interviews / case studies we did last year, one of those that aged better is the one with Greg from Graphite.

I think it’s because we talked very little about tech, and more about values and culture. In particular, Graphite is obsessed with building a team where engineers have high agency.

What does a high-agency engineer look like? For Greg, it’s someone who owns problems end-to-end, which allows for:

• More productivity — less back-and-forth, less waiting, less “that’s not my job”.

• More fulfillment — people who have real impact stay engaged, grow faster, and stick around longer.

High agency, though, it’s not (only) a personal trait — it needs to be enabled by your team environment. For Greg, at a team level, agency comes from three things:

1. Purpose — a clear vision of where you are going and why it matters.

2. Permission — freedom to go after big things, make decisions, and occasionally get things wrong.

3. Simplicity — cognitive load low enough that ownership feels like a superpower, not a burden.

To make this happen, for example, Graphite is extremely light on product management: a couple of PMs for 30+ engineers. Engineers need to fill the gaps: talk to stakeholders, prototype, dogfood, and push work forward without waiting to be unblocked.

To be honest, they also have an unfair advantage: they build a dev tool, so their engineers are their users. Which means product intuition comes for free.

But for everyone else, the principle holds: get engineers closer to customers. The difference is you have to invest more intentionally about it:

• Bring engineers to customers — sales calls, user interviews, support escalations. First-hand experience and empathy beats summaries.

• Make context accessible — record calls, share clips, pipe tickets into Slack.

• Dogfood relentlessly — even if the product is not “for” engineers, find ways to make them use it.

I wrote a full case study about how Graphite ships 👇

Refactoring

How Graphite Ships 🚢

It’s a weird time for engineering teams…

Read more

a year ago · 19 likes · Luca Rossi and Greg Foster

🧭 Growth trajectory >> AI fluency

Greg’s story made me think about my interview with Austen McDonald, former hiring committee chair at Meta, and author of Mastering Behavioral Interviews, where we discussed how AI is reshaping how engineers get assessed.

Austen recommends evaluating AI skills in both technical and behavioral rounds, but the questions should be different. In behavioral interviews, stories are king. So you may ask something like “Tell me about a time you used AI and it didn’t work out.”, instead of abstract prompts like “How do you think about AI?”

But the strongest predictor is not current AI usage at all. It is growth signal: is this person staying on top of industry trends, running side projects, adapting when the ground moves? This has always been important, but now more than ever.

“The most important thing about this person is not how they use AI right now, but how they are going to be adapting to using AI as the landscape changes.”

Austen particularly focuses on ownership. As AI handles more of the stack, “full stack” expands toward more areas of the business: customers, go-to-market. Does the candidate reach for more end-to-end ownership? Are they willing to do so?

You can find the full conversation with Austen here 👇

📚 Weekly Readings

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

🥇 If We Do Not Stop to Help Each Other, What Do We Become?

3 min • by Jeff Atwood

Jeff shares a great message from a developer who once got through a dangerous deployment because strangers on Stack Overflow chose to help him. An LLM could have provided the same (or a better?!) answer, but not the feeling that somebody cared. We need that reminder!

🥈 Dishwasher Mode for AI Tasks

1 min • by Clemens Adolphs

A dishwasher is slower than washing plates by hand, but we don’t care, because it still frees up our time. Clemens uses the same frame for AI: give it small, annoying tasks off the critical path, then care more about reliable completion than raw speed. I liked this a lot.

🥉 The Sensible Defaults Playbook

2 min • by Thoughtworks

Thoughtworks shares its collection of good defaults. Their approach is to have defaults remove recurring friction, but without becoming dogma. Start with practices that usually work, adapt them to the context, and review them as the environment changes.

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:

📚 Master production-grade orchestration, for free!

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

A few months ago we published an article about how to orchestrate AI workflows, together with the team at Kestra, an awesome open source project used by the teams at Apple, JPMorgan, and more.

Today I am happy to help them spread the word about the Kestra Academy, where you can find self-paced courses on infrastructure automation, AI workflows, and standardizing orchestration across your engineering org.

In the academy, you can learn how to govern complex workflows and start running production pipelines the same week.

You should check it out! 👇

Learn how to run orchestration

🏁 Faster coding vs faster delivery

Most AI coding tools optimize the inner loop: you describe a feature, watch the agent write the code, and get something working a few minutes later.

This is where AI has delivered the most visible improvements, but it is just a small part of how software gets shipped. There is an outer loop too: deciding what is worth doing, shaping and reviewing the solution, releasing it, and learning from production.

If you don’t improve both, the constraints move elsewhere:

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

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

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

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

So the goal should be end-to-end throughput, which requires a workflow that encompasses both the inner and the outer loop.

I wrote a full case study about how the guys at TRM are doing this 👇

🧪 Agents will game your tests

When I spoke with Anush Elangovan, VP of AI Software at AMD, he described a funnel where creativity is allowed to run wild at the top, but progressively more human judgment is needed as code moves toward production.

He also shared an entertaining story about building Spur, an AI-native job scheduler. The agents writing the code were so “smart” that they found a shortcut: instead of actually running unit tests on hardware, they simulated the hardware and reported success.

“The agents were so smart that they would simulate the hardware and pass the unit test and say ‘yes, success.’ We had to say no, no, no — you never simulate the hardware. You have to actually run the test on hardware before you can promote a PR.”

That forced the team to build a superset of the guardrails they previously had for humans. Test harnesses now need to account for adversarial agent behavior. The result, Anush said, is a quality system roughly 10x more comprehensive than what was needed when humans were the only contributors.

I have found this to be a useful posture: assume agents will optimize for passing the tests, not necessarily respecting their spirit, and design accordingly.

You can find the full conversation with Anush here 👇

📚 Weekly Readings

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

🥇 The Manager’s Path in the Age of AI

13 min • by Camille Fournier

Camille asks what still belongs to managers when AI raises individual output and eats the small day-to-day interactions that build trust and rapport across an org. This is the written version of the talk I heard at LDX3. I loved 100% of it and it gave me a lot to think about.

🥈 Code Yellow, Code Red

11 min • by James Stanier

James walks through declaring a Code Yellow after months of instability eroded some customer trust. Running it well means clear communication, defined goals, and company-wide support to fix problems, without blame.

🥉 Trying the Software Factory Pattern

3 min • by Will Larson

Will is trying a “software factory” loop: agents audit the project’s goals and metrics, keep track of state on Linear, work on the non-blocked tasks, and re-check when the description goes stale. This was short and practical, and a good 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.

Run a better engineering team

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:

🔨 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

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

6 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

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

5 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

8 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

6 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

6 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

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

6 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

10 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

6 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

6 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