What Is Thread-Based Engineering?
Thread-Based Engineering is the way we structure AI-assisted development. Each piece of work is a thread with two mandatory human checkpoints: a person writes the prompt at the start and reviews the result at the end. Between them, the AI does the work and automated checks run. A person still merges every change.
This is Part 2 of our AI Technical Debt series. Part 1 looked at the data on AI-generated code. This part shows how we govern our own work. The workflow counts come from our own repository as of 2 October 2026; the industry figures are attributed to Stack Overflow and Veracode. Our definitive guide to Thread-Based Engineering covers the framework in full, and the thread commands are published as an open-source kit on GitHub.
A thread, from prompt to merge
Our working method, October 2026
Prompt
a person defines the work
Work
the AI implements
Gates
automated checks run
Review
a person reads the change
Merge
a person merges
Why Does AI-Assisted Code Need Governance?
AI-assisted code needs governance because a lot of it is almost right. The output usually compiles and often looks finished, so the errors that remain are the ones a quick read misses. The 2025 data from developers and from security testing points the same way.
What developers reported in 2025
Stack Overflow Developer Survey 2025, AI section
use or plan to use AI tools
trust the accuracy of AI tools, down from 43% in 2024
name "almost right, but not quite" output as a top frustration
say debugging AI-generated code takes longer
Sources: Stack Overflow Developer Survey 2025 and Veracode's 2025 GenAI Code Security Report. Neither number is a reason to avoid AI tools. Both are reasons to put a person and a set of automated checks between AI output and production.
Which Thread Types Do We Use?
We use seven thread types, each a slash command in our repository, plus two utility commands. The type is chosen by the shape of the work, and it sets where the human checkpoints fall.
| Command | When we use it | Checkpoints beyond the prompt |
|---|---|---|
| /thread-base | A single scoped task, such as a bug fix or a small feature | Start and end |
| /thread-parallel | Three to five independent subtasks with no shared files | Start and end |
| /thread-chain | Multi-phase work where early decisions shape later ones | Between every phase |
| /thread-long | Extended autonomous work | Optional self-check |
| /thread-big | Coordinated subagents with dependencies | Start and end |
| /thread-fusion | Uncertain approach: compare two or three strategies | Start, selection and end |
| /thread-zero | Well-tested, low-risk work, fully autonomous | End only |
| /thread-review | Evaluate a finished thread | Not applicable |
| /thread-status | Metrics and optimization suggestions | Not applicable |
None of the thread commands can commit, push or merge. Those steps need an explicit instruction from a person, in every thread type.
What Does Every Change Pass Before It Merges?
Every change passes three layers of gates: checks before the commit, required checks on the pull request, and a human review and merge. This is our real developer workflow; an earlier post on a "developer collaboration framework" described tools we do not use, and we have merged it into this one.
| Stage | What runs | What it stops |
|---|---|---|
| Before commit | ESLint and Prettier on changed files, a type check, the content build, 10 repository validators | Type errors, broken content, retracted claims, bad links, missing assets, migrations without grants |
| Commit message | commitlint with conventional commits | Unreadable history |
| Pull request | CI: lint, type-check, the full test suite, repository validation | Anything that broke since the commit |
| Main branch rules | A pull request, all four checks passing, every review thread resolved; no force pushes or deletion | Unreviewed or unchecked merges |
| Review | Automated Qodo review on the pull requests we open; OpenAI Codex as an independent reviewer on larger changes | Defects a second reader can see |
| Merge | A person reads and merges every pull request by hand | Changes nobody has read |
Our gates, in numbers
pixelmojo.io repository, 2 October 2026
automated steps before every commit
checks the main branch requires
tests in the suite
pull requests merged by hand
Why put rules in tools instead of documents?
Because a rule in a document depends on someone remembering it, and a rule in a tool does not. Two examples from our lint configuration: React's raw-HTML injection prop is a lint error, so that route to cross-site scripting cannot come back by accident. And AI provider SDK imports, along with the known provider API addresses, are blocked by lint everywhere except one file, the one that carries the kill switch, the call logging and the timeouts its query functions use.
A rule in a document versus a rule in a tool
Our view, from running both
- Depends on the reader remembering it
- Breaks silently when missed
- Found in review, if at all
- Runs on every change
- Fails loudly with the reason
- Cannot be skipped by accident
Where Do the Human Checkpoints Sit?
The human checkpoints sit at the start of every thread, at the end of every thread and at the merge. The person who writes the prompt defines what correct means. The person who reviews reads the diff against that definition. The person who merges is the last check, and no agent can do it.
Some work gets more than the minimum. Changes to sign-in, payments, access gates or database security policies are made only when a person asks for them by name, and they get extra review. Part 3 covers the practical patterns for keeping AI-assisted code production-grade.
What Does This Not Claim?
This approach does not make technical debt impossible, and it is not a certification. The gates catch the categories they check. A person still has to judge everything the gates do not cover, which is why the review checkpoint is mandatory in every thread type, including the autonomous ones.
What Changed in This Post?
We rewrote this post on 2 October 2026 and merged in our August 2025 post "The Developer Collaboration Framework: How We Built a System That Actually Works", whose old address now redirects here. The changes:
- the merged post's tool stack is withdrawn, because it is not the stack we use, along with its claims of "50+ development teams" and "$2.3M additional revenue";
- the claim that the framework already complies with a government AI governance framework is withdrawn;
- a comparison with Meta's SPDL data-loading library is removed, because that work is about loading training data, not governing code;
- the description of Hive as a code generator with built-in security scanning is removed;
- third-party figures we could not check are removed; the Stack Overflow and Veracode figures are checked against their sources;
- the gates described are the ones we run, with counts from our own repository.
What This Series Covers
This is Part 2 of the AI Technical Debt series. Part 1 covers the data on AI-generated code, Part 3 covers practical mitigation patterns, and Part 4 is a dated note on our Lakbay AI build.
Thread-Based Engineering: Questions Readers Ask
Common questions about this topic, answered.
What is Thread-Based Engineering?
Thread-Based Engineering is the way we structure AI-assisted development. Each piece of work is a thread with two mandatory human checkpoints: a person writes the prompt at the start and reviews the result at the end. Between them, the AI does the work and automated checks run. A person still merges every change.
Does Thread-Based Engineering prevent AI technical debt?
It reduces it; it does not make it impossible. The checkpoints and automated gates catch the problems they are built to catch, such as type errors, failing tests, unsafe HTML injection and claims we have retracted. Debt the gates do not check for can still get through, which is why a person reviews every change.
How many thread types are there?
Seven: base, parallel, chain, long, big, fusion and zero. Each is a slash command in our repository, alongside two utility commands for reviewing a finished thread and reporting status. The open-source kit we published in February 2026 has the same set.
What checks does a change pass before it merges?
Before a commit: ESLint and Prettier on changed files, a type check, a content build and 10 repository validators, 13 steps in all. On the pull request: lint, type-check, the full test suite and repository validation, all four required by the rules on our main branch, plus resolved review threads. A person merges.
Who reviews the code?
Claude Code does most of the implementation. Qodo reviews the pull requests we open, OpenAI Codex acts as an independent reviewer on larger changes, and a person reads and merges every pull request by hand. No agent merges code.
How common are problems in AI-generated code?
Common enough to plan for. In Stack Overflow's 2025 survey, 66% of developers named AI output that is "almost right, but not quite" as a top frustration, and only 33% trusted the accuracy of AI tools. Veracode's 2025 testing of over 100 models found that AI-generated code introduced risky security flaws in 45% of tests.
Is Thread-Based Engineering a compliance framework?
No. An earlier version of this post said it already complied with a government AI governance framework; we withdrew that, because nobody had assessed it. It is a working method with human checkpoints and automated gates, and it can support a compliance effort, but it is not a certification.
What changed in this post on 2 October 2026?
We rewrote it and merged in our August 2025 post on a developer collaboration framework, whose address now redirects here. That post described a tool stack we do not use, so its stack and results are withdrawn. This version describes the gates we actually run, with counts from our own repository, and keeps only third-party figures we could check.
