We’ve Accidentally Created Infinite Features

The productivity bit is real

Recently, I had one of those deeply suspicious moments in my software career where something starts working so well you immediately stop trusting it.

Not in the dramatic sense. Nothing caught fire. Nobody sent an email that made me feel nauseous. There wasn’t even a keynote involved, which already puts it ahead of most modern technical revolutions. It was just the quiet, disorienting realisation that working with AI had made me, and the team around me, noticeably more productive. Properly productive. The kind of productive where work that used to take a hard week is done before lunch, and looking smug about it.

I don’t mean this in the vague nonsense way people say “productivity” when they really mean they’ve cancelled three meetings and ordered a nicer chair. I mean actual progress. The work moves. You can get from rough idea to plausible feature much faster than before. You can explore options without feeling like every experiment is going to cost three days and a minor emotional collapse. You can spend less time chiselling individual lines of code out of the side of a mountain and more time thinking about what the feature is supposed to do in the first place.

One of the best side effects of AI in a development team is that your focus gets to shift upward. Away from the time consuming business of writing code and more towards understanding the shape of the thing. What does this feature actually need to do? How should it behave? What are users trying to achieve? Where are the awkward bits? What happens when the normal happy flow goes off-road and ends up upside down in a ditch?

That is good work. Proper work, even. Software has always improved when developers spend less time doing syntax carpentry and more time trying to describe what the thing is actually supposed to do.

But for years, we quietly defined the job as the code.

That was the craft. The identity. The bit you could point at and say, “this is what I do.”

AI has made that definition feel incomplete.

Because now the code turns up quickly, sometimes suspiciously quickly, and you’re left staring at the bit we used to treat as more of a side quest: deciding what should exist in the first place, and whether it’s going to behave itself once real people get involved.

There is a massive benefit here. Most of the effort has moved from typing to thinking, which is lovely, because typing was never really where the value lived. It was just where the back pain lived.

Finishing is now the hard part

But, and this is where software once again shuffles onstage wearing a fake moustache and pretending not to be the same old problem, the productivity uplift is now the new problem.

Because once you can produce work at warp speed, once the barrier between “we could do this” and “here is a working version of this” gets low enough, your brain starts doing what human brains always do when presented with new power. It becomes insufferably optimistic. You stop seeing a feature as a bounded piece of work and start seeing a thousand adjacent possibilities bobbing around it like overexcited ducklings.

You sit down to finish one thing and suddenly you’re not really finishing it anymore. You’re expanding it. Improving it. Noticing three other things nearby that could also be improved while you’re in the area. You are five minutes away from adding a form and somehow end up halfway through redesigning a workflow because the machine made the first bit easy and now your mind has wandered off into a nearby field, drunk on possibility.

I know this because I do it myself. I’m not reporting from a great height here like some stern Victorian headmaster of software discipline. I am one of the idiots in the room getting excited.

This is where finishing starts to suffer.

Not because people care less. Almost the opposite, really. It’s because people care so much, and can suddenly imagine so much more, that the satisfying, boring, necessary business of finishing one thing completely begins to feel a bit provincial. A bit small. A bit like staying home to do your taxes when there’s a whole theme park outside and someone has just handed you unlimited ride tokens.

And the sometimes unpleasant truth about software is that finishing is the job.

Not starting. Not ideating. Not marvelling at all the wonderful things we might be able to build before the kettle boils. Finishing. Rounding it out. Closing the gaps. Checking the edges. Dealing with the weird state transitions, the ugly error cases, the boring validation, the miserable user path where somebody uploads the wrong file, double-clicks the button, loses their connection, and then phones support as if you personally have hidden their documents in the woods.

That work still exists. AI has not made it disappear. It can help with parts of it, obviously. It can help generate tests, suggest edge cases, document behaviour, untangle logic, and generally act like a very keen assistant who never gets hungry or asks whether any of this is really the best use of our brief time on earth. But even with that help, there is still a big chunk of evaluation and validation that has to be done by people who understand the system, the product, the trade-offs, and the various exciting ways in which reality tends to ignore our assumptions.

Currently that evaluation, at least for me, does not move at the same speed as generation.

That’s the mismatch.

Because the more AI helps you produce, the easier it is for the team to start feeling that everything can be fixed just as easily. The logic goes a bit like this: if it took less time to build, surely it will take less time to repair. If changes are cheaper, maybe mistakes are less serious. If iteration is faster, perhaps caution is a touch old-fashioned, like adding your name to a waitlist for a new VHS release at Blockbuster.

This is where your brain tries to start skipping steps.

Not in some villainous way. Nobody sits there twirling a moustache saying, right, let’s recklessly under-test a feature and see whether we can make support cry. It’s subtler than that. You just feel the temptation to move on a little sooner. You tell yourself the final pass can happen later. The edge case can be tightened up in the next round. The weirdness in the workflow probably isn’t weirdness, it’s just one of those things that feels odd because it’s new. Besides, if it is broken, we can fix it quickly. We’re fast now.

Maybe you can. In fact, many times you can. That is what makes it dangerous.

Because once “we can fix it quickly” enters the room, process starts getting treated like a polite suggestion. The last twenty percent of the feature, which was already less glamorous than the first eighty, starts to look almost optional. Not entirely optional, obviously. Just a bit flexible. Something to circle back to after this one interesting idea, and then the next one.

AI has given the team jet skis

The metaphor that keeps turning up in my head is that AI has basically given the whole team jet skis.

Now, a jet ski is undeniably fun. I have never seen a sad person on a jet ski. That’s part of the issue straight away. It is fast, responsive, and deeply exciting to the person operating it. You do not gently potter about on a jet ski reflecting on the virtues of restraint. You zip. You skim. You turn aggressively for no real reason. You become, for a brief and stupid period, the sort of person who thinks spray counts as progress.

That’s a lot like my current feeling of building with AI. You can move so quickly across the surface of things that it all starts to feel thrillingly manageable. More features. More variations. More experiments. More tight turns and bursts of speed. Everyone’s having a marvellous time, carving elegant loops across the water and shouting, “look how fast we’re going”.

The problem, unfortunately, is that software is not a nice open ocean on a sunny afternoon. It is a marina full of posts, ropes, hidden debris, tired old structures, and other people trying to do something sensible nearby. There are rules. There are depth markers. There are bits where you’re absolutely meant to slow down, though nobody likes admitting that. There is also, somewhere off to one side, the poor users standing on the shore, trying to work out why six new vehicles have appeared, all of them half-fuelled, one of them parked at a café, and none of them apparently having passed a proper inspection.

Then because this is a metaphor and I have clearly lost control of it, support is the harbourmaster, operations is a rescue boat, the product owner is shouting that one of the jet skis was only supposed to be a paddle board, and the executive team is asking whether this means we now have capacity to open a water park.

That’s roughly where we are.

Not doomed. Not ruined. The uplift is real. The shift from writing code to understanding and describing functionality is real. The increased ability to explore ideas is real.

It’s just that the bottleneck has moved, and moved in a way that messes with your head.

The problem is no longer just getting software produced. The problem is holding your attention steady enough to finish what you started when five more exciting options are now within arm’s reach. Validation still takes time. Judgment still takes time. None of the old boring responsibilities have gone away just because the front end of the process has become dramatically more fluid. Speed creates optimism, and optimism has always been one of the leading causes of software being done wrong.

So I think that’s the new version of the old mistake.

For years we thought the pain was in getting the code to work, and now that some of that pain has lifted, we’re discovering the deeper discomfort was elsewhere all along. It was in deciding clearly. It was in finishing properly. It was in resisting the urge to wander off halfway through the feature because another shinier idea just popped out of the machine wearing sequins.

AI has made teams more capable. I believe that. It has also made distraction more productive, which is an absolutely ridiculous sentence to have to write but seems to be true. You can now make a surprising amount of progress in the wrong direction before lunch, and do it with such confidence that by the time anyone notices, the room is full of half-rounded features and cheerful explanations about how easy it will be to sort them out later.

Sure, maybe it will be easy.

But later is where software goes to become expensive.

So yes, enjoy the uplift. Use it. Shift your attention upward into understanding the product better, because that is where the real value has been hiding all along. Just keep an eye on the other thing AI has quietly made easier, which is getting so excited about what could be built next that you forget to finish the thing right in front of you.

Because it turns out the hard part was never really writing the code. It was knowing when to stop doing loops of the bay at speed and come back to the shore.