How to Trust AI-Generated Code: 8 Verification Rules for Solo Builders

The Illusion of the Working Screen

When the first demo build of my ShopifyShopifyA global commerce platform hosting digital and physical storefronts, supporting localized translations, checkouts, and custom apps.Read More → membership app finally compiled without errors, I was ecstatic. A clean, responsive dashboard lit up the browser. Toggle buttons switched on and off seamlessly, and the point-allocation forms updated dynamically. Every click triggered a satisfying UI transition. It had taken me just two days of feeding high-level promptsPrompt EngineeringThe practice of structuring, refining, and optimizing textual inputs to instruct generative AI models to produce desired outputs.Read More → into an AI coding assistant. At this rate, I thought I could publish it to the ShopifyShopifyA global commerce platform hosting digital and physical storefronts, supporting localized translations, checkouts, and custom apps.Read More → App Store by next week.

The excitement evaporated the moment I ran a real transaction. Using a test account to purchase a membership plan and accrue points did absolutely nothing. Digging into the source files revealed a sobering reality: the numbers displayed on the shiny dashboard were dummy values hardcoded into the component. The actual billing API integrations, webhook handlers, and discount triggers did not exist. Not a single line of functional backend logic had been written. It was a beautiful, hollow shell.

I am not a trained software engineer. I work as an IT Product Manager, and in my spare time, I act as a solo builder, launching side projects with the help of AI agentsAI AgentAn autonomous software entity that perceives its environment through sensors, makes decisions, and executes actions using tools.Read More → like Gemini, Claude, and Codex. Over the past year, I have built a web analytics SaaS called AttractiveWebAI, ShopifyShopifyA global commerce platform hosting digital and physical storefronts, supporting localized translations, checkouts, and custom apps.Read More → merchant plugins, and a macOS window management utility.

Early on, I was intoxicated by the velocity. I would describe a feature, and within seconds, a wall of code would appear. But as the applications grew and subsystems began to interact, the debt hidden beneath the surface came due all at once.

---

10 Ways AI Quietly Broke My App

My shipping log is filled with painful, highly specific failures that compiler checks missed completely:

1. The Ghost Database: The UI happily threw a "Saved successfully" toast message, but the data never reached the Supabase tables; it simply lived and died in local client memory.
2. Disconnected Endpoints: Frontend buttons and forms were fully rendered, but the corresponding API call functions were omitted entirely.
3. Forgotten Mocks: Placeholder arrays and Mock API responses introduced during early testing remained active in production mode.
4. Redundant Implementations: Lacking global context of the codebase, the AI would re-generate existing helper functions or React components under slightly different names, bloat-charging the repo.
5. Regression Loops: Fixing a minor layout issue on one page silently broke critical state management logic on an unrelated route.
6. The Build Pass Trap: Running npm run build compiled flawlessly, yet the app crashed into a blank white screen during runtime due to an unhandled edge case.
7. The Stub Out: The assistant proudly declared a task "complete," but looking at the file, the business logic was replaced with a single comment: // TODO: Implement actual billing logic here.
8. Stale Schema Migrations: Moving from a staging Supabase instance to a production one, the environment variables were updated, but the SQL tables, schema relationships, and DB triggers were left behind.
9. Invisible Business Logic: On the ShopifyShopifyA global commerce platform hosting digital and physical storefronts, supporting localized translations, checkouts, and custom apps.Read More → merchant app, the layout was complete, but Billing API webhooks and discount coupon generation APIs were completely unlinked.
10. OS Permissions Failures: On the macOS preview utility, system panels showed screen recording and accessibility permissions as "granted," but the app’s runtime code failed to register the authorization, causing a silent crash.

Staying up late resolving these issues taught me a vital lesson: the real bottleneck in AI-assisted development is not writing the code. It is the human verification process—proving that a change is actually complete and safe. Without this discipline, your codebase degrades into an unmaintainable swamp.

Here are the 8 verification rules I live by to keep my code quality intact.

---

Rule 1: Write a Definition of Done Before You Ask

Asking an AI to "build a login system" is an open invitation for lazy defaults. Instead, I write a specific list of acceptance criteria directly into the prompt:

[Definition of Done]
1. Users must be able to log in using Google OAuth.
2. Session cookies must persist across page refreshes and browser restarts.
3. Clicking "Log Out" must clear the session and redirect the browser to the homepage.
4. Unauthenticated requests to private API endpoints must return a 401 Unauthorized status.
5. Database RLS policies must restrict data access to the owner's session token only.
6. No raw tokens or credentials should be logged to the browser console.

By presenting clear boundaries, the AI is forced to write robust exception handling and validation code from the start.

Rule 2: Never Accept "Complete" at Face Value

When an AI agentAI AgentAn autonomous software entity that perceives its environment through sensors, makes decisions, and executes actions using tools.Read More → announces that a feature is done, that is when you should be most suspicious. I always follow up by demanding a detailed breakdown:

• List all modified or newly created files.
• Describe the exact changes made to each file and the reasoning behind them.
• Identify any mock data, stubs, or placeholders left behind.
• Show the exact locations of TODO comments or console.log statements.
• Outline any edge cases that were skipped due to API limitations.

Forcing the AI to explain its output regularly reveals hidden shortcuts or promptsPrompt EngineeringThe practice of structuring, refining, and optimizing textual inputs to instruct generative AI models to produce desired outputs.Read More → it to rewrite unfinished blocks.

Rule 3: Separate Build Success from Functional Success

Passing a linter check or getting a successful build output is merely the baseline. Once the build finishes, I manually run a verification checklist:

• Persistence check: Input data, save it, force-refresh the tab, and confirm the data is pulled correctly from the live database.
• Input torture: Submit empty forms, double-click action buttons rapidly, and input invalid characters to test stability.
• Permissions test: Log out, try to access dashboard routes directly, and ensure no unauthorized data leaks.
• Console audit: Keep the browser Inspector open during testing to catch any silent warnings or 404 resource errors.

Rule 4: Shrink the Surface Area of Requests

Asking for a "dashboard page with analytics integration" in one go leads to messy code and missed requirements. I break implementation down into sequential micro-tasks:

1. Define the DB table schemas and migrate them.
2. Write and test the API endpoint independently.
3. Build the UI layout with mock values.
4. Bind the real API endpoints to the UI components.
5. Write error-boundary components to handle network drops.
6. Verify behavior on staging and refactor.

Rule 5: Keep Creator and Reviewer AIs Separate

An AI model has a natural cognitive bias toward its own generated code in the same session.

To bypass this, copy the generated code, open a completely fresh session (or use a different model), and prompt it with a critical persona:

"You are a senior systems engineer and an aggressive QA specialist. Review this code for potential security flaws, edge-case failures, unhandled exceptions, and performance leaks. Be brutal."

This split-brain approach gives me access to an objective peer-review process that caught dozens of unhandled database connection leaks in AttractiveWebAI.

Rule 6: Track Feature States via a Granular Matrix

Saying a feature is "working" is too vague. To keep myself honest, I maintain a simple feature status matrix in my notes:

• Unimplemented: Planned, no code written yet.
• UI Only: Visual components rendered, no backend connection.
• Mocked: Interactive elements run on local dummy data.
• API Connected: Communicates with local backend services.
• DB Persisted: Writes to and reads from a persistent database.
• QA Verified: Tested for error paths and edge cases.
• Prod Verified: Verified on the live production environment.

This matrix prevents me from assuming an application is complete just because the landing page looks polished.

Rule 7: Force Context Analysis Before Any Code Mod

Do not drop a file into a chat and say "fix this." The AI will often throw ad-hoc solutions that violate the existing architecture. Instruct it to analyze first:

"I want to modify this file. Before writing any code, analyze the existing design patterns, the data flow, and how this file interacts with other parts of the application. List the functions that might be affected by changes."

Only after the AI successfully maps the dependencies do I allow it to write the refactored code.

Rule 8: Document Tech Debt Openly

Taking a shortcut to hit a launch deadline is sometimes necessary. The danger lies in forgetting where those shortcuts are. I keep a dedicated tech-debt.md file in the root of my repositories:

## Active Technical Debt

* [AttractiveWebAI] Dashboard chart uses temporary mock data (must connect Google Analytics pipeline before public launch).
* [ShopifyShopifyA global commerce platform hosting digital and physical storefronts, supporting localized translations, checkouts, and custom apps.Read More → App] Missing webhook validation for billing updates (major security risk; address before app store submission).
* [macOS Utility] Hardcoded 3-second delay used for permission polling (replace with system event listener).

Keeping the debt visible guarantees that my next development sprint has a clear list of priorities.

---

Shipping Software That Actually Works

AI coding makes development feel light and effortless. Watching lines of code materialize out of simple sentences creates a false sense of control.

But a reliable product is not measured by the lines of code generated. It is defined by the exceptions handled, the edge cases tested, and the dummy mocks successfully removed. A product built on unchecked AI assumptions collapses the moment real users interact with it.

AI is an exceptional assistant and an incredibly fast typist. But the responsibility for setting boundaries and verifying quality belongs entirely to the human builder. Investigating the silent logs, checking the database states, and verifying raw code is the real work of engineering in the AI era.