Choose how the code is written, reviewed, and judged; who controls the standard; and what happens if it breaks. Your five answers map to one of eighteen signs.
No stars were consulted. Five picks, one lookup table, and arithmetic you can read in the source.
How does the code get written?
How does the code get written?
Star 1 of 5
All eighteen signs
The signs sit on a three-by-three map: how code gets written against how it gets checked. Some positions split when the work is a sandbox project; one also depends on who has the final say. None of the signs is a rank. Vibe coding can be sensible for a prototype and reckless for a payments platform. Agent-written code with human review is simply a different working style from writing by hand. Horoscode looks for a mismatch between your workflow and its consequences. Automation is plentiful; independent checking is not. An AI review is independent only if the reviewer is different from the model that wrote the code. Two copies of the same model tend to share the same blind spots.
The first two stars place you on the map. The next three tell us who makes the final call, whether the code-and-review loop can move the goalposts, and how costly a failure would be. Those answers change the risk, and sometimes the sign itself. When agents both write and approve the code, a workflow with an outside authority is a Dark Factory. A workflow that accepts the model’s own verdict is a Believer.
Reference and Judgement sound similar, but they ask different things. Reference asks who controls the acceptance standard. Judgement asks who or what applies it. Tests and gates deserve credit for consistent enforcement, but a loop that writes both the code and its tests still controls its own standard. The standard can change; the important question is who may change it. Horoscode does not score Waterfall against Agile, or written-first against discovered-later.
Forged · Every lineLive service · Under audit
The Craftsman
nothing ships unread
Hand-written, human-read, real consequences
People write the code and people read every change before it ships. That gives you strong independent review at the cost of speed. Someone can explain every line in production.
Breaks when
The review queue becomes the bottleneck and the team routes around it
Throughput expectations rise without the verification model changing to match
Forged · Second pairSandbox · Live service · Under audit
The Practitioner
hand-made, machine-checked
Hand-written, machine-assisted review
You write the code and use a model as a second pair of eyes. The model handles the first review pass, but it did not produce the code it is checking. That separation makes the review useful.
Breaks when
The AI pass becomes the only pass without anyone deciding it should
Reviewers learn to trust a green check they have not calibrated
Forged · Machine-gatedLive service · Under audit
The Lone Author
a team of one
Every line yours, no human reads it
You write every line, but no other person reviews it. This often happens to a solo engineer inside a larger company, or to a senior engineer nobody feels qualified to challenge. A machine reviewer offers some independence, but business context still lives with one person.
Breaks when
No human has read this code in months and the model does not know what the business cares about
A bus factor of one, in a system somebody is paying for
Assisted · Every lineSandbox · Live service · Under audit
The Pair Programmer
two hands, one pen
AI drafts, you edit, you review
AI drafts, you edit, and a person reviews the result. You save time on the first draft without giving up human verification.
Breaks when
Reviewing generated code at the same depth as hand-written code, and quietly halving the gain
Accepting a suggestion that is locally right and globally wrong, because it reads well
Assisted · Second pairSandbox · Live service · Under audit
The Centaur
half and half, both ways
Human and machine on both sides of the loop
People and models share both writing and review. A human stays responsible for load-bearing code. This common team setup works well when everyone knows which changes require which kind of attention.
Breaks when
Habit decides which changes get human attention because the team never wrote down the rule
Human review disappears first when a deadline gets tight
Assisted · Machine-gatedSandbox · Live service · Under audit
The Shipper
merge and move
Fast iteration, machine verification
You iterate quickly and let machines handle verification. That works while failures stay small and changes remain easy to reverse. Both conditions need regular checking.
Breaks when
The code that ships this way outlives the assumption that made it safe
A schema, payment path, or integration becomes hard to reverse without triggering a review change
Summoned · Every lineLive service · Under audit
The Supervisor
the human gate
Agents generate, humans verify, real stakes
Agents write code for systems that matter, and people review every change. This preserves strong independent checking at high automation, but it consumes a great deal of human attention.
Breaks when
Review capacity sets the limit even when agents can generate much more code
Reviewer fatigue turns a real gate into a rubber stamp nobody has measured
Summoned · Second pairSandbox · Live service · Under audit
The Orchestrator
fleets, not diffs
Fleets of agents, harnesses instead of diffs
You run several agents and spend your time on specs, harnesses, and evals instead of individual diffs. The pipeline is the unit of work. Verification remains independent because you design and maintain it as its own system.
Breaks when
Nobody can reconstruct why a given decision was made, because no human made it
The evals measure what was easy to measure, and the gap is invisible until production finds it
Summoned · Machine-gatedLive service · Under auditJudgement: Own taste · Peer council · Codified law
Machines write and check the code while people watch dashboards. Throughput is high, but independent verification is low because the writer and reviewer often share the same blind spots. If the model also has the final say, there is no outside authority left in the process.
Breaks when
Correlated failure: the model that wrote the bug is the model that cleared it, and it fails silently
The first serious incident is also the first time anyone reads the code
Summoned · Machine-gatedLive service · Under auditJudgement: The oracle
The Believer
takes the model at its word
Machines write it, machines check it, and the machine says it is correct
Agents write the code, an AI reviewer approves it, and the model has the final say. Unlike a Dark Factory, no person, team, or fixed gate can overrule the system. The writer, reviewer, and judge share similar blind spots, so one bad answer can be approved three times. This is the least independent position on the map, and it can look perfectly healthy from inside the loop.
Breaks when
The writer and every checker share blind spots, making some mistakes hard for the whole system to see
Confidence grows even as independent checking falls, and the model continues to report a clean result
Eight of them exist only at Sandbox stakes
With nothing at stake, the sign comes down to who controls the target. An outside standard makes the work directed: the finish line cannot move to suit the result. A loop-owned standard makes it exploratory because the same loop writes the code and decides what counts as done. That separates a Learner from a Hobbyist, or a Benchmarker from a Skeptic. At higher stakes, the consequences define the sign and an independent reference changes the risk instead.
Forged · Every lineSandboxIndependent reference
The Learner
the long way round
Hand-written, self-reviewed, nothing at stake
You write every line of a project that cannot hurt anyone. It is slow, but the work builds the intuition you will need when you start delegating. Learning through the friction is part of the result.
Breaks when
Mistaking tool avoidance for rigour
Staying here past the point of return, so the first agent-heavy job is a cold start
Forged · Every lineSandboxLoop-owned reference
The Hobbyist
for its own sake
hand-written, self-reviewed, no target but yours
You write and review the code yourself, without a written definition of done. The project takes shape as you build it. With no other stakeholder and little at risk, you can learn lessons that would be costly on a live service.
Breaks when
Habits that work for a solo project fail when users or teammates start depending on it
Nothing was written down, so returning to it later means reconstructing the intent from the code, and the code is all there is
This is interview prep, katas, or deliberate practice. You work unaided, then ask a model to grade the result. Because the model did not help write the answer, it can provide a useful outside view.
Breaks when
Optimising for a rubric that no longer resembles the job
Practising generation while the job has moved to specification and verification
Forged · Machine-gatedSandboxLoop-owned reference
The Weekend Builder
shipped by Sunday, gated by the model
hand-written, machine-checked, whatever you feel like building
You write the code and let an AI reviewer approve it. The scope changes as you go, but only your weekend is at stake. The same workflow on a live service would leave a much thinner margin.
Breaks when
The model's approval is the only signal you get, and you will not notice the day it stops being a good one, because nothing here fails loudly
The identical posture at Live service is a Lone Author on a thin margin, and it does not feel any different from the inside
Summoned · Every lineSandboxIndependent reference
The Benchmarker
runs agents against a known answer
agents write it, you read all of it, and the target was set in advance
You give agents a task with a known answer, such as a kata, benchmark, rubric, or written spec, then read everything they return. The goal is to learn what the tools can do before you depend on them. A fixed target and a full human review make that test meaningful.
Breaks when
A good benchmark result is mistaken for proof that the agent will handle an unfamiliar codebase
The experiment assumes a level of human attention that will not scale to delivery work
Summoned · Every lineSandboxLoop-owned reference
The Skeptic
read it all anyway
Agents write, you read every line anyway
Agents write the code, but you still read every line. You are testing the tools before relying on them, and building an evidence-based view of where they help and fail.
Breaks when
Reading output at a volume no human sustains, then stopping without noticing
You define “done,” hand the work to agents, and let an AI reviewer judge the result. Nobody reads the diff. In a sandbox, this is a cheap way to learn whether your written target can be checked by a machine.
Breaks when
An ambiguous line in the spec becomes a wrong answer with no outside check
A safe sandbox result is treated as proof that the workflow is ready for live systems
Describe it, run it, and keep it if it works. For a disposable prototype or demo, that can be a sensible trade. The machine handles both writing and review, and a failure affects only you.
Breaks when
The prototype gets users
The demo becomes the codebase and nobody marks the moment it happened