How I Use AI to Build Software Without Letting AI Own the Architecture

AI is part of my development toolchain. I use tools such as Claude and ChatGPT to accelerate work across web and mobile projects, including exploration, repetitive implementation, debugging, and content structure. I do not treat their output as a specification, an authority, or a substitute for understanding the codebase.

That distinction matters most after the first impressive answer. Generated code can look tidy, use convincing names, and still be wrong for the installed SDK version, the security model, or the way an existing app actually behaves.

AI Is a Tool, With Different Failure Modes

I think of AI alongside documentation, IDE tooling, static analysis, and code review assistance. Each is useful for a different kind of leverage.

Documentation is usually the source of truth for platform behavior. Type systems catch a class of local mistakes. Tests describe expected behavior when they are good. AI is particularly good at turning a bounded request into a useful first draft, finding relevant areas of a codebase, suggesting hypotheses, or making an unfamiliar API easier to interrogate.

Its failure mode is confidence. A response can invent an API, recommend a deprecated method, assume an environment variable is secret because its name sounds private, or build an elegant abstraction around a problem the existing product does not have. That makes validation non-negotiable.

What I Delegate

The highest-value uses are usually the ones where I can state the problem and inspect the result:

• boilerplate, repetitive UI, and strongly patterned implementation;
• targeted codebase searches and summaries before changing a feature;
• initial test cases and edge-case checklists;
• mechanical refactors and migration drafts that I can review as a diff;
• debugging hypotheses when an error message is unclear;
• API exploration, documentation drafts, and configuration audits;
• first-pass data structures or content models.

For example, DevGuess has enough moving parts—technology metadata, hints, APIs, share output, and a game loop—that fast codebase orientation is valuable. In a React Native app, AI can speed up a repetitive screen or help enumerate the states around a purchase flow. It turns blank-page time into reviewable material.

Ritual Grove is a useful reminder that an accelerated prototype is not the end of the work. Turning a rough idea into a shipped app still meant making UX decisions, debugging behavior, preparing store materials, testing purchases, and deciding what the product should and should not promise.

What I Do Not Delegate Blindly

Some decisions need an accountable owner because they define the system's boundaries:

• architecture and data ownership;
• authentication, authorization, and Row Level Security;
• payment and entitlement logic;
• privacy choices and sensitive-data handling;
• server-authoritative state and trust boundaries;
• production deployment and rollback decisions;
• accepting a change that has not compiled, tested, and been read.

An AI can propose options for those areas. It cannot know which tradeoff fits the product without the surrounding context, and it cannot accept responsibility if a subtle breach or outage reaches users.

This is why “the client says the user is premium” is not enough for a server-backed paid feature, or why a provider token is not automatically an authorization rule. Those are architectural facts, not implementation preferences. They have to remain consistent across the app.

The Ways AI Goes Wrong in Practice

The failures are rarely cartoonishly bad. They are plausible.

An answer may use a method removed in the current Expo or Supabase version. It may assume an OAuth redirect works in Expo Go even though a custom scheme requires a development build. It may put a privileged key in an EXPO_PUBLIC_ variable, because it has not distinguished public configuration from a secret. It may overengineer an offline sync layer for an app whose core product is intentionally local and account-free, as PassportPlate is.

Those mistakes are why I prefer narrow prompts tied to actual files: “inspect this flow, preserve this contract, list the risks, then propose the smallest diff.” A tool can help generate a solution; it should not silently redefine the problem.

My Validation Loop

My practical loop is straightforward:

1. Define the user problem, constraints, and what must not change.
2. Inspect the existing code and its tests before requesting an implementation.
3. Ask for a targeted change, alternative, or audit—not a vague rewrite of the whole system.
4. Review the diff for ownership, state flow, error handling, and accidental scope expansion.
5. Run type checks, linting, tests, and a production build.
6. Test the real behavior on the relevant device, browser, account state, or network condition.
7. Verify security- and platform-critical claims against official documentation.
8. Iterate until the implementation and the product behavior agree.

Compilation is a useful gate, not proof of correctness. It cannot tell me whether a first-launch flow makes sense, whether a server trusts the wrong input, whether an App Store reviewer can restore a purchase, or whether an offline write survives a reconnect.

Architecture Still Needs an Owner

The value of architecture is consistency. Authentication affects data access. The data model affects offline state and migrations. Monetization affects what a server must verify. Analytics and privacy choices affect disclosure. Error handling affects whether people can recover when any one of those systems fails.

AI can contribute to each area, but someone needs to maintain the map between them. That is the part I keep explicit when building and maintaining projects: where state lives, which component owns it, what data crosses an API boundary, what can be trusted, and which failures need a user-facing answer.

That is also why I keep product scope close to architecture. A simple offline app such as 100 Reps or Ritual Grove can avoid a backend for its core loop. A shared or account-backed feature earns a backend only when the product promise needs it. More infrastructure is not automatically more professional; justified infrastructure is.

More Capability, Not Automatic Correctness

For an independent developer, AI makes it more feasible to explore ideas, inspect unfamiliar systems, and maintain several focused projects without pretending that one person can know everything instantly. It shortens some feedback loops. It does not remove the need for judgment, testing, or ongoing maintenance.

The healthy outcome is not “AI wrote the app.” It is a developer who can move faster while still being able to explain the system, verify important claims, and own the consequences of the code that ships.

Summary

I use AI as an accelerator for reasoning and implementation, then apply the same engineering discipline I would apply to any other contribution: inspect context, review the change, run the checks, test reality, and verify the claims that matter. Architecture still needs an owner. That responsibility is exactly what makes AI-assisted work useful instead of merely fast.