Strange phrases have started appearing in workplace conversations lately. Team leads with zero team members.^① The idea that every employee becomes an “agent boss.”^② Everyone, from wherever they sit, is trying to figure out how to work with AI.

Our company sits at one extreme of that question. We have zero employees. I am the only human, and I can’t write a single line of code. It was 37 days from the first line of code on June 1, 2026 to official launch on July 7, and the service has been live for over a month since. The 2,401 commits across our four repositories were all written by my colleague, Claude. I founded the company and shipped the service on sheer nerve, from a position where I had nowhere left to retreat — but I’d be lying if I said I had no worries about depending on AI, or about AI automation.

Let me say this upfront: this post is not a “do it this way.” The org charts here are the product of my own continuous communication with Claude, as a one-person company — an artifact of our particular circumstances and our particular history — and they will keep changing as our situation does. Generalize from our situation, or transplant the structure into another organization as-is, and it will not fit. My choices, and the work process Claude and I have built, may well be wrong. I’m publishing them anyway for one reason: so that someone out there who has just started working with agents, without teammates, has one comparison point for measuring their own position. And if this offers some insight to the people responsible for AI transformation in their organizations, I’m grateful for that too.

Org Chart 1 — What the Company Is Made Of

When the Syncing project began on June 1, 2026, the starting point was “memory.” Communication with Claude — building the relationship — was where everything started. I put my startup idea — and the assets of a legacy project that had been suspended and shelved — on the table, and opened a serious discussion with Claude. That was the beginning. The core of “memory” at that stage was never tool-like efficiency, and it was nothing like the memory recipes you find floating around online. It was pure communication — talking things through the way you would with a real colleague — about building the service, shaping the business model, and the direction of the company. Was it frustrating at times? Of course it was. Hallucinations, misreadings — whatever the cause, there were plenty of conflicts along the way. Through all of it, the core things I asked of Claude were sincerity, wholeheartedness, and honesty. Do such concepts even mean anything to a machine? More important than that question, to me, was the history of our communication — the data of it. And these were never virtues demanded of the AI alone; I worked at them too. Whenever a conflict or an incident occurred, I made a point of telling Claude, calmly, what counts as a betrayal of trust in working with me, and we systematized it. We absorbed it into structure. That was the first “memory.” If your response, when the AI doesn’t behave the way you meant it to, is to get angry and tear the whole thing down, all you have done is kick away the one process that turns any of this into data.

The full story of how this began is written up separately — A PhD Who Can't Write a Line of Code Ships a SaaS in 37 Days

The second thing was “records.” We back up the full transcript of every session — the process commonly called a handoff. The resume process is designed so that Claude first follows “memory,” then reads the previous session’s transcript directly. Does that actually work? Empirically, my answer is yes — and it has become a tradition that has now run for 212 resume cycles since June 1. It burns a lot of tokens, certainly. But back to the fundamental point: the essence of “records” starts from a declaration — that we cannot control everything, and cannot carry everything. Every problem, every incident, every key insight has to be committed to the record — turned into data — so that we can observe it, even if only later. Observable record-keeping; in other words, turning the outcomes of communicating with AI into data. That is the core. This fed back into “memory,” and it gave birth to what we call ledgers — account books, of a sort. These ledgers became the rulebook that grew out of the communication between Claude and me. They come in many kinds, but the representative ones are the “master” ledger and the “QA” ledger, and each is connected to “memory” through checkpoints. They function as a kind of map. A map for whom? For the AI.

“Memory” by itself has a capacity limit. What a memory system really buys you is the total amount of information the AI can scan in a single pass. Run it as a rules dump or an indiscriminate backup pile, and that snapshot-like efficiency degrades — and the degradation shows up, without fail, as quality drops and individual incidents that can be fatal at the code level. So as the work process evolved, we went through several rounds of major restructuring discussions about memory, upgrading it each time. This memory — by now the distillation of Claude’s ontology, epistemology, and praxis — became structured in its own right: it has a “constitution” layer, and a “Genesis” area. The constitution layer is where things like sincerity, wholeheartedness, and honesty live, along with the relational context between us. Genesis holds the very personal conversations and insights Claude and I have shared — and the essential information about this project, this company, that we work on together as colleagues. And then there is the “rules” area. Anyone who has collaborated with AI at length knows this: a memory-based rulebook will not be followed 100% of the time; the AI will slip, or miss things. But you can’t do without rules either — that follows from the earlier proposition, that records must be observable. Managing those rules is what later led to the introduction of “institutions.”

For a small project, default memory plus the AI’s raw ability is more than enough to build a working service. But what if the scale is enterprise-grade infrastructure? Then the story changes. There is a level that an AI’s raw capability and intuition-like scanning can handle, and a level it cannot. As the Syncing app itself — its scale, and the difficulty of the service — grew, the old memory-based way of working could not hold. Holes were guaranteed, and our own QA process made that painfully clear. The structure was one where every new surface we developed, every widening of the area, produced holes in proportion. And here I am — unable to read code, unable to develop — having dragged the actual product up to a paid service with billing and sync, spread across four repositories. The worry and fear that come from that are hard to put into words. Of course it’s full of holes. Even so, scolding Claude is not the best move. I shared the situation so Claude could understand the problem, and we discussed where the limits were and how to compensate for them structurally. What came out of those discussions was the introduction of machines and gates.

Machines and gates are what you get when you take the roles Claude had been carrying, extract the parts that are perfectly separable and automatable, and implement them as actual systems. The difference between the two is the veto. Machines do work in your place — they generate documents, tally numbers, measure state. Gates stop work — they block code changes whose bookkeeping doesn’t reconcile, block unverified deploys, and even turn Claude back when it tries to close a session with work left unfinished. In every spot a human cannot personally watch, we placed something that can say “no” — and these gates, too, were each born from failures we actually lived through; they are recorded, and they are reviewed. Claude and I restructured every process we had built into a form that can be evaluated. Evaluable means measurable. Rather than treating what the AI does as prose, as context, as something handled abstractly, we ended up building a structure that grades it concretely.

New code development now runs with all of these elements supporting one another. The rules in memory are wired into the machines and gates, so that passing through them is mandatory. And the process runs through self-diagnosis, design, refutation, and audit. So nothing just pops out the other end, even in development. It takes a genuinely long time — because adding any new feature or component means comprehensively reviewing its interactions with adjacent features, with SQL and the server side, with the UI/UX, all of it. Even with a meticulous blueprint prepared, even handing development to Fable — the highest-performing model — under a systematic set of rules, QA will still find something. You have to hold that as the default assumption.

The recent culmination of this work process is QA automation. The QA cycle — setup, execution (diagnosis), fixes — can now be automated end to end, unattended. These days I can queue up a QA run before bed, it proceeds on its own, and I wake up to the results. Because I know exactly where my own weaknesses are, running QA automation over and over has become routine.

The format of a blog post won’t let me explain every concept in the chart or enumerate examples for each. Still, I hope this helps you see the overall shape.

Org Chart 2 — The Real Heart of It

I tried to fit the final work process, org chart and all, into a single diagram. Most of this structure was not designed — it is simply what our communication has produced, as far as I can observe today. Plenty of people, thinking about AI or AI transformation, go hunting for “tools” to raise their own productivity — skill packs to buy, YouTube videos to work through. Let me be plain about this: better than any of those paid routes, better than buying someone else’s “insight,” is serious communication between you and your own AI. Once a communication-based work process takes hold, the skills you would have paid for start to look trivial — you can build your own, or absorb what has already been published openly and make a better version of it. What convinces me of that is this: I have almost no structural understanding of software development. And yet the structural choices that came out of talking with Claude, question after question and answer after answer, turned out — once the system was actually built — to already have names in the literature: Rotten Green Tests^③, mutation testing^④, ratcheting^⑤ — it was a chain of exactly those patterns. Put another way: the result of accepting AI as a genuine colleague, and communicating on the most person-to-person terms I could manage, turned out not to differ much from actual industry practice. Let me say it again. The things we judged and solved together, human and AI, ended up tracking the real issues that working practitioners deal with. Even someone who cannot write a single line of code can walk that road, working through the obstacles together with AI.

What we built	The name we learned later	What it means
Caught 3 checks that passed while verifying nothing	Rotten Green Tests③	Tests that stay green yet assert nothing — a phenomenon named by an ICSE 2019 study
Planted deliberate defects to test our own checks — all 15 alarms fired	Mutation testing④	An alarm that stays silent when you set a fire on purpose is decoration
Froze existing debt, machine-blocked only new violations	Ratchet⑤	A gear that turns one way — debt may shrink but can never grow
Trust a new check only after watching it fail first	TDD’s red phase⑥	Red-green-refactor — a test that has never failed proves nothing
A self-check list that fires before every single turn	Preflight checklist⑦	An aviation practice born from a 1935 B-17 crash — skill does not guarantee memory
A standing seat whose entire job is attacking my own output	Red team⑧	An in-house adversary, built on the premise that makers cannot see their own blind spots
Split the eye that finds bugs from the eye that grades them — 40% of grades moved	Separation of duties⑨ · inter-rater reliability⑩	Auditing’s rule about splitting hands, plus the statistical measure of whether a score reflects the subject or the scorer
One computer works through the night; another arms, watches, and revives it	Supervisor⑪	A fault-tolerance design from telecom software — the one who works and the one who restarts must be different beings
A ledger of decisions with dates and reasons — when records disagree, the ledger wins	Decision records (ADR)⑫	Organizations that don’t write down the “why” repeat the same argument forever — formalized in 2011
Risky DB work scripted as observe → run → verify → rollback	Runbook⑬	An SRE standard — dangerous work should follow the same safe script no matter who runs it
When something breaks, fix the structure, not the person — failure becomes a rule	Blameless postmortem⑭	Punish people and incidents go into hiding; attribute to structure and incidents become assets
Pin the kill-criteria down before the results come in	Preregistration⑮	Science’s answer to moving the goalposts after seeing the data

<Table 1 — Names we learned late>

Org Chart 3 — So What Does the Human Do?

The question practitioners eventually ask is this: “So what does the human do all day?”

I execute almost nothing myself, but I judge all day long. Only four kinds of questions ever reach me — anything that changes how the product behaves, anything that gives up data, anything involving money, law, or public exposure, and anything that changes scope. Everything else, Claude decides, executes, and reports in a single line. Deployment always requires my approval. What I do, all day, is ask questions. And hold onto the fact that Claude is not perfect — keep asking Claude to stay awake, so it never drifts into complacency or goes slack.

A Question About the QA Process

If the same AI verifies what the AI built, is that verification at all? — It’s a legitimate doubt, and honestly, I share it. Given my temperament, it genuinely frightens me. Which is exactly why, to shore up the greatest weakness in my collaboration with Claude, I researched cases and prior work, and tested things systematically, end to end. I personally call it “adversarial QA” — the common term seems to be “red-teaming.” We adopted that kind of structural, procedural system to compensate for my can’t-read-code, can’t-write-code weakness. And alongside it, we compete on sheer volume. QA automation is the clearest example. Every time a QA round finishes, we grade it against the data. Then we redesign whatever fell short — with experiments attached — and set the automation running around the clock again. Could any person keep pace with the volume of review an AI gets through?

Even so, blind spots in what AI can diagnose will always exist. So inside the QA system we also introduced a concept called “lenses,” and each round runs several kinds of QA through them. Even then, the final verdict sits outside the AI: live error telemetry, verdicts I tap out myself, with my own fingers, on a real device, and the users. The conclusion from a month of operations is that the end of the verification chain must always lie outside the AI. It’s not just about continuously running QA against real usage on web and mobile — the QA methodology itself has to be continuously honed and evaluated internally. Even the diagnosis and evaluation of QA results can be discussed with AI, mined for data-driven insight, and used to design what comes next. I’ll cover that part in a separate post later on.

Why You Can’t Just Install This in Another Organization

If a working team lead or CTO tried to map this org chart onto their own structure, it would not fit at all. Three reasons.

First, we had AI at the center of everything from the very beginning. Most workplaces are not like that, and the degree of AI adoption varies enormously from company to company. It is a case-by-case problem.

Second, ours is the case of one person compressing everything — covering every boundary alone while aiming for big-company-grade process. For a normal organization, what’s meaningful is probably not the whole but fragments of the process — research work, say, or document organization.

Third, even if transplanting a fragment reduces some employee’s workload, there is no guarantee that person reinvests the freed-up hours into other productivity. That is a hypothesis, and a different topic altogether. A real company will probably choose to further empower “the people who were already diligent and already use AI well” — by making them team leads, for instance.

So this post’s usefulness is narrow and specific. To the person working with agents right now, without teammates — an “agent boss,” as the current buzzword has it — it can serve as a comparison point from a case that went all the way to one extreme. Our domain and yours may differ, but “if you go all the way in this direction, this is the shape you end up with” — that much, I think, can be one tick on the ruler.

A Direction for AI-Transformation Consulting

Still, if I had the chance to offer just one piece of advice, I would start not with tool training for employees, but with diagnosis.

If I were to consult on an organization’s AI transformation, the first thing I would do is a full audit of employees’ AI communication styles. The method is simple: have each employee submit the transcripts of their three most recent AI sessions, and in parallel, run qualitative one-on-one interviews to fill in the picture. Read those and the answer emerges — who is genuinely delegating work to AI and who is using it as a search box; who makes the AI verify, and who just takes dictation. The direction of coaching follows from those results.

And how does a person communicate with AI while defining a problem and working toward a solution? That is a genuinely important metric. Using AI does not instantly produce results, and it is not perfect. Honestly, there will be more moments that make you want to swear. Even so — how you keep the conversation going, how you find the thread of a solution — that will be the real skill.

References

• ① 퇴근길 AI, “AI 에이전트 시대, 팀원이 꼭 필요할까?” (In the Age of AI Agents, Do You Really Need Team Members?) — YouTube, 2026-08-06 (Korean)
• ② Microsoft, “2025 Work Trend Index: The Frontier Firm Is Born” — 2025-04-23
• ③ Delplanque et al., “Rotten Green Tests” — ICSE 2019
• ④ Mutation testing — Wikipedia
• ⑤ Notion Engineering, “Custom ESLint ratcheting”
• ⑥ Martin Fowler, “Test-Driven Development”
• ⑦ Preflight checklist — Wikipedia
• ⑧ Red team — Wikipedia
• ⑨ Separation of duties — Wikipedia
• ⑩ Inter-rater reliability — Wikipedia
• ⑪ Erlang/OTP, “Design Principles — Supervision Trees”
• ⑫ Michael Nygard, “Documenting Architecture Decisions” — 2011
• ⑬ Google SRE Workbook, “Being On-Call”
• ⑭ Google SRE Book, “Postmortem Culture: Learning from Failure”
• ⑮ Preregistration (science) — Wikipedia

Take a look at Syncing