Writing code is no longer the bottleneck. Knowing what to build is.

The cost of producing a working draft of software has collapsed. A team can describe a screen, a report, or a small workflow and have something runnable the same afternoon. That is useful. It is also easy to mistake for the whole job.

The hard part was never the keystrokes. The hard part is knowing what to build, on which data, and how to run it safely once real people depend on it. Those questions do not get cheaper because a model can emit a function. They get more urgent, because the draft shows up before anyone has agreed on the answer.

Start with the problem, not the ticket. In a mid-size company the person who feels the pain is often close to the person who can change the system. That proximity is an advantage, and it is wasted when the conversation starts with a feature list. A useful first hour is spent naming the decision the software has to support, the number that has to be right, and the exception that currently lives in someone’s inbox. If that hour is skipped, the generated code is just a faster way to encode a guess.

Then the data. Most internal tools fail quietly because they read the wrong table, the stale extract, or a spreadsheet that three teams have edited by hand. Which data is a product decision. It includes what is certified, what is still a working copy, and who is allowed to see the row. A model will happily join whatever you point it at. The join is the easy part. Standing behind the number when finance asks where it came from is the work.

This is where teams get hurt by convenience. The extract that was “good enough for the demo” becomes the source the region quotes in a forecast. Nobody meant for that to happen. The draft was simply allowed to leave the room. A plain rule helps: if the output can be repeated to someone who will act on it, the data underneath it has to be data the company has already agreed to trust. If it is not there yet, the app stays a draft. The code can be brilliant and still be the wrong thing to ship.

Then the running of it. A prototype on a laptop is not a system. Someone has to know what happens when the source is late, when a user pastes a bad identifier, when the model is confidently wrong, and when the person who built it is on leave. Safe, here, is practical. Identity you already trust. A place the code lives. A review before it is shared. A way to turn it off. High quality is the same idea at a smaller scale. The screen does what the operator expects on a Tuesday afternoon, not only in the demo.

None of that is a platform manifesto. It is the short list a colleague needs in order to inherit the thing. Where does it run. Who is it allowed to be. What may it read. What do we do when it is wrong. If those four answers are missing, you do not have software yet. You have a file that happened to execute during the meeting.

This is why the people who know the business have to sit next to the people who build. Not in a quarterly workshop. Next to them, while the thing is being made. The business owner catches the case the spec forgot. The builder catches the place where the process is slower than it needs to be. Neither can do the other’s job from a document. Bespoke software, built where talent meets technology, is that arrangement made concrete: your people, your know-how, and the tools that let a small group ship something that fits the company instead of a generic suite.

Generating code does not remove the need for that pairing. It changes the ratio. A pair can now try three approaches before lunch and keep the one that matches how the work actually happens. The bottleneck moves upstream, to judgment, and downstream, to operation. Teams that staff only for typing will feel busy and still ship the wrong thing. Teams that staff for the decision, the data, and the guardrails will find that the code was never the scarce resource.

None of this requires a new department with a new name. It requires a habit. Before a build starts, write down the decision, the data it may use, and the line it may not cross. Put the person who owns the outcome in the room with the person who can change the system. Review the result against those three lines, not against how impressive the draft looked. When the next request comes in, the same lines are already there. That is how the work gets faster without getting sloppy.

The companies that will get the most from this shift are not the ones that generate the most code. They are the ones that can say, in plain language, what they are building, why that data is the right data, and how a colleague who was not in the room can run it on Monday.