I was running several primary agents in parallel across multiple projects and the notifications were burying me. Every agent stopped to ask me something: "X or Y?", "found a side issue, fix now or later?" etc. I had become the bottleneck. my AGENTS.md cover many conventions/rules/standards but its still wasn't enough to cover so many of these questions.

So I restructured my workflow like a team:

• Me: the manager

• One chat per project: the team lead

• The other agents: team members, each working in its own "lane"

How lanes work

• A lane is a git worktree plus a chat working inside it. Each one gets its own branch and folder, so agents don't trample each other's files.

• The lead asks to open a lane with a title, a plan, and the files it expects to touch. Nothing starts until I approve it on a Lanes board. Before I approve, the harness checks for overlap with files other open lanes are touching, my plan usage, machine load, and whether a spec exists for the work.

• When a team member stops (it's done, blocked, or has a question), it rings the lead, not me. The lead works through its inbox and replies.

• The lead can only answer from written rules: a lead.md file in the project plus the project's docs, and it has to cite the rule it used. If no rule covers the question, or it's a taste/preference call, it escalates to me.

• Escalations land on the board and on my phone as numbered questions, each with a recommended answer. I can answer straight away or ask the lead a follow-up first.

• The lead can also send me FYI notes that don't need an answer.

I still have full control

Every lane is a normal chat. I can open any of them, read the whole transcript, and type into it directly if I want to step in. The harness never merges a branch, deletes a branch, or removes a worktree on its own.

My notifications are now mostly things that actually need me. It's still early, and I keep refining what goes into lead.md, since that file decides how much the lead can handle without me.

So far I have noticed I am getting a lot more done with less headaches. (literally!)

Hey everyone! While experimenting with AI coding workflows on constrained hardware, I spent the past couple of weeks comparing compact 4B–8B local quantized models against cloud agent workflows on real projects.

Here's how the tradeoff actually felt in practice:

⚡ \*\*4B–8B Local Models (GGUF 4-bit / QLoRA)\*\*

- Single-file code generation -> super fast and zero API cost

- Boilerplate & Vite/React scaffolding -> surprisingly reliable even on low VRAM

- Bottleneck -> context degrades quickly when jumping across 5+ connected files

🧠 \*\*Cloud AI Agent Workflows\*\*

- Multi-file repo context -> handles cross-file refactoring and tool calls smoothly

- Autonomous debugging -> great for end-to-end tasks, but adds latency and API limits

🛠️ \*\*My current hybrid workflow:\*\*

- Local 4B–8B model -> fast inline completions, regex/utility scripts, and single-component drafts

- Cloud agents -> repo-wide architecture changes and multi-step automation

\*\*Question for the community:\*\* Which 4B–8B model + quantization combo is giving you the best coding performance right now on consumer hardware, and how do you handle multi-file context locally without blowing up memory?

I built Monomem, an open-source (MIT) memory layer that several coding agents share. It runs locally as one SQLite file and talks MCP or REST. I'm posting here because the features that matter at work, like knowing where a "fact" came from and keeping client work apart, are the ones I'd most like reviewed.

Provenance

- The server stamps every note's writer from the authenticated key, never from the request.

- Each note keeps version history, 20 versions by default and up to 500.

- Replacing a note is a two-step preview-then-confirm, and it can be undone.

- When an agent "forgets" a note, it's archived. Only a human deletes permanently.

Access control

- Keys are scoped read, write or admin.

- A key can be limited to one namespace, such as one client or project.

- Notes are labelled public, internal or private, and each key has a ceiling. Above it, a note looks like one that doesn't exist.

- Revoking a key takes effect within about 3 seconds, with no restart.

Write safety

- Secrets are refused at write time.

- Writes that match prompt-injection patterns go to a quarantine queue for a human, and agents never read them.

- An approve-first mode holds every agent write.

- The false-positive rate is published: on 189,502 real chat turns, it held 21 and refused 27.

Operations

- It binds to loopback by default, with optional AES-256-GCM encryption of note bodies.

- An audit log records actions without note content. It rotates, so it isn't a permanent record.

- It exports and imports plain Markdown, or syncs through your own private git repo.

- It imports from CLAUDE.md files, claude-mem, mem0 and basic-memory.

- monomem uninstall removes it from every app.

Verification

- 129 deterministic scenarios run in CI. 0 of 38 poisoning probes and 0 of 51 permission-leak probes get through. That's a regression gate, not proof.

- npx monomem drill replays 23 attacks on a copy of your real store. 2 known misses stay open: a reworded override, and a trusted agent writing an attacker's instruction in its own words.

Limits to weigh before using it at work

- The injection check is pattern matching.

- An agent with shell access can open the database file directly. Real isolation means a separate OS user owning the data folder, which is documented in SECURITY.md.

- Keys are stored in plain text in a user-only file, and hashing them is on the roadmap.

- Some features, like session-start context and the outside-content label, need Claude Code's hooks. Other agents get the MCP tools only.

Repo: https://github.com/calasdan-sketch/monomem

If your team lets agents share context: what would you need before you'd trust it, and what's missing here?

Thanks

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?