Control AI-Built Products with Request, Approval, and Recovery Records

Natural-language requests are starting to become real services

People can now describe the feature they want in plain language and have AI produce a plan and early screen drafts. In an AiApp case published by GRIDGE (그릿지), Claude, a conversational AI, structured natural-language requirements and created initial drafts of screens and features.

GRIDGE said the time from planning through initial implementation fell by about 80%, and one developer saved about 10 hours a week. It reported around 100 cumulative projects and apps, and adoption by around 50 companies. These are supplier-reported experience figures, so they should not be assumed to apply directly to other organisations.

Microsoft also lets people begin designing workplace apps in Power Apps with natural language. At the same time, its official operating guidance says to manage requirements, changes, testing, deployment, and rollback together, while recording who changed what. In other words, the ability to build quickly and the process for operating safely should not be treated separately.

In a survey of 500 Korean companies by the Korea Chamber of Commerce and Industry (대한상공회의소), a business organisation, and the Korea Institute for Industrial Economics and Trade (산업연구원), 78.4% said AI was necessary, but 30.6% said they were actually using it. Four out of five companies see the need, while fewer than one in three are using it in practice.

This gap does not exist only because building capability is lacking. Requirements sit in messaging apps, AI-generated changes sit in build tools, and test results are scattered across photos and documents. The larger problem is that it is impossible to connect who approved what.

Connect the points where the work breaks first

Imagine that the owner of a 12-person window and door installation company builds a service for reporting site defects. A customer uploads photos, the office assigns a technician, the technician leaves completion photos, and the owner confirms whether the work is complete.

The owner receives requests from field staff through KakaoTalk, writes features in a notes app, and pastes those sentences into an AI building tool. They check the changed screen on a phone and, when there is an error, upload a screenshot back into the chat. The change request, the actual change, and the verification result are split across different tools.

A few days later, a request arrives: “Let customers upload multiple photos.” The problem gets bigger. The AI may change not only the photo feature but also the position of the completion button or notifications sent to customers. Because the owner cannot read code, it is difficult to know the scope of the change.

What is needed is not a document explaining code. It is one record that connects a single change from start to finish: the original request, what the AI understood, the one thing to change now, the condition for calling it complete, the approver, the release time, and the version to roll back to.

Rules that must not change should be separated from change requests and kept visible at all times. Write down the boundaries the service must uphold, such as: “A technician cannot see another technician’s customer address,” “Only the owner can reverse a completion,” and “Customer photos do not appear on public screens.” If a new feature touches these rules, approval should come before building.

Assign one change at a time, and write the completion criteria as an action. Instead of “Improve the photo feature,” write: “On iPhone and Android phones, a user can upload three photos, delete one, and complete the report.” The owner can then test it directly.

An error record should not just say “It does not work.” Record the device used, the sequence of taps, the expected result, the actual result, and a screenshot. If a test fails, return to the last working version and separately check whether data changed too. Restoring a screen and recovering lost customer information are different jobs.

Some work still remains with people. AI cannot take responsibility for deciding which request to build first, how much customer information to collect, or whether to release despite an error. For a non-developer, control does not mean being able to read code. It means setting the criteria for approval and stopping.

The scope of control is expanding beyond build speed

Jon Cheney, founder of US-based GenAIPI, built a website, admin tools, and an early product draft with Replit without coding experience. Replit charges for account subscriptions and AI task usage, and provides a feature that saves work state so users can return to earlier versions.

According to a Replit customer case study, he built the initial product over a weekend for less than KRW 540,000 instead of an outsourced quote of about KRW 140 million, and secured a first contract worth about KRW 20 million within five days of launch. These figures were published by the supplier and customer and need separate verification. Still, the example shows that small-scale building and fast sales validation have become possible. A saved version is only a recovery tool, however; it does not prove who approved a change.

At US subscription commerce company AppDirect, non-developer marketing staff used Lovable to build internal apps. Lovable sells subscriptions for organisation accounts and AI usage, and provides project permissions, change versions, and rollback features.

In a case published by Lovable, the marketing team created 11 projects and released four of them into actual work. The company said more than 80 apps were in development across the organisation.

The UK Home Office did not open Power Apps to all staff from the start. It began with a restricted pilot involving about 250 people. Microsoft sells user accounts and organisation-level operating features, while the Home Office tested governance, training, and support channels during the pilot.

According to an official customer case study, the number of people participating in creation later grew to more than 1,500, and 1,421 business staff registered 696 solutions. The time saved in the first two months of that financial year was 5,875 hours. The key sequence was to validate governance, training, and support channels in a controlled pilot of about 250 people, then expand the scope of use.

Four things you could build from this

1. AI build request form

• What it does: A service that takes chat messages or meeting notes and separates them into the original request, the feature to change, rules that must not change, and completion criteria.
• Who uses it: The owner of an academy who wants to build an academy management service with booking and payment features using AI.
• Why now: Natural-language building is faster, but there is still a need for a separate tool that keeps the original request and the AI’s interpretation side by side.
• What to put on the first screen: Put the original-text input on the left, and the four sections plus a “Send this build request” button on the right.

2. Change approval inbox

• What it does: Shows before-and-after screens and affected features, then lets the user choose approve, hold, or reject.
• Who uses it: The operator of a five-branch salon who manages a booking app with an outsourced builder and AI tools.
• Why now: AI can change several areas from a single sentence, so a checkpoint is needed between the build request and the actual change.
• What to put on the first screen: Put today’s list of changes to approve, before-and-after screens, and indicators for effects on customer information, payments, and permissions in one place.

3. Guided hands-on test tracker

• What it does: Lets non-developers follow on-screen instructions to test tasks such as logging in, registering, editing, and cancelling a payment, then save evidence photos of the result.
• Who uses it: The owner of a neighbourhood side-dish shop who built an order-intake service, along with two staff members.
• Why now: A screen opening is different from a real order being processed from start to finish, so evidence from direct user verification is needed.
• What to put on the first screen: Include a test item such as “Complete one new order,” pass and fail buttons, and a field to attach screenshots.

4. Error reproduction packet

• What it does: After receiving an error report, it groups the device, sequence of actions, screenshots, and service version into one packet.
• Who uses it: The manager of a small equipment company that built an AI-assisted inspection app used by field technicians on phones.
• Why now: Sending only a report saying “It will not save” to an AI can cause it to change unrelated features.
• What to put on the first screen: Ask users to select the screen where the error occurred first, then ask in order: “What did you tap?”, “What did you expect?”, and “What actually happened?”

Why this matters where you are

Check whether a recent AI-assisted change in your own work can be traced from the original request through approval, testing, and a rollback version. The tools, regulations, and organisational roles will differ by market, but scattered records create the same operating problem. Start by making one change traceable before adding more building speed.

What to check today

Pick one recent change you assigned to AI. Within 30 minutes, find the original request, the rules that must not change, the result you checked yourself, and the version to roll back to, then write them on one page. If you need to search through three or more chat windows and documents, or cannot find even one of the four items, it may be worth building a tool that connects change records before adding more building features.