"Compounding Engineering", Building Self Improving Systems With AI
Building systems that build themselves better the second time around.
This is the first in a series of posts on lessons learned from implementing AI in my work and how I was able to 5x our production code velocity within my team and personal projects. It’s a bit of a sidecar to my side projects, if you will.
Here’s a tight brief on “compounding engineering”—Every’s term for building AI-native systems that get faster and better with every task because lessons are captured, encoded, and reused by default. Every, the media and research company founded by Dan Shipper, has become known for its deep dives on technology and productivity, and recently for coining the idea of ‘compounding engineering,’ a way of building systems that continuously get better.
High Altitude 🪂 What It Is and Why I’m a Fanatic For It
If you do it twice, make a tool for it to do itself.
Core idea: If you do it twice, make a tool for it to do itself. Don’t just use AI to go faster today; wire your system so that every it teaches your system to do better the next time: prompts, tests, linters, scaffolds—so tomorrow’s work is easier than today’s. —Every
At Every: Engineers build prompt libraries, automations, and guardrails so “each feature makes subsequent features easier to build,” not harder. Lenny’s interview with Every’s co-founder Dan Shipper highlights this as a central operating model to how they are building 6 products and running their content series with only 11 people. Lenny’s Newsletter
Why it matters: It aligns with the broader shift to compound AI systems: composed workflows where modules and memory compound capability over time so each iteration takes less and less intervention. bair.berkeley.edu
Low Altitude 🤿 3 concrete things your startup can do this week
Pattern → Prompts
Do: If you do it twice, it’s worth looking to automate it. Build a prompt/tool library for repeated tasks from writing articles, commenting on others’ posts, making tasks and calendar invites from your AI meeting notes, etc.
Effect: Continuously, half the time you spend on repetitive tasks without losing your authenticity or personal touch.
Concrete Examples For Programmers:
Code Reviews
Do: Instead of letting code review feedback get lost in comment threads, have an agent capture the key lessons from each pull request in a simple, shared library (think: a living team playbook for all code). Summarize patterns and common pitfalls, drop them into your internal guide, and make sure the team gets a quick update.
Effect: Code review feedback doesn’t die in comments; it becomes the model’s defaults for future changes (naming, security, migrations, infra, conventions) and creates a cheat sheet for new devs and AI agents to prevent repeated mistakes. Every
Bug → Guardrail Pipeline
Do: When an issue is labeled “bug,” trigger a bot to study it, analyse it, and prevent it in the future i.e. generate a failing unit test, add a regression test on fix, create a linter/check (or policy-as-code), and append a “Never again” rule to your agent’s prompt pack.
Effect: Each bug permanently raises the floor for fewer repeats, faster reviews, safer refactors. This is exactly the “every bug becomes a permanent lesson” loop. Every
Support → Playbook → Agent Tools
Do: Make solved support tickets solve future problems by turning each one into a quick Q&A entry or snippet, tag the root cause, and drop it into both your customer help tools and your team’s internal playbook.
Effect: Time-to-resolution drops, support knowledge base compounds across channels; ops and engineering gain a live knowledge base that AI can act on. (Echoes Every’s emphasis on prompt libraries and ops enablement.) Lenny’s Newsletter
An example of this in Sales would be lead gen, deal enrichment, outreach, scheduling, etc. Anything you are doing twice in your sales process across your deals. We built or use AI tools in every one of those use cases to help a lead salesperson act as a full sales team, so he’s in more meetings and fewer cold calls.
Back to High Altitude ✈️ with Operating as a System
Adopt a simple loop and an owner:
Observe → Translate → Automate → Measure.
Observe: Repeated tasks, PRs, incidents, tickets, specs.
Translate: Summaries → prompts, tests, policies, etc. (How the AI can read it)
Automate: bots, mcps, codegen, prompt libraries, etc.
Measure: Lead time, escaped bugs, repeated tasks, duplicate issues, % PRs auto-scaffolded, % fixes that add tests.
Assign an AI Operations Lead to your team. This person doesn’t need to be technical but can spearhead the process of finding compounding opportunities and building solutions across sales, marketing, fundraising, engineering, etc. I took this idea straight from Every’s Dan Shipper, and spearheading it from the top encourages adoption throughout the company. Lenny’s Newsletter
This scales small teams: Each task deposits reusable assets (tests, prompts, patterns) into your system. Over weeks, scaffolds and guardrails accumulate like compound interest, shifting your team from one-off velocity to systemic acceleration—a hallmark of compound/compound-AI workflows. This multiplies efforts across any role in your company. bair.berkeley.edu
Further reading & proof points: Every’s essays and podcast on compounding engineering and AI agents in practice. Every



On the AI train! Woot woot
This loop is real. What surprised me is how much making the 40-10-40-10 split explicit (plan-work-review-compound) formalised what I was already doing implicitly. The compound step is easy to skip because it feels like overhead, but it's the whole point. Without it you're just running the loop without capturing the learning and you're back at zero next session. The other unlock was git worktrees to keep agent work isolated. Wrote this up as a proper guide: https://reading.sh/compound-engineering-with-ai-the-definitive-guide-05530cf717dd?sk=613e5efd4b161229eee1aba7a7ba1a32