Starting vs finishing, product engineering, and weeklin readings! 💡
Monday Ideas — Edition #220
Hey, Luca here! Welcome to a new edition of the 💡 Monday Ideas 💡 — ideas and readings to start the week on the right foot.
📖 42: The AI Builder’s Stack
This newsletter is brought to you by Eltex!
The guys at Eltex run a great engineering studio and just released 42: The AI Builder's Stack, which is the practitioner's guide to the toolchain they run on: Claude Code, MCP, agents, AI IDEs. They covered what worked, what failed, and what the vendors will not tell you.
The book includes a companion Claude Code setup that is free and MIT-licensed: 42 subagents, rule packs, and a commit guard that blocks force-pushes and staged secrets. Trimmed versions of every chapter are free to read.
“A hands-on guide that speaks the language of real developers building real systems.” — Richard Cave, ex-Apple Engineering Manager.
🏁 Starting is easier and finishing is harder
AI makes it incredibly easy to start more work.
Engineers are opening more branches, touching more PRs, and getting to something that looks close to done much faster than before.
But shipping is another story.
In the Faros report I covered recently, the most interesting pattern was how AI made the last mile worse: teams have a lot more stalled work, more restarts, and often times… fewer deployments overall!
This shouldn’t be surprising if we look at the classic WIP equation:
Lead Time = Work In Progress / Throughput
So if AI increases WIP but throughput stays the same, the system just accumulates more unfinished work.
To avoid getting stuck in this, we should inspect our dev process as a whole, measuring how much more valuable work actually reaches users. Otherwise, we may just be making the queue longer.
I wrote more about this in the full piece on the acceleration whiplash 👇
🔺 Product engineering is the ceiling
If your team already has good DevEx and good AI workflows, building things gets faster. But that still does not guarantee you will ship a lot more valuable work, because engineers spend only a small slice of their week actually writing code.
The rest is coordination: meetings, waiting, handoffs, status updates, and all the small negotiations that happen before something reaches users.
So, to unlock more time (and more gains) we should ask ourselves: can an engineer spend more time coding and less time coordinating? Which pretty squarely translates into: can one engineer own a larger slice of the product loop? This is what product engineering is about.
Not every engineer should and will become a PM and a designer at the same time, but if they can safely own more context, make more local decisions, and move with fewer handoffs, the whole system becomes lighter.
Also, to make it work, product engineering requires infrastructure available to everyone: product context, design platform, tight feedback loops to intercept mistakes, and in general tooling that makes this broader ownership easy and safe.
We should continuously strive to reduce the coordination tax that keeps good work stuck between roles.
I wrote more about this in the full piece on the new pyramid of software engineering 👇
3) 📚 Weekly Readings
Finally, here are the best articles I have read this week:
🥇 The Conductor Developer
4 min • by Rachel Laycock
Rachel is CTO at Thoughtworks and has a good frame for what AI is doing to software development. The developer becomes more like an orchestra conductor, who needs to keep the whole system in their head while many agents play different, specialized parts. This feels directionally right to me, which makes me forgive that the article itself feels a little bit AI-generated :)
🥈 LLMs Reward Expertise
4 min • by Sean Goedecke
Sean’s take matches my own experience: when working with AI, the better you know the domain, the better questions you can ask, the harder you can steer the model, the faster you can spot weak answers, and so on. In other words, AI massively rewards expertise.
🥉 Don’t Be a Meat Proxy
1 min • by Niklas Gruhn
If you use AI in a team, your job is to read, check, compress, and contextualize what AI gives you, before you pass it on to other people. Otherwise, people might as well talk to the model directly.
And that’s it for today! If you are finding this newsletter valuable, subscribe to the full version!
1700+ engineers and managers have joined already, and they receive our flagship weekly long-form articles about how to ship faster and work better together! Learn more about the benefits of the paid plan here.
See you next week!
Luca