Now That AI Builds Software Faster, Can You Skip the Planning?

Software development really is changing. AI-assisted tools help teams write code, draft tests, generate documentation, and stand up a prototype faster than they could a year ago, and any serious software company should be using them. 

We are. We deliver at more than 10% above the industry pace because of it, and that saved time goes straight back into the work, into more iterations and tighter details.

But faster building only answers the easy question. 

The hard one is still what should be built, and no model can answer that for you. That question belongs to the business and the people responsible for understanding the work. 

If the workflow is unclear, if ownership is undefined, if the data is messy, or if every department describes the process differently, AI will help you produce the wrong software faster. 

The work has to be followed before the tool gets built.

‍

What does AI actually change, and what does it not?

It changes the speed of building, and it leaves the hard part untouched: the clarity you build from. AI can draft code, generate tests, summarize documentation, and explore options faster than a team working alone, and that is real leverage. 

What it cannot do is tell you which of your workflows matters most, which exception happens every day versus once a year, which report your leadership actually trusts, or who should approve a request. 

Those answers come from understanding the business, and they have to exist before the speed is worth anything.

This is the part the current hype skips. A model can produce a working screen in minutes, but it does not know your business, your customers, or the promise you are trying to keep. Speed applied to a clear direction is leverage. 

Speed applied to a fuzzy one just gets you to the wrong place sooner.

‍

What is the risk of building before you understand the work?

The speed hides the mistake until it is expensive. When building gets faster, the temptation is to start sooner, especially when everyone is tired of planning meetings. 

The trouble is that faster development makes unclear decisions show up faster without resolving them. 

You build the dashboard before agreeing what the numbers mean, automate an approval no one owns, or launch a portal before knowing what customers need to see, and now those problems live in production instead of in a conversation.

The tooling makes this easier to do and easier to regret. 

AI-written code produces roughly 1.7 times more issues per change than human-written code, and Google's 2024 DORA research found that every 25 percent increase in AI usage came with about 7.2 percent more instability in the system. 

AI raises your output. Judgment is still on you, and output without judgment is just more to clean up.

Builder.ai is the cautionary tale at full scale. The startup raised more than 450 million dollars from investors including Microsoft and Qatar's sovereign wealth fund, on the promise of AI that builds your app for you, and reached a 1.5 billion dollar valuation. 

In May 2025 it collapsed into insolvency, after reporting revealed much of the "AI" was roughly 700 engineers writing code by hand and the company had overstated its revenue by around 300 percent. 

They were selling the speed of AI while skipping the understanding of the work underneath it.

‍

What does "following the work" actually mean?

Tracing what really happens, end to end, instead of what the process diagram says happens. 

The real workflow usually lives in the places leadership does not see: the side spreadsheet, the Slack thread where approvals actually happen, the personal checklist, the CRM notes, and the exceptions everyone handles but no one has written down.

Following the work means asking a specific set of questions and chasing the honest answers:

• Where does the request begin, and who touches it first?
• What information is needed, and where does that information live?
• What causes the delays?
• What gets copied by hand from one place to another?
• Who actually makes the decision?
• What happens when something does not fit the standard path?
• Where does the customer feel this process?
• What does leadership need to see at the end?

The answers are where the real requirements hide. 

They are almost never in the first feature request, which is usually a guess at the solution before anyone has studied the problem. 

This is the work AI cannot do for you, and it is exactly the work that makes everything built afterward worth the speed.

‍

Where does AI fit once you understand the work?

Everywhere it can accelerate a disciplined process, and nowhere it becomes a shortcut around one. 

Once the team knows what the system needs to do, AI is genuine leverage: exploring options, assisting with code, drafting tests, generating documentation, debugging, and speeding up the internal work. 

That is how we get to more than 30 percent faster, and that speed exists to buy more thinking, more iterations and tighter details in thoughtful design and clean code.

The judgment stays with people. Architecture, security and permission decisions, data structure, UX calls, business-rule validation, QA, and a plan for who owns the system after launch are human responsibilities, and every AI-driven feature we build for a client still has to clear the same bar: that it is purposeful, reliable, and secure. 

Our own tooling works this way. Tinker, the monitoring agent we built, watches a codebase and can fix many issues on its own, but every fix is reviewed by one of our developers before it ever reaches production. 

The AI does the watching and the first pass. A person still signs off.

‍

Why does ownership matter more now, not less?

Because the easier software is to generate, the easier it is to generate something no one is accountable for. 

When a model can produce a feature in an afternoon, the questions that decide whether it helps or hurts are all about ownership: who owns the workflow, who owns the data, who owns the customer experience, who reviews the AI-assisted work, and who is accountable if the software routes a request wrong, exposes the wrong data, or gives a confident answer that happens to be incorrect.

This is where we hold a simple line. 

We believe that business is built on transparency and trust, and that good software is built the same way, which means someone real is always accountable for what we deliver, AI-assisted or not. 

Technology drives the work, and the human stays at the center of every decision. That has been our position since well before AI became the thing everyone puts on the homepage, and it matters more now, not less.

‍

What should you clarify before you start the build?

These decisions are what make the software worth building, so get clear on them before you start:

• The workflow. Map how work actually moves today, unofficial steps included.
• The business rules. Document the logic people use to make decisions, route work, and handle exceptions.
• The owners. Define who owns each part of the process, and who owns the system after launch.
• The data. Clarify what information matters, where it comes from, who maintains it, and which reports depend on it.
• The users. Understand what employees, admins, customers, and leadership each need from the system.
• The exceptions. Identify the edge cases that happen often enough to design for.
• The future state. Define what the system needs to support as the business grows.
• The maintenance plan. Decide how fixes, documentation, QA, and ownership work after launch.

Do this work and AI makes a strong process faster. 

Skip it and AI just helps you build the wrong thing at 30 percent above the industry pace.

The most useful question a leader can ask about AI right now is whether the business understands the work well enough to build the right thing. 

Ask that before you ask whether it can be built faster, and AI stays in its proper role: an accelerator for a team that already knows where it is going.

AI will keep changing how software gets built, and ignoring that would be a mistake. But the companies that get the most from software will still be the ones that understand the work before they build the tool. 

Speed matters. 

Clarity matters more. 

A faster build is only worth something when the system reflects how the business runs, supports the people using it, and has someone ready to own it after launch.