Building AI products with Claude, Codex, and human review.

My current development workflow did not begin as a planned toolchain. It evolved while I was building real products, encountering changing token limits and pricing, and learning which assistants were most useful for product thinking, interface design, backend work, integrations, and review.

The result is not a process in which one model writes an entire product. Claude, Codex, ChatGPT, GitHub Copilot, VS Code, GitHub, and Figma each occupy different parts of the work. I still decide what should be built, examine the code and commits, test the behavior, and determine whether an output belongs in the product.

Ask Swedenborg began as a two-week project

Ask Swedenborg began as a focused two-week build: a working research application for exploring Swedenborg’s writings while keeping the source material visible. The initial stack was intentionally pragmatic—PHP, HTML, CSS, JavaScript, MariaDB, semantic retrieval, and a controlled theological corpus.

The application did not stay frozen after that first release. It grew into a bilingual research workspace with corpus search, paragraph citations, saved passages, notes, authentication, and an early source-grounded writing workflow. As the scope expanded, the development environment expanded with it.

The toolchain changed with the work

The project was maintained in a GitHub repository from the beginning, giving the work a durable history outside any individual assistant. I initially updated the application in VS Code with Codex support. In a second coding stage, I adopted GitHub Copilot while generous credit and token allocations made that workflow practical. When those conditions changed, I added the Continue extension in VS Code and connected it to models through OpenRouter. That created flexibility, but also introduced another layer of configuration and context management.

When Codex developed its own working interface and GitHub integration, I began using it more directly. The conversation, repository context, file changes, validation, and deployment work could remain part of one continuous product task instead of being split across editor prompts.

Later, limits attached to monthly usage again influenced the balance. I started using Claude more extensively for design exploration and complex backend work. Figma remains useful as a visual canvas, but for my current projects Claude is increasingly the place where interface behavior, user flows, edge cases, and their relationship to the implementation are worked through together.

My current division of work

The present workflow is deliberately mixed. It assigns work according to the kind of reasoning and context required rather than forcing every task through one assistant.

• Claude for design and complex backend work. I use it to reason through demanding application logic and to connect UX decisions with the states, data, and constraints underneath the interface.
• Codex for implementation and delivery. It is particularly useful for portfolio pages, landing pages, repository-wide changes, deployment work, and integrations involving tools such as the Stripe CLI and Supabase.
• ChatGPT and Codex as a product-owner-like collaborator. Conversation is used to refine scope, sequence work, challenge assumptions, maintain the plan, and turn decisions into GitHub issues. I remain accountable for priorities and acceptance.
• VS Code for direct inspection. I keep the editor open to read the actual code, review diffs, understand file relationships, and inspect commits visually rather than treating generated changes as a black box.
• GitHub as the record of work. Issues, commits, and repository history preserve the relationship between an intended change and the implementation that followed.
• Figma as a supporting design surface. It is still useful for visual reference and focused prototyping, but it is no longer the center of the design process when design questions need to be resolved together with code and backend behavior.

Design is not separate from implementation

AI-assisted design is most useful to me when it goes beyond producing an attractive frame. A research workspace, evidence inspector, payment flow, or legal decision interface has states that a static mockup can hide: empty results, uncertain evidence, authentication boundaries, interrupted requests, mobile navigation, consent, and changes that must persist across sessions.

Using Claude for design and UX integration makes it possible to discuss those states in the same context as the implementation. The design question becomes not only what should this look like?, but also what is the user trying to understand, what data supports it, what can fail, and what must remain visible when it does?

That does not eliminate visual design tools. It changes when I need them. Figma is strongest when a shared canvas, exact composition, or design-system view is the primary artifact. A conversational coding environment is stronger when the interaction and its technical conditions need to evolve together.

Different products require different stacks

The workflow crosses several products, but it does not force them into one technology stack. Each product uses languages and deployment infrastructure that fit its maturity and problem.

• Ask Swedenborg: PHP, HTML, CSS, JavaScript, MariaDB, Pinecone vector retrieval, Google OAuth, and retrieval-augmented generation over controlled source material.
• iApply.pro: TypeScript, Next.js, React, Supabase/PostgreSQL, authentication and row-level security, AI-provider routing, document ingestion, Stripe, GitHub Actions, Hetzner, PM2, and Cloudflare at the public edge.
• Digital Democracy: TypeScript and Node.js, Next.js, React, Fastify, PostgreSQL, deterministic JSON/YAML rulemaps, Docker, Caddy, MinIO, Mailgun, GitHub Actions, and container delivery through GHCR to Hetzner.
• The portfolio and research pages: lightweight HTML, CSS, and JavaScript, version-controlled locally and deployed directly to conventional web hosting.

This variety matters because “AI product development” is not a programming language or deployment model. AI can assist across discovery, interface work, application code, database integration, testing, documentation, and release operations. The engineering choices still have to fit the product.

Integrations expose the difference between a demo and a product

A generated interface can look complete while avoiding the difficult boundaries around it. Stripe payments require product and price configuration, webhook behavior, test and live modes, and a reliable relationship between billing state and access. Supabase work requires database structure, authentication, policies, and care around which operations a user is allowed to perform.

This is where I use Codex as an implementation partner rather than a code-completion tool. A useful task includes inspecting the existing system, defining the smallest safe change, updating the relevant surfaces, validating the result, and preserving a clear GitHub history. The command-line integration is only one part of the work; the product behavior remains the acceptance criterion.

Agent work can fail after it looks aligned

One of the most expensive failure modes appears before any obvious error. A conversation can feel aligned: the agent restates the goal, produces a credible plan, and begins coding. The implementation can still encode a different assumption, touch more of the system than intended, or build a polished version of the wrong behavior.

The tokens and subscription allocation spent reaching that point cannot be recovered. Neither can the time required to understand the resulting changes. If the implementation is too broad to review safely, continuing to patch it may cost more than returning to a known state and restating the task with tighter boundaries.

This changes how I define agent work. Alignment is not demonstrated by a convincing conversation. It is demonstrated by small, inspectable changes that satisfy explicit acceptance criteria and survive testing.

Testing is where generated confidence meets the product

Testing occupies far more of the workflow than a coding-assistant demonstration suggests. Generated code can be syntactically correct and still fail at a product boundary. The test burden grows with every authentication flow, database rule, webhook, retrieval path, language variant, mobile layout, deployment target, and third-party service.

• Test the smallest logic directly. Rule evaluators, parsers, data transformations, and authorization conditions need repeatable examples—including expected failures and unknown states.
• Test integrations at their boundaries. Stripe test events, Supabase policies, email delivery, OAuth callbacks, database migrations, and provider errors must be exercised rather than inferred from code.
• Test complete user journeys. Signup, login, document upload, analysis, saving evidence, payment changes, and signout cross multiple layers that can each work independently while the journey still fails.
• Test responsive and content behavior. Navigation, article layouts, forms, errors, loading states, long text, and footers need inspection at desktop and mobile widths.
• Test after deployment. A passing local build does not prove that DNS, certificates, environment values, permissions, background services, email, or production data access are correct.

Testing is also how agent scope is audited. When a previously working behavior changes unexpectedly, the failure is evidence that the task affected more of the system than the plan acknowledged.

Deployment is engineering, not the final upload

The original Digital Democracy deployment made this lesson concrete. Soon after the new server was provisioned and the application deployed, the server was compromised and the hosting account was blocked. The first deployment therefore failed—not because the interface could not render, but because the operating environment was not yet sufficiently protected.

I used an agent to help investigate the incident, identify the likely path of failure, rebuild the deployment approach, configure a firewall, and introduce additional server and access protections. The lesson was not that an agent makes infrastructure secure. It was that deployment needs its own threat model, verification steps, monitoring, and recovery plan.

Production delivery also includes services that disappear from a screenshot. Digital Democracy needs Mailgun for signup and transactional email flows. iApply places Cloudflare in front of the application and combines edge protection with application-level access controls, Supabase policies, secret management, and deliberate deployment checks. These are not decorative integrations; they determine whether a user can safely create an account and whether the system can be operated responsibly.

Digital Democracy is being designed with control patterns associated with SOC 1- and SOC 2-oriented operations, including access boundaries, change traceability, audit records, secrets handling, backups, and incident response.

Human review is the control layer

Using multiple assistants does not distribute accountability to multiple companies. The human operator still has to decide whether a suggestion is correct, whether the scope has drifted, and whether a change should reach production.

• Review the intended behavior before the code. A technically valid implementation can still solve the wrong product problem.
• Inspect changes in the repository. Diffs and commits should make the consequence of a task visible.
• Test at the system boundary. Authentication, billing, data access, responsive behavior, and deployment cannot be accepted from a plausible explanation alone.
• Preserve uncertainty. If a tool cannot establish a fact about the code, data, or external service, that gap should become an explicit check—not an invented answer.
• Keep scope recoverable. Small issues, focused commits, and reversible releases make AI-assisted speed safer.

What an independent AI workflow actually costs

Ask Swedenborg, iApply, and Digital Democracy are privately funded products built alongside limited available time. The visible AI-tool budget is roughly the cost of monthly Claude and OpenAI subscriptions. Hosting, domains, email delivery, databases, monitoring, and security create a second operating cost. The largest cost, however, is still the time required to inspect, test, correct, deploy, and sometimes recover the work.

Tool access is now part of production planning. On the plans I use, five-hour usage windows can be consumed quickly by sustained design or complex implementation. The useful response is not to rush more work through the remaining allowance. It is to build a setup that can move between tools without losing the product decision, repository state, or quality bar.

• Match the model to the consequence. Reserve deeper reasoning and larger context for architecture, security, data changes, and difficult design integration. Routine edits and well-bounded implementation rarely need the most expensive option.
• Pause instead of forcing continuity. If one tool reaches its useful limit, preserve the state of the task and stop. I can continue product-owner work with ChatGPT and Codex—clarifying scope, refining issues, defining acceptance criteria, planning tests, or reviewing the result—then return to Claude for complex backend or design work when that is the better fit.
• Know when Auto is enough. Automatic model selection is useful for bounded, low-risk work and early exploration. I steer the model and method directly when the task carries architectural, security, data, deployment, or visual-system consequences.
• Watch the work while it is happening. I follow the agent's plan, file choices, tool actions, and interim explanations rather than waiting only for the final answer. Correcting a false assumption early is far cheaper than reviewing a large implementation built on it.
• Create rules that remove repeated decisions. Repository instructions, scope boundaries, acceptance criteria, naming conventions, test expectations, and deployment checks should make collaboration easier. A useful rule protects an important constraint without preventing the agent from completing ordinary work.

This changes how the work is sequenced. Security, testing, deployment, documentation, and recovery compete with visible feature development, even though those less visible tasks often determine whether a product is credible. GitHub issues, commits, and explicit operating rules provide continuity when subscriptions, interfaces, model choices, or limits change.

That continuity is also why the product-owner conversation matters: it keeps the purpose and next decision available while individual coding and design sessions pause, change tools, or move to a different model.

The assistant is part of the team, not the owner

Calling Codex or ChatGPT a product owner is useful shorthand for how I use conversation: maintaining context, turning broad intentions into bounded work, sequencing the backlog, and checking that implementation still matches the goal. It is not a transfer of accountability. I choose the outcomes, provide domain knowledge, resolve tradeoffs, and approve what becomes part of the product.

The same boundary applies to Claude’s role in design and backend work. A strong assistant can reveal options, connect details, and complete substantial implementation. It cannot decide what is responsible to ship without the product context, evidence, and human judgment around that decision.

A practical AI-assisted product loop

The workflow I use now can be summarized as a repeatable loop:

• Frame: define the user problem, current condition, desired outcome, constraints, and evidence of completion.
• Plan: break the outcome into GitHub issues or bounded tasks with dependencies and acceptance criteria.
• Design: use Claude and, when useful, Figma to explore flows, states, hierarchy, responsive behavior, and the backend implications of the interface.
• Build: assign implementation according to context—Claude for complex backend and UX integration; Codex for repository work, websites, integrations, and delivery.
• Inspect: use VS Code, diffs, and commits to understand what changed before treating the implementation as complete.
• Test: exercise logic, integrations, user journeys, failure states, responsive behavior, and production boundaries.
• Secure: review exposure, identities, permissions, secrets, network controls, dependencies, logs, and recovery before release.
• Release: deploy deliberately, verify live behavior, retain a rollback path, monitor the system, and feed what was learned into the next scoped task.

This is less dramatic than asking one model to build an application from a sentence. It is also more useful. The aim is not maximum generated code. It is a working product whose decisions, implementation, and evidence remain understandable.

More research: Browse all articles and product briefs →