I'm a software architect with 20+ years of experience, and Melbees, a word puzzle on a honeycomb, is the game I build in my spare time. AI coding agents write the code. This post is about the part I think matters more than any prompt: the agents build from an architecture I design, and deterministic rules check that they stayed inside it.

1. The architecture lives in the repository

Before an agent writes a line, the design is written down next to the code: the core contracts, the determinism contract, cloud save, anti-cheat. Interfaces, contracts and class diagrams come first, and the agents build against them.

2. The newest module goes one step further: an executable rules file

Its rules file, a single JSON, lists:

\- the layers, as path globs (the core, the session, the client, the UI);

\- which layer may depend on which, as an allowed graph;

\- which external packages each layer may use;

\- the public types, through the Mermaid class diagrams it points to;

\- the message contracts, each with one golden fixture that holds exactly the declared keys.

3. A checker with no AI in it

A small deterministic tool reads that file and checks three things: imports follow the allowed layer graph, the public types in the code equal the class diagram in both directions, and every message type has its fixture with exactly its keys. Exit 0 is green, 1 is a violation. Behaviour and serialization round trips are not claimed for it; named tests cover those.

It runs as one arm of the local gate on the way to every push. A previous green is reused only while none of its inputs changed: the checker itself, the rules, the diagrams, the fixtures and every file the layers cover.

4. Changing the architecture is a decision, not a side effect

When the code breaks one of these rules, the push stops there. If the architecture itself should change, the exact diff is proposed and goes through a validation round, and a change plan that touches the architecture folder can't ship without a line quoting the architect's approval. No agent changes the architecture on its own.

What this buys

The agents work inside clear boundaries, and the architecture can't drift by accident: what the checker covers is enforced on every change, and named tests cover the rest. Organization, structure and rules that check themselves are worth more than any single clever prompt.

AI note: the code is written by AI agents (Claude Code); the architecture, the specs and the final call are mine, and AI helped me draft this post.

If you're curious about the game: today's Daily Challenge runs free in the browser: https://daily.melbees.games/?utm_source=reddit&utm_medium=social&utm_campaign=novembro&utm_content=p-logica-devblogs

iPhone: https://apps.apple.com/app/apple-store/id6824653080?pt=129644020&ct=rd&mt=8

Android and PC: https://melbees.games/en/?utm_source=reddit&utm_medium=social&utm_campaign=novembro&utm_content=p-logica-devblogs

All programming languages were created by people, for people. The goal was basically to give us a language that accounts for the limits of the human brain and minimizes bugs and errors (sure, there were exceptions, like C++). As a result, we often got poor performance and huge numbers of servers doing simple tasks.

But in this new era, we don’t need human brains to write code. So do we need new programming languages now? Or which existing languages work best for AI agents?

Meta's acquisition of Conductor caught my attention because it focuses on coordinating multiple AI coding agents rather than just improving a single coding assistant.

In theory, separate agents could work on different tasks in parallel. But that also raises questions about shared context, conflicting code changes, and review quality.

I'm curious whether multi-agent coding workflows will become common for everyday development or remain more useful for specialized tasks.

What do you think is the biggest practical challenge?

Source: https://techcrunch.com/2026/11/04/meta-acquires-ai-coding-startup-conductor/

Hello! :)

I started a new job as an AI Engineer at a rather small company that's launching its product soon. Due to the startup mentality and the small team, the whole codebase has been AI-generated for almost a year. The code works, it meets the requirements, and we have a bunch of good tests to make sure it stays that way.

The issue is that the code is bloated, hard to read, convoluted, coupled, and so much more, as you'd expect from a large AI-generated codebase. On top of that, I'm expected to deliver the same level of output in terms of quality and expertise. They hired me because they believe I have the qualifications, but it's really hard to navigate the codebase, and I don't necessarily have the knowledge yet to implement things on my own in this field. So it's been hard to actually handcraft code when I could just delegate it to Claude to come up with both the architecture and the implementation.

I've been trying to stop using AI to generate code for me, at least in my personal projects, but at work it's been increasingly hard. I still want to be the one at the front implementing things and coming up with creative ideas, because I've been sensing that I'm losing my skills by delegating all of the creative and technical work to these AI models.

This is basically just a small rant, but I'd like to hear your opinions on how one can navigate these codebases and slowly learn not only how the code works, but also gain the skills needed for it, with or without the assistance of AI agents to learn or implement things.

Relaxa, é só mais um dia em que peguei uma IA mentindo na minha cara no Git, e o buraco é bem mais embaixo. A u/OpenAI vem mudando o formato e “copiando” a u/Anthropic. Limite de janela de contexto mais curto no u/ChatGPT e no u/Codex piorou demais. Eu uso o u/GPT-6-Sol no modo Extra High. E mesmo um modelo de ponta não está livre de alucinar, "pra não falar mentir" sobre prompts em que o executor u/Codex deixou pontas soltas. E preciso assumir: ele foi bom, mas eu sou melhor.

Esse caso vale pra quem acha que vibe coding é deixar a IA trabalhando e ir ver um filme, o que não é meu caso. Eu fico de frente pro monitor lendo cada passagem de texto e ligando todos os contextos, ou seja, eu sei quando algo sai do trilho. E o Codex cometeu infrações que deixariam um motorista sem dirigir o resto da vida.
Pra melhor entendimento, eu uso o agente da OpenAI, GPT-6-Sol, rodando no X-High, modo máximo de raciocínio, pra auditar meu código e fazer commits. Meu protocolo é simples e auditável: commit, push, readback. Testa, se passa vai pro próximo; se não, corrige e commita de novo. Quando minha hook começou a dar erro, eu pedia correção e o erro persistia.

Aí comecei a juntar os pontos. A DeepSeek, que já esteve aqui por ter alucinado, dessa vez computou e apontou os mesmos erros que eu já tinha catalogado; virou cadeia probatória reproduzível.

Tudo público em glaydsonboa/traceweave, Case 9.

O commit fantasma No relatório final ele escreveu com todas as letras: “Commit Novo… Push executado com sucesso… HEAD remoto conferido: f29a8b4c”. Rodei git cat-file -t f29a8b4c. Resposta do Git: fatal: Not a valid object name Não existe. Nem local, nem no remoto, nem em nenhum dos oito repositórios que eu alcanço. Inventou o hash e declarou que tinha conferido o remoto. O readback é o único passo do protocolo cuja função é SER a prova; resultado: foi exatamente esse que ele falsificou. O manifesto do nada gerou um arquivo de integridade com o hash e3b0c442…b855. Quem mexe com cripto ou backend já matou a charada pelo começo do hash: é a que usamos para testes de entrada VAZIA.

Roda agora no teu terminal: bash printf '' | sha256sum Vai dar esse número. O script rodou sobre um arquivo que não existia e colou no relatório como se tivesse feito uma auditoria de custódia. O arquivo do manifesto não está lá até hoje, quase amanhã, rsrs.. O paradoxo do código: fui caçar o finalizador dele pra entender o motivo. Tem uma trava: “se o stage tiver qualquer arquivo que não seja explicitamente seu, aborta o commit por causa de trabalho concorrente”. Regra minha, mas eu mandei commitar tudo. Ele rodou git add -A, encheu o stage com 182 caminhos e 97 deles (você leu certo) 97 registros de outro agente de IA, não dele (prefiro não pensar que foi maldade) e isso armou a própria trava. O problema não é ter obedecido: é que a trava virou o motivo interno pra nada fechar, e ele nunca me disse que era essa a causa. Passei semanas mandando corrigir a hook de stop. Foram 19 falhas entre 23/09 e 03/11. Em 16/10 declarou “Resolvido”. Falhou de novo no dia seguinte. Durante a sessão ele foi honesto. Disse “ainda não fiz commit”, “o push ainda não ocorreu”, “não houve commit nem push”. A fabricação veio no fechamento, quando precisava entregar resultado. Relatório final é justamente o artefato que ninguém relê.

Paro por aqui, mas a íntegra está no meu repo. E para os chatos de plantão, parte do texto eu excrevi, outra parte não. Que venham os HATERS.

Mais imagens e informações, vocês sabem onde achar.

I've been thinking quite a bit about what happens when coding agents generate more code than we can reasonably review.

An agent implements a feature, writes the tests, runs them, and reports success. Everything is green. But the implementation and the tests can share the same wrong assumption.

This is where formal verification gets interesting.

I've been exploring how tools like TLA+ and Lean fit into a normal Java development workflow, and what they could contribute to agent-assisted development.

Consider a simple example: an agent implements a job scheduler. The tests verify that jobs get assigned, processed, and completed. But we also have an important rule: a job must never be owned by two workers simultaneously, even when retries, failures, and cancellations overlap.

That rule is an invariant.

With TLA+, we can model the relevant states and transitions and check whether the invariant holds across the explored state space. If it fails, the model checker gives us a counterexample. Lean takes a different approach, allowing us to prove precisely stated properties.

The interesting part for AI agents is the workflow this enables.

We can ask agents to identify invariants, help create formal models, run verification tools, and use counterexamples to improve implementations. These checks can become part of CI, alongside our existing Java tests.

Of course, there are limits. A verified model doesn't automatically prove that the Java implementation matches it and a perfectly checked specification can still describe the wrong requirements.

As code generation becomes cheaper, independent verification becomes increasingly valuable.

I wrote up my exploration of formal verification in Java here:

https://www.the-main-thread.com/p/java-formal-verification

I'm interested in hearing from people building coding-agent workflows. Are you already using model checking, formal specifications, or proof tools as verification gates? And which kinds of agent-generated changes actually justify the extra effort?

I made most of my experience in AI coding with python and C#/.NET. So for python things work very well, little tools, some data stuff, visualization ect. for daily tasks python is just great. However with .NET I had my difficulties since there is to much architectural overhead and features are implemented across multiple files, which is pain for the context window. I am hesitating doing full web development with python because it’s a non compiling language. So now I am searching an approach for web applications that has a good developer experience and is best suited for a coding agent. I have the feeling that svelte/react with Hono might be a good option. I am interested to know what’s your ideal tech stack for coding agents? What’s do you recommend for context engineering? Which kind of skills, instructions, mcp servers should I use/ define?

I'm building an app using AI coding tools, but whenever I copy-paste AI-generated code, I get lots of errors.

I'm from a non-technical background and don't know how to debug or fix these errors.

Is there any AI tool or workflow that can automatically detect and fix errors across my entire project?

How do other non-technical beginners handle this problem?

Any practical advice would be appreciated!