*Hey, Luca here! Welcome to a new edition of the *
I also publish an original essay every Wednesday. Here is the one from last week in case you missed it:
This week’s newsletter is brought to you by our friends at Blitzy!
Coding agents have sped up individual tasks, but they haven’t solved the coordination, validation, and handoffs that determine how quickly software ships, especially the enterprise one!
Tomorrow join Sid, CTO and co-founder of Blitzy, for a live session on what changes when a system can hold context across an entire codebase—not just a single file or function.
He’ll walk through a real project in Blitzy, covering reverse engineering, tech spec generation, the Agent Action Plan, code generation, and PR Review, including where human review gates the process. There will also be a Q&A at the end 👇
Out of the various interviews / case studies we did last year, one of those that aged better is the one with Greg from Graphite.
I think it’s because we talked very little about tech, and more about values and culture. In particular, Graphite is obsessed with building a team where engineers have high agency.
What does a high-agency engineer look like? For Greg, it’s someone who owns problems end-to-end, which allows for:
More productivity— less back-and-forth, less waiting, less “that’s not my job”.More fulfillment— people who have real impact stay engaged, grow faster, and stick around longer.
High agency, though, it’s not (only) a personal trait — it needs to be enabled by your team environment. For Greg, at a team level, agency comes from three things:
Purpose— a clear vision of where you are going and why it matters.Permission— freedom to go after big things, make decisions, and occasionally get things wrong.Simplicity— cognitive load low enough that ownership feels like a superpower, not a burden.
To make this happen, for example, Graphite is extremely light on product management: a couple of PMs for 30+ engineers. Engineers need to fill the gaps: talk to stakeholders, prototype, dogfood, and push work forward without waiting to be unblocked.
To be honest, they also have an unfair advantage: they build a dev tool, so their engineers are their users. Which means product intuition comes for free.
But for everyone else, the principle holds: get engineers closer to customers. The difference is you have to invest more intentionally about it:
Bring engineers to customers— sales calls, user interviews, support escalations. First-hand experience and empathy beats summaries.Make context accessible— record calls, share clips, pipe tickets into Slack.Dogfood relentlessly— even if the product is not “for” engineers, find ways to make them use it.
I wrote a full case study about how Graphite ships 👇
Greg’s story made me think about my interview with Austen McDonald, former hiring committee chair at Meta, and author of Mastering Behavioral Interviews, where we discussed how AI is reshaping how engineers get assessed.
Austen recommends evaluating AI skills in both technical and behavioral rounds, but the questions should be different. In behavioral interviews, stories are king. So you may ask something like “Tell me about a time you used AI and it didn’t work out.”, instead of abstract prompts like “How do you think about AI?”
But the strongest predictor is not current AI usage at all. It is growth signal: is this person staying on top of industry trends, running side projects, adapting when the ground moves? This has always been important, but now more than ever.
“The most important thing about this person is not how they use AI right now, but how they are going to be adapting to using AI as the landscape changes.”
Austen particularly focuses on ownership. As AI handles more of the stack, “full stack” expands toward more areas of the business: customers, go-to-market. Does the candidate reach for more end-to-end ownership? Are they willing to do so?
You can find the full conversation with Austen here 👇
Finally, here are the best articles I have read this week:
Jeff shares a great message from a developer who once got through a dangerous deployment because strangers on Stack Overflow chose to help him. An LLM could have provided the same (or a better?!) answer, but not the feeling that somebody cared. We need that reminder!
A dishwasher is slower than washing plates by hand, but we don’t care, because it still frees up our time. Clemens uses the same frame for AI: give it small, annoying tasks off the critical path, then care more about reliable completion than raw speed. I liked this a lot.
Thoughtworks shares its collection of good defaults. Their approach is to have defaults remove recurring friction, but without becoming dogma. Start with practices that usually work, adapt them to the context, and review them as the environment changes.
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
