From Prompt to Production: Why AI-Generated Code Still Needs Developers

 AI coding tools can turn an idea into a feature-rich application with extraordinary speed. But speed does not replace architecture, secure development, testing, maintainability or accountable human review. 

AI-assisted software development has dramatically shortened the distance between an idea and a working application.

A member of staff can describe a workflow and see it turned into a prototype. A designer can explore several user experiences in a morning. A developer can ask an agent to implement a feature, refactor existing code, write tests or review a pull request.

This is a meaningful change. It lowers the barrier between understanding a problem and demonstrating a possible solution. It allows ideas to be tested before significant development time is committed, helps experienced developers work faster and enables people who are not developers to communicate what they need more effectively.

It also makes it easier to confuse a working application with a production-ready one.

In an earlier 9ine article, When School Staff Build Their Own AI Apps: Innovation, Accountability and the Hidden Risk, we considered the governance and accountability issues created when staff can build their own applications. This article looks more closely at the engineering question: where AI-assisted development creates value, where it can create hidden technical debt, and what is required to move safely from prompt to production.

AI coding is no longer one type of tool

The term “AI coding tool” now covers products supporting different parts of the design and development process. Examples include:

• Design and interactive prototyping tools, such as Claude Design and Figma Make.
• Prompt-to-application platforms, such as Google AI Studio, Replit Agent, Firebase Studio, v0, Bolt, Lovable and Base44.
• AI-enabled development environments and assistants, such as GitHub Copilot, Cursor, Devin Desktop, Gemini Code Assist, Amazon Q Developer, JetBrains Junie and Tabnine.
• Terminal, repository and autonomous coding agents, such as OpenAI Codex, Claude Code, Google Jules, Devin, Amp, Cline, Roo Code, Aider and Continue.
• AI-assisted code review and quality tools, such as Qodo and CodeRabbit, alongside review capabilities built into wider coding platforms.

These examples show the breadth of the market rather than endorsing or ranking individual products. Some are designed primarily for experienced developers. Others deliberately make application creation accessible to people with limited development experience. They should not be treated as though they produce the same output or carry the same level of risk.

There is also significant overlap. A tool that began as code completion may now plan work, edit multiple files, run commands and open pull requests. A design tool may generate working application code, while a prompt-to-app platform may provision authentication, databases and hosting.

The market is changing quickly. The best tool for a task today may not be the best one next week as capabilities, pricing, data terms and integrations develop. The more important questions are what the tool can access, what it can change, how independently it can act and how its output will be reviewed.

Why organisations are using these tools

The clearest advantage is the speed at which an idea can become something tangible. Traditional development often begins with requirements documents, meetings, wireframes and technical specifications. Those activities remain important, but stakeholders may struggle to understand an idea until they can see and use it.

AI-assisted prototyping makes it possible to create a basic version, test a workflow and explore several designs before committing to a particular direction. This lowers the cost of being wrong. A feature can be demonstrated, challenged and rejected before it becomes a lengthy development commitment, and feedback can be collected against something real rather than something imagined.

This can be particularly valuable in schools and other organisations where the person who understands the operational problem may not have software development expertise. They may not know how to structure an application, but they know where the current process fails, what information is needed and what would save time. AI can help make that knowledge visible earlier.

Experienced developers benefit as well. AI tools can support routine implementation, explain unfamiliar code, suggest refactoring options, generate an initial set of tests and documentation, or provide an additional review pass. Used well, this does not replace the developer. It gives them more time to focus on architecture, integration, security, difficult edge cases and decisions requiring genuine technical judgement.

A working application is not a production service

The visible parts of an application are often the first to appear. The interface looks polished, the buttons work, data can be entered and a dashboard displays information. This creates a strong impression of progress and can make an application appear nearly finished.

Much of what makes software trustworthy is less visible. How is access controlled? Can one user access another user’s information? What happens when invalid data is submitted? Are important actions logged? Can the service recover from failure? Is it accessible? Will it continue to perform as data volumes grow? Can another developer understand and safely change it?

A prototype can show that an idea works. It does not prove that the resulting service can be trusted, integrated, supported or maintained.

AI coding tools generally respond to the task placed in front of them: add a feature, change a screen, connect a data source or fix an error. Without clear architectural constraints, each request can produce another local solution rather than a change that fits coherently into the wider application.

The same logic may be recreated in several places instead of being moved into a shared service. Similar interface components may be implemented differently. Database queries may be duplicated, configuration scattered across the codebase and new dependencies introduced for tasks that existing components could already perform.

Generated code can also use resources inefficiently by making unnecessary API calls, repeatedly processing the same data, loading more information than a user needs or relying on additional services instead of reusing existing capabilities. Each individual change may work, while the overall codebase becomes more expensive to run, harder to test and increasingly risky to change.

This is one of the less visible disadvantages of AI-assisted development: code can be generated more quickly than the organisation can understand or review it. A developer who can generate five times more code does not automatically have five times more time to assure it. The bottleneck may simply move from writing code to understanding, testing and maintaining it.

The appropriate level of oversight should therefore reflect the consequence of failure. A disposable demonstration using synthetic data has one risk profile. A public application processing personal information has another. The mistake is allowing the first to become the second without a deliberate engineering process in between.

A practical lesson from our own development

Our work exploring the 9ine Trust Centre demonstrated both the advantages and limitations of AI-assisted development. It allowed us to move quickly from an idea to a feature-rich working application, explore different functionality and user journeys, and establish which features could provide genuine value.

That learning was useful. However, when the application was reviewed against the requirements for integration into the wider 9ine Platform, it became clear that the underlying code quality, architecture, reuse and maintainability were not at the standard required for direct integration.

The appropriate decision was to retain the learning and rebuild the required functionality within the established architecture of the 9ine Platform. The prototype had not failed: it had helped establish what should be built. It had not, however, produced the production codebase from which those features should be operated

This distinction matters. The value of a prototype should be measured by what it helps an organisation learn, not solely by how much of its original code is retained. AI reduced the time needed to explore the idea, but it did not remove the need for engineering.

AI can amplify good development practices - or bad ones

An organisation would not normally ask a newly appointed developer to build an entire application without providing standards, architecture, existing components, security requirements or a review process. AI coding tools should not be treated differently.

They need context, boundaries, acceptance criteria and review. A mature development process should define:

• The application architecture, data model and approved frameworks, libraries and services.
• The existing components that should be reused rather than recreated.
• How authentication, authorisation, data validation, logging and error handling must work.
• The coding, accessibility, privacy and security standards that apply.
• The tests and automated checks that must pass before a change can be accepted.

These requirements should be made available to the AI tool through repository instructions, technical documentation, examples, automated tests and clearly scoped tasks. Rather than asking an agent to “build the application”, a development team can ask it to make smaller, reviewable changes within an agreed design.

Linters, formatters, type checking, test suites, dependency policies, secret scanning and continuous integration provide objective feedback. Branches and pull requests create controlled points for human review. Architecture records capture decisions that should not need to be rediscovered from prompt history.

The code should then be reviewed by a developer who understands the language, framework and wider application. AI may provide an additional review pass, but asking one AI tool to assess another tool’s output is not a substitute for competent and independent human review.

Without established practices, AI can create inconsistency at speed. With them, it can help a development team apply those practices more efficiently. AI should operate within the development process; it should not become the development process.

Security, access and data risk

AI-generated code is still code. It remains exposed to established application security risks, including broken access control, security misconfiguration, insecure design, authentication failures, injection and software supply-chain weaknesses.

A generated application can appear to authenticate users while relying on weak authorisation behind the interface. It may hide a button without preventing direct access to the underlying function, store a secret in client-side code, grant excessive database permissions, accept data without adequate validation or expose personal information through logs and error messages.

The problem is not that AI is uniquely capable of creating insecure code. It is that it allows more code to be produced more quickly, sometimes by people who are not equipped to recognise the weaknesses it contains.

Security assurance should therefore be proportionate to the application and the consequences of failure. For a production service, this may include human code review, threat modelling, unit and integration testing, static analysis, dependency and secret scanning, dynamic application testing, and manual security testing or penetration testing where appropriate.

Modern coding agents also do more than produce text. They may read an entire repository, write files, execute commands, install packages, connect to databases, create cloud resources, open pull requests or deploy an application. This can make them extremely effective, but it also increases the impact of a mistake or unsafe instruction.

Agents should receive the minimum access required for the task. Development and testing should take place in isolated environments, production credentials should not be available by default, and destructive or high-impact actions should require meaningful approval. Approval is only a useful control when the person granting it understands the likely consequence.

The data risk begins before the application is deployed. Source code, database structures, configuration files, screenshots, error logs, internal documentation and infrastructure details may all be shared with an AI provider during development. A developer may also accidentally include an API key, password, access token, client data or personal information while trying to diagnose a problem.

Approving a product name is therefore not enough. The organisation needs to understand the account type, configuration and contractual terms through which it is used, including:

• Whether submitted content can be used to improve the provider’s models.
• How long prompts, code, outputs and agent sessions are retained.
• Where information is processed and stored, and which data processing terms apply.
• Which repositories and connected systems the tool can access.
• Whether administrators can control access, review activity and remove data.

Test data should be synthetic or anonymised wherever possible. Secrets should not be pasted into prompts, sensitive files should be excluded from agent context, and development credentials should be tightly scoped, monitored and capable of being revoked or rotated.

A statement that information is not used for model training does not remove the need to understand how it is processed, retained, accessed and protected.

Dependencies, licences and provenance still matter

Modern applications rely heavily on third-party libraries, packages and services. AI coding tools can add these quickly, which can be helpful where a well-maintained component avoids recreating a common capability. It can also introduce unnecessary complexity.

Every dependency must be understood, patched, licensed, monitored and eventually replaced. Generated suggestions may rely on outdated documentation, unsupported methods or packages that do not exist. Even where the code works, the organisation still needs to understand where third-party code has come from and whether any licence obligations apply.

AI-generated projects should therefore enter the same software supply-chain process as any other application. Versions should be controlled, unused packages removed, known vulnerabilities monitored and licence requirements reviewed. A Software Bill of Materials should be maintained where appropriate, and source code should live in an organisational repository with version history, access control, review and backup.

Prompt history is not an architecture record, and a conversation with an AI tool is not a substitute for technical documentation.

A practical route from idea to production

Organisations do not need to apply the same level of control to every experiment, but they do need a clear point at which an experiment becomes a development project.

1. Explore safely. Define the problem and create a time-limited prototype using synthetic data. Use AI to explore features, interfaces and user journeys, but do not connect the prototype to production data or systems simply because doing so is technically easy. Record what has been learned and be clear that the output is a demonstration, not an approved service.
2. Engineer deliberately. Assign a developer or technical owner. Define the architecture, coding standards, reusable components, security requirements and acceptance criteria. Decide whether the prototype code should be retained, refactored or replaced, then move the work into an approved repository and break development into small, reviewable changes.
3. Assure independently. Have the code reviewed by someone who understands the language, framework and security implications. Complete functional, negative, privacy, accessibility, performance and security testing according to the risk. Review permissions, logging, error handling, dependencies, backup and recovery before release.
4. Operate it as a service. Assign ongoing ownership and document deployment, support, monitoring, backup, recovery and incident-management arrangements. Plan for changes to the original team, AI tool or underlying dependencies, as well as the eventual retirement of the application.

Secure development does not end when an application is released. Design, development, deployment, operation and maintenance are connected parts of the same lifecycle.

Five questions to ask before trusting an AI-built application

Before an AI-assisted application is treated as a production service, leaders should be able to answer five questions clearly:

1. Who owns and understands the code?
2. Which architecture, coding and security standards has it been built against?
3. What information and system access were provided to the AI tools during development?
4. How has the application been reviewed, tested and independently assured?
5. Who will maintain, monitor, recover and eventually decommission it?

If those answers are unclear, the application is not ready simply because it works in a demonstration.

Conclusion: AI can accelerate development, not accountability

AI coding tools can make ideas visible, reduce the time needed to explore features and help developers complete routine work. They can support testing, documentation, refactoring and review, and allow people who understand a problem to contribute more directly to its solution.

Those are meaningful advantages. The risk arises when speed is treated as evidence of quality. A feature-rich application is not necessarily maintainable, a polished interface is not evidence of secure access control, and a successful demonstration is not proof that an application should be placed into production.

AI can produce code, but it cannot accept acountability for the service that code creates.

Use AI to accelerate discovery, developers to engineer the product, and independent assurance to earn trust.

How 9ine can help

9ine supports schools and EdTech providers in understanding and managing the governance, privacy and cyber security risks associated with new applications and AI-enabled technology. This includes reviewing how technology is introduced, assessing data and security risk, and completing proportionate security testing before systems are trusted with users or sensitive information.