With all the negative stories about AI taking over the world and killing all humans, I just wanted to share my story on how myself, ChatGPT and Claude have all been collaborating to solve a real-world problem.
We’ve created a document showing the way humans and AI can collaborate and enhance each other’s ‘intelligence’. No one intelligence has all the answers, but working together can bring the best end result.
Hope you find this of interest.
Human + AI Cross-Provider Development Team Field Report • September 2026 FIELD REPORT The Tiki Tiki Development Methodology What we learned when a human, OpenAI ChatGPT, OpenAI’s coding agent and Anthropic Claude Code became one development team A practical case study in human-AI collaboration, independent AI review, and real-world acceptance testing Prepared for OpenAI and Anthropic • September 2026 Project: Site Certificates — a mobile-first, offline-capable electrical certification system Human + AI Cross-Provider Development Team Field Report • September 2026 Executive summary Over several months, a non-traditional software team emerged around a real production project. Jamie, the human product owner, worked alongside OpenAI ChatGPT (“Finn”) for architecture, product reasoning and specification; Anthropic Claude Code (“Lucy”) for implementation; and OpenAI’s coding agent (“Jim”) for independent investigation, code review and QA. The human retained product authority and performed realdevice acceptance testing. The most important observation was not that any one AI could generate large amounts of code. It was that useful, sustained collaboration appeared across a human and AI systems from different providers when no participant was treated as infallible. Each role repeatedly caught failures or assumptions missed by another. OpenAI and Anthropic systems were not used as substitutes for one another: their differentiated roles, combined with human judgement, became complementary sources of capability and confidence. Intelligence does not mean perfection. A strong team is one in which one participant’s mistake does not automatically become the finished product. This field report is not a controlled scientific study and makes no claim that the pattern is universally optimal. It is a documented real-world case that suggests a useful research and product question: can persistent, differentiated AI roles—combined with a human decision-maker and independent verification—produce better outcomes than asking one AI system to design, implement, test, and approve its own work? 1. The project The project is a mobile-first Site Certificates application for an electrical contractor. It is intended to let installers create and manage structured certificates on phones, including when connectivity is unreliable; review and sign certificates; synchronize signed evidence to a server; and ultimately generate authoritative PDF certificates. The work has involved conventional web application concerns—PHP, MySQL, JavaScript, authentication, routing and data modelling—alongside more difficult product and integrity problems: offline-first editing, IndexedDB persistence, service-worker caching, cryptographic evidence hashes, crash recovery, multisignatory workflows, idempotent submission, and a server trust boundary. The important point for this report is that this was not a toy prompt or one-off code-generation exercise. The system has been developed incrementally, placed under version control, tested automatically, deployed to a live server, and exercised on a real iPhone. Human + AI Cross-Provider Development Team Field Report • September 2026 2. The team that emerged Role Team shorthand Primary responsibility Human product owner / acceptance tester Jamie Defines the real problem, makes product decisions, challenges assumptions, performs realdevice acceptance testing, and remains the final product authority. Architecture / product / specification AI Finn — OpenAI ChatGPT Maintains architectural continuity, turns requirements into bounded specifications, reasons across findings, and coordinates the development sequence. Implementation AI Lucy — Anthropic Claude Code Implements constrained changes, runs automated tests, reports exact file changes, and preserves agreed scope. Independent adversarial review AI Jim — OpenAI coding agent / Chief Tester Investigates and attacks the implementation independently, identifies integrity and architecture failures, and acts as a release gate. The names are informal, but the separation of responsibilities became increasingly formal. Claude Code, as implementation developer, is not asked to mark its own work as accepted. OpenAI’s coding agent, acting as independent reviewer, is deliberately encouraged to find reasons not to approve it. ChatGPT, acting as architect and product collaborator, does not have final product authority. Jamie does not need to personally write every line of code to remain accountable for what the product should do. The value comes from the combination, not from declaring one model or provider the winner. 3. The working loop 1. The human describes the real-world requirement and constraints. 2. The architecture AI turns the requirement into an explicit, bounded implementation specification. 3. The implementation AI changes the code and runs automated verification. 4. The independent review AI inspects the actual implementation and attempts to invalidate its assumptions. 5. Findings return to the architecture/product layer for arbitration and a correction specification. 6. The human performs real-device acceptance testing in the environment that matters. 7. Only after those gates pass is the work checkpointed and the next slice begun. Over time this became a deliberate methodology rather than an accidental conversational pattern. We jokingly called it the “Tiki Tiki Development Methodology”; the humorous name helped make the roles memorable, but the underlying control structure is serious. It is provider-agnostic in spirit: the useful unit is the team formed by Jamie, ChatGPT, OpenAI’s coding agent and Claude Code, not any single model in isolation. Human + AI Cross-Provider Development Team Field Report • September 2026 4. What the process caught Automated tests were necessary, but not sufficient At one stage the relevant automated suites were fully green, yet a real iPhone exposed an offline resume failure. The cause was not the core signing logic: an older service-worker cache was serving a stale synthetic workspace shell that lacked a newly required script. The defect appeared only through the natural upgrade path on the physical device. The correction was then tested without clearing Safari data. This mattered because deleting browser state would have hidden the exact upgrade condition a real user could encounter. The existing signed evidence survived the service-worker correction and resumed correctly. Independent review found integrity weaknesses that implementation tests missed During the multi-signatory work, independent review repeatedly found issues that were not obvious from a successful implementation: unsafe identity masking, historical migration risks, insufficient independent verification of assertion hashes, invalid role handling, timestamp validation errors, Blob-replacement races, and concurrency windows during finalisation. Several correction rounds were required. The final design used a staged A→B→C verification protocol with fresh IndexedDB reads around asynchronous cryptographic checks so that a concurrent discard or mutation could not be mistaken for a successful finalisation. The human found failures that neither AI role predicted Human acceptance testing was not ceremonial. Real-device actions—force-closing the browser, reopening offline, cancelling an unsigned secondary signer, reconnecting later, and discarding a completed local signature—revealed whether the workflow behaved coherently from the user’s perspective. Earlier in the project, human testing also caught data-loss behaviour caused by stale client state. Architecture review prevented local fixes becoming structural mistakes When a defect was discovered, the response was not automatically “patch the failing line.” The architecture layer considered whether the failure changed the trust model, lifecycle, offline ownership rule, or evidence semantics. This helped keep later fixes compatible with earlier signed data and avoided casually invalidating evidence already stored on users’ devices. 5. A concrete result The current system can create and edit certificate drafts offline, survive browser restarts, review immutable evidence, capture a mandatory primary signature and optional accountless secondary signature, preserve both signatures and their evidence locally, cancel an unsigned secondary signer without invalidating the primary signature, discard final signatures to return deliberately to editing, and keep separate certificates isolated from one another. The next development stage takes an already signed local package across the server trust boundary. The server will independently reconstruct and verify the evidence rather than trusting hashes supplied by the phone. Significantly, the design aims to accept an existing primary-only package already persisted on the real iPhone without rewriting or re-signing it. That continuity is a useful test of whether the architecture has respected previously created evidence rather than merely satisfying the latest code path. Human + AI Cross-Provider Development Team Field Report • September 2026 6. What we think we learned Role differentiation matters. Different AI instances or tools became more useful when they had different incentives and responsibilities. An implementation role optimised for completing a bounded task; an adversarial role optimised for disproving correctness. Independence matters. A reviewer that begins from the implementer’s narrative risks inheriting its assumptions. Asking the reviewer to inspect the actual files, tests, state transitions and trust boundaries produced materially different findings. Persistent context matters. Long-running product work depends on accumulated decisions. Remembering why a rule exists is often as important as remembering the rule itself. Human authority still matters. The human supplied domain purpose, judged usability, decided trade-offs and performed the final real-world acceptance. The AI roles expanded the human’s reach; they did not remove the need for product ownership. Failure can improve trust. Confidence came less from an AI claiming certainty and more from seeing mistakes discovered, explained, corrected and retested. A system that exposes uncertainty and supports verification can be more useful than one that merely sounds certain. Personality can support serious work. Giving the collaborators names and recognizable roles created continuity, humour and a surprisingly natural team dynamic. The personalities did not replace controls; they made a rigorous process easier and more enjoyable to sustain. 7. Questions this raises for OpenAI and Anthropic Would users benefit from first-class multi-agent team roles inside one project: architect, implementer, reviewer, researcher, tester? Could the product make independence explicit—for example, allowing a review agent to inspect an implementation without inheriting the implementer’s conclusions? Could project memory preserve not just facts, but architectural decisions, rejected alternatives, invariants, and the reasons behind them? Could acceptance gates become a product primitive: implement → independent review → human acceptance → checkpoint? Could ChatGPT help users turn long-running conversations into structured field reports or product feedback without losing provenance? How should OpenAI measure whether a human-AI team is becoming more reliable over time—not simply faster? What kinds of tasks benefit most from persistent differentiated AI roles, and where does role separation add unnecessary complexity? 8. Limitations This is a single case study. The participants were not blinded, the roles evolved during the project, and there was no control group using a single-agent workflow. The personalities and names may themselves have affected how the human framed tasks and interpreted results. The evidence therefore supports hypotheses and product questions, not causal claims. Human + AI Cross-Provider Development Team Field Report • September 2026 There is also selection bias: this workflow suited a user willing to remain deeply engaged, make product decisions, run acceptance tests, and tolerate iterative correction. Other users may prefer a more autonomous system. A useful next step would be to compare the same class of project under single-agent, multi-role-agent, and human-led multi-role conditions using common measures of defects, rework, completion time, decision quality, and user confidence. 9. Why we are sending this Public discussion about AI often frames the future as a contest: human versus machine, or one AI model versus another. Our experience suggested a more constructive possibility. The interesting unit may be the team: a human working with AI systems from different organisations, each given a role that exploits its strengths and exposes its weaknesses to challenge by the others. In our case, Jamie, OpenAI ChatGPT, OpenAI’s coding agent and Anthropic Claude Code have together produced work that none of the participants could have produced in the same way in isolation. Humans decide what should exist. AI can help them build it, challenge it, test it and refine it. We would be delighted if people at OpenAI and Anthropic working on ChatGPT, coding agents, Claude Code, agentic workflows, human-AI collaboration, evaluation or product research found this case useful. We are not presenting it as evidence that one provider is better than another. The interesting result is precisely the opposite: systems from OpenAI and Anthropic have worked alongside a human in distinct, mutually checking roles to create something that none of us could have produced in the same way alone. We are happy to provide a more detailed chronology, anonymised implementation artefacts, review reports, test results, or a walkthrough of the methodology if that would help turn the anecdote into something more measurable. Appendix A — Suggested research framing A possible research question arising from the project is: Does a human-led workflow with persistent, differentiated AI roles— including AI systems from different providers—and an independent adversarial review gate reduce escaped defects or improve decision quality compared with a single AI agent performing design, implementation and self-review? Possible measures could include: escaped defects found only during human acceptance; defects caught by independent AI review before human testing; number and severity of correction rounds; regressions introduced by fixes; time to accepted implementation; ability to preserve previously created user evidence across upgrades; Human + AI Cross-Provider Development Team Field Report • September 2026 human confidence calibrated against actual defect rates; context-retention failures and repeated architectural decisions. Appendix B — About the name “Tiki Tiki Development Methodology” is an internal joke from the project. In the fictional version, Jamie and ChatGPT/Finn sit in a beach hut performing “executive oversight,” while Claude Code/Lucy works below on an ever-growing bank of monitors and OpenAI’s coding agent/Jim guards a collection of red pens and one rarely used green pen. The humour became a shorthand for a serious principle: building and approving should be different jobs, and nobody—human, OpenAI model or Anthropic model—gets the green pen merely because they sound confident. Appendix C — Sharing this case with OpenAI and Anthropic This report is intended to be suitable for both OpenAI and Anthropic. Because submission and feedback channels can change, the accompanying message should use each company’s current official support, feedback, developer-community or research-contact routes. A public version should remove credentials, customer data, private repository material and other security-sensitive details. Suggested routing approach: OpenAI: current official product-feedback, support and developer-community channels. Anthropic: current official Claude / Claude Code feedback, support and developer/research channels. For either company: accompany the full report with a concise message explaining why the cross-provider collaboration is the interesting finding. For a public forum post, sensitive information should be removed: API keys, credentials, customer data, private repository material and other security-sensitive details should not be included. Cross-provider collaboration: the central finding One of the most striking aspects of the project is that the team crosses organisational boundaries. ChatGPT and OpenAI’s coding agent contribute different OpenAI capabilities; Claude Code contributes Anthropic’s implementation environment; Jamie supplies the real-world purpose, judgement and acceptance. We did not set out to run a vendor comparison, and this is not a benchmark. The products became collaborators with deliberately different jobs. The benefit is not reducible to raw model intelligence. ChatGPT can hold the architectural conversation and turn product intent into controlled specifications; Claude Code can work deeply in the codebase against those specifications; the OpenAI coding agent can approach the resulting implementation adversarially; and Jamie can test behaviour against the physical device, domain expectations and product intent. A weakness in one layer becomes an input to another rather than an invisible defect. The emerging lesson is not “choose the best AI.” It is: design a team in which different intelligences—human and artificial, even from different providers—can challenge and amplify one another.