Become an investor in AI infra startups! ✨

Today’s sponsor is Alumni Ventures!

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

You can signup for free and get:

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

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

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

Join Alumni Ventures AI Infrastructure Syndicate Today →

💡 Never start from a blank page

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

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

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

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

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

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

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

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

• Capture — store the thought on a durable support.

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

• Express — use it to do something larger.

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

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

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

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

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

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

Refactoring

How To Take Notes 🌱

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

Read more

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

🎙️ Principles for better decisions

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

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

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

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

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

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

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

Here is the full interview with Annie:

📚 Weekly Readings

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

🥇 Sometimes Your Job Is to Get in the Way

5 min • by Rands

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

🥈 Why Can’t They Just…

5 min • by Lara Hogan

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

🥉 Contributor Poker and AI

6 min • by Loris Cro

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

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

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

Make your team ship faster!

See you next week!
Luca

Stop babysitting your agents! 🙅‍♂️

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

Agents can generate code, we know it.

But getting it right for our system, conventions, and past decisions is still the hard part — we waste time and tokens in correction loops. Patching many MCPs together may give agents access to information, but not necessarily understanding.

That’s why I am a fan of what Unblocked is building with their context engine — giving agents exactly what they need to understand things and succeed. Join their webinar on May 6th (free) to see:

• Where teams get stuck on the AI maturity curve

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

• Live demo: the same coding task with and without a context engine

Learn more and register!

💡 Personal leverage is now unlimited

A couple of months ago I wrote about my experience with OpenClaw — what I do with it, what procedures it runs automatically, and so on.

I also argued that the story of OpenClaw itself seems to point to the idea that a good solo engineer can now achieve… pretty much anything. Look at the progression of AI assistants and coding tools:

1. At first, it was VS Code + Copilot. Created by Github/Microsoft, which is a big tech.

2. Copilot was surpassed by Cursor, created by a team around 1/100th its size.

3. Cursor was then surpassed by Claude Code, which has been created literally by 2 engineers inside Anthropic, and whose team to this day is ~20 engineers.

4. OpenClaw has been created by Peter Steinberger. That’s it.

In my (very small, comparably) experience with Tolaria, I am seeing this as well. If you are equipped with the right set of ingredients, it’s hard now to see the limits of what a single engineer can do. But what are these ingredients? To me it’s:

1. 🔧 Tech skills — you still need these! Especially to steer a sizable project. E.g. Peter is first and foremost a world-class engineer.

2. 🧑‍🍳 Taste — your personal taste for what good looks like, your domain expertise, how knowledgeable you are about the problem you want to solve, your product senses — these are the things that AI is not going to replace anytime soon, if ever.

3. 🏃 Drive — above all, the drive and discipline needed to put something out there. I know an awful lot of people who have the first two ingredients, but kinda miss this one.

My OpenClaw article is one of the most popular pieces I have ever written, you can catch up with it below 👇

Refactoring

My experience with OpenClaw 🦞

Hey, Luca here! This is a 🔒 weekly essay 🔒 from Refactoring! To access all our articles, library, and community, subscribe to the full version…

Read more

3 months ago · 53 likes · Luca Rossi

🎙️ Junior engineers will just be fine

Last month I interviewed the legendary Chris Lattner on the podcast. Chris created LLVM, Swift, led Tesla autopilot, brought TPUs to the market at Google, and more! He is now the founder of Modular, where he creates portable infra to work with GPUs.

Chris told me that, despite the industry-wide narrative that AI favors senior engineers, Modular is actively hiring a ton of new college grads and interns. Chris’ reasoning is based on two observations:

• 🧠 AI-native thinking — junior engineers bring a completely different expertise. They are native to the tools and adapt faster than many experienced engineers.

• ⚖️ Team balance — good teams need people at multiple levels learning from each other. All-senior or all-junior teams both fail in different ways. (we wrote about this also here!)

You can find the full interview with Chris below:

You can also find it on 🎧 Spotify and 📬 Substack

📚 Weekly Readings

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

🥇 The Last Software Engineer

10 min • by Kent C. Dodds

Fast forward to the moment right before AI takes over everything engineers do — what’s the last valuable thing left? I won’t spoiler! Fantastic article by Kent.

🥈 Why Sell Software If Anyone Can Make It?

2 min • by Clemens Adolphs

It’s not hard to make bread at home — even better than the one you buy at the bakery. Yet nobody really does it at scale. Don’t let the “everyone can code now” narrative scare you out of building a software business.

🥉 How I use AI to Code

19 min • by Chris Sherwood

A thorough, opinionated guide on AI coding, updated to April 2026. Covers both the mindset and the practical tools. I liked it!

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

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

Make your team ship faster!

See you next week!
Luca

Reporting from Salesforce’s TDX event! 🧑‍💻

This week’s sponsor is Salesforce!

Our friend Conor Bronsdon was our eyes and ears on the floor at TDX last week, and wrote a full breakdown on Chain of Thought.

He says Agentforce is now Salesforce's fastest-growing product, and the signs were everywhere at TDX:

• 60+ new MCP tools in Headless 360

• Agent Script open-sourced on GitHub

• Agentforce Vibes 2.0 (their vibe coding tool),

• plus new Slack agent capabilities.

Salesforce went as far as publishing the full language spec, grammar, parser, and compiler for their agent-definition language.

They're betting an open agent ecosystem wins developer adoption, while enterprise-grade upgrade paths let businesses actually ship reliable agents to production.

Read the full TDX breakdown

💡 Coding is not solved, but bad code… kinda is

Last week I launched Tolaria, which by now is one of the fastest growing repos on the whole Github! It got 6000+ stars in less than a week.

Tolaria is a lot of code: 100K+ LOCs, 2K+ commits, 3K+ tests, 70+ ADRs. I publicly said many times I didn’t write any of it, which made some people think I believe coding is solved.

I don’t think coding is solved at large, but bad code feels solved. To understand what I mean by that, a useful way to think about tech debt is to split it into two kinds:

• Bad code

• Misaligned code

Bad code is basic hygiene failure: lack of tests, high complexity, tight coupling, duplication, outdated libraries. It is bad regardless of business context, and we know it increases lead time, outages, and maintenance cost.

As of today this kind of debt is largely avoidable if you choose to enforce quality. On Tolaria, AI-generated code must meet three gates: high test coverage, strong CodeScene health scores, and current library/docs usage. These rules live both in CLAUDE.md and CI, because agents still forget or ignore instructions. Once those checks are in place, the basics can be trusted without manually reviewing every line.

Misaligned code is harder, and is definitely not solved yet. Code may be clean, tested, and well-structured, but still wrong for the product direction you want. It’s code that is a good circle when you really needed a square: a leaky abstraction, an old design assumption, or a model that no longer matches intent.

Reviewing architecture and abstractions still feels supremely important, because they're the things that the AI model can’t figure out by itself, because they are about what you want to build in the future, and why.

I wrote more about this in my series of articles about my AI coding workflow:

1. My AI Coding Workflow (Feb 2026)

2. Updates to My AI Coding Workflow (Apr 2026)

3. Introducing Tolaria (last week!)

🎙️ Progressive disclosure of complexity

In May last year I interviewed Guillermo Rauch, founder and CEO of Vercel

Guillermo talked about the qualities of great technology, and one principle that stuck with me was what he called the progressive disclosure of complexity.

A defining feature of great tech is that’s approachable for beginners but powerful enough for enterprise needs.

This principle guides the design of Vercel, Next.js, and everything they do.

“I’m building a platform that should not be intimidating for your first line of code, and gives you the superpower that you could be one day a top 30 internet website with the same infrastructure, with the same tools, with the same access.”

Guillermo draws inspiration from products like the iPhone, which can be used by both children and the elderly while still serving business professionals with complex needs.

His approach to API design focuses on what he calls token minimization (not AI tokens!) — requiring minimal code to get started, then gradually introducing more sophisticated features as needed:

• 🏁 Low barrier to entry — a new Next.js project can be started with just a few lines of code.

• 🌱 Growing with users — complexity is only introduced when needed for specific requirements.

• 🔄 Same technology at all scales — the technology that powers a beginner’s first project is the same that can scale to handle millions of users.

Here is the full interview with Guillermo:

You can also find it on 🎧 Spotify and 📬 Substack

📚 Weekly Readings

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

🥇 My CTO Daily Driver

8 min • by James Stanier

I basically recommend all of James’ articles, and this makes no exception. He explains how he uses Claude Code to drive a personalized CTO workspace with memory. With custom slash commands tied to Linear, Notion, and BetterStack.

🥈 The Peril of Laziness Lost

12 min • by Bryan Cantrill

Laziness has always been a programmer’s virtue — it’s what drives us to build abstractions instead of doing the same thing twice. LLMs don’t have that instinct: you have to supply it to them. If you don’t, you lose the elegance, efficiency, and maintainability that comes from human constraints.

🥉 99% of Our Production Code Is Written by AI

20 min • by Peter Pang

Took a lot of ideas from this post. Feels a bit AI-generated at times, but the ideas around feature gates, self-healing feedback loop, and bug fixing are awesome. Peak “harness engineering”, as kids call it these days.

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

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

Make your team ship faster!

See you next week!
Luca

Stop babysitting your agents 🍼

Today’s sponsor is Unblocked!

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

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

Join our friends at Unblocked on April 23 (FREE) to see:

• Where teams get stuck on the AI maturity curve

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

• Live demo: the same coding task with and without a context engine

Register now!

💡 Developer Experience is your floor

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

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

• 📈 +15% activity on feature branches

• 📉 -7% activity on the main branch

• 📉 -15% success rate on the main branch

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

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

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

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

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

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

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

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

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

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

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

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

I wrote a full piece about DevEx, AI, and Product Engineering, and how these are the new pyramid of software engineering 👇

Refactoring

The New Pyramid of Software Engineering 🏔️

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

Read more

2 months ago · 49 likes · Luca Rossi

🎙️ Why did the day need saving?

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

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

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

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

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

Here is the full interview with Rands:

You can also find it on 🎧 Spotify and 📬 Substack

📚 Weekly Readings

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

🥇 Who Will Be the Senior Engineers of 2035?

11 min • by James Stanier

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

🥈 Open Source Isn’t Dead

3 min • by Alex Schapiro

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

🥉 Agents as Scaffolding for Recurring Tasks

4 min • by Will Larson

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

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

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

Make your team ship faster!

See you next week!
Luca

How Augment Code is going AI-native

Today’s sponsor is Augment Code!

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

• How we hire AI-native engineers now

• Confidence is the new bottleneck

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

Check out the 5-min survey

💡 Just ask engineers

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

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

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

• How to get started with engineering metrics

• What’s next in measuring dev productivity

• You have metrics, now what?

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

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

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

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

Refactoring

The Listening Tour 📞

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

Read more

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

🎙️ Past behavior predicts future results

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

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

Austin breaks down what interviewers look for into signal areas:

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

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

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

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

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

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

In fact, companies exist on a wide spectrum:

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

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

• Google has traditionally leaned more technical.

Here is the full interview with Austen:

You can also find it on 🎧 Spotify and 📬 Substack

📚 Weekly Readings

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

🥇 The Git Commands I Run Before Reading Any Code

3 min • by Ally Piechowski

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

🥈 Feedback Flywheel

10 min • by Rahul Garg

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

🥉 The Human Weight of It

7 min • by Cate Huston

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

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

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

Make your team ship faster!

See you next week!
Luca

Make your team ship faster!

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

Build with Intent 🔭

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

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

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

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

Learn more about Intent

1) 🎯 In your AI context, share the why

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

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

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

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

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

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

• How much of this is written down?

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

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

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

Refactoring

How to Manage Context in AI Coding 📑

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

Read more

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

2) 🎙️ Functional vs cross-functional teams

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

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

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

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

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

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

Here is the full interview with Gonçalo:

You can also find it on 🎧 Spotify and 📬 Substack

📚 Weekly Readings

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

🥇 Every Layer of Review Makes You 10x Slower

11 min • by Avery Pennarun

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

🥈 The Middle Loop

7 min • by Annie Vella

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

🥉 Don’t Let AI Write For You

2 min • by Alex Woods

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

4) AI “Aha” Team Meetings

7 min • by Lara Hogan

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

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

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

Make your team ship faster!

See you next week!
Luca

I am repeating last week’s experiment of adding the best articles I have read last week, other than the classic weekly ideas. Let me know if you like it!

To access all our articles, library, community, and support my work, subscribe to the full version of Refactoring.

Subscribe now

Secure your mobile app and the APIs it interacts with

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

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

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

Register now

1) 🧵 Tech Leadership Archetypes

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

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

1) Clarify expectations

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

2) Sense how the role evolves over time

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

3) Identify signals when hiring

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

4) Plan intentional career growth

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

You can find the full guides below 👇

2) 🎙️ The Perfect Team

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

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

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

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

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

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

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

Here is the full interview with Rob:

You can also find it on 🎧 Spotify and 📬 Substack

3) 📚 Weekly readings

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

🥇 Architecture Decision Record

8 min • by Martin Fowler

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

🥈 The 2028 Global Intelligence Crisis

25 min • by Citrini Research

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

🥉 Nobody Gets Promoted for Simplicity

8 min • by Matheus Lima

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

4) Better, Faster, and Even More

10 min • by Rands

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

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

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

Make your team ship faster!

See you next week!
Luca

To celebrate this milestone I want to experiment with some tweaks. Instead of our classic three ideas, today I am going to post:

1. 🧵 One idea from a recent article I wrote.

2. 🎙️ One idea from a recent podcast interview we did.

3. 📚 A small digest of the best articles I have read this week (in the style of what I have been doing with Hybrid Hacker).

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

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

Brought to you by Unblocked! 🔳

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

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

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

See how Unblocked works

1) 🧵 The rise of slave software

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

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

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

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

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

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

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

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

2) 🎙️ Be skeptical of polarities

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

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

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

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

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

3) 📚 Weekly readings

Here are the top three articles I have read:

Finding Comfort in the Uncertainty 🥇

8 min • by Annie Vella

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

GNU and the AI Reimplementations 🥈

9 min • by antirez

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

Prioritize Relatively 🥉

2 min • by Boz

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

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

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

Make your team ship faster!

See you next week!
Luca

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

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

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

Fill out a 3-min survey

1) ✂️ Layoffs predictions are (probably) overblown

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

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

It doesn’t seem so.

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

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

Here are a couple of revealing quotes from the survey:

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

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

You can find the full survey here:

Refactoring

The State of AI Adoption in Engineering Teams 📊

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

Read more

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

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

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

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

It’s actually the other way around.

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

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

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

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

Refactoring

In Praise of "Normal" Engineers 🛠️

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

Read more

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

3) 🎙️ Your second brain with Claude Code

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

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

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

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

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

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

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

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

He shared the full story in the interview 👇

You can also find it on 🎧 Spotify and 📬 Substack

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

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

Make your team ship faster!

See you next week!
Luca

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

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

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

Fill out a 3-min survey

1) 🎽 The Big Three Behavioral Questions

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

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

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

1.1) Tell me about yourself 🙋‍♂️

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

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

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

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

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

This should take 1–2 minutes max.

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

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

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

1.3) Tell me about a conflict you resolved ⚔️

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

You can find the full guide below 👇

Refactoring

How to Master Behavioral Interviews 📞

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

Read more

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

2) 🔨 AI should improve your code quality

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

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

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

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

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

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

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

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

Refactoring

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

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

Read more

8 months ago · 29 likes · Luca Rossi

3) 🎙️ Standardization vs. flexibility

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

So, a few things that should be standardized are:

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

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

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

What can stay flexible:

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

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

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

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

Here is the full interview with Rob Zuber:

You can also find it on 🎧 Spotify and 📬 Substack

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

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

Make your team ship faster!

See you next week!
Luca

Make your team ship faster!

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

📖 Create a shared engineering playbook

This idea is brought to you by Packmind!

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

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

Try Packmind Open Source

1) 🪴 Share your culture

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

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

1️⃣ Map your touch points

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

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

2️⃣ Show, don’t tell

Instead of listing abstract values, share real stories.

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

3️⃣ Write from your best performers

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

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

Refactoring

Generative culture 🪴

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

Read more

a year ago · 38 likes · 2 comments · Luca Rossi

2) 🎌 Find your allies

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

1. You have to identify what needs to change.

2. You have to make change happen.

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

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

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

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

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

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

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

Refactoring

How to Help a Struggling Team 📉

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

Read more

9 months ago · 25 likes · Luca Rossi

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

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

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

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

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

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

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

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

Here is the full interview with Adam:

You can also find it on 🎧 Spotify and 📬 Substack

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

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

Make your team ship faster!

See you next week!
Luca

Make your team ship faster!

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

Product Methodology Survival Guide 📚

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

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

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

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

Download the guide

1) 📋 Keep backlogs radically short

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

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

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

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

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

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

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

— Mary Poppendieck

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

You can find the full guide below 👇

Refactoring

How to Build a Product Engineering Culture 🪴

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

Read more

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

2) 🔨 Interview methods for 2026

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

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

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

This reshuffles the classic methods.

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

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

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

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

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

You can find the full guide below 👇

Refactoring

How to Interview Engineers 📋

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

Read more

a year ago · 45 likes · Luca Rossi

3) 🎙️ Evergreen career advice for engineering managers

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

1) Focus on relationships 🤝

Camille emphasizes the importance of good relationships at all levels:

• Reports — people have to want to work for you

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

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

2) Maintain technical credibility 💻

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

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

3) Represent the company well 🏢

She reminded managers that they are representatives of the company:

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

4) Learn continuously 📚

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

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

You can find the full interview below 👇

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

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

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

Make your team ship faster!

See you next week!
Luca

Make your team ship faster!

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

Agent-first development for your org 🤖

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

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

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

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

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

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

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

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

Download the free report

1) 🔬 Most AI teams don’t need researchers

… they may not even need AI engineers.

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

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

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

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

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

You can find the full article below!

Refactoring

How to Build AI into Tech Products 🔨

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

Read more

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

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

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

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

So I tried two things:

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

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

Both experiments were a huge success.

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

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

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

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

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

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

Refactoring

What I am reading in 2025 (and how) 📚

Hey, Luca here! This is a 🔒 weekly essay 🔒 from Refactoring! To access all our articles, library, and community, subscribe to the full version…

Read more

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

3) 🎙️ Driving AI adoption as a CTO

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

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

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

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

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

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

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

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

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

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

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

Here is the full interview with Darragh:

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

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

Make your team ship faster!

See you next week!
Luca

🎟️ Scale AI coding without sacrificing quality

On February 23rd I will join a webinar with Adam Tornhill and our friends at CodeScene about how to use AI to improve your code quality — instead of making it worse!

I am a big fan of CodeScene and all of their recent work, including their MCP server and their code health whitepaper.

If you want to hang out and have a chat there, you can RSVP for free below! 👇

Join our webinar on AI code quality

1) 💊 Beware AI productivity “placebo”

Research on productivity is tricky, because most data is just… self-reported.

The way we usually investigate AI’s impact is by asking developers how they feel about it — and engineers are generally satisfied. However, we also know that the only time we tried to measure productivity using proper control groups, developers thought they were more productive, while they actually were not.

In other words, it’s productivity placebo: AI triggers the feeling of progress without guaranteeing real output.

Has it ever happened to you to get into a multi-hour bug-fixing rabbit hole, try everything and nothing works, you give up for the day, and then the morning after you fix it in 5 minutes?

This happens because relentless bug fixing is like a fake state of flow. You enter a workflow with quick feedback loops (change something → see if it works), and it feels cognitively easy to sustain, so you can go on for hours. But it feels easy precisely because you are not truly engaged — you are working on autopilot, and unsurprisingly, not making real progress.

There is a way to work with AI that feels exactly like this. You feel productive, but you are not.

So how do you escape it? To me it’s about good work hygiene:

• Stay engaged — try to understand what the AI is doing, provide feedback, and steer the output actively.

• Do not multi-task — pick one of two extremes. Either set things up so the agent is autonomous for a long time, allowing you to meaningfully do something else (e.g. a meeting), or move in short iterations that keep you focused on the task without wandering to email, browser, or Slack. Frequent context switch makes us stupid and less capable of intercepting AI mistakes.

• Make frequent pauses — get up for 5 mins every 30 (pomodoro-style), have a quick walk, and get back to work. Avoid your own brain rot by forcing yourself to reset frequently.

I covered this recently in this article 👇

Refactoring

The AI Productivity Paradox 🏃‍♂️

Hey, Luca here! This is a weekly essay from Refactoring! To access all our articles, library, and community, subscribe to the full version…

Read more

6 months ago · 40 likes · Luca Rossi

2) 🏋️‍♂️ Hard work is a lagging indicator

There is a big feud in tech over hard work. It’s between teams who work long hours / 996 / hustle all the time, vs those who focus on a more measured approach, in the style of “slow is smooth, smooth is fast”.

It has become a culture war — people attach part of their identities to one camp, and often disdain the other.

I believe this whole conversation is based on a fallacy.

In my experience, motivated people naturally work hard — because they care, not because you told them so. When you hire talented people and give them the right amount of direction and agency, the result is... they work hard!

Working hard feels fun when people do so because they enjoy pushing themselves. It’s not fun when they do it out of fear, or to seek approval. That’s where teams crash and burn.

So the question is: have you created the conditions where people want to work hard? Or do they do it because they feel they need to?

Hard work works best as a lagging indicator — the natural output of a healthy, high-agency environment. You can’t force it upstream, but you can create the conditions for it to happen downstream.

I talked about this (and a lot more) with Greg Foster, co-founder of Graphite, in this recent piece 👇

Refactoring

How Graphite Ships 🚢

It’s a weird time for engineering teams…

Read more

5 months ago · 17 likes · Luca Rossi and Greg Foster

3) 🎙️ Strategic quitting

In August I interviewed Annie Duke on the podcast. Annie is one of the world’s top experts in decision-making and we talked about it at length during the interview.

When making decisions under uncertainty, Annie argued that one of the most important skills is quitting — yet it’s severely undervalued due to cultural associations with failure.

The core logic is simple: since we’re neither omniscient nor have time machines, we’ll always learn new information after making decisions. Sometimes this information suggests we should change course.

“What more important skill could you have than the ability to quit what you’re doing? You make a decision under conditions of uncertainty, afterwards you find out new stuff... and then you get to stop.”

People don’t quit when they should because they:

• Associate quitting with failure and lack of character

• Fear judgment from others (though research shows people actually respect good quitting)

• Fall victim to sunk cost fallacy

Annie uses the extreme example of Shavano Keith, who broke her leg at mile 8 of the London Marathon but continued running for 18 more miles despite medical advice to stop.

You can’t think your way out of cognitive biases, but you can create processes that help. Two of the most effective ideas are:

• 📋 Kill criteria — define in advance what signals would indicate it’s time to quit.

• 👥 Accountability partners — have others help enforce your kill criteria.

Annie explains that there’s a huge psychological difference between encountering a warning signal on the fly versus having pre-committed to act on that signal. The signal is identical, but your response will be dramatically different.

Here is the full interview with Annie:

You can also find it on 🎧 Spotify and 📬 Substack

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

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

Make your team ship faster!

See you next week!
Luca

Make your team ship faster!

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

❌ Stop doing work about work

This idea is brought to you by Steady!

55% of your engineering team’s time is spent doing busywork—chasing status updates, hunting for information and managing the mechanics of work.

All that work about work pulls devs out of flow, threatening focus, productivity and velocity.

The guys at Steady, who I have known for a long time (here is my interview with Henry!) have created an awesome guide for what they call continuous coordination:

• The proven system that gives teams time back

• How to increase autonomy and accountability

• Advanced techniques for reducing coordination overhead

Check it out below 👇

Get the free guide

1) 🖥️ From IDEs to CLI tools

When you open up Cursor, or VS Code with Copilot, it feels like a normal IDE with AI bolted on top.

This is obvious from the UI: 70% of the screen is traditional IDE real estate—editor, file sidebar, terminal—while the AI chat gets a column on the right.

Sure, you can tweak the layout, but the karma of the tool remains that of an IDE.

Why is this a problem? When I’m not writing code, most of this interface is noise—context I don’t need, at the expense of context I do need: what is the AI doing? What commands is it running? What’s the plan?

These two types of context are fundamentally different. I’d call the first engineer context, and the second manager context.

So, if I had to summarize the difference between Cursor and Claude Code in one line:

• Cursor treats me as an IC

• Claude Code treats me as a manager

Which leads me to this slide you may have seen on Linkedin, which made me laugh — but also reflect.

This is vibe coding via humans — also known as management. In the picture it’s not great management maybe, but management nonetheless.

In fact, the developers I know who are having the most success with AI are, first and foremost, good managers of themselves.

Now, I think CLI tools make this transition easier because they spare you from the cognitive pull of the code itself. You can still jump into your IDE whenever you need to, but the terminal keeps focus on the sequence of actions and instructions.

In other words, it defaults to manager mode, while IDEs default to engineer mode.

I have written more about this shift in this recent article 👇

Refactoring

Engineers are replacing IDEs with terminals 🖥️

Six months ago, every developer I knew who was serious about AI coding used an IDE — like Cursor or Windsurf. I know because I asked them — which is part of my fiduciary duty towards readers: I ask people how they work, so I can later write about it…

Read more

7 months ago · 43 likes · 1 comment · Luca Rossi

2) 🔨 Bring me solutions… but also problems!

I keep getting back to this article that Anna Shipman published on Refactoring at the end of last year. It’s full of small gems that I think about often.

One of them is about the cliché that execs want solutions, not problems. Like many cliches there is truth in it, but also nuance.

As an exec, I would much rather know about problems than never find out because you didn’t want to tell me without a solution, so this shouldn’t become a reason not to flag areas where your leaders should be concerned.

However, you do not want to pass all decisions up to your boss either.

You probably have great ideas about how to solve issues you see, and generating good solutions is a skill that definitely improves with practice. If you want your proposal to land, it needs to cover not just “we should solve this problem” but “and here’s one way we could do that”. It’s also useful to include some options you considered and discarded.

Your initial proposed solutions may not align with business value, but you will get feedback and learn and improve. If you never try, you will never get better and you will find you are senior and still making similar suggestions that do not get adopted.

You can find the full (awesome) piece here:

Refactoring

The Engineer → Executive Translation Layer 🔀

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

Read more

6 months ago · 27 likes · Luca Rossi and Anna Shipman

3) 🎙️ The Forest & The Desert

I keep using this analogy all the time. It was created by Kent Beck and it explains how software teams often live different realities.

Teams that work in the desert have strict processes and limited resources. There is no room for error, and everything feels unsafe and ready to kill you.

In the forest, instead, things just work. There is collaboration, flexibility, and things are built in small, safe steps. People share a clear goal and feel great about their work.

I also talked about this with Martin Fowler on the podcast last year, and he said something that stuck with me:

“It’s hard to communicate what you can do in the forest, and how fast you can move, to people who’ve never lived in that world.”

These worlds are not only different — each one hardly understands the other, which is why practices from one camp are often met with resistance and skepticism from the other camp.

Here is the full interview with Martin:

You can also find it on 🎧 Spotify and 📬 Substack

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

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

Make your team ship faster!

See you next week!
Luca

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

Join our yearly industry report and win $150! 🗳️

Once or twice a year we run broad surveys to investigate the state of some important part of software engineering. We have done that in the past with AI adoption, engineering maturity, and more.

This time we want to understand what the development process looks like for teams today! Many trends have been steering it for the past few years (AI, product engineering, devex, and more), so we would like to report an updated picture for 2026.

You can answer the survey below, it should take only ~7 minutes 👇

Answer our survey and win $150!

The questions will also make you reflect on your own process, so there is utility in that! And, as always, respondents have the chance to win one of 20 Refactoring memberships ($150 value).

1) 🎨 Generalists for product + specialists for platform

I have been thinking long and hard about the role of generalist and specialist engineers in modern teams.

When you look at what the best teams do, there is a recurring pattern:

• 📱 Generalists work on product

• 🧱 Specialists work on platform

The best way to use e.g. a senior frontend engineer’s skills is not to build yet another form, but to build the component system that empowers others. That’s 1) a higher-leverage use of their time, and 2) more engaging and rewarding work for them.

So generalists scale throughput, while specialists scale quality.

You might call one “product engineering” and the other “platform engineering”, but the two are closer than they may seem. Good platform engineering suspiciously looks like product engineering, but where your customers are other engineers.

Platform engineers do pretty much the equivalent of what the best product engineers do: they design products (tools), build things that customers want, dogfood them, and ship things from top to bottom.

I wrote more about this in this recent take on what a great team looks like today 👇

Refactoring

What does an elite team look like today? 🥇

Over the past few weeks I have been interviewing several Refactoring community members. It’s mostly people who are responsible for engineering teams — EMs, tech leads, but also VPs of small to mid-size orgs…

Read more

7 months ago · 31 likes · Luca Rossi

📋 AI docs cheatsheet

You see everywhere that AI changes documentation, what’s worth documenting, and so on. But how? Here is my cheat sheet:

• Provide business context — As humans, we often outperform AI only because we have more context into specific business nuances. These would be tedious to include in individual prompts, so provide them upfront. Hayden Miyamoto pioneered this with the Master Prompt method: a long one-pager where AI can learn everything about your company, team, and goals.

• Capture decisions — The most valuable human docs aren’t descriptions anymore (have they ever been?!), they are decisions. E.g. ADRs (Architecture Decision Records) work like append-only logs: you don’t update them when things change, you write a new decision that supersedes the old one. AI can trace this evolution and understand the current state, history, and the why behind decisions.

• Keep docs simple and close to the action — Markdown wins over complex formats. Docs in repos get the double benefit of being in the same context space and easy to update with code.

• Automate the How — Trust AI to own the implementation layer: code comments, API docs, runbooks. Enforce updating these at every commit for disciplined doc history.

• Connect AI to all your tools — Finally, knowledge is scattered across Linear, Slack, repos, and wikis. Use AI as a horizontal layer to navigate it all.

I wrote a full guide on this here 👇

Refactoring

How AI is Changing Engineering Docs 📑

Here's a thought experiment: tomorrow morning, an AI wakes up with perfect knowledge of every programming language, framework, and design pattern ever created. It can read any codebase, understand any system, and generate any documentation you ask for…

Read more

a year ago · 73 likes · 2 comments · Luca Rossi

3) 🎙️ The SCARF Model

Last October I interviewed Meg Adams on the podcast, and we talked about Neuroleadership.

Neuroleadership applies neuroscience research to leadership contexts, focusing on how brain structure and nervous system function impact thinking, feeling, and decision-making.

One of the ideas that stuck the most with me was the SCARF model, which represents five domains that our brains continuously evaluate in social situations:

• 🏆 Status — how important we feel compared to others

• 🔮 Certainty — how predictable the future feels

• 🎮 Autonomy — our sense of control over events and choices

• 🤝 Relatedness — feeling of connection and safety with others

• ⚖️ Fairness — evaluation of whether exchanges and decisions are just

“Our brains respond to social situations much like physical threat and reward. Think of how you might feel if I was holding a knife versus if I was handing you a plate of warm cookies that I made just for you.”

When these domains feel supported, our brain’s reward circuitry activates — we feel collaborative, open to change, and perform at our best. When threatened, the threat circuitry kicks in instead, limiting resources to planning and reasoning while scanning for more threats.

For engineering teams specifically, certainty and autonomy tend to be the most frequently triggered. Engineers often struggle with moving goalposts and lack of control over their time and work approach.

Here is the full interview with Meg:

You can also find it on 🎧 Spotify and 📬 Substack

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

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

Make your team ship faster!

See you next week!
Luca

Make your team ship faster!

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

🔬 AI code review with the judgment of your best engineer

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

This week I am happy to promote Unblocked, which I am a big fan of, and whose team I have been in touch with for a long time.

Unblocked is the only AI code review tool that not only has a deep understanding of your codebase — it also knows past decisions and internal knowledge, giving you high-value feedback shaped by how your system actually works.

Try Unblocked for free

2) 📋 Task context vs shared context

There is consensus today that AI works well when it has the right context. This spawned the whole context engineering conversation — RAG, MCPs, context windows, and so on.

But before we design systems around it, the big question to me is: what does good context look like? Not just for AI, for humans too.

When an engineer builds a new feature, they obviously need product specs, UI designs, and technical requirements. But imagine they’re not on your team—they’re a contractor you’ve just brought in (which is closer to what an AI is). Suddenly they need much more: Do you require tests? How do you instrument features? What about feature flags? Naming conventions?

A useful mental model separates two types of context:

• ☑️ Task-specific instructions — the what needs to be done

• 🔄 Procedures and principles — the how it should be done

In any team, with or without AI, a good north star is continuously shrinking the what and growing the how.

You don’t want to say “write tests” in every prompt or ticket—you want it to be standard practice that everyone (including AI) already knows.

So the best context system is one where developers succeed with minimal explicit instructions.

To improve on this you need to focus on inputs, not outputs. When something turns out wrong, ask: was it sloppiness, or was context missing? In my experience, it’s usually the latter.

So, good context engineering isn’t (just) about defining the right context—it’s about nurturing the feedback loop that improves it over time. For every failure, fix the output, but also go back and improve the inputs.

We wrote a full guide on context engineering late last year 👇

Refactoring

How to Manage Context in AI Coding 📑

Hey, Luca here! This is a ✨ monthly free essay ✨ from Refactoring! To access all our articles, library, and community, subscribe to the full version…

Read more

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

3) 🧱 Technical capabilities from Accelerate

These days I looked back at my notes on Accelerate, and went through the technical capabilities that the research proved to have the biggest impact on delivery performance.

It’s such an incredible greatest hits of practices. You can literally hang this on a wall and look at it every so often to think about how you are doing:

1. Version Control — keep all production artifacts (code, configs, infrastructure) in version control for reproducibility and traceability.

2. Automated Testing — reliable tests (unit, integration, acceptance) give teams confidence to deploy frequently, correlated with lower failure rates and faster recovery. See our full guide on testing.

3. Test Data Management — the most common bottleneck in reliable testing is having good test data, which requires intentional investment.

4. Continuous Integration (CI) — developers merge work into a central repository, triggering automated builds and tests to catch integration issues early.

5. Trunk-Based Development — developers work in short-lived branches and integrate at least daily, avoiding the integration hell of long-lived feature branches.

6. Continuous Delivery — main branch code is always deployable. It passes CI, gets deployed to staging, and awaits manual approval for production.

7. Continuous Deployment — every change passing tests gets automatically deployed to production. This is the aspirational goal. Note: deploying doesn’t mean releasing—decouple these with techniques like canary releases.

8. Shift Left on Security — integrate security early by automating checks in the delivery pipeline. More here.

9. Loosely Coupled Architecture — components can change and deploy independently, reducing coordination and blast radius. See monoliths vs microservices.

10. Empowered Teams — teams have autonomy to design, build, test, and deploy without excessive dependencies. As per Team Topologies.

Here is our full review and summary of Accelerate:

Refactoring

Accelerate 📗

Every two months we read a book in our community book club, read it on our own, and review it together in a lively online event…

Read more

a year ago · 37 likes · Luca Rossi

4) 🎙️ Sicily vs tech hubs

In April of this year I interviewed Salvatore “Antirez” Sanfilippo, creator of Redis and of a wealth of open source software.

It is safe to say Salvatore is one of the most gifted engineers in the world, and he made a deliberate choice to build his career from Sicily (Italy) rather than relocating to tech hubs like Silicon Valley.

In our chat, he explained that while being in tech centers might lead to greater wealth, it’s not necessary for engineering excellence:

”To be a successful software engineer, you can be everywhere, but to make a lot of money, it is much better to stay in the center of things.

For me, it was not a problem of performance, but how much money you want to make.”

He also believes that once you reach a comfortable income threshold (he mentions around €4,000/month in Italy), additional money contributes minimally to wellbeing.

So, his decision to remain in Sicily was driven by:

• Personal values — preferring Europe’s balance of capitalism and social services.

• Community connections — maintaining important relationships in his hometown.

• Quality of life — prioritizing wellbeing over wealth accumulation.

He notes that he’s seen many young people in the US who “become rich too fast” and experience a lack of purpose as a result, reinforcing his comfort with his choices.

This is one of the interviews I look back to the most often, not just for the tech part, but for the wisdom and general life advice.

Here is the full interview with Salvatore:

You can also find it on 🎧 Spotify and 📬 Substack

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

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

Make your team ship faster!

See you next week!
Luca

Make your team ship faster!

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

1) 🎙️ Reward AI skeptics

In September I interviewed Birgitta Böckeler, global lead for AI-assisted software delivery at ThoughtWorks. Her full-time work is to figure out how engineering teams can make the most out of AI!

One idea that I loved is that teams that are having the most success with AI are often approaching it with both critical thinking and ambitious experimentation.

In other words, while avoiding the extremes of (blind) faith or (complete) skepticism, they encourage and accept some version of both.

To Birgitta, the key to progressing our understanding of AI is not to sit in the right camp — of believers or skeptics — but rather to constantly produce high-quality thinking about it, in any direction.

If you have skeptics on your team, who are posing legitimate arguments, as opposed to pure prejudice, you should reward them! Someone has to play the devil’s advocate and that’s a healthy part of the exploration.

Here is the full interview with Birgitta:

You can also find it on 🎧 Spotify and 📬 Substack

2) 🎯 Precision vs Accuracy

In June last year I attended the LDX3 conference, where Pat Kua gave a great talk about delivery management.

One of the ideas that stuck with me is the difference between precision and accuracy in software engineering:

• Accuracy — is about building the right thing (meets business needs).

• Precision — is about building it consistently (on time, good quality, etc).

This distinction matters because it leads to different failure modes for teams. You may have teams that are:

• Precisely inaccurate — extremely good at executing stuff, but it’s not stuff that brings a lot of value. E.g. they are overly focused on technical work and are somewhat detached from customers.

• Imprecisely accurate — they can identify where the value is, but they are inconsistent in the delivery. E.g. they make good plans but never ship things on time, or releases often lead to big fires.

Diagnosing how your team fails is the first step towards improving.

3) 🏆 Generalists are motivated by impact (and they are right)

It’s hard to find a proper definition of what makes for a generalist.

Common traits include being proficient in many skills, being able to apply for roles across different career tracks, and regularly performing tasks that fall into different domains.

These things also exist on a spectrum. Full-stack engineers may feel like generalists, but they are arguably less so than a good friend of mine who started as a pre-school teacher, turned into customer success operator, QA engineer, and eventually engineering manager.

There is a common notion that people end up generalists because of accidental twists in their careers. It may be the case for some, but I don’t think it’s how it happens for most. The reality is we follow our inclinations more than we realize.

I have known a lot of generalists, and here is an observation: the vast majority of them are motivated by impact and the value they create, rather than building stuff for the sake of it.

This is usually the right mindset in tech.

By and large, people get promoted because of the impact they produce, not the skills they possess. And on your resume, what you helped accomplish always speaks for your skills more than anything else you can put there.

We need to avoid the trap of valuing ourselves, as professionals, by the level of sophistication of the software we craft, and instead value ourselves by the amount of value we create for the customers and the business.

Incidentally, I think that’s also what will allow us to embrace AI without restraint, instead of feeling threatened by it.

I wrote more about generalists, specialists, and AI, in this recent piece 👇

Refactoring

Generalists in 2025 🎨

About four years ago, I published an article about generalists which was part advice part self-therapy…

Read more

7 months ago · 47 likes · Luca Rossi

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

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

Make your team ship faster!

See you next week!
Luca

Make your team ship faster!

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

Brought to you by Aboard!🔺

Aboard is your partner for AI transformation. We use a proprietary AI platform to build software to help you run your business. Our software looks good, uses best practices, is highly secure, and ships in a fraction of the time it used to take.

We aren’t bots—we manage them. We keep people at the center, both our engineers and our clients. AI accelerates development, but humans step in when it matters most: to refine, polish, and launch at production quality.

Your growth matters to us. Spend less time struggling toward software solutions. We’ll save you time and money, and stay nearby whenever you need us.

Learn more about Aboard

1) 🪄 Take a small AI leap of faith

In most workflows, today, people are using AI to create drafts — drafts of code, drafts of code reviews, drafts of docs — and have humans do a final pass.

This is nice, but it also corners people into doing a lot of context switching and micro tasks.

I believe that sometimes, under controlled conditions, we should take a leap of faith and completely automate some tasks with AI.

We should switch from an “approve first” to a “possibly revert later” approach.

Ask yourself: what are those things that AI can do that would be relatively inexpensive to revert in case it does them wrong? Chances are it’s more than you think.

2) 📱 Fragmentation testing journey

Earlier this year we wrote a thorough guide on mobile fragmentation testing.

A key theme was that your approach to fragmentation should evolve alongside your product and team journey: applying enterprise-level rigor to a pre-PMF product wastes resources, just as neglecting testing at scale is a recipe for disaster.

We tried to map your fragmentation strategy to each stage, so here is the cheat sheet:

Zero-to-One 🌱

Focus: Speed, iteration, validating core hypotheses.

Your device “matrix” is likely just the founders’ phones plus a couple of emulators for basic layout checks. Testing is manual and happy-path only: does the core loop work? Can users sign up? Automation is probably overkill.

Risk tolerance: Very high. The bigger risk is building the wrong product, not having a polished app on every device. Don’t let fragmentation concerns slow you down.

Finding PMF / Early Growth 🪴

Focus: Stabilizing core features, growing users, understanding segments.

Use analytics to identify your top 5-10 devices and OS versions—this becomes your evolving matrix. Testing is still manual but more structured. Consider automating 1-2 critical paths (e.g. signup, purchase) if you have expertise. Cloud device services become useful for occasional checks on devices you don’t own.

Risk tolerance: Medium. Core functionality on popular devices must be solid.

Scaling / Established Product 🌳

Focus: Reliability, performance at scale, protecting brand reputation.

Maintain a well-defined, multi-tiered matrix updated with fresh analytics. Invest significantly in UI automation for regression testing. Rely heavily on cloud device farms, potentially supplemented by an in-house lab over time.

Risk tolerance: Low for Tier 1 devices, higher for Tier 3.

You can find the full guide below 👇

Refactoring

How to Test Mobile Apps 📱

Mobile apps are the primary interface through which hundreds of millions of people interact with services daily…

Read more

a year ago · 38 likes · Luca Rossi

3) 🎙️ Managers need to be more hands-on

In May I interviewed Rands, Senior Director of Engineering at Apple and writer of several popular books about engineering management, including “Managing Humans”, which is a personal favorite of mine.

I asked him how engineering management is changing today, and the first thing he noted was how the pace of change dramatically increased. With respect to a decade ago, where management felt more like a timeless skill, today it feels harder for individuals and teams to adapt and learn new playbooks as quickly as tech evolves.

For this reason, Rands now believes engineering leaders should stay deeply connected to tech, reversing his earlier stance that managers should step away from coding.

His preferred org structure, however, remains consistent:

• 👥 7±3 direct reports — optimal span for providing meaningful human attention to each team member.

• 📊 Three layers maximum — from CEO to individual contributor for effective communication.

• 🤝 Small, empowered teams — avoiding the bureaucratic layering that characterizes large tech companies.

“I truly believe that a manager or leader is capable of managing about seven plus or minus three folks... more than that, and you do not have time for humans.”

And speaking about AI, rather than changing what ideal teams look like, Rands believes it’s making already-optimal team structures even more effective.

Here is the full interview with Rands:

You can also find it on 🎧 Spotify and 📬 Substack

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

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

Make your team ship faster!

See you next week!
Luca

Supercharge your tech career 🚀

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

1) 🌱 Review your notes weekly

Most people who know me are aware I’m a note-taking nerd. And as a full-time writer, I am afraid I’ve become even more insufferable about it.

I usually avoid giving specific advice—everyone should find the tools and workflows that work for their life. But there’s one thing I recommend to everyone: do a weekly review of your notes to 1) organize them, and 2) trash what doesn’t deserve long-term storage.

During the review, I go through everything I captured that week. The key is separating reviewing from capturing and processing everything at once. When you do this, interesting things happen:

• Many things that seemed interesting days ago no longer do. I delete over 60% of what I capture.

• When you’re in “organization mode”, you find more connections and work faster than doing it hastily on the spot.

• It becomes a genuinely pleasurable activity—like a mini time capsule where each idea feels like a rediscovery.

I also use this time to clear email, DMs, downloads, and tasks—everything that piles up during the week—so each Monday starts with a clean slate.

If you set personal goals, it’s also the perfect time to check progress and plan your next actions.

The weekly review is by far my most important routine. I talked more about it (and my whole note-taking nerdiness) in this recent article:

Refactoring

How To Take Notes 🌱

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

Read more

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

2) 🔨 Explore → Embrace → Empower

In October we released our biggest industry report ever, about the state of AI adoption in real-world engineering teams.

We connected the dots about how 400+ teams use AI, and we came up with a three-step process: Explore → Embrace → Empower

🌱 Explore

Adoption begins with personal exploration—engineers getting familiar with AI tools and their ergonomics. This is largely bottom-up. Managers can encourage it by providing tools without performance expectations, identifying champions, and creating knowledge-sharing ceremonies.

Early wins include small automations, AI-written features, minor refactoring, and more docs and tests.

🪴 Embrace

Once basic proficiency exists, graduate AI usage into team practices: AI doing first-pass code reviews, better testing and documentation standards, improved meeting summaries.

Critically, these must become actual standards— e.g. if AI makes testing easier, enforce tests in PRs. Some things might feel risky, but if it doesn’t feel risky, is it real change?

Create feedback loops through retros and 1:1s to continuously tweak what’s working.

🌳 Empower

What do we do with the residual capacity AI creates?

The best teams use it to expand people’s scope—engineers going full-stack, PMs creating prototypes, designers trying frontend. Benefits include reduced coordination costs, higher velocity, and stronger growth.

AI keeps improving, so we keep adapting. Let’s get to work!

You can find the full report below 👇

Refactoring

The State of AI Adoption in Engineering Teams 📊

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

Read more

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

3) 🧠 Create mode vs Review mode

Beyond productivity gains, I’ve been paying attention to how using AI makes me feel about doing work.

And the concerning part is I often feel... dumber. Or more precisely, less engaged — my brain enters a lazier mode that’s hard to steer back.

I call it create mode vs review mode:

🎨 Create mode

Create mode is when you produce output through some non-obvious process—writing an algorithm, or an essay, or an important email.

You make connections between ideas and turn them into something new. It feels draining but rewarding, like a workout. Every time you create these connections, you’re rewiring your brain, improving your mental models.

🔬 Review mode

Review mode is when your brain compares a draft against rules about what it should look like and improves it.

It feels 10x cheaper energy-wise, and I feel as humans we’re genuinely good at it — spotting details and steering output tactically.

But review mode has limits. Most critically, it’s hard to radically change course once you have a draft. The draft becomes an anchor. Daniel Kahneman, in Thinking, Fast and Slow called it the anchoring bias, and provided a hilarious example 👇

In an experiment, Kahneman asked participants to estimate the percentage of African countries in the United Nations. Before answering, they spun a wheel that landed on either 10 or 65. Those who saw 10 guessed an average of 25%, while those who saw 65 guessed 45%. The initial number, despite being random (and they knew it!), significantly influenced their estimates.

I feel this is the trap with AI assistance. Having a first version in front of you restricts what you can create yourself. There’s a mix of anchoring, sunk cost, and genuine laziness that kicks in.

So what’s the solution?! I explored some heuristics in this recent article 👇

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

8 months ago · 75 likes · 14 comments · Luca Rossi

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