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
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.
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 👇
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.
See you next week!
Luca