AI does not make you better by itself. It makes you faster, which means it amplifies whatever is already there: good engineers get leverage and bad habits get velocity. The first draft was never the expensive part, because knowing whether it is right, fits the system, and can be owned in production is the real work. AI rewards clear thinking and exposes vague requirements, and it never transfers accountability. The model did not merge the pull request. You did.
There is a comfortable story going around: AI writes garbage, invents things, and produces slop. It is convenient because it lets us blame the new tool instead of the old system. But most AI slop is human slop with a faster feedback loop. The instructions were thin, the standards were tribal, and the architecture lived in one senior engineer's head. AI just stopped letting us pretend the process was ever clean. Write the standards down and the AI gets better. So do the humans.
The easiest mistake in engineering is assuming the person before you should have known better. A strange workaround, an awkward abstraction, a manual deploy step: sometimes the work really is careless, but a lot of the time it is context you do not have. Before criticizing a design, walk a mile in the author's context, then fix what is still broken.
Context switching is real, but it is not the disease. The cost of interruption is a symptom of a deeper problem: we build software delivery around fragile human memory, where the engineer is the only place the working model of the system actually lives. AI raises the stakes by quietly turning individual contributors into orchestrators of small AI teams, which means even more context to carry. The fix is not heroic focus, it is durable context that lives in the system instead of in one person's head.
A dark factory runs with the lights off because the machines do not need people on the floor. Applied to software, a fully autonomous delivery system is not practical for most teams, but it is a useful forcing function: pretend the system had to run without constant human intervention, and ask where it would break first. Wherever it breaks is where your delivery still depends on undocumented judgment, unclear ownership, weak tests, fragile deployments, and rollback plans nobody has practiced.
Most teams that say they want CI/CD really just want the deploy button to hurt less, so they reach for CD first. That is the wrong order. The first problem is CI: trunk-based development and meaningful automation. Get those right and CD becomes a controlled move of a known-good main branch instead of a faster way to ship uncertainty.
Arguments about monorepos usually start with tooling, but the real issue is coordination. A repository structure is a delivery model: it encodes ownership, dependencies, release flow, and how much coordination people need before they can safely ship. Size repositories around deployables and publishables so the repo boundary tells the truth about how the software actually ships.
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, "we think we're close," 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.
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.
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.
