Tag: context engineering

The Monorepo Cargo Cult: You Broke Your Architecture for an Illusion

Developers are physically merging separate projects into one git repository because they think it helps AI agents read code. It doesn’t. You’re paying a real architectural price for an imaginary benefit.

I ran into a misguided pattern going by the terrifying name "the monorepo." People are seriously merging different projects into a single physical git repository because they think it makes it easier for an agent to "walk the files" and understand the overall context of a large corporate system. Dozens of comments under the post: oh yes, we started doing this too, excellent mechanism, everyone is happy.

This is the wrong abstraction boundary.

Continue reading “The Monorepo Cargo Cult: You Broke Your Architecture for an Illusion”

Why AI works for everyone except certain developers

Non-technical people are outperforming developers with AI. This isn’t luck. It’s a very old principle showing up in a new context.

Something counterintuitive has been happening over the past year. The people most likely to complain that AI is "useless" are software developers. The people actually getting results? Course sellers, project managers, humanities graduates, and business analysts.

The pattern has a name.

Continue reading “Why AI works for everyone except certain developers”

The Self-Learning Agent Pattern: decisions.md + mistakes.md

AI keeps repeating the same mistakes? That’s not a model problem. It’s an engineering gap. How to give your agent persistent memory in three minutes — and why this beats RAG for most projects.

Developers complain that AI repeats the same mistakes. "I've explained five times that we don't use Redux here." "It suggested FTP again instead of a queue." "It keeps ignoring our naming conventions."

That's not a model problem. It's an engineering gap.

Continue reading “The Self-Learning Agent Pattern: decisions.md + mistakes.md”

How to design professional software architecture with AI even if you don’t know the domain

Without a domain substrate, an agent ships FTP and CSV and calls it done. Book-as-context puts a book into the project as a wiki — next to LLM Wiki and book-to-skill — so a short prompt yields outbox, queues, idempotency, and fault tolerance.

Give the agent an authoritative book on the subject as a wiki in the repo — indexed and cross-linked, not a one-off file drop into the chat. Then even a short prompt designs in the source’s terms: queues, delivery guarantees, idempotency, fault tolerance. Below: the book-as-context method, a shop→ERP walkthrough, and the method’s limits.

Continue reading “How to design professional software architecture with AI even if you don’t know the domain”