Which questions do you know to ask?

Every piece of software starts with a need. Someone in the business runs into a process that is slow, error-prone or held together with spreadsheets, and wants something better. Traditionally, that need is the start of a long chain. With AI, a new world opens up: the person with the need can go straight to a working application.

That is a real shift in who develops software. And it comes with a reversal worth looking at: the business person knows which questions to ask about the process, but not about the technology. In classical development, it was the other way round.

Lost in translation

The traditional path runs from the business, through a product owner, to a development lead, to a team of developers. Each step is a translation, and the bigger the project, the more steps there are. Each translation loses something, adds something, or bends it to fit what the next person already understands. Remember playing the telephone game as a kid?

When the person with the need builds the application, there is only one translation step. They know what they need. Just as important, they know what they don't need. They tell the AI, and when the AI asks a question about the process, they can answer it directly. A developer would have to walk back up the chain.

Developers are good at building brilliant solutions. At the start of my career I worked at a job placement agency. In its workflow process for job applications, the ability to edit the process and change the order of its steps worked brilliantly. In reality, only a few predefined processes were needed. A configurable process might have been useful in the future, but it required additional mechanics to compensate for changes. It took more time to build and it introduced risk. If it had been needed, that would have been justified. It was not.

Someone who knows the process would not have asked for it. Not for lack of imagination, but because they know what the work actually looks like.

AI can be just as eager as I was as a junior developer, but a few skills (reusable instructions for the AI) can guide it to separate what is needed from what is possible. An excerpt from one of the skills we use at Afternoon Code for business people using AI-assisted development:

Once the problem is confirmed, challenge the goal by stating what it is **not**, then draw the line:

- **The minimum** that solves the confirmed problem — "based on this, the minimum we need is X" —
  and what it rests on that is not in place, with the limits without it.
- **The options** — "optionally we can add Y and Z" — each with what it adds for the user.
- **Not part of this** — "A is not part of this", so the user can object now rather than at the
  demo.

Hours instead of days

The second advantage is the speed of feedback. AI does not only describe what it is going to build; it shows you, and quickly. And when it heads in the wrong direction, switching tracks costs minutes, not days or weeks.

That changes how a process gets built. Instead of days of explaining and negotiating before building even starts, you build a version, use it, and adapt it within hours. In the Cockpit project, René could see his concept working within hours: actual functionality, not a mockup.

It also takes the edge off the sunk cost fallacy. Developers, including me, take pride in their work, and discarding something we worked on affects us. Is that a reason not to change direction? It shouldn't be, but I have seen many a project plough ahead because starting again would cost too much. AI is not attached to the code it wrote; it will happily tear it down and replace it within hours.

The reversal

Classical development puts technical people in charge of building. They ask the right technical questions: how is this secured, how does it perform under load, what happens when the network fails. They ask the process questions less well, if at all, because they are several translations removed from the work.

AI-assisted coding flips this. The business person asks the right process questions without effort, because they live in the process. Security, performance and maintainability are a different matter altogether.

This is not a new problem. Experienced developers leave vulnerabilities in software too; the difference is in the kind. AI can add security, but it generally needs the right guidance: the right questions. The kind of mistake it makes is forgetting a security check because no one said it was required. Experienced developers, especially with a proper review process, typically catch these, but they may miss a restriction on a business role for a specific process.

"Ask the AI to check it" does not close the gap. AI works best when it is directed to specifics: check this endpoint for authorisation, check this query for injection, check how this data is stored. To direct it, you need to know what to ask. You cannot point it at something you do not recognise. The result is an application that works and feels finished, with no way for its builder to tell whether it is safe.

Which gap is easier to close

Both approaches have a blind spot. The question is which one is easier to fix afterwards.

I would argue it is the technical one. A wrong process means the software does the wrong thing, and fixing that means rebuilding what it does. Technical issues tend to be specific: a missing check, an exposed setting, an inefficient query. They can usually be fixed within what is already there, without changing what the application does for its users.

Getting the process right is the harder half. AI-assisted coding puts that half with the person best placed to get it right.

There is one condition: the foundation has to be right from the start. Technical correctness on top of a working process is only easier if there is something solid underneath.

Groundwork, process, correctness

I left the architect out of the initial translation chain on purpose. They are not a step in the chain but a separate path altogether, whether AI is involved or not. An architect's job is to lay the groundwork that allows both the business and the technical needs to be met. That role still exists, although it changes when working with AI.

Groundwork. A high-level concept of the business process is enough to lay the foundation: the stack, how authentication and authorisation work, how data is stored and handled. The decisions that are expensive to change later. The AI uses this groundwork to shape the solution.

Process. The business person builds the process on top of that foundation, at full speed, without waiting for anyone.

Correctness. Technical expertise finishes the job: reviewing what was built, checking it, hardening it. With AI this is a challenging job: it places high demands on the reviewer to understand the processes built by the business. But with AI and the ability to ask the right questions, evaluations can be done consistently across the application.

The translation loop does not disappear completely: technical reviews may surface questions about the intent of functionality. These questions still go back to the business, but with the proper guidance they can adjust.

Which questions do you know to ask?

If you are building your own software with AI, you are in a better position than ever to get the process right. You know what the work looks like, what is needed, and what is not.

So ask yourself honestly: which questions do you know to ask? About the process, probably all of them. About security, performance and data protection? That is where you bring in someone who does.