Trend articles have a reliability problem: the predictions are unfalsifiable. “AI will transform development” is true in the way that “the weather will change” is true. Nobody can be wrong, so nobody learns anything.
So here are five shifts that are already visible in how teams work, each with a specific thing that has changed and a specific thing that has not. If a claim below is wrong, you will be able to tell.
1. Code generation moved the bottleneck, not the work
Writing code is faster than it was. That was never the slowest part of shipping software, so total delivery time has moved much less than the demos suggest.
| Activity | Changed by AI? | Why |
|---|---|---|
| Writing boilerplate | Substantially | Pattern-heavy, easy to verify |
| Writing tests | Substantially | Same reason |
| Understanding legacy code | Somewhat | Explanations help; correctness still needs checking |
| Code review | Barely | Judgement about intent, not syntax |
| Deciding what to build | Not at all | Requires context no tool has |
| Debugging production | Somewhat | Good at hypotheses, poor at your specific system |
The visible consequence in teams: more code produced, and review as the new queue. Several teams have responded by making reviews smaller and more frequent, which is a genuine process change rather than a trend prediction.
2. Platform teams replaced DevOps-as-a-job-title
The “every developer owns their infrastructure” idea produced a lot of half-learned Terraform. The correction has been internal platform teams that provide paved paths: a standard way to deploy, log, monitor and roll back that most teams use without thinking about it.
What has not changed: someone still has to be on call, and the person who wrote the service is still the fastest at fixing it at 2am.
3. Type safety won the argument
Ten years ago this was contested. It is now close to settled — TypeScript over plain JavaScript, typed Python in anything shared, Rust taken seriously in systems work. The reason is not aesthetics; it is that types are the cheapest form of documentation that cannot go stale.
The practical version for a small team: adding types to the interfaces between components buys most of the benefit. Typing every internal function buys much less and costs more.
4. Monolith-first came back
Microservices solved an organisational problem — many teams shipping independently — and were widely adopted by companies that did not have that problem. What they got instead was distributed debugging, network calls where a function call would do, and five repositories for one feature.
The current default is a well-structured monolith with clear internal boundaries, split later only where a real constraint appears — a component with different scaling needs, or a team that genuinely needs to deploy on its own schedule.
This is the trend most likely to be reversed again in five years. It moves in cycles because both answers are right under different conditions.
5. Supply chain security stopped being optional
A modern application depends on hundreds of packages, most of which nobody on the team has read. That was always true; what changed is that attacks on that surface became routine rather than theoretical.
- Lock files committed, always, and dependency updates reviewed rather than applied automatically.
- Automated vulnerability scanning in the pipeline — cheap, and catches the known cases.
- Fewer dependencies. The most effective mitigation is not adding a package for something you could write in twenty lines.
What has not changed at all
Worth saying plainly, because trend lists imply everything is in motion:
- Unclear requirements are still the most common cause of wasted work.
- The hard part of a system is still the data model, and it is still the most expensive thing to change later.
- Communication between people is still slower than any tool, and still the real constraint on team size.
- Most outages still trace back to a configuration change, not a code change.
Where those failures happen is at the handoffs, which we went through in detail in the SDLC seams.
Common questions
Should a junior developer still learn fundamentals?
More than before, not less. Generated code has to be evaluated, and evaluating it requires knowing what good looks like. The people who benefit most from these tools are the ones who could have written the output themselves.
Is low-code taking over?
It has taken over a specific band of work — internal tools, forms, simple workflows — and stalled at the same wall it always hits, which is the custom requirement that the platform does not support.
Which of these should a small team act on first?
Dependency hygiene, then types on your interfaces. Both are cheap, both pay back within months, and neither requires reorganising how you work.
How do I tell a real trend from marketing?
Ask what it would look like if the claim were false. If you cannot describe that, it is not a prediction — it is an advertisement. The same test works on software reviews, which we covered here.
Leave a Reply