Starting vs finishing, product engineering, and weeklin readings! 💡
Hey, Luca here! Welcome to a new edition of the 💡 Monday Ideas 💡 — ideas and readings to start the week on the right foot. This newsletter is brought to you by Eltex!

Hey, Luca here! Welcome to a new edition of the 💡 Monday Ideas 💡 — ideas and readings to start the week on the right foot. This newsletter is brought to you by Eltex!
*Hey, Luca here! Welcome to a new edition of the *
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.
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 👇
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 👇
Finally, here are the best articles I have read this week:
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 :)
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.
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
Send this story to anyone — or drop the embed into a blog post, Substack, Notion page. Every play sends rev-share back to Refactoring.
We’ve simplified responses to 👍 / 👎. Past comments are archived but no longer visible.