One change in how software teams work

In 2021, I was involved in an Australian tax compliance–related project.
Four engineers, about four months of delivery time.

In 2025, I saw a different project — in a different domain, but with very similar overall complexity — delivered by two engineers in about one month.

Depending on how you count, that’s roughly an 8–16× shift in delivery speed.

This didn’t come from people working longer hours or typing faster.
It came from a change in where engineering effort goes.

Over the last 24 months, I’ve seen teams move from primarily writing code to primarily reviewing and shaping code generated by machines. In some teams, engineers now spend more than 50% of their time reviewing machine-generated code rather than producing it line by line themselves — and that ratio is still increasing.

The third shift is about learning.
In 2020 or 2021, when a new framework or programming language was required, teams often had to pause major delivery work so people could learn it as their primary day job.

That pause rarely happens anymore.

Today, new knowledge is absorbed continuously, in the flow of work. Learning a new language or framework has become just one part of an ongoing, everyday learning loop rather than a separate phase.

My first working theory is this:
AI hasn’t simply made engineers faster.
It has changed throughput, learning curves, and the shape of the work itself.

This isn’t a reason to panic.
If anything, it’s an invitation to rethink how teams are structured, how people grow, and where human judgment really matters.

I’ll be sharing a few more working theories like this over time.

Curious how others are experiencing this shift.