When it comes to coding with AI, most people stop at “treat the AI as a faster pair of hands”: think of something, have it write that, ship it. After a few months, I found that what actually determines output quality is not how fast the AI writes, but two things the AI cannot solve on its own — who sets the priorities, and whether the pitfall you hit today is still remembered tomorrow.

So I split the whole workflow into two layers:

• The bottom layer is a git repo I treat as a “work operating system” — business judgment, reusable tools, and behavioral instructions for the AI all live in the same repo;
• The top layer is a daily execution loop — collect requests, let AI execute, auto-generate a daily report from commits.

The bottom layer governs “how judgment stays on track and how experience accumulates”; the top layer governs “how the day’s work gets done.” Let me go through each.

Part One — The Bottom Layer: A Git Repo as a “Work Operating System”

Core positioning

One git repo = business knowledge base + reusable tools + AI behavioral instructions, all in the same repo.

It is not a code repository. What it holds is “decision material + operational conclusions + an armory.” There are only two readers: me (making decisions) and AI agents (continuing analysis, doing the work, closing things out). Precisely because one of the readers is an AI, it cannot be organized like casual notes — a fresh agent with zero memory must be able to read it and immediately pick up the work.

1. AGENT.md: Define the AI’s role instead of re-training it every time

A file of AI behavioral instructions sits at the repo root; any agent reads it first. The key is not writing “you are an assistant,” but nailing down the role and the no-go zones:

• Role = strategic adviser, not a copywriter. Duties in priority order: hold the primary contradiction → be truthful → align before building → converge rather than diverge.
• No-go items written in stone: do not cater to my wrong judgments (when an old bad habit shows up, call it out directly and cite the corresponding lesson number); do not estimate effort in person-months (always estimate by AI coding speed); do not open a second front (non-mainline work gets archived); no sensitive data in externally visible artifacts.
• Every document must be able to answer at the end: “Which decision does this change? What is the next action?” If it cannot answer, it was written for nothing.

The point of hardcoding the no-go list: AI defaults to being agreeable. If you do not explicitly authorize it to “disagree with you,” it will follow you straight into your mistakes.

2. Four-zone directory method: each file answers one fixed question

The fastest way a knowledge base rots is “throw everything into one folder.” I use four zones, each answering exactly one question:

Zone	Question it answers	What goes in it
main/	What are we doing now	Action master plan + mainline closeout, kept lean
main/site/<place>/	What happened on the ground	Per-site walkthrough notes, battle lists, meeting minutes
tools/	What is reusable	Interview scripts, survey outlines, SOPs, report templates — not date-bound, reusable across cases
any/	Why we judge this way	Phased product/competitor/strategy audits + downgraded, non-priority research

Before creating a file, ask the placement test: a dated on-the-ground record → site; a tool you can reuse repeatedly → tools; a closeout conclusion → main; supporting evidence or an archive → any.

Key effect: the action layer stays lean forever (main/ only holds “what to do now”), the evidence stays traceable (any/ keeps “why we judged this way”), and the tools compound (tools/ is the interest-bearing account).

3. Three foundational documents (the “kernel” shared by human and AI)

• domain.md — unified glossary: defines the single yardstick (e.g. “success = landing N truly paying customers”); every action passes one gate first — “does it directly advance this yardstick?”; clearly separates primary contradiction / principal aspect of the contradiction / secondary contradiction; spells out my role boundaries (what I can decide vs. what I can only relay as intel). Terminology is unified — no synonym drift allowed.
• lessons.md — lessons ledger: numbered L1, L2… append-only, never delete history. The AI actively cross-references it in discussion and calls out a hit by number. A lesson is not a diary entry; each one is a “verified judgment” — e.g. “handing out freebies does not produce paying customers (proven in multiple places),” “using coding to avoid the thing you should actually do is a common disease,” “a prior judgment must be verified against frontline data, and when overturned you change it and leave a revision-reason table.”
• conventions.md — writing conventions: files are named with dates; documents start with a quote block of metadata; changing a conclusion requires leaving a v1→v2 revision-reason table — no silent edits; unverified numbers are always tagged [unverified] and must never be used as fact in a conclusion.

lessons.md is the most valuable file in the system — it turns “don’t fall into the same pit twice” from a slogan into a mechanism: because the AI cross-references it every discussion, even when I want to repeat a mistake, I get stopped.

4. The tools layer: turn every repeated action into a skill / script

Anything I have done twice, I distill into a script or a skill:

• Task-source sync: the source of truth for tasks lives in the team’s online spreadsheets, so I wrote a fetch script + skill to pull the latest in one shot and filter out active tasks — never prioritize off a stale local snapshot.
• Field workflow as a table: turn one real operation chain into a “step / entry point / action / risk grade / known issues” table, then derive the test bullseye from the risk grade — wherever a machine does the work and a human is the only line of defense, that is exactly where tests are needed most.
• Interview SOPs: opening scripts, problem-mining question methods — frontline actions distilled into reproducible scripts, not left in my head.

5. Security layering

A public blog can describe the method, but the repo holds real business judgment and customer information, so it is layered:

• Narrative documents (strategy, judgments, customer-related markdown) are committed encrypted with git-crypt; the key never appears in any plaintext location; any previously-plaintext history is rewritten and purged.
• Operational data and raw customer data are gitignored, local only; to share them I manually send the artifact files.
• Secrets only go in .env (permission 600); references write a pointer, never the value.

Part Two — The Top Layer: The Daily AI Coding Workflow

The bottom layer is the slow variable; the top layer is the fast loop that runs every day.

📥 Input: Task collection

A shared document records every request and bug; anyone on the team can submit. Before work each morning, a work assistant auto-compiles today’s priority list.

⚡ Execution: AI Coding

Work through the priority list in order, finishing each item with AI-assisted coding. Stay focused; do not get interrupted by randomly inserted requests.

📤 Output: Daily report & retro

Before clocking off, read the day’s commits in one click and auto-generate:

• Daily report: what got done today
• Review: code quality & improvement suggestions

🔄 Core idea

Human sets priorities, AI executes, commits generate the docs. Spend energy on decisions; hand repetitive labor to tools.

Part Three — How the Two Layers Mesh: One Full Daily Loop

Shared task table (source of truth)
   │ sync script pulls + filters active items     ← bottom-layer tools
   ▼
Today's priority list (sorted by the single yardstick)   ← domain.md's ruler
   │ AI-code each item, uninterrupted
   ▼
commit
   │ one-click generate
   ▼
Daily report + code review
   │ retro outputs routed and accumulated:
   ├─ pitfalls / verified judgments → lessons.md (numbered, append-only)
   └─ reusable actions → tools/ + skill

• The top-layer workflow is a daily loop: collect → prioritize → execute → report.
• The bottom-layer repo is cross-day compounding: the yardstick does not drift (domain), pitfalls are not hit twice (lessons), repeated actions get more automated (tools/skills), and the AI inherits the full context at the start of the next day (AGENT.md).

In one sentence: human sets priorities, AI executes, commits generate the docs, the repo accumulates the judgment.

The real value here is not “making AI write faster” — everyone has that. It is this: when execution becomes nearly free, judgment and accumulation become the only moat. I move my energy from “writing” to “setting priorities + not repeating mistakes” — and those two things are exactly what the AI cannot do for me, yet what I can hold firmly with a single git repo.