In Ratatouille, Chef Gusteau believes cooking should be open to everyone. Remy is less convinced: the ability to cook does not necessarily mean someone should be let loose in the kitchen. Their brief exchange captures a tension that now feels familiar in software development.
Give someone an AI coding assistant, and they can turn an idea into a working application. A dashboard. A customer portal. An automation that removes hours of repetitive work.
That is a remarkable opportunity. People who understand a business problem can participate directly in solving it, even when they have never considered themselves developers.
But a working application is the beginning of a responsibility.
Someone still has to decide where its data belongs, who can access it, how changes reach production, and what happens when something breaks. Someone has to ensure it fits the company’s systems, policies, and ways of working.
Anyone can produce a dish. A restaurant needs a whole kitchen behind it.
When experiments become essential
Consider a scenario.
An employee wants a better way to track customer requests. With an AI coding assistant, they build a small application. It looks good, saves time, and quickly attracts a few colleagues.
They connect it to real customer data. They add a background process to keep everything updated. To make it accessible, they share a link.
Within a few weeks, the team depends on it.
But the application runs on the employee’s laptop. Its integration uses a personal credential. Nobody has agreed who should have access, tested a backup restoration, or documented how to maintain it. When the laptop closes, the background process stops.
The code might perform exactly as intended. The business still has an unmanaged dependency.
Nothing about this requires malicious intent or an incompetent coding tool. Each step can feel reasonable when the immediate objective is simply to make something useful.
The difficulty is recognising when an experiment has become a system other people rely on.
The work beyond code
Software development contains a great deal of work that is barely visible in a successful demo:
- Architecture and consistency. Should this feature extend an existing application? Which database, framework, and shared components should it use? How does it fit the company’s existing systems and interface conventions?
- Data integrity. How can the database structure change without damaging existing records or interrupting other applications? If a request is retried, will it create a duplicate payment, ticket, or customer?
- Change management. Where is the code versioned? Which branch contains the change? How are concurrent work, rebases, reviews, releases, and recovery handled?
- Requirements and evidence. What was requested, and what counts as success? Can someone follow a Jira issue or support ticket through implementation, tests, evidence, and release? Does closing the ticket mean the user’s problem was actually resolved?
- Environments and workstations. Which runtimes, dependencies, containers, and local services are approved? Can another person reproduce the setup? Are development, test, staging, and production data and credentials appropriately separated?
- Operations and ownership. Who monitors the application, controls its costs, updates its dependencies, responds to failures, and maintains it when its creator moves on?
There are also decisions about the experience people receive. Two applications can work correctly while presenting conflicting interfaces, calculating the same business metric differently, or maintaining competing versions of the same customer record.
And company policies apply throughout the process. An AI usage policy may determine which tools and accounts are approved. Privacy requirements influence what data can enter prompts, logs, screenshots, and test evidence. Access rules determine which systems a person—or an agent acting for them—may read or change.
These responsibilities remain even as code generation improves.
In fact, we can make the argument without debating whether AI writes good code at all: even if every generated line were correct, these questions would still need answers.
Give AI the context
Codex and Claude Code can help with much of this work. An agent can inspect an existing architecture, prepare a database change, work on a branch, run tests, document evidence, and update an issue.
But it needs the company’s context. A request to “build a customer dashboard” does not, by itself, explain which customer system is authoritative, which fields are sensitive, or which approval is required before release.
The same applies to experienced developers joining an unfamiliar organisation. Technical capability and institutional knowledge are different things. Both matter.
The encouraging part is that this knowledge can become part of the development environment.
Codex supports shared project instructions through AGENTS.md. Claude Code supports persistent guidance through CLAUDE.md. Skills, custom plugins, and integrations can provide reusable workflows and access to the systems where work is tracked.
Instead of repeatedly explaining how the company develops software, teams can maintain guidance alongside that software: which components to reuse, how to test a change, where evidence belongs, and what must happen before an issue is considered complete.
Back guidance with controls
An instruction telling an agent to avoid production data should be backed by credentials and permissions that restrict access. A requirement to run tests should be supported by release checks. Approved environments should make the expected setup easy to reproduce.
Claude Code’s documentation explicitly distinguishes instructions that guide behaviour from permissions that control actions. That distinction is essential to a dependable company setup.
People also need a clear understanding of their responsibilities. Freedom to experiment can be broad, while access to sensitive information and authority to release changes depend on the person’s role and the consequences of the application.
Experienced engineers remain central to this model. Their judgement shapes the architecture, establishes the controls, reviews consequential changes, and turns lessons from individual projects into foundations others can reuse.
Where Guanta helps
At Guanta, we help companies build that environment around AI-assisted development.
The work starts with the organisation: its systems, data, policies, teams, and operating responsibilities. From there, we bring together development guidance, reusable components, integrations, controlled environments, and workflows that connect a business request to a verifiable outcome.
The aim is to make the company’s standards part of how work gets done, so people can spend more time solving useful problems with AI.
That is how broader participation becomes sustainable. Someone with a good idea should be able to explore it, build on existing foundations, and follow a clear path towards something the organisation can support.
The promise behind “anyone can code” deserves to become real.
Give them a kitchen built for it.