Two years ago, a working internal tool with authentication, a database, an admin view, and a couple of integrations was a team's quarter. Now it is a week, and a fair amount of that week is deciding what not to build.
That is a real change and it is worth being precise about what changed, because the loose version of this claim is doing a lot of damage.
What actually moved
The gain is not that code gets written faster, though it does. The gain is that the cost of a first attempt collapsed. When building the wrong thing costs a day instead of a month, you can afford to build the wrong thing on purpose, put it in front of someone, and learn from the fact that they hate it.
That inverts the old economics. Requirements documents existed because building was expensive and being wrong was catastrophic. Neither premise holds as firmly now.
The second gain is narrower and less discussed: the range of a single person widened. I can now hold a build, its infrastructure, its automations, and its integrations in one head without any of them being a black box I am afraid to touch. That is not the same as being a specialist in all four, and pretending otherwise is how people get hurt.
Where it still breaks
The first failure mode is dependency. Speed comes partly from not building things, which means the things you did not build are now load bearing.
A client system of mine generates PDF brochures through a third-party plugin. In August it started returning a 400 on every generation. Nothing in the build had changed. The plugin vendor's own demo sites were down the same day, along with several of their other products, so it was an outage on their side and there was nothing to do but wait and tell the client that.
That is the trade in plain terms. Using the plugin saved a week of work. It also meant a core client-facing feature went down for reasons entirely outside my control, and my only lever was an email. I would make the same call again, but I now ask a question I did not use to ask: if this breaks and stays broken, what is the manual path, and how bad is it?
The second is mess, and it is quieter.
When iterating is cheap, versions accumulate. On one site I inherited a page that had a second, hidden full build of itself sitting inside the same page wrapper, left over from a redesign that was kept around just in case. Everything looked fine until the slider started showing twenty-five items instead of eight and repeating its navigation dots. Two sliders were running, two collection lists were feeding them, and a consent script was loading twice. All of it invisible until it was not.
Nobody made a bad decision anywhere in that. Someone kept an old version live rather than deleting it, which is a reasonable thing to do once. The cost of that reasonable thing dropped so far that it happened repeatedly and nobody cleaned up.
The old economics forced tidiness, because building twice was expensive. That pressure is gone, and if you do not replace it with a deliberate habit you get exactly this: a site that works, right up until an attribute collision makes the duplication visible.
What I have changed as a result
Speed makes review more important, not less. A thing I can build in a day is a thing I can build wrong in a day, and the traditional brakes, estimation pressure and the friction of writing it by hand, are gone. Something has to replace them deliberately.
For me it is three habits: I do not ship anything touching money or personal data without reading every line of it. I keep a written record of decisions, because the reasoning is now the scarce artefact rather than the code. And I cut scope twice, which is a subject of its own.
The honest summary is that the ceiling on what one person can produce has moved a long way, and the ceiling on what one person can be responsible for has barely moved at all. Most of the trouble I see comes from confusing the two.