Great list of resources here by Pete Steinberger:

These resources will help you master the new paradigm of AI-assisted development, where agents become true collaborators that can handle entire codebases and ship production features. Each piece was chosen for its practical, real-world insights.

I especially appreciate that it’s a combination of articles (yay!) and videos (not for me!), and that he provides a nice overview of each so you can decide if you want to click through or not. Excellent curation, would recommend!

Read Essential Reading for Agentic Engineers ↗

Great advice here for new managers in this wild time we find ourselves in. In general:

Whereas the previous focus of managers was to rapidly hire and scale their teams, today’s focus is on expanding impact. This is because in today’s macroeconomic environment, output is key. In the eyes of a 2025 company, the more that you can do with fewer people, the better. There are very few additional people to go around, so the focus is on how you can help your team do more with less.

James focuses specifically on EMs, but the advice definitely applies to PMs too, so check out his post if this is you!

→ New advice for aspiring managers

I’ve been thinking about engineering estimates a lot and need to write about it. But for now, Adam Keys sums it up nicely:

Everyone knows surprises will happen. The estimate should help the team make better decisions when they do, not box them into promises they can’t keep. The best estimates I’ve given weren’t the most accurate—they were the ones that helped teams navigate uncertainty instead of pretending it away.

→ On estimates as navigation, not promises

Great tip!

Convert GitHub repos to markdown with repo2txt, drag into Google AI Studio, and ask questions. Gemini’s massive context window makes it amazing for code comprehension.

The rest of the article goes into Peter’s AI coding workflow. I’ve mostly been using ChatGPT o3 for spec creation, but this is another compelling alternative.

→ My AI Workflow for Understanding Any Codebase

I know we’re drowning in vibe coding stuff right now, but this extensive post about shipping code with Claude is a fantastic resource. Great prompt rules and tips, and also solid advice for what the humans are for…

Your role as a senior engineer has fundamentally shifted. You’re no longer just writing code—you’re curating knowledge, setting boundaries, and teaching both humans and AI systems how to work effectively.

Lean management and continuous delivery practices help improve software delivery performance, which in turn improves organizational performance—and this includes how you manage AI collaboration.

→ Field Notes From Shipping Real Code With Claude

I love this take on the “10x engineer” phenomenon. Ubuntu (the African concept, not the operating system…) strikes again. “I am because you are.”

Individual engineers don’t own software; engineering teams own software. It doesn’t matter how fast an individual engineer can write software. What matters is how fast the team can collectively write, test, review, ship, maintain, refactor, extend, architect, and revise the software that they own.

→ In Praise of “Normal” Engineers

I like this idea from Lorin Hochstein about focusing more on the almost-incidents in our products:

Because most of our incidents are novel, and because near misses are a source of insight about novel future incidents, if we are serious about wanting to improve reliability, we should be treating our near misses as first-class entities, the way we do with incidents.

I imagine that a culture of “post near-incident reviews” could be really beneficial for the resiliency of our products—and our ability to predict and avoid some of the really catastrophic incidents.

In Code shufflin’ Robin Rendle writes about why he, as a designer, still messes around with coding projects. I think this is why I continue to obsess over my side project as well—and proactively reach out to indie devs who use the Cloudflare platform to see if I can help.

I’d forgotten what it feels like not to ask permission for changes and instead make pull requests and break things. There’s a momentum to this sort of work that I crave deep down in my bones because it doesn’t rely on meetings or six months of quarterly planning or going up the chain of command. And what I love most about shuffling code around is that every day there’s progress, every day there’s a tiny degree of success you can point to.

James Stanier has a good argument for why deadline-driven development is so… difficult:

Given that non-technical people don’t understand why software is hard, dates become the stick that they beat you with when you don’t deliver on time. Don’t ask me why, it’s just human behavior. I’m sure you’ve done it when roadworks have taken longer than were specified on the sign, or if a delivery of a package was late. Dates mean something to people, so handle them with care. In fact, perhaps we could do something entirely different instead.

What’s the “something different”?

So, instead, you should take a forecasting approach that follows the uncertainty curve that we outlined above. You start wide, and you taper in. At the beginning of a given project, you might even just have the year that you’re aiming to ship. Then, as you progress, you can start to narrow it down to a quarter, then a month, and finally a specific date.

This is why I will always advocate for time horizon roadmaps.