AI Speeds Up Execution, Not the System Around Itee40c71

A developer leaves standup with a ticket and comes back the same day with an implementation, a migration plan, and three pull requests; a year ago that was a week of work. AI made execution dramatically faster, but most teams are not bottlenecked on execution. They are bottlenecked on planning and validation, and AI does little for either by default. Speeding up the middle of the delivery system just backs the work up at review, testing, and deployment. The fix is to improve the whole loop, not only the part that writes the code.

The Real Cost Tradeoff Between Serverless and Hosting2518763

We only pay when it runs, says one team; this instance is cheaper at volume, says the other. Both can be true, and both can lead to bad decisions. The real tradeoff is not serverless versus servers, it is utilization efficiency versus economies of scale. Serverless makes waste visible as usage; hosting hides it as idle capacity. The cheapest system is the one whose cost model matches the shape of the workload and the maturity of the team operating it.

Don't Triage at the Customer's Expense4f0391c

Production is broken, engineers are on a call, and every few minutes a voice says "we think we're close." Everyone is busy, nobody is lazy, and the customer is still broken. Once a defect is in production, the customer should not become part of your debugging environment. Triage that feels like progress, more logs, another build, often just means the customer keeps absorbing the failure while engineering looks for certainty. The mature move is to stop the bleeding first, then diagnose.

Work Yourself out of a Job42e5e3e

I am the only one who knows how to do this. It is not the flex people think it is; most of the time it means part of the system only works because you are standing next to it. Working yourself out of a job does not mean making yourself useless. It means removing the broken, fragile, one-person-dependent parts of your work so the system no longer needs babysitting. The best engineers do not protect a little kingdom of broken things. They make the kingdom unnecessary, and earn their way into bigger problems.

Boring Software1377668

The demo worked, the team hit the date, and everyone felt good for about thirty minutes. Then the support tickets started. Boring software is not dull to build, it is uneventful to operate. The thing you ship can be clever and satisfying, but running it in production should be routine: practiced rollbacks, clear ownership, and no reliance on heroics. That kind of boring is engineered, not accidental.

Why Long-Running Branches Are a Tax on Everyone Elsed3c312f

I started writing software before source control was a given: you found out who changed a file by asking around. Git made creating branches cheap, but it never made integrating them cheap. Long-running branches feel productive for the developer who opens them, but the cost lands on everyone else through delayed integration, hidden assumptions, and uncertainty that surfaces right before a release. Trunk-based development is less a trend than the natural consequence of taking CI/CD seriously.

Cost-Adjusted Software Engineering269fda0

Somewhere in most codebases there is a clever abstraction that saved three days of development and has been collecting interest ever since. Cost-adjusted software engineering judges work by the value it creates against the full cost of building and operating it, not just whether it shipped. You can pay up front through testing, CI/CD, and clear ownership, or pay forever through incidents and rework.

Start Here: The System After the Code Shipse9e8d07

Every software system exists twice: once as what the team believes it built, and once as what shows up after it ships. This blog lives in the gap between the two. Notes on ownership, deployment, operations, and the human layer underneath. Most architecture problems are really ownership problems.