Can AI-Written Code Go to Production? 7 Key Points You Must Check

AI coding agents can now generate a complete application in minutes—including frontend, API, database models, authentication logic, and tests—something that used to take days just a few years ago. But a critical question follows: Would you be willing to put AI-generated code in front of real users, real money, and real production data?

A working demo and production-readiness are two different things. The original author systematically breaks down the seven most easily overlooked risk areas in AI-assisted development. Let's unpack them layer by layer.

1. Code That Runs Is Not the Same as Code That Is Correct

Take an API endpoint that "returns a project by ID" as an example. AI typically writes it like this:

app.get("/projects/:id", async (req, res) => {
  const project = await db.project.findUnique({
    where: { id: req.params.id }
  });
  res.json(project);
});

The logic looks fine—but what happens when one user requests another user's project? Without verifying data ownership, you've just created a privilege escalation.

A safer approach is to include ownerId as part of the query condition:

const project = await db.project.findFirst({
  where: {
    id: req.params.id,
    ownerId: req.user.id
  }
});
if (!project) {
  return res.status(404).json({ error: "Project not found" });
}

The point of this example isn't that "AI always writes insecure code"—it's that a successful response doesn't prove the endpoint is secure or correct. Humans must understand what the code is supposed to protect.

2. Passing Tests Can Still Miss Critical Problems

Tests are necessary, but they can only tell you that "the scenarios you tested" work.

Suppose AI generates a payment feature and you test four scenarios: successful payment, invalid payment rejected, amount displayed correctly, and confirmation message shown. All pass—so is the payment system ready for production?

Not necessarily. The more critical edge cases are often not covered:

• What happens if the payment provider confirms success but your database update fails?
• What happens if the payment provider sends the same webhook twice?
• What happens if the user retries the request because the first response was delayed?
• What happens if someone tampers with the price in the request before submitting?

These issues involve failure recovery, retries, concurrency, and trust boundaries. Payment systems typically need idempotency (the same operation or webhook processed multiple times should not result in duplicate charges), server-side price validation, and reliable reconciliation with the payment provider. AI can help you implement these safeguards, but developers must verify that they actually exist and behave correctly.

Passing tests only means the tested scenarios passed—it doesn't mean all important scenarios are covered.

Idempotency is a core concept in distributed systems: executing the same operation once or multiple times should have exactly the same effect on system state. In payment scenarios, the payment provider may resend the same webhook due to a network timeout, and users may click "Pay" repeatedly because the interface seems unresponsive. If the server lacks idempotency guarantees, the same order could be charged twice or shipped twice.

Common approaches to implementing idempotency include: generating a unique idempotency key for each operation and checking whether that key has already been processed before handling it; adding unique constraints at the database level on business identifiers like order numbers so duplicate writes fail immediately; and wrapping "charge" and "record order status" in the same transaction or state machine to avoid inconsistency from partial success.

It's worth emphasizing that idempotency is not a patch you can add after the fact—it's an architectural decision that must be considered during the design phase. AI-generated payment code often assumes "each request comes only once," which is precisely the most dangerous assumption.

3. The Most Dangerous Bugs Are Often the Least Obvious

Broken buttons, crashing pages, and API errors—these bugs are immediately visible. The truly dangerous ones are the problems that lie dormant in production until real users encounter them. The original article lists five categories worth focusing on:

Security and authorization: Does every protected operation verify that the current user has permission to perform it? Authentication answers "who are you," authorization answers "what can you do"—the two cannot be conflated.

Database integrity: Could concurrent requests produce duplicate records? Could deleting a record leave inconsistent related data behind? Are important constraints enforced at the database level?

Error handling: What happens when an external API times out, a database connection fails, or an unexpected value appears?

Performance: Is the interface loading thousands of records when only ten are needed? Is the page making redundant API requests? Will queries become expensive as data grows?

Configuration and secrets: Are API keys exposed in frontend code? Are production secrets stored securely? Does the application fail safely when a required environment variable is missing?

These problems aren't unique to AI-generated code—experienced developers make them too. But when AI rapidly generates large volumes of code, you can easily produce more code than you're capable of reviewing—and that's where the real risk begins.

Authentication and authorization are often conflated, but they play completely different roles in a security model. Authentication answers "who are you"—verifying user identity, typically through password login, JWT token validation, or OAuth. Authorization answers "what can you do"—determining whether an authenticated user has the right to access a resource or perform an action.

The most typical privilege escalation vulnerability occurs between the two: the user is indeed logged in (authentication passed), but the system doesn't check whether they have permission to access the target resource (authorization missing). This problem is especially common in AI-generated code, because AI often only implements the "must be logged in to access" layer while ignoring the "can only access your own data" layer.

The key defensive principle: authorization checks must be enforced server-side and must never rely on hiding buttons or menus in the frontend. For every protected operation, you must explicitly verify the ownership or role relationship between the current user and the target resource. Authentication is the gate; authorization is the true boundary.

4. Stop Only Asking "Does It Run?"

After a feature is done, clicking around for a few seconds and calling it finished is the easiest mistake to make. The author suggests changing the way you ask questions: Have AI critically review its own implementation.

You can give AI a review prompt like this:

Review this implementation as a critical software engineer.
Do not assume the code is correct just because it works.

Check for:
1. Authentication and authorization problems.
2. Data leaks between different users.
3. Input validation issues.
4. Database consistency and race conditions.
5. Missing error handling.
6. Security vulnerabilities.
7. Performance problems.
8. Missing tests and edge cases.

For every finding:
- Explain the actual risk.
- Identify the affected code.
- Describe how the problem could be reproduced.
- Suggest a concrete fix.

Do not claim an issue exists unless you can support it
with evidence from the code or a reproducible test.

This is a useful starting point, but it's not a security guarantee. AI reviewers can miss vulnerabilities or report problems that don't exist. For critical systems, combine code review with automated security tools, targeted testing, and independent verification. Also, don't just ask AI to list problems—ask it for evidence: where the problem occurs, why it matters, and how to reproduce it.

5. Give AI Smaller Tasks, Then Verify the Results Yourself

Another habit that improves reliability: don't dump a large feature into a giant prompt for AI.

Take building a complete subscription system as an example—it can be broken into six stages:

1. Define requirements: Clarify subscription states, payment flows, cancellation rules, access permissions, and failure scenarios.
2. Design the implementation: Before generating code, review the database schema, API contracts, and key security decisions.
3. Implement in slices: Break subscription models, payment integration, webhook handling, and access control logic into manageable chunks.
4. Test each chunk: Check normal behavior, invalid input, duplicate requests, failed operations, and exceptional states.
5. Review integration: Confirm that all components still work correctly when combined.
6. Verify deployment: Check production configuration, database migrations, logging, monitoring, and rollback procedures.

This approach doesn't eliminate bugs, but it makes problems easier to isolate, understand, and fix. You can still move fast with AI—just don't treat speed as the only measure of progress.

API contract refers to the explicit agreement between frontend and backend, or between services, about interface behavior—typically including: request path, method, parameter format and validation rules; response status codes, data structures, and error formats; and behavior in various edge cases (such as what to return when a resource doesn't exist, permissions are insufficient, or parameters are invalid).

Establishing the contract before having AI generate code is valuable because it separates "design decisions" from "code implementation." Once the contract is set, you can first review whether the database schema, permission model, and error handling strategy are reasonable, then have AI implement in chunks. A clear contract also allows frontend and backend to develop in parallel and provides a definitive basis for subsequent integration testing.

Rushing to generate code without a contract commonly results in: inconsistent field names across interfaces, arbitrarily defined error codes, and edge-case behavior that's all guesswork. Discovering problems at the integration stage costs far more in rework than spending time upfront to write the contract clearly.

6. The Developer's Role Is Changing, Not Disappearing

The author's core judgment: whether AI can write code is no longer the most important question—it obviously can. The more interesting question is: when writing code becomes faster and easier, where should developers focus their attention?

The answer is engineering judgment: understanding requirements, choosing appropriate architectures, identifying risks, verifying implementations, and being accountable for the results. AI can help in all these areas—explaining unfamiliar code, suggesting alternative architectures, generating tests, identifying potential vulnerabilities, and automating repetitive work.

But "generating a suggestion" and "proving the suggestion is correct" are two different things. As AI tools become more powerful, understanding the fundamentals becomes more valuable, not less—you need to be able to judge whether an implementation is reasonable, whether an assumption is dangerous, and when more evidence is needed.

7. A Practical Checklist Before Shipping AI-Generated Code

Before deploying an AI-assisted feature, the author recommends confirming each item:

• Does the implementation meet the real requirement?
• Are authentication and authorization enforced server-side?
• Can one user access another user's private data?
• Is input validated server-side?
• Does error handling leak sensitive information?
• Have important edge cases been tested?
• Could retries or concurrent requests cause duplicate or inconsistent operations?
• Are secrets excluded from public code and logs?
• Have database queries and API calls been reviewed for performance?
• Have automated checks and relevant security tools been run?
• If the feature breaks, can it be monitored and rolled back?

Not every feature needs the same level of scrutiny. A personal prototype and a production payment system have completely different risk profiles—the greater the potential impact of failure, the more evidence and independent verification is needed.

Final Thoughts

AI coding agents have genuinely changed the speed of building software, and that's a good thing. Developers can experiment faster, automate repetitive tasks, and spend time on more meaningful problems.

But faster code generation doesn't automatically produce more reliable software. A working demo is not proof of security, passing tests are not proof of completeness, and AI saying "implementation complete" is not evidence that a feature is production-ready.

The real skill is knowing how to turn generated code into software you're willing to maintain. Don't just let AI help you build the application—also let it help you prove the application is correct. Then verify that evidence yourself.