Field notes on AI-assisted development, observability, delivery systems, and the engineering-leadership decisions underneath them.
Managing AI coding agents, and agents that direct other agents, is structurally the same job as being an engineering manager, a director, a VP, or a CEO. You give high-level direction to autonomous workers, and you operate through systems and outcomes instead of inspecting every artifact.
Horizontal code agents are running on VC-subsidized tokens. Vertical agents are paying sticker price. If you're building one of the latter, you have a problem to solve, and "we have a better prompt" isn't it.
Companies picking an AI plan almost always frame it as a budget question. Which tier gives us the most usage for the money? It's the wrong question.
Every agent company hires from the same labor pool. You and your competitor employ literally the same workers: the same frontier models, refreshed quarterly by the same vendors. Raw capability is identical by construction.
We still assign a human reviewer to every pull request. The human opens the diff, scrolls, approves. That ritual is already dead. Most teams are just propping up the corpse.
The most valuable thing I do as an engineer right now isn't writing code. It isn't even reviewing code. It's building the harness that lets the agent verify its own work before it asks me to look at it.
The thing nobody talks about with AI-assisted development isn't the models. It's the cycle time. The agent's iteration loop got longer, the right way to work changed, and most people are still working as if the loop is two seconds long.
My laptop is a four-year-old Dell XPS 15 with 16 gigs of RAM. Fine for normal work. Not fine for running Windows, WSL, a real codebase, a Claude session, and a browser at the same time.
I haven't written a Linear ticket by hand in six months. I don’t write the majority of my Claude prompts. The two stopped being separate things. The ticket is the prompt.
AI did not make the whole software delivery system faster.
I've been rebuilding one of my Claude Code workflows because the old version was too linear.
Your engineering team adopted AI coding tools six months ago. Deployment frequency is up. Lead time is down. PRs are flying through the pipeline. Everyone feels faster.
You're four steps into an AI agent workflow. Steps one through three went perfectly. Step four goes sideways. So you start correcting.
Three AI agents. Three different problem contexts. Each time, the solution emerged with the same architecture.
AI is forcing software development back to first principles. The practices most teams abandoned as overhead, specs, formal verification, architectural review gates, are becoming essential again the moment humans stop reading every line of code.
The distance between what you meant and what the AI produced, and why no refactoring pass can reverse it.
AI-generated tests pass. That's the problem.
The software development lifecycle isn't dead. It just lost its center of gravity.
Not every repetitive task is worth automating. Some tasks feel tedious but resist automation because they require subtle judgment at every step. Others feel complex but are actually just long sequences of mechanical steps.
I've written before about personalized software as the hidden iceberg of the AI era. Software that was never economical to build, but that people genuinely want. I keep coming back to this idea because I keep building more of it.
People are building incredible things with AI coding tools. Custom applications, full-stack prototypes, automation pipelines. But there's a quieter, equally powerful use case: using Claude Code as an operational partner.
Most AI adoption failures share the same origin story: someone tries the hardest possible task, it fails spectacularly, and they declare they'll "come back next year." This happens constantly because teams lack a mental model for sequencing adoption.
SaaS companies are all AI companies these days. How deep does does that AI integration really go, though?
Every unit of work in a data processing system should aspire to be small, independently processable, and consistently sized. When these three properties hold, scaling becomes almost trivially simple.
Batch processing architecture has a clean pattern that scales elegantly: decouple batch systems asynchronously from everything else.
When designing data platforms, I frequently encounter teams trying to build one unified system that handles both real-time streaming and batch analytics.
Everyone has opinions about candidates. That's the problem.
Everyone's worried about AI replacing engineers. The more interesting question is what happens when the cost of building software drops so dramatically that entirely new categories of software become viable.
Every small organization has gaps. Maybe you have an engineering lead but no dedicated DevOps team. Maybe your product manager is stretched thin and the tech lead is absorbing PM responsibilities. Maybe a designer role is emerging, but nobody owns it yet.
Every engineering blog paints a picture of clean microservices, continuous deployment, and comprehensive observability. I've been in this industry for over a decade, and I've never experienced this ideal state across the board. I've seen glimmers. Teams that nail one dimension.
Most architecture discussions devolve into abstract debates about microservices, monoliths, and database choices. After years of explaining these concepts to engineers and product leaders, I've found that thinking about software architecture like a physical
The two-minute deploy is killing my productivity.
Most engineering teams waste weeks solving the wrong problems.
Every sprint plan will go sideways. Every project timeline will hit unexpected problems. This isn't pessimism. It's pattern recognition from years of leading engineering teams through hundreds of delivery cycles.
Engineering teams have always made judgment calls about risk and speed. With AI development tools becoming standard practice, that judgment call has gained a new dimension demanding more careful consideration.
In cycling, the pain doesn't decrease as you get better. You just get faster.
This is one of my saltier posts. You've been warned.
Having too many alerts that drive everyone insane is still better than having no alerts at all. I've complained about alert fatigue plenty of times before, but here's the uncomfortable truth: that statement is completely backwards.
Successful monitoring platforms rest on a fundamental principle that many teams overlook: the format of a page should be determined by who you expect to be there and what job they need to accomplish.
Enterprise customers love asking for on-premises deployments. The contract values look irresistible: 2-5x your standard SaaS pricing, multi-year commitments, and the validation that comes with enterprise logos.
Every engineering leader has lived this nightmare: two days from deadline, the team discovers the core architectural assumption doesn't work, the third-party API is missing critical functionality, or the algorithm can't handle production scale.
I've written before about the importance of keeping work discussions in public forums: Slack channels, JIRA tickets, shared docs, anywhere that's searchable and accessible. If it's about work, other people probably need to know about it.
Engineering leadership's most expensive monitoring decision isn't choosing the wrong tool. It's falling into the monitoring trap that costs organizations in wasted engineering time and preventable downtime.
Through managing teams across multiple clients, I've observed that engineering productivity isn't just about technical skills. It's about recognizing that different engineers thrive under different working conditions.
You promote your best engineer to team lead. Three weeks later, productivity has tanked and people are frustrated. Sound familiar?
Most teams focus on faster incident response. The real solution is preventing incidents from happening in the first place.
I'm a zero inbox person. Empty to-do lists, cleared Slack notifications, organized email. You know the type. So naturally, I wanted my AI tool chats to be empty too.
Everyone's trying to get better AI output by tweaking prompts. They're optimizing the wrong variable.
As engineering teams grow from 5 to 50+ people, leadership responsibilities naturally expand beyond what any single person can effectively handle. Yet many organizations struggle to identify exactly what types of leadership they need to scale successfully.
Traditional war games work great for single teams. But what happens when you have three subsystem teams, a dedicated SRE group, and multiple stakeholders who all need to respond to incidents together?
I had this beautiful dream once. We'd have perfectly structured JIRA tickets with clear requirements, a proper hierarchy of initiatives and epics, success criteria defined upfront. Everything an engineer could ever want.
Every AI conversation starts the same way: explaining context you've already explained dozens of times before. "I'm working on a product that does X, my team structure is Y, and I need help with Z." By the time you finish setting the stage, you've burned half
Time management lives alongside prioritization and communication as the foundational skills for being an effective team leader. Team leads (alongside everyone else in most organizations) have more work than they can handle, so what work should they do and when?
How long do you spend talking about your burndown chart during your sprint retrospectives? Burndown charts tell you so much more than if you finished all the work in the sprint or not. From these charts, you can learn:
Slack Analytics are a powerful tool for understanding the way your company communicates. How and where your team chats is a pillar of your overall team communication structure. Conway’s Law states the following:
In any company (small companies especially), it’s easy for leaders to get busy. Rushing between planning meetings, standups, retros, and one-on-ones, then trying to squeeze in some dev work as well.
When I was a backend team lead, I would sometimes jump in and help during sprints by writing code or diving into operations. Occasionally I would even be the best person for the job because I had domain knowledge for that service or sub-system.
I like to joke that every problem, at its core, is a communication problem.
Here’s a bit of a paradox: the better you are at solving SaaS production incidents, the harder each incident is to solve.
A little excitement in your job is usually a good thing. It could be learning a new development language, preparing to release a new feature, or taking on new responsibilities as part of a promotion. That’s great for most jobs, but not operations.
When I started my development career, I thought I was hired to write feature code. What else is there to building a product? I only now realize how wrong I was.
Over the last two articles (SaaS War Games - Part 1 and SaaS War Games - Part 2), we dove into the value of War Games. In this article, the rubber meets the road on how to run one.
This article builds on SaaS War Games - Part 1, so I recommend reading that article before diving into this.
It’s 3 AM and your phone is ringing. There’s only one number you let ring through your Do Not Disturb settings. You open one eye and look at the first of 12 on-call notifications.