AI can build your app. But can you trust what it builds?

You can trust it once you can answer four things about every change: what was decided, what changed, what shows it works, and how you’ll build on it next. Owning your software doesn’t require reading every line of its code. What you can’t hand off are the product decisions, and a reliable way to verify the rest.

AI makes it possible to build software without writing the code yourself. That creates a new problem: how do you know the software does what you intended?

A working demo is one thing. A product with paying customers, real data, integrations, and changing requirements is another. When something breaks, when a customer asks for a feature, or when one change affects another, someone still has to be accountable for what happens.

That doesn’t mean founders need to become software engineers. It means the way AI-built software is planned, reviewed, and maintained has to change.

Engineers are asking the same question

A recent Hacker News discussion (opens in a new tab) asked how to deal with shipping AI-written code you don’t fully understand. It started from an engineer’s post saying that code written with AI felt like a black box, and that checking each line would take forever.

Hundreds of replies followed, and they disagreed on much of it. Several of them apply to founders too.

Building is now easier than owning

Writing code is often no longer the slow part. A feature described in plain words can become a working version in an afternoon.

The harder work comes after. You have to know what the product should do, control what changes, and keep it reliable once customers depend on it. Those jobs didn’t get easier, and they’re the ones a founder can’t fully hand off.

Good software starts with clear decisions

Before any code is written, have the AI ask what it needs to know. Ask it to explain the tradeoffs in plain words, then to show you a plan.

You decide how the product behaves: who can see what, what happens when a payment fails, and what a customer sees after canceling. You can make those calls without designing how the code is organized.

Match the scrutiny to the risk

Not every change needs the same attention. A new button color is low risk. A change to payments, logins, or how your data is stored is not.

One developer in the thread described this split: AI writes almost all the code behind their app’s pages, but they still write the database structure by hand (opens in a new tab). Mistakes there, they explained, tend to be far more serious.

Look most closely where a mistake would cost money, data, or trust.

Ask for evidence that it works

Tests, independent reviews, and checks that older features still work are all useful. So is trying the change yourself, the way a customer would. None of them is a guarantee on its own. How to test an AI-generated product explains what to test and how.

One engineer compared it to overseeing a team before AI, when no one could review all the code. That engineer wrote that human code review reduces, but does not eliminate, the number and severity of bugs shipped (opens in a new tab). Another argued that someone should still be able to explain the code, and warned that tests can be wrong too (opens in a new tab).

So ask what was verified, and what wasn’t.

The real test comes after launch

Your software has to stay understandable as you add features, change business rules, and fix problems.

Imagine a founder who used AI to build a subscription app. Six weeks after launch, they want to add annual billing, prorated upgrades (charging only the difference for the rest of the billing period), and refunds when a customer cancels.

They don’t need to understand the code. They should be able to answer five questions:

1. What billing rules are changing?
2. Will existing subscribers be affected?
3. What happens with refunds and failed payments?
4. How will we verify that existing billing still works?
5. Can we identify and reverse a change that causes problems?

The answers also need to be written down where the next change can find them. If they live only in a chat history, the next change starts from a guess. Why your AI keeps forgetting how your app works explains how to keep them where the AI will read them.

How Forged handles this

Forged connects each change to what was decided, what was built, and how it was verified, rather than reviewing the code alone. Each feature arrives as a pull request, a proposed change to your code that you can read on GitHub.

Dimension	The Forged approach
Understanding your product	An Overview of what your product does, plus notes on the codebase, kept as Forged works
Making decisions	Clarifying questions, then a plan where you accept, edit, set aside, or archive each feature
Risky changes	A Changes data or roles warning on any feature that would change the database or permissions
Controlling what changes	Each feature built in your GitHub repository, where your code is kept, as its own pull request
Evidence it works	Each acceptance criterion marked Passed, Failed, Can’t be checked here, or Not checked, with the test that checked it, or “Checked by reading the code”
Building on it next	Your decisions, and what Forged learned from each change, saved for the next plan

You see what was verified and what wasn’t. Each piece of work has acceptance criteria, the conditions that say when it’s done. Forged reviews the work against them, by a test where it can or by reading the code. A criterion it couldn’t check where it builds and tests changes is marked Can’t be checked here, with the reason, and it holds that work until it’s settled.

What you decided stays with the product. Your answers to a plan’s questions, and what Forged assumed where you didn’t say, are listed under Decisions. After each change merges, Forged saves what it learned about the code, so the next plan starts from it.

Your questions, answered

Should I still read the code AI writes for me?

Not every line.

Know what each change does, look more closely at the risky ones, and ask for evidence that each one works. When customers depend on your app, paying a developer to review the riskiest changes is often worth it.

Can AI review its own code?

Yes, but not as the only check.

An independent review, tests, and your own testing each catch different things. None of them proves the code is correct on its own.

Which changes need the most care?

Anything that touches payments, logins, permissions, or stored customer data.

A mistake there can cost money or trust, and it can be hard to undo.

What should I keep a record of?

The decisions behind each change, what changed, and how it was verified.

Without it, the next change can undo a decision nobody remembers making.

Know what each change did, and why

Connect Forged to your repository, and plan your next feature with it.

You don’t need to write every line of your software. You need a reliable way to understand, control, verify, and improve what AI builds for you.