The velocity AI creates in coding is interesting because it is not nearly as uniform as people assume.
I was looking at my GitHub contribution chart this morning and thinking about that.
You’ll see stretches with hundreds of contributions in a day, spread across six projects. Then it drops to five. Or three. Last week, I had a day with two contributions, 11,000 lines of code, and roughly 150,000 lines of documentation that affected six repositories.
That kind of pattern looks strange until you understand what the work actually is.
Engineering the context
Not all application work is implementation.
Some of it is exploratory. You test things that may never make it into the final project.
Some of it is planning. And while planning is dramatically accelerated if you’re using AI well, it is still the most labor-intensive part of any serious project.
That is exactly how it should be.
In fact, failing to plan is one of the biggest mistakes you can make these days.
As an industry, we have always undervalued planning and documentation. AI has not changed that. It's only made the consequences impossible to ignore.
When output velocity goes up, weak process stops being a nuisance and starts becoming a demolition charge.
The way to understand documentation in the era of AI coding is as context infrastructure and behavioral shaping.
Whether you mean to or not, your tools are going to consult it constantly.
They are reading your specs, your notes, your examples, your tests, your naming conventions, your repo structure, and every other breadcrumb you leave behind.
This is also why TDD starts to feel a lot less optional.
When the difference is 5,000 lines that solve a real problem versus 100,000 lines that do nothing useful while detonating technical debt, you learn very quickly what matters and why.
The recurring failure modes
So when people issue dire warnings about “vibe coding” and AI automation at scale, most of the complaints map back to a few very specific failure modes:
1. Poor documentation, or missing documentation. This includes documentation that is too dense, or difficult to reason through.
2. Giving agents root access to production systems.
3. Letting agents set up or manage CI/CD without strong technical oversight.
Remember: Words like "good" or "better" mean nothing in software engineering unless they're backed by rigorous technical backing.
Your job role as a software engineer or SRE will continue to exist for the foreseeable. But the role is very different now, and so are the expectations.
Automation has changed the shape of things.
More and more, the work is drifting upward: architecture, context design, validation, behavioral guidance, testing, governance, and review.
Today, it falls on you to manage the conditions under which automated systems behave well.
Congratulations on your recent promotion.
Now it’s time to start taking it seriously.