AI writes code, but who is responsible for the result?

AI can already create functions, fix errors, write tests, and modify several project files at once. The ability to generate code quickly does not, however, mean that the code solves the problem correctly, follows the architecture, or is safe for users. Responsibility for the result still belongs to the specialist or team that accepted the change and released it into the product.

AI-generated code should be treated as a proposal from an unverified external contractor. It may look convincing, compile successfully, and pass a simple test while still containing incorrect business logic, weak permission checks, a vulnerability, an outdated method, or a nonexistent dependency. The main question should therefore be not “does the code work now?” but “do we understand its behaviour in every important scenario?”

Safe work begins before generation. The task should include context, constraints, acceptance criteria, architecture rules, and security requirements. The more precisely the developer describes permitted actions, data formats, user roles, and failure scenarios, the lower the chance of receiving a visually polished but dangerous solution.

Access keys, passwords, clients’ personal data, private source code, and internal documentation must not be shared with AI without proper consideration. The company must define which tools are permitted, what data may be sent to a model, how that data is stored, and whether it is used for training. Secrets must remain in secure stores and must never appear in prompts or the repository.

Changes are best generated in small parts. One limited module is easier to understand, verify, and roll back than a large set of files rewritten by AI in a single request. Every change needs a clear diff, an explanation of the reason, a connection to the task, and a developer who accepts responsibility for approving the result.

After generation, the code must pass normal engineering controls: manual review, linters, type checking, unit and integration tests, dependency scanning, secret detection, and static security analysis. Authentication, payments, personal data, and administrative functions require additional review by a specialist who understands the relevant risk domain.

Dependencies require particular attention. AI may suggest an outdated package, a library with an unsuitable licence, or even a plausible but nonexistent name. Before installation, the official source, reputation, update date, known vulnerabilities, licence, and actual need for the dependency must be checked. A smaller number of verified components is generally safer than many randomly added libraries.

AI agents that can run commands and modify files should not immediately receive full access to production infrastructure. They need an isolated environment, minimal permissions, an allowlist of tools, and mandatory confirmation for irreversible actions. Work with production, payment systems, client databases, and secrets must follow separate controlled procedures.

Responsibility does not end when the code is merged. The change should be released through CI/CD, tested in a staging environment first, and then deployed gradually while errors, performance, and user behaviour are monitored. The team must be able to disable the feature or roll back the version quickly if AI-generated code causes a problem under real load.

A strong team neither bans AI nor trusts it unconditionally. It uses AI to accelerate work while preserving the traceability of every decision: who defined the task, what was generated, which tests were run, who conducted the review, and who approved the release. This process turns AI from a source of new risks into a controlled engineering tool.