Loop Engineering with ChatGPT Work and Codex: From Idea to Verified Product

The most useful part of Vaibhav Sisinty's conversation with OpenAI's Wulfie Bain is not early access or a secret prompt. It is the operating pattern: collect context, delegate research, preserve evidence in simple files, build an artifact, let an agent test it, and convert the successful workflow into something repeatable.

That is the shift from prompt engineering to loop engineering. The prompt starts the work. The loop decides whether the work is actually finished.

Video and interview credit: Vaibhav Sisinty, with Wulfie Bain from OpenAI's Applied AI for Startups team. Product facts are checked against official OpenAI pages and Help Center documentation.

Source Note

The live workflow, personal habits, startup advice, token-spend stories, and long-running experiment come from the supplied interview transcript. They are useful field observations, not formal OpenAI policy or controlled benchmarks. OpenAI's own documentation is the factual spine for product availability, model tiers, Work and Codex surfaces, plugins, Scheduled Tasks, Record and Replay, Computer Use, and Sites.

Link Map

What Is Officially Confirmed

OpenAI launched GPT-5.6 for general availability on July 9, 2026. The family has three capability tiers: Sol as the flagship, Terra as the balanced option, and Luna as the fastest and most affordable. Availability still depends on plan and product surface.

OpenAI's current Help Center describes ChatGPT as having Chat, Work, and Codex experiences. Work is for longer research and finished materials. Codex is for repositories, code, terminals, tests, and software delivery. Work is available on eligible web, mobile, and desktop accounts, while Codex remains a desktop mode with supported remote-task access from mobile.

Plugins are now the discovery layer for packaged workflows. A plugin can include reusable skills and connections to apps, but it does not bypass the permissions of those apps. Workspace administrators can control plugin and app availability separately.

Chat, Work, and Codex Are Different Doors

The "super app" framing is useful only if it reduces handoff friction. It does not mean every thread sees every local file, every Work conversation syncs to desktop, or Codex becomes a selectable web and mobile chat mode. The official guide documents those surface boundaries.

The Live Startup Workflow

The interview builds a fictional science-fiction bookstore and community product. The sequence is more valuable than the concept:

1. Research the market and pitch structure. Parallel agents gather evidence and save it into local files.
2. Create a pitch deck. The agent synthesizes the research into a presentation instead of starting from a blank slide.
3. Generate visual directions. Several front-end concepts are produced in parallel before one direction is selected.
4. Build the application. Codex turns the selected direction into a working web product.
5. Introduce known defects. The demo deliberately breaks descriptions and an interaction so the QA loop has something observable to find.
6. Use Computer Use for testing. The agent opens the app, clicks through it, finds failures, fixes code, and creates regression tests.
7. Schedule repeatable checks. A visual test is converted into recurring work.
8. Teach a browser workflow. Record and Replay observes an expense flow and drafts a reusable skill.
9. Publish an internal artifact. Sites turns analysis into a small shareable dashboard.

This is a strong prototype-to-evidence pipeline. It is not yet a company. Customer discovery, permissions, economics, legal review, production operations, and support still sit outside the demo.

The Markdown Pattern Is Simple and Valuable

Wulfie repeatedly asks agents to write plain Markdown files. The point is not that Markdown is magical. It is that durable, inspectable files prevent research from collapsing into one short chat summary. Several agents can write separate evidence packets, and a later agent can synthesize them without discarding all of the underlying context.

# WORK BRIEF

## Goal
Create a decision-ready pitch and testable product prototype.

## Inputs
- Customer notes
- Market sources
- Product constraints
- Existing brand or design references

## Required files
- research/market.md
- research/customers.md
- research/competitors.md
- decisions.md
- product-brief.md

## Evidence rules
- Link every external claim to its source.
- Separate facts, assumptions, and recommendations.
- Record unanswered questions instead of inventing answers.

## Definition of done
- Every claim is traceable.
- The product brief contains user, problem, workflow, and non-goals.
- A human has approved the direction before implementation.

Use documents for stable context and chat for coordination. This makes the work easier to review, resume, compare, and hand to another model or person.

The Harness Matters as Much as the Model

In the interview, a harness means the system around the model: instructions, files, tools, browser access, connected apps, subagents, memory, execution environments, and the interface where humans review work. A powerful model without the right context and validators still guesses. A capable harness turns model intelligence into a repeatable process.

Parallel agents help when work can be separated cleanly: four design directions, independent research lanes, test suites, or source reviews. They create noise when every subagent edits the same files, depends on the same unresolved decision, or produces outputs nobody will review.

Loop Engineering Needs a Contract

The interview's central idea is correct: stop spending all your energy describing every step and give the agent a goal plus a validator. But a loop without a budget and stop condition is just an expensive way to repeat uncertainty.

# LOOP CONTRACT

GOAL:
Make the implemented page match the approved reference and pass its user flow.

CHECK:
1. Run automated tests.
2. Open the page at desktop and mobile widths.
3. Complete the critical user path.
4. Compare the result against the approved reference.

LOOP:
Fix one evidence-backed failure at a time, rerun the relevant checks,
and keep a short change log.

STOP WHEN:
- All required tests pass.
- No page-level overflow exists.
- The critical path completes without errors.
- Remaining visual differences are listed for human review.

BUDGET:
- Maximum 8 repair cycles or 90 minutes.
- Stop earlier after 2 cycles with no measurable improvement.

APPROVALS:
- No production deployment.
- No schema migration, purchase, email, or external post.
- Ask before using credentials or changing permissions.

Good validators are observable: tests pass, a measured loss reaches a threshold, every citation resolves, a browser flow completes, or a screenshot stays within an approved tolerance. "Make it great" is not a validator.

The overnight neural-network story is a useful illustration, but not proof that longer runs are inherently better. The transcript reports roughly 10 to 15 attempted approaches over an overnight run. Without the final metric, logs, compute cost, and baseline, duration only tells us the system kept working.

Route Models and Effort by Consequence

OpenAI's published API prices are $5 input and $30 output per million tokens for Sol, $2.50 and $15 for Terra, and $1 and $6 for Luna. Those prices do not include human review, tool calls, failed attempts, infrastructure, or the cost of a wrong external action. Optimize for cost per accepted result.

Computer Use Turns Browser QA Into Evidence

The strongest technical moment in the demo is intentionally breaking the app, asking the agent to click through it, fixing what it discovers, and adding tests so the same failures do not return. That closes the loop between generated code and observed behavior.

A safer version uses a preview deployment, seeded test data, test accounts, restricted credentials, and a fixed path list. Computer Use should capture screenshots, console errors, failed steps, and the exact change that resolved each issue. The agent's completion message is not evidence by itself.

• Test the happy path and at least one failure path.
• Check desktop and mobile layouts.
• Verify data persistence and duplicate submissions.
• Record browser console and server errors.
• Add a regression test for each confirmed defect.
• Stop before production release and request approval.

Tasks, Skills, Record and Replay, and Sites

Scheduled work

OpenAI distinguishes ChatGPT Scheduled Tasks from focused Codex automations. Scheduled Tasks are useful for reminders, recurring briefings, and monitoring. They have plan-specific active-task limits, cannot run more than once per hour, and may pause after inactivity. Connected apps still follow their permissions.

Record and Replay

Record and Replay is designed for stable computer workflows that are easier to demonstrate than describe. The expense example is plausible because many enterprise tools lack clean APIs. It is also sensitive: the recording can observe window content and actions. OpenAI advises keeping recordings focused and avoiding secrets or sensitive information.

Initial availability is macOS-only for eligible users and excludes the European Union, Switzerland, and the United Kingdom. The correct Portugal guidance today is to check availability, not promise that the feature will appear.

Sites

Sites can turn analysis into a shareable internal artifact without a separate deployment pipeline. Before publishing, review what the Site includes: prompts, conversation context, files, generated code, hosted URLs, access settings, logs, and operational metadata may be involved depending on the workflow.

Plugins

Browse plugins by the workflow you need, not by novelty. Review included skills, required apps, publisher, permissions, action scopes, and privacy policy. A plugin that can read a spreadsheet is a different risk from one that can send email, deploy software, or change a database.

What OpenAI Does Not Replace for a Founder

The second half of the interview asks what remains defensible when anyone can build a first version. The answer is not "better prompts." It is a system of customer knowledge, distribution, workflow integration, trust, data, and learning speed.

Wulfie's strongest startup advice is to become obsessed with a vertical problem and spend time with the people who experience it. The product is not only code; it is accumulated understanding expressed through code, operations, support, and go-to-market.

His one-way-door versus two-way-door framework is also practical. Drafting code, testing an interface, generating research candidates, and preparing a pull request are usually reversible. Sending a message to every customer, changing production data, signing a contract, spending a large budget, or making a regulated decision is not.

The interview's million-dollar token story and the "$100,000 on tokens or engineers" question are anecdotes and thought experiments, not spending guidance. Most teams should buy a small amount of inference, prove one workflow, measure accepted output, and scale only when the economics are visible.

A Safer Seven-Day Implementation Plan

1. Day 1: choose one recurring outcome. Pick a weekly report, meeting brief, bug triage, slide deck, or internal dashboard.
2. Day 2: create the Markdown work brief. Define inputs, files, evidence rules, non-goals, and definition of done.
3. Day 3: run one supervised workflow. Observe every tool call and record where context or instructions fail.
4. Day 4: add a validator. Use tests, a checklist, source verification, a browser path, or a numerical threshold.
5. Day 5: add a bounded loop. Set cycle, time, and spend limits plus explicit approval boundaries.
6. Day 6: compare model routes. Test a fast route and a capable route on the same accepted outcome.
7. Day 7: convert only the proven part. Save it as a skill, scheduled task, or reviewed operating procedure.

What the Video Proves and Does Not Prove

The video demonstrates an unusually broad workflow in one interface: multi-source research, parallel agents, slides, image generation, application development, browser control, bug repair, automations, learned computer workflows, and hosted internal artifacts.

It does not prove that a startup was commercially validated, that every generated artifact was correct, that an overnight run beat a shorter baseline, or that token-heavy autonomy is cheaper than engineering. The product and startup predictions are the speakers' views. Availability, limits, and behavior can vary by plan, region, surface, workspace settings, and rollout stage.

Sources

• Vaibhav Sisinty: OpenAI Just Built Their Most Powerful AI Ever
• Vaibhav Sisinty on YouTube
• Wulfie Bain on LinkedIn
• OpenAI: GPT-5.6
• OpenAI: ChatGPT for your most ambitious work
• OpenAI Help: ChatGPT Work and Codex
• OpenAI Help: GPT-5.6 in ChatGPT
• OpenAI Help: Plugins in ChatGPT and Codex
• OpenAI Help: Scheduled Tasks
• OpenAI Help: Using Codex with your ChatGPT plan
• OpenAI Help: Creating and managing ChatGPT Sites
• OpenAI Developers: Codex use cases