# ============================================================================= # COMPETENCY RECORD - Cedric Ancellin's demonstrated engineering skills and # experience. Third-party technologies and vendors are named as the concrete # skill surface. Professional background / track record. # ============================================================================= # ============================================================ # AI-ORCHESTRATED SOFTWARE DELIVERY & AGENT GOVERNANCE # - COMPETENCY RECORD # ============================================================ # Core Purpose: # Demonstrated experience directing AI coding agents to build # and operate a production application end to end - as product # owner, not code author - and engineering the governance system # that keeps a memoryless AI producing consistent, safe code. # ============================================================ summary: > Led a production web application built with 100% AI-authored source code, zero human-written lines, acting as product owner and technical director rather than code author. The differentiator is not "used AI to code"; it is the governance system engineered to make that safe and repeatable: a project-local knowledge oracle that serves as the codebase's institutional memory, a codified rule set learned from real production incidents, agent-onboarding and escalation protocols, and hard guardrails on how agents may act. This is the same documentation-as-infrastructure discipline as COMP-11, taken to its limit, the AI is the only author, so the knowledge system IS the engineering process. Demonstrated across more than one product, spanning a supervision spectrum: from an AI-led build the owner directs, to a distributed system whose load-bearing architecture is human-designed and could not have been produced by AI alone (see section 6 and COMP-21). # ================================================================== # 1. THE DELIVERY MODEL # ================================================================== model: classification: "AI-First / agent-directed development." split: "Human-authored source code: 0%. AI-authored: 100% (components, server actions, API routes, middleware, config, and the documentation itself)." human_role: title: "Product owner & technical director" does: - "Defines what to build, why, and in what priority." - "Reviews AI output in real time and approves or redirects." - "Validates behavior in production and owns the outcome." - "Approves every architectural decision, the AI cannot approve its own." does_not: ["Write source code", "Write documentation", "Debug code directly"] ai_role: title: "Developer (model varies by session)" does: ["Writes all code and docs", "Debugs from production error reports", "Proposes architecture", "Runs build/deploy/validation"] constraint: "No persistent memory across sessions, every session starts cold and must rebuild context from the oracle + code alone." # ================================================================== # 2. THE GOVERNANCE ORACLE (INSTITUTIONAL MEMORY) # ================================================================== governance_oracle: premise: > With no human author and no AI long-term memory, undocumented knowledge does not merely degrade, it ceases to exist. So the knowledge base is not supplementary; it is the only place project understanding persists between sessions. structure: "~50 cross-referenced YAML files: an overview + architecture entry point, a file registry, per-feature domain docs, and per-template specs." key_artifacts: laws: "A compact, scannable set of ~18 non-negotiable production rules, the anti-drift backstop for long sessions." anti_patterns: "~35 entries, each a real production bug or near-miss an agent caused and then fixed, written as full wrong-vs-correct examples with grep-able enforcement checks, debugging history, not style preference." decisions: "An approved architectural-decision log (all AI-proposed, human-approved)." open_questions: "Explicitly tracked unresolved questions, so uncertainty is visible rather than silently guessed at." operating_rules: - "The oracle is the single source of truth, if a decision or constraint is not written down, it effectively does not exist." - "Document the WHY, not just the WHAT, the next agent starts fresh and must reason correctly in novel situations." - "Every session must leave the oracle better than it found it, knowledge only persists if the agent writes it down before the session ends." # ================================================================== # 3. AGENT GUARDRAILS & PROTOCOLS # ================================================================== guardrails: oracle_first_rule: "Agent-entry files (AGENTS.md / CLAUDE.md) mandate reading the relevant oracle docs before writing any code, enforced as the first step, even for 'simple' changes." onboarding_order: "A prescribed reading order (overview → architecture → laws → anti-patterns → the task's domain file) so a cold agent reaches sufficient context before acting." sandboxing: "Throwaway discovery/diagnostic scripts are quarantined to a dedicated git-ignored directory, never mixed into production code or the knowledge base." human_approval_gate: "Agents propose; the human approves. No agent ships an architectural decision on its own authority." framework_currency: "An explicit warning that the framework version differs from agent training data, forcing agents to read the shipped docs instead of relying on stale priors." # ================================================================== # 4. ESCALATION - KNOWING WHEN THE FIX ISN'T CODE # ================================================================== escalation: principle: > Some failures live in systems only the human controls (tracker admin screens, identity provider, cloud, DNS). Editing code until the error disappears silently defeats the feature. The governance system codifies STOP-and-escalate directives for these. worked_example: > A tracker "field cannot be set, not on the appropriate screen" error is a tracker-admin configuration issue, not a payload bug. The directive: translate the field id to a human name, tell the owner exactly which screen to edit, and re-test the UNCHANGED payload, explicitly do NOT strip the field to make the error go away, which would discard the data the form exists to capture. # ================================================================== # 5. WHAT THIS DEMONSTRATES # ================================================================== insights: consistency_is_double_edged: "Agents apply a pattern uniformly, a strength for coherence, a risk because a flawed pattern propagates to every surface at once (one migration had to update all 38 submit functions together). The oracle's laws exist to catch this class before it ships." process_as_artifact: "Treating the AI development loop itself as an engineered system, with memory, rules, onboarding, and escalation, rather than ad-hoc prompting." transferable: "The same discipline underpins the platform-scale knowledge base and MCP server in COMP-11; here it is proven on a full, independently-shipped product." # ================================================================== # 6. THE SUPERVISION SPECTRUM - WHERE HUMAN ARCHITECTURE IS LOAD-BEARING # ================================================================== supervision_spectrum: description: > Not all AI-assisted delivery is equal. Across more than one product, the same governance discipline was applied at very different levels of required human input, the key judgment is recognizing which a given system demands. ends_of_the_spectrum: ai_led: "A self-contained app (COMP-19) where the design space is narrow enough that the owner directs and the AI authors nearly everything under review." human_architected: "A distributed, multi-repo platform (COMP-21) where the hard value is in the seams, frontend/backend segregation, delegated-verification-vs-self-minted-session split, and PaaS/reverse-proxy failure modes. That system design is human, deliberate, and load-bearing; AI could not have produced it unaided." what_the_harder_end_requires: - "Human system architecture up front, deciding what is segregated, what crosses each boundary, and who owns identity vs. session." - "Continuous 'AI babysitting': catching an agent about to reintroduce a provider cookie, forge an identity header, or use the container origin behind a proxy, each already encoded as a non-negotiable law after it bit once in production." - "Strong, standing guidance: per-repo laws, AI-governance rules (script quarantine, native-edit-only, check-oracle-before-asking), and machine-validated oracle integrity (pre-commit hooks) that keep a memoryless agent inside the architecture's guarantees." leadership_signal: "The competency is not 'AI writes the code', it is knowing when AI can lead, when it must be tightly supervised, and building the guidance apparatus that makes the supervised case ship safely." cross_reference: ai_knowledge_engineering: $ref: "https://zc8.com/competencies/11_ai_knowledge_engineering" note: "Platform-scale sibling, knowledge base + MCP server. This competency is the standalone, end-to-end delivery proof." technical_leadership: $ref: "https://zc8.com/competencies/12_technical_leadership" modern_fullstack_product: $ref: "https://zc8.com/competencies/19_modern_fullstack_product" note: "The AI-led end of the spectrum, the application this methodology produced." distributed_service_segregation: $ref: "https://zc8.com/competencies/21_distributed_service_segregation" note: "The human-architected end, a distributed system AI executed under strong supervision."