*Hey, Luca here! Welcome to a new edition of the *
If you are finding this newsletter valuable, subscribe to the full version!
Learn more about the benefits of the paid plan here.
Today’s newsletter is brought to you by our friends at Augment Code!
Most engineering teams are using coding agents today, but many aren’t seeing the productivity gains they expected. Developers are moving faster, but work still gets stuck in planning, review, and deployment.
Our friends at Augment Code put together a new guide that looks at how teams can move past the plateau by building a software factory one loop at a time.
It includes practical examples for PR to merge, ticket to PR, and alert to resolution, plus the foundation those loops need to work at scale.
Check it out below 👇
When people talk about AI being “smart”, they usually mash two skills together.
Knowledge— is what you should know about the problem domain.Reasoning— is applying that knowledge to the task in front of you.
AI already knows more stuff than any person ever will, while I find that people are still better at the actual reasoning. Most work needs both, so it’s easy to get sloppy about which one you hand off.
My heuristic is: outsource the knowledge, protect the reasoning.
So I ask myself: am I using AI because I genuinely do not know something, or because I do not want to think it through myself?
I feel that looking up things I do not know is ok. I even learn some of them as a byproduct. But using AI as a thinking partner, every time, is where my “cognitive workout” disappears, and I fear that some of my brainpower atrophies.
Also this is not black or white. Some days I have more work to do than energy, and letting AI cover a piece I would have skipped anyway is a good call. I just try to keep the part that actually trains my brain.
One thing that works for me: I write the first draft myself, then ask AI to produce the same artifact from scratch, without looking at mine. That flips the usual anchoring. I keep the reasoning, and I still get AI’s wider knowledge as a second pass. AI is also pretty bad at disagreeing with you, so a blind rebuild beats “please review this.”
I wrote more about this in the full piece 👇
In my recent conversation with Anush Elangovan, VP of AI Software at AMD, he said something that stuck with me: at this moment in history, because of how fast things are changing, you cannot stay one layer away from the work. You need to be in the trenches and understand how such work... works.
Anush has generated more code in the last four months than in the previous four years combined, and he is a VP. His target is 40% of his time hands-on, usually starting around 9:30 PM after the day job and family time are done.
Reading articles and forming opinions is fine, but you also need to get the ground truth by yourself.
So, instead of scheduling four status meetings to understand a problem, he can hook it up to Claude Code, spend three to five hours debugging, and come back with a concrete assessment plus a unit test that, if passed, would fix the issue. A few hours with the actual problem replaces a week of coordination.
If your job is to make the team faster, some of that speed has to come from you still knowing what the work feels like.
You can find the full conversation with Anush here 👇
Finally, here are the best articles I have read this week:
An ordinary apartment is full of things that used to be miracles: electric light, clean water, refrigeration, vaccines, anesthesia, washing machines, instant communication. Each one was once astonishing, or unavailable to almost everyone. A great reminder to be grateful for all the small things we stop noticing everyday.
Recently I wrote about how finishing a project seems to have become the hardest part of it. That last stretch is where scope creeps, energy drops, and human reviews bottleneck everything. In this great article, James argues that landing is a skill. You plan for it the same way you plan for the start, especially now that AI makes kicking things off so cheap.
Instead of asking an LLM to explain a hard topic, Laurentiu asks it to build a little simulation of it, like a low-poly Rollercoaster Tycoon for a chip fab. I loved this! You learn by poking at a model of the thing, which I like more than asking for a summary.
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
