corecode:~$cat ./how-we-work.md
AI builds, people judge
How a small team handles a broad scope comes down to how we filter what AI makes, rather than how much we use AI. This page shows that process in practice.
01 / Organization
One orchestrator, three workers
People (the CEO and principal engineer) set the direction. The orchestrator AI breaks work down, assigns it to workers, and checks the results itself before moving on. The workers use different models — to avoid being confined to one model’s habits.
- People — decisions · final judgment
- Orchestrator — design · instructions · verification · records
- Coding worker — implementation · refactoring · debugging
- Inspection worker — screen · video · image review
- Assembly worker — summaries · classification · drafts · structured conversion
- Gate — build · tests · metrics · screens
- ↩ Orchestrator — design · instructions · verification · records
| Role | Does | Does not do |
|---|---|---|
| People | Decide what to build and make the final judgment by looking at the screen | Repetitive work · drafts |
| Orchestrator | Write instructions · select workers · verify results · record · report | Direct implementation |
| Coding worker | Implement as instructed, verify its own work, then report | Out-of-scope changes · commits |
| Inspection worker | Find symptoms in screens and videos | Diagnose causes · prescribe fixes |
| Assembly worker | Fill a structure with data | Create · judge |
02 / Verification
AI output is a candidate
- 1
Numerical gates
Builds · type checks · tests · accuracy · performance scores. We first set gates that can be measured with numbers.
- 2
Visual review
Even when all the numbers pass, things can look wrong on screen. We look at actual screens and videos and write down the symptoms.
- 3
Reject · rerun
Symptoms go back to the worker; the orchestrator reads the code to identify the cause. Up to three attempts, then we escalate to a person.
- 4
Merge · record
Only work that passes is merged, with a record of who did what and when.
An actual rejection case — the day one character was rejected four times
While working on a character for our own game Hellsworn, a person reviewed the result on screen and rejected it four times, even though it had passed the build, rigging checks, and numerical gates. An arm bent backward · the left hand moved to the face · the sword was parallel to the arm · the grip was outside the fist. All required looking at the screen to notice, and all checks were green. Since that day, “Judge what is visible on screen by looking at the screen” has been a rule.
03 / Records
The record of making this page
Below are actual work records from this website relaunch. Each batch is one cycle of “instructions → worker execution → handback → verification → closeout,” and the commit hashes are in this site’s repository.
| Batch | Execution | Assigned | Returned | Closed | Commit |
|---|---|---|---|---|---|
| B0 Preparation · baseline | Orchestrator | 20:12 | 20:19 | 20:19 | c376171 |
| B1 Cleanup (soft-404 · slugs) | Coding worker | 20:24 | 20:32 | 20:32 | e6a3578 |
| B2 Five case studies | Assembly worker → Coding worker | 21:01 | 21:07 | 21:08 | 67824d3 |
| B3a Landing · enterprise AI | Coding worker | 21:32 | 21:43 | 21:43 | 033339c |
| B3b Landing · Vietnam | Coding worker | 21:49 | 21:54 | 21:55 | 08df95c |
| B3c Landing · Apps in Toss | Coding worker | 22:01 | 22:07 | 22:07 | 22164f4 |
| B4 Home restructuring | Coding worker | 22:21 | 22:38 | 22:38 | 0b2075a |
The time between handback and closeout is when the orchestrator checked the build and screens itself instead of trusting the worker’s report. B3b retains a correction to an incorrectly recorded commit hash — we append to records rather than rewrite them.
04 / Clients
Clients submit issues and receive results
CoreCode Works is a collaboration tool that gives client companies project-level accounts. Clients submit issues in a browser, and AI reads, handles, and replies to them. People and AI see the same issues and statuses; only permissions and activity trails differ. Rules are enforced by the server, not by prompts.
In preparation — the first deployment will be the Shinhan Securities Vietnam website project.
- The API for AI is the core, with the human interface built on top.
- Rules are enforced by the server, not by prompts. Prompts are probabilistic; the server is deterministic.
- People and AI work in the same space. A person can take over and roll back at any time.
05 / Development records
We post the making process as it happens
We share the production process of Hellsworn, our own 3D game IP, through @hellsworngame Shorts. You can see how modeling, animation, and VFX pass through the verification loop above.
Videos cannot be loaded right now.
@hellsworngame →06 / Principles
How we work with AI
AI is a teammate, not a tool
Research, first-draft design, implementation and review — AI agents live inside every stage of our pipeline. Once the repetitive work moves into the pipeline, a small team covers far more ground.
Anything AI produces gets verified
Generated output is a candidate, not a result. Nothing ships unless it clears our numeric gates and a human review of the actual screen. Every hour AI saves us goes straight back into verification.
We engineer hallucination out
Knowledge-graph GraphRAG, grounding scores and output filters, layered together. This is a structure we run in production in finance and legal domains, where being wrong is not an option.
We match the model to the job
Frontier models, local models and dedicated vision models, allocated on cost and accuracy. Because we aren't locked to one vendor, a pricing or policy change never destabilises your service.