Hey, Luca here, welcome to a weekly edition of the💡 Monday Ideas 💡 from Refactoring! To access all our articles, library, and community, subscribe to the full version:
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.
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 👇
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:
Version Control — keep all production artifacts (code, configs, infrastructure) in version control for reproducibility and traceability.
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.
Test Data Management — the most common bottleneck in reliable testing is having good test data, which requires intentional investment.
Continuous Integration (CI) — developers merge work into a central repository, triggering automated builds and tests to catch integration issues early.
Trunk-Based Development — developers work in short-lived branches and integrate at least daily, avoiding the integration hell of long-lived feature branches.
Continuous Delivery — main branch code is always deployable. It passes CI, gets deployed to staging, and awaits manual approval for production.
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.
Shift Left on Security — integrate security early by automating checks in the delivery pipeline. More here.
Loosely Coupled Architecture — components can change and deploy independently, reducing coordination and blast radius. See monoliths vs microservices.
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:
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.
See you next week!
Luca