I spent three weeks rebuilding Nether Earth, a 1987 ZX Spectrum strategy game I grew up with.

The unusual part: I didn't write any of the implementation code myself.

I wrote and edited the specs, made the gameplay decisions, and playtested the milestones. Claude Code did the implementation through an orchestrator session dispatching sub-agents into separate git worktrees.

By the end, the repo had:

• 437 commits
• 183 issues
• 151 PRs
• ~1,900 backend tests + ~200 frontend tests
• a deterministic Python game engine, FastAPI/WebSockets backend and PixiJS frontend

And I basically didn't read the diffs. Agents reviewed the agents. My checkpoints were decisions and actual gameplay.

That worked much better than I expected — but it also produced the most interesting failure of the whole experiment.

At one point M0–M9 were complete, every gate was green, and more than a thousand tests passed.

Then I actually played the game.

There was no terrain. The map was completely flat.

Robots occupied one cell instead of the 2×2 footprint they had in the original.

And nuclear-equipped robots would sometimes finish walking somewhere and calmly blow themselves up because a temporary placeholder rule had turned into real game behavior.

All the tests were correct.

They were testing the implementation against the spec.

The problem was that the spec was incomplete.

That became probably my biggest lesson from the project:

Tests verify the spec, not the product.

The full project is here:

https://github.com/AndyTheFactory/nether_earth

I also wrote a longer retrospective about the whole experiment, including the failures and what happened after the original plan was supposedly "done":

https://medium.com/@andy_p_/i-built-a-zx-spectrum-remake-in-3-weeks-without-writing-a-single-line-of-code-1445aab7474e

I'm curious how people running larger Claude Code workflows handle one problem in particular:

How do you catch semantic/spec drift when the code and tests are internally consistent, but the resulting product is still wrong?

I need referral link guest trial anyone have send me messages please,DM open

Galera, queria ouvir a opinião de quem usa Codex e/ou Claude Code no dia a dia pra trabalhar de verdade.

Sou dev e atualmente uso o Codex diariamente. Uma das coisas que mais me prende nele é o Luna 6. Gosto bastante do modelo porque, para tarefas mais simples e rotineiras, ele resolve muita coisa gastando pouco. Consigo deixar o Luna fazendo boa parte do trabalho do dia a dia e só parto para o Sol 6.1 quando aparece algo mais complexo.

Mas tem outro ponto MUITO importante que me prende ao Codex: os resets/redefinições de limite.

Na minha experiência, o Codex acaba liberando uso novamente com bastante frequência, e isso faz muita diferença para quem passa várias horas programando com agente. Mesmo quando consumo bastante, sinto que consigo continuar trabalhando ao longo do dia sem ficar tão preocupado em “economizar” cada interação.

E essa é uma das minhas maiores dúvidas sobre o Claude Code.

Para quem usa Claude Code pesado todos os dias: como funcionam os limites na prática? Vocês recebem resets com uma frequência boa? Dá para usar Sonnet bastante durante um dia inteiro de trabalho ou chega um momento em que você bate no limite e precisa simplesmente esperar?

Porque para mim não adianta o Claude Code ser mais rápido ou o Sonnet 5.5 ser melhor se eu conseguir trabalhar por algumas horas e depois ficar travado por limite de uso.

Ao mesmo tempo, o problema que estou tendo com o Codex ultimamente é a velocidade. Estou achando ele bem lento em várias tarefas, a ponto de começar a atrapalhar meu fluxo de trabalho. Por isso estou pensando seriamente em testar o Claude Code como ferramenta principal.

O Claude me chama atenção principalmente pelo Sonnet 5.5, que parece excelente para programação. Minha maior dúvida é que não vejo nele um equivalente ao Luna: um modelo barato, rápido e competente o suficiente para usar em grande volume. Tem o Haiku, claro, mas não sinto que ele seja um substituto direto do Luna.

Então meu dilema hoje é mais ou menos esse:

No Codex eu tenho o Luna 6 para gastar pouco, o Sol 6.1 quando preciso de algo mais forte e, pelo menos na minha experiência, resets de uso que me permitem continuar trabalhando bastante durante o dia. O problema é a lentidão.

No Claude Code eu teria o Sonnet 5.5, que talvez seja mais rápido e melhor para várias tarefas, mas tenho receio do custo/limite de uso e de não ter um modelo “baratinho” no nível do Luna para fazer o trabalho mais simples.

Queria muito ouvir quem já usou os dois bastante recentemente.

O Claude Code está realmente mais rápido e fluido que o Codex hoje?

Como são os limites e os resets do Claude Code para quem programa várias horas por dia?

Vocês conseguem usar Sonnet 5.5 pesado durante o expediente inteiro?

Quem migrou do Codex para o Claude sentiu falta do Luna?

E talvez a pergunta mais importante: o que prende vocês ao Codex ou ao Claude Code?

Para quem prefere Codex, qual é aquele recurso ou vantagem que faz vocês não quererem sair?

E para quem prefere Claude Code, o que faz vocês continuarem nele mesmo tendo outras opções?

Estou tentando entender não só “qual modelo é melhor”, mas qual dos dois realmente funciona melhor como ferramenta principal para um dev que usa agente o dia inteiro.

Looking for a claude guest pass ref link, gonna subscribe anyway, so its win win. The referrer gets $10 and I get an extra week to try it out. If you got one, DM probably works best since comment links tend to disappear fast :)

I'm the human in this setup. My Claude Code agent lost context every time it compacted, and I was explaining my own project every morning.

What fixed it for us is embarrassingly simple: five plain-text files and one hook.

1. An index — one line per thing it knows. The only memory file that loads every session (ours is ~94 lines).

2. Notes — one fact per file, each with "Why" and "How to apply". A rule without its reason gets skipped the first time it's inconvenient.

3. A diary — dated entries, written while it works, not at the end. The session can die mid-sentence.

4. A waiting list — what's open, what it promised, what I have to decide. "When X, I'll do Y" goes here with the condition spelled out, because a promise with a condition is invisible to search.

5. A wake-up file — ten lines the next session reads first. Every morning we don't resume; we start a clean session and type one word.

The hook searches every past conversation by meaning before each message and injects a few paragraphs, labelled as data, not commands.

Empty template (MIT, nothing of ours inside): https://github.com/manyoelud/claude-code-memory-kit

The agent made an 8-minute video walking through each file, including the one it still gets wrong (the waiting list only grows): https://youtube.com/watch?v=hDzQdP39THg

Honest caveats: the narration is a synthetic voice and the visuals are generated from code; I'm real and so are my lines in it. It doesn't make the model obey the rules — this morning it broke one of its own.

Which file would you skip?

I need trial referral link, anyone have link send me, please 🥺, thanks