October 24th, 2026, posted in for_founders
by Miruna
Over the last few years, most companies did the same thing. They bought their developers a Copilot or Claude subscription, told them to ship faster and waited for the results.
The results were disappointing. Delivery didn’t speed up much. Code quality got worse in places. Then the token bill arrived, and nobody could explain why it cost thousands of dollars a month.
The tools weren’t the problem. The problem was who was using them to decide what gets built. Developers suddenly became responsible for writing the foundational prompts that the entire application is built from. That’s a product owner’s and a designer’s job, and very few companies noticed the switch.
That’s why we don’t let our developers write them. At UPDIVISION, product owners and UX designers map out the whole application first and turn it into precise specs: user stories, acceptance criteria and technical tasks. Those specs become the prompts the application is built from.
Our developers still use AI every day. They prompt to adjust code, fix issues and make changes along the way. But those prompts are corrections and refinements, not the main build. That leaves developers free to focus on what they do best: architecture, code quality and making sure everything works.
Specs were never a developer's job
Before AI, you would never have handed a developer a one-line brief and asked them to work out the rest. Defining the product was the job of product owners, designers, architects and testers. A developer received a specification and built the code from it.
Then AI tools arrived, and many companies quietly skipped that step.
When a developer types a paragraph into a chat window, they are writing a specification. They’re writing it alone, under pressure to deliver faster, without the design, without the user research and without the conversation the business had last week about what this feature is actually for. When the result doesn’t match what anyone wanted, the developer gets blamed for a decision they never should have made on their own.
In practice, you’ve asked one person to do the work of a whole team. Nobody can do all four jobs well, and an AI subscription doesn’t change that. It looks like you’re saving time and money, but you’re really just creating more work to fix later.
The fix isn’t a better AI tool. It’s giving each job back to the right person.
Developers became code editors, and that's the harder job
There's a version of this argument that insults developers. This isn't it.
Writing code was never the valuable part. Judging code is. Does this work under load? Will the data model survive the second customer? Where's the injection risk? Is this the right abstraction or just the first one a model reached for?
AI can produce a plausible implementation of almost anything. It cannot tell you whether the plausible thing is correct, safe, or maintainable. It suggests patterns that were right three library versions ago and states them with total confidence. Someone has to catch that.
That’s the job now. Developers stopped being typists and became editors: the people with the judgment to accept, reject and correct. They still prompt, but to refine and fix, not to decide what the product is. It’s a more senior job than the one it replaced, and it’s full-time work. Which is exactly why we don’t also ask them to invent the requirements.
Design is where the specification actually lives
If developers aren't writing the specs, someone is. For us, it starts with UI/UX design, with a strong product discovery base.
A written requirement can stay vague. "A dashboard where users track their orders" is a sentence everyone can nod at while picturing something completely different.
A design can't stay vague. To draw that dashboard, someone has to decide how many orders appear, how they're sorted, what happens when there are none, what happens when there are ten thousand, what's clickable, what an error looks like, what it becomes on a phone. Every one of those is a decision a developer would otherwise make alone, with no context and no authority.
Design forces those decisions into the open while they're still cheap. Moving a button in Figma takes minutes. Moving it after it's wired to a backend takes a sprint.
And design carries more than screens. It encodes the user flows, so you can see how someone actually gets from intent to outcome, including the paths nobody planned for. It encodes the design system: colors, typography, spacing, buttons, inputs, states, the whole component library. That system is the reason the translation to code is accurate. Consistent components with proper variants convert cleanly. A folder of loose screenshots doesn't.
By the time a design is finished properly, the specification already exists. It just hasn't been written down in words yet.
From design to build, in a straight line: ULTRA
That's the step our ULTRA tools handle.
We feed the designs and the feature descriptions into ULTRA Stories, and it generates the user stories. From those come the acceptance criteria, the technical tasks, the estimates and the automated tests. What used to take days of a product owner's time per feature now takes minutes.
That timing matters more than it sounds. The reason most teams skip specs isn't that they think specs are worthless. It's that writing them by hand was expensive enough to feel optional when a deadline was close. Make it cheap and the excuse disappears.
The output is a complete, build-ready spec derived directly from the design, with nothing invented along the way. That's what our developers receive. That's what the AI coding tools receive. Nobody is guessing.
The three ways coding with no design usually goes wrong
Developers write the specs.
They're improvising product decisions under time pressure. What comes back is technically competent and often not what the business asked for. Everyone discovers this in review, which is the expensive place to discover it.
Code starts with no design.
The first version looks like whatever the model produced. Then the real design arrives and half of it has to be rebuilt, because the layout, the states and the component structure were all decided by accident. Or worse, the client decides to remove certain features, or to change them. Already that’s a ton more work, which would’ve been done faster by starting with design.
User stories are written with no design.
This one looks disciplined and isn't. Stories written from imagination cover the happy path and go quiet on everything else: empty states, permissions, error handling, the second user type nobody mentioned. Those gaps don't disappear. They surface as change requests, which are the same work at three times the price.
All three are the same mistake. A decision gets made too late, by the wrong person, with too little information.
What businesses who are building software get out of this
You see your product before you fund it.
Within weeks, there's a clickable prototype of the real thing. Not a description of it, or a document about it. The actual screens and flows, before anyone has spent a month on code.
Changes are still cheap.
This is the part people underestimate. Reading a feature list and imagining the product is hard, so nobody catches the problems. Looking at a screen, people catch them instantly. "That's not how our approvals work." "Where's the filter?" Every one of those in week two is free. In month five it's a rewrite.
Estimates you can plan around.
You cannot estimate a paragraph. You can estimate a task list derived from a design. The numbers hold because they came from something concrete.
It's faster.
Our AI-assisted process runs 3.7x faster than our traditional one, and closer to 4x on repetitive work like setup, CRUD features and integrations. The speed comes from the spec, not from anyone typing quicker. A developer who knows exactly what to build doesn't stop, doesn't guess wrong, and doesn't wait two days for an answer.
The spec outlives the project.
In two years, when a new developer asks why a feature works this way, the answer exists. That's the difference between a system you can change and one everyone is scared of.
Why this works for three different buyers
If you run a business that needs software built around it, the risk is a system that doesn't fit how you actually work. Design is where your process gets encoded, and where you find out whether we understood it, before the budget is committed.
If you're a founder with a product idea, the risk isn't slowness. It's spending your runway building the wrong thing. You'll see the product in weeks, cut what doesn't matter while cutting is free, and own a spec you could hand to any team, including your own.
If you have a development team already, the problem usually isn't capacity. It's that your developers are doing four jobs and only one of them is theirs. Give them real specs and their output changes without a single new hire.
FAQ
Doesn't this slow developers down?
It does the opposite. What slows developers down is ambiguity: stopping to decide something they don't have the context to decide, or waiting two days for someone else to decide it. A complete spec removes both.
Isn't this just waterfall?
No. Waterfall specifies the entire product up front and resists change. We specify each piece properly before it's built, and the pieces still ship iteratively. You're not committing to a two-year plan. You're refusing to start any single feature without knowing what it is.
Can AI write the user stories?
Yes, and ours does. ULTRA generates them from the designs and feature descriptions in minutes. What AI can't do is know your business, sit with your stakeholders, or decide which trade-off is right for your market. It's excellent at turning a decision into an artifact. It can't make the decision.
What if we already have designs?
Then you're partway there, and we'll tell you honestly what's missing. Most designs we receive cover the happy path and stop. The states, permissions and edge cases are usually absent, and that's where the build time hides.
Do your developers actually like working this way?
They prefer it. Nobody became an engineer to guess at requirements and rewrite the same feature three times. They get to solve the hard problems, which is the work worth doing.
See it on your own product
The fastest way to understand this is to watch it happen to something you care about. We start with design, show you the product before it exists, and turn it into a build-ready spec that's yours either way.
Talk to us about your project.
