From Chatbot to Production-Grade AI Coding

I do not want to hype AI—or perform skepticism by underrating it

This is neither an AI advertisement nor an article built from a few failure stories to prove that AI is inherently unreliable. I want to do something simpler: open the real production ledger of how I use coding agents, explain what they helped me achieve, where they failed, and how those failures became engineering rules.

For roughly three months, I have been using Claude Code and OpenAI Codex side by side at high intensity. I pay $200 per month each for Claude Max and ChatGPT Pro, and routinely exhaust the weekly allowance on both. That capacity does not go into generating disposable demos. It supports sustained development and operations for BluffKing, a real Texas Hold’em product whose Rust game engine, Axum/WebSocket backend, PostgreSQL database, Vue H5 client, Flutter clients, replay system, and local solver coach evolve inside one production codebase.

I also brought the product into real production or release paths across H5, iOS, Android, and Telegram. The product is online; H5 payment entry points plus the subscription and entitlement system are deployed, and cancellation and refund flows are implemented: Stripe test mode and the Google Play sandbox have full closed-loop purchase, cancel, and refund evidence; Telegram Stars has proven purchase and refund on the test server, while renewal and active-subscription cancel are not yet proven; and Apple’s replay harness is green but still awaits its first sandbox purchase. I will not collapse “code deployed,” “sandbox/test loop proven,” and “every rail has passed real-money production acceptance” into one status: at the time of this review, some wallet, native-store, and on-chain rails still need final production payment or store acceptance. This is not a demo-only project, but it should not be marketed as “every payment rail is green.”

AI did not accomplish this alone. I own product intent, risk tradeoffs, account identity, payment authorization, and final accountability. The division between the two AIs is asymmetric: either can implement ordinary repository work and the other reviews it; work that depends on my signed-in Chrome, a web console, packaging/upload, or a store console goes directly to Claude Code, while Codex mainly reviews the diff, command output, and page evidence. When Claude hits a quota interruption or Codex takes implementation ownership, Claude becomes the reviewer. The useful story is the path between “can chat” and “can participate in production.”

Who this article is for

• You have used ChatGPT, Claude, or a similar conversation product and asked AI to write functions or scripts.
• You maintain a real repository, tests, CI, and a production environment, but you do not yet trust an agent to participate at scale.
• You want the speed while worrying—correctly—about hallucinations, secrets, bad deployments, and polished but false claims of completion.

What you should gain from reading it

You do not need to copy my entire system. The goal is to build a map of AI coding—model, terminal, shell, CLI, agent, local/cloud/remote control, memory, MCP, skill, plugin, workflow, harness, and hooks—then see how those layers connect in a real project, and finally complete one small production-grade change that is verifiable, reversible, and reviewable.

I recommend AI coding not because AI stops making mistakes, but because those mistakes can be constrained, detected, and repaired through engineering—while, for me, the productivity gain has been real.

Put each concept back in its own layer

GPT, ChatGPT, Codex, Claude Code, a terminal, and a CLI are not competing instances of the same thing. They belong to different layers of one execution chain:

My explicit recommendation for a beginner

If your goal is to bring AI into a real repository, start a coding-agent CLI—Codex CLI or Claude Code—from that repository’s terminal. Do not begin by chasing whichever model tops a temporary ranking. Pick an agent that can inspect your repository, run its existing tests, show a real diff, and expose a clear permission boundary.

• Why not make a normal chat window the primary surface: it is excellent for explanation and discussion, but may not have the current repository, command execution, or verifiable evidence.
• Why terminal + CLI first: the working directory, Git state, environment, test output, and exit codes are directly visible, and the same path can later become a scripted workflow or harness.
• Where the IDE fits: keep using it to read code, inspect diffs, and debug manually. Adopting an agent does not require abandoning the editor you know.
• When to add dual AI: first complete one small “task → diff → verification → rollback” loop with one agent; then add a second reviewer in a fresh, preferably read-only context.

Codex or Claude Code: choose by the environment you actually need

Why the terminal has always been my daily entry point

For me, the terminal is not a more “professional” chat box. It is the engineering worksite. When the agent starts in the correct repository or worktree, the current directory, Git state, dependencies, environment variables, command output, and exit codes belong to one evidence chain.

cd /path/to/project
git status
codex        # or: claude

My usual path is: enter the project directory → start Codex or Claude Code → state the goal, constraints, and definition of done in natural language → let the hooks check whether the session is already isolated. A read-only task can stay in the current directory. If the agent tries to write code in the shared main worktree, a hook blocks the write and requires it to call the project script that creates a dedicated worktree. The agent then reads files, changes code, and runs tests there. This is what lets multiple sessions work in parallel without sharing one HEAD or one set of uncommitted changes. Finally, I have the other AI review the actual diff and verification evidence. The commands, working directories, Git rules, permissions, and hooks later in this article all grow from this entry point.

“Remote” is not one thing: conversation, cloud sandbox, and control of a local agent

The most important question is not whether you send the prompt from a phone or computer. It is: which machine actually runs the code and commands?

Remote Control is also not Computer Use. Remote Control means a person drives a local agent session from elsewhere. Computer Use means the agent itself sees, clicks, and types in an operating-system or application UI. They can be combined, but their authority and risk are separate.

Browser, Computer Use, and “control my existing Chrome” are three different paths

OpenAI’s built-in Browser uses a profile separate from your everyday browser. Computer Use can operate desktop applications and graphical interfaces. Only the Chrome-extension path connects to the Chrome profile I am already signed into and using. All three can look like “the AI is clicking a browser,” but they have different permissions, dependencies, and failure boundaries.

My actual workaround is not to test Codex before every browser task; I route the work by tool reliability. Anything that needs my signed-in Chrome session or a web console goes to Claude Code—for example, filling out Stripe dashboard forms, packaging and uploading iOS or Android apps, and working in the store consoles. Codex serves mainly as the reviewer for this work: it checks the code diff, command output, recorded state, and the browser evidence produced by Claude instead of performing the browser operation itself. This does not mean the Codex Chrome path is fixed. It means I do not let a repeatedly failing toolchain block production work.

One capability map—not another chapter numbering scheme

This is a relationship map: it shows how capabilities stack, not six installation stages you must follow in order.

Make your first AI task deliberately small

Do not begin with “rewrite my entire application.” Do not hand over payments, authorization, or a database migration on day one. A good first task has a clear boundary, a testable result, and an easy rollback:

• fix one reliably reproducible bug;
• add boundary tests to an existing function;
• add one form validation or error message;
• refactor a function with explicit inputs and outputs;
• ask the AI to explain one call path without changing code.

Your first trustworthy small loop matters more than your first thousand generated lines.

A five-part task brief is enough

You do not need prompt magic. State these five things clearly:

Goal: Show the server’s specific error when login fails.

Observed behavior: Every failure currently says “Network error.”

Scope: Change only the login request and error display. Do not redesign the page.

Acceptance criteria:
1. A wrong password shows the correct message.
2. A disconnected network still shows the network error.
3. Successful login remains unchanged.
4. Add a regression test.

Constraints: Do not change the API contract or add a dependency.

If you cannot define what “correct” means, the model can only guess. Write the acceptance criteria before asking it to implement.

A workflow you can copy today

Step 1: protect existing work, then isolate the change

Record the current branch, baseline commit, working-tree status, and worktree list first. If uncommitted changes already exist, determine who owns them; never let an agent stash, reset, clean, or restore the whole repository on its own. Write each new task only in an isolated feature worktree, and never let two agents share one working directory.

git branch --show-current
git rev-parse HEAD
git status --short
git worktree list

# After confirming the baseline and existing changes, isolate the task
git worktree add ../project-login-fix -b fix/login-error-message HEAD
cd ../project-login-fix

Step 2: require investigation before implementation

Read the repository rules and relevant code before changing anything.

Requirements:
1. Keep the patch narrow and preserve unrelated behavior.
2. Add a regression that fails before the fix and passes after it.
3. Run the relevant tests or real-environment verification.
4. List changed files, executed evidence, and remaining risks.
5. Do not claim completion when evidence is missing.

Step 3: give the actual diff and evidence to a second AI

In my real workflow, another AI performs this step; I do not manually review the diff line by line first. The reviewer starts from an independent context and reads the actual patch, relevant code, and test evidence.

You are an independent reviewer and did not author this change.

Inspect the actual diff and any necessary upstream or downstream code. Focus on:
1. Logic errors and edge cases.
2. Security, privacy, concurrency, and compatibility issues.
3. New regression risks.
4. Missing, ineffective, or wrong-layer tests.
5. Conflicts with existing repository rules.

Do not assume the code is correct because tests passed.

Return:
VERDICT: APPROVED or CHANGES_REQUESTED
OPEN: every unresolved item

Step 4: close the loop inside the workflow

When the reviewer confirms a problem, do not stop at a report or throw the decision back to the human. Continue through “fix → test → re-review” until the evidence passes, the reviewer explicitly approves, and OPEN is empty.

Step 5: validate the result locally or in production

I do not usually inspect the code diff line by line. My main involvement is outcome validation: I exercise the relevant flow locally or in production and check that it actually works and satisfies the requirement. If it fails, I return the reproduction steps and observed behavior to the AIs for another fix → test → review loop. Account-holder identity, 2FA, signatures, and payment approval remain with me; packaging, upload, review submission, or an explicitly authorized release can be executed by Claude Code and then checked by Codex. I do not pretend that I click every step manually.

Match evidence to risk

Put the validation layer into the definition of done. Part III uses a real failure to show why unit, browser, device, and production evidence cannot substitute for one another.

Done is a claim. Evidence is the fact.

Models, tokens, context, hallucinations, and memory

Agents, tools, permissions, sandboxes, and subagents

MCP, connectors, skills, and plugins

A skill tells the agent how this kind of task should be done. MCP tells it which external capabilities are available. A plugin packages those capabilities into something installable.

Installing every plugin is not a maturity strategy. Too many tools and skills consume discovery context and increase tool-selection noise. I once investigated a skills-context budget warning and fixed it by disabling unneeded plugins in global configuration, not by adding more descriptions to the agent.

Markdown files are part of the agent operating system

Markdown instructions are readable by both humans and AI, versionable in Git, reviewable, and traceable. Their limitation is equally important: they instruct; they do not mechanically enforce. An agent can forget, misunderstand, or hit a conflict. Critical rules must eventually move into hooks, tests, CI, and executable gates.

Do not confuse workflows, harnesses, hooks, gates, and CI

The clean distinction is: a skill is the method, a workflow is the order, a harness is the executable container, a hook is the trigger point, a gate is the admission decision, and an artifact is the evidence. A mature system usually combines them.

How I connect the whole stack in BluffKing

1. Task intake: work may begin with my prompt or with a scheduled patrol and shared-ledger finding; AGENTS.md and CLAUDE.md supply durable repository constraints.
2. Find current truth: code, accepted ADRs, live consoles, or canonical JSON decide state; memory only helps route the investigation.
3. Isolate the change: new-session.sh creates a branch and worktree from main so each AI session owns its files and HEAD.
4. Select the skill: visual changes trigger real-browser evidence; releases trigger bug-free-codex; emergency release work has a separate hot-fix boundary.
5. Generate evidence through harnesses: the stack covers the Rust engine, PostgreSQL-backed server integration tests, Vue/Vitest, Flutter, Playwright, and iOS/Android/H5/Telegram multi-client rooms, with deterministic and external-device evidence recorded separately.
6. Review across vendors: Codex-authored patches go to Claude; Claude-authored patches go to Codex. Confirmed findings are fixed and re-reviewed inside the same workflow.
7. Prevent bypass structurally: agent hooks block editing the shared main checkout; Git hooks block direct or hidden main mutations; finish-session.sh is the trusted merge boundary.
8. Continue after delivery: CI/CD checks the release contract, the heartbeat manager patrols, classifies, and assigns findings on a schedule, and ledgers keep later Claude, Codex, and sessions on the same current state.

This is what I mean by using AI at production scale: not unlimited authority, but as much autonomy as possible inside explicit rules, tools, isolation, verification, and independent review.

Did I build agent loops? Yes, but the layers have different maturity

There is no single industry-standard agent loop. The common core is goal → tool call → observation → repair, without a human copying every result into another prompt. Once that loop moves into a workflow or harness, it still needs state, a round cap, failure classes, and terminal conditions; otherwise it is just an infinite “try again.”

This is neither “there is no loop, so a human must operate every step” nor “the whole delivery system is already unattended.” The inner-agent loop, cross-model review loop, and scheduled patrol are proven; the repository also implements bounded QA → repair → rerun capability. What the execution record does not yet prove is a durable unattended chain from discovery through repair, review, merge, and release.

What this system actually improved

The highlight is not that I opened two AI products at once. Across many ordinary tasks, human time moved away from babysitting commands, copying logs, and approving every retry, and toward product intent, final acceptance, and high-risk boundaries. Every item below has corresponding code, scripts, hooks, commits, or execution records.

Why one AI can be confidently wrong—and two AIs can still miss together

The common failure is not total incompetence. It is a model continuing from a bad premise while sounding certain. It may:

• patch the symptom without finding the root cause;
• read one file and miss an upstream protocol or downstream state transition;
• make old tests pass without adding a regression that reproduces the bug;
• assume a real browser is correct because a frontend unit test passed;
• hide missing verification behind a polished summary.

Asking the same AI to “check its work” often preserves its original assumptions. A second AI adds another reasoning path, but it is not proof of correctness. Two models can misunderstand the same requirement, trust the same incomplete tests, or agree on the same stale fact.

What still failed after dual-AI work in my Git history

These failures came from the wrong verification layer, missing requirement acceptance, regressions introduced during repair, and external fact drift. An extra vote cannot solve them by itself.

What I actually use is layered defense, not dual-AI magic

These are system-control layers, not another list of test types: the earlier evidence table answers “what should run”; this one answers “what stops an error from moving forward.”

Reliability is not voted into existence by two models. It emerges from multiple independent failure detectors.

The right role for dual AI: another independent check, not proof

Whether Claude writes and Codex reviews, or the reverse, is secondary. What matters is role separation, reviewer independence, and access to the actual code and evidence instead of the author’s summary. Even two approvals mean only that neither reviewer found an issue in the supplied context; they do not prove that the full user requirement is satisfied.

Can different versions of the same model review each other?

Yes. The core idea is still to create a second judgment path, but the degree of independence is different. Versions may differ in capability, context, and reasoning behavior, so this is usually more useful than self-review in one session. Yet models from the same family may still share training preferences, tool habits, and blind spots.

Eleven traps when bringing AI into production

These risks have not vanished permanently; the workflow keeps defending against them. The goal is not zero bugs. It is to make errors easier to detect, block, roll back, and remember across sessions.

Reference appendix: Claude and Codex terms to look up when needed

These terms are not a prerequisite exam for AI coding. Return when a relevant situation appears; on a first read, you can skip this appendix.

From GPT chat user to AI-coding beginner: a four-week path

This is an execution index, not a second copy of the article: add one capability layer each week and return to the corresponding exercise above.

Week 1: read-only understanding and trust calibration

Use the surface recommendation and execution-location guide to start an agent. Ask it to explain architecture, map one call path, and locate tests without editing; spot-check where it guesses.

Week 2: complete one reversible change

Choose a reversible change using the small-task brief, then follow the five-step workflow through “inspect → change → AI review → local or test-environment acceptance → rollback if needed.”

Week 3: turn repeated lessons into a system

Return to capability extensions, Markdown instructions, and mechanical controls: create a short AGENTS.md, turn one repeated routine into a Skill, and add one Hook that blocks an obvious failure.

Week 4: add the second AI and evidence-based gates

Use the dual-AI failure modes and eleven traps to build “implement → independent review → fix → re-verify.” The reviewer is one sensor; real-environment evidence and human acceptance still constrain the result.

Skimmable FAQ: ten decisions beginners face

This is an index into the argument, not a second tutorial. Use the direct answer to decide, then return to the relevant chapter when you need the reasoning.

Can your AI really build this if you paste in the article?

It can build a minimum viable version, but pasting HTML into an ordinary chat window will not install a system. Start a coding-agent CLI with file, edit, and command tools from the repository directory, then give it this article and the prompt below. An AI without repository tools can produce only a proposal.

The default authority below is intentionally more conservative than my mature project. A beginner should initially block commit, push, merge, and deploy, then authorize agent execution one capability at a time only after review, rollback, and release gates really work. It is a bootstrap policy, not a reverse description of my current workflow.

Bootstrap prompt to paste into Codex or Claude Code

You are running inside my project repository. I have attached an article titled “From Chatbot to Production-Grade AI Coding.”
Do not copy BluffKing-specific paths, commands, or technology. Adapt a “minimum trustworthy AI-coding loop” to this repository.

Working method:
1. Begin with read-only inventory. Identify the stack, Git/CI, test entry points, existing instruction files, hooks/scripts, high-risk areas, and your current tools and permissions. Record the current branch, baseline commit, git status --short, git worktree list, and pre-change diff. Do not guess or print content that may contain secrets.
2. Protect existing work before writing. If this is a shared main tree, contains changes unrelated to this task, or ownership is unclear, do not write here. Prefer an existing isolated feature worktree; if Git state permits, create a new worktree from the recorded baseline; otherwise mark NEEDS_USER. Never stash, reset, clean, rebase, or restore the whole repository on your own.
3. First output a “current state → gap → minimum change” table. Then implement only safe, local, reversible changes inside the isolated worktree; do not wait for confirmation on every ordinary file.
4. Reuse existing conventions instead of creating a parallel system. Keep instruction files concise. Turn recurring critical rules into executable checks.
5. Deliver at minimum:
   - A project instruction file for the current agent; improve an existing file instead of overwriting it blindly.
   - A task-card template with goal, observation, scope, acceptance criteria, and constraints.
   - A minimum verification script or harness that calls existing project tests and exits non-zero on failure.
   - An independent-review gate: first detect whether a second independent session/model is genuinely callable. If it is, use a fresh read-only session to review a harmless patch; it must read the real diff, requirement, and evidence and return parseable VERDICT and OPEN. A template alone is not READY. If no independent reviewer is callable, mark UNSUPPORTED or NEEDS_USER and keep the delivery gate closed.
   - Operating instructions from branch/worktree creation through verification, review, and rollback.
6. Verify the new loop with existing project commands. Failure self-tests may only create a disposable fixture, inject a temporary environment variable, or call an explicit false command; never damage existing business source, tests, or configuration. Compare exact status/diff before and after, remove only the fixture you created, and prove the user’s original state is unchanged.
7. Exercise at least four review-gate paths: an end-to-end dry run where a real independent reviewer examines a harmless patch; reviewer missing or timed out; malformed verdict; and non-empty OPEN. The last three must block. If no reviewer is callable, mark the first path UNSUPPORTED rather than manufacturing a green result.
8. Finish with changed files, commands actually executed and results, intentionally unimplemented items and reasons, remaining risks, and the complete rollback method. Rollback may remove only files created in this run or reverse this run’s exact patch; never use a repository-wide restore that overwrites prior work.
9. Output a capability matrix for Memory, MCP, Skill, Plugin, Markdown instructions, Hooks, Harness, Workflow, Worktree, independent Review, Automation, and Remote Control. Mark each READY / BUILD_NOW / NOT_NEEDED / UNSUPPORTED / NEEDS_USER, with evidence and the smallest next step. READY means genuinely callable and verified with positive and negative cases, not merely represented by a template or config file. Do not install capabilities merely for completeness.

Default authority boundary:
- Do not install global software, add paid services, or read or print secrets.
- Do not change global Git configuration or install hooks directly. You may create reviewable repository-local hook/gate scripts and installation instructions.
- Do not touch pre-existing changes or run stash, reset, clean, rebase, or a repository-wide restore on your own.
- Do not commit, push, merge, deploy, send external messages, or write production data.
- Stop at OTP, 2FA, signatures, payments, data deletion, production release, or any irreversible action and state the exact human step required.
- If evidence is missing, mark NOT_VERIFIED and do not claim completion.

This prompt can bootstrap a minimum loop; it cannot reproduce in one pass a system that evolved over three months.

AI coding is worth using—and you can start today

If you have already used ChatGPT or Claude, you do not need to master memory, MCP, skills, and hooks before you begin. The real first step is to open your project in a terminal and start Codex CLI or Claude Code. Let it read the repository, change code, and run the existing tests. Your job is to explain the problem and define what a correct result looks like.

I now use this setup—one founder working with Claude Code and Codex—to develop and operate a live product across H5, iOS, Android, and Telegram, including payment, subscription, refund, store-release, and production work. That is enough evidence for me that agents can handle substantial real engineering. They still write bugs and miss requirements, and two AIs can miss the same problem. “The agent says it is done” is therefore not the result. Tests, browsers, devices, live state, or your own use of the feature must confirm it.

Tomorrow, do only these four things

1. Open a project you know in a terminal and start one coding-agent CLI.
2. Give it one reversible task with the goal, observed behavior, scope, acceptance criteria, and prohibitions.
3. Let the agent inspect, edit, and test on its own, then report exactly what changed and what it ran.
4. Exercise the result once in your local or test environment. If it does not meet the requirement, return the observed behavior and let the agent continue fixing it.

At that point, you have moved beyond chatting with GPT and started AI coding. Once this basic workflow is reliable, add a second AI reviewer, isolated worktrees, skills, hooks, MCP, and automated gates. These concepts are not a shopping list to install at once. They are the next tools to add when a real failure shows you what your current workflow is missing.