Appearance
Workshop 7: Slide Content
Deck title: Engineering Standards & Avoiding AI Technical Debt Duration: 60 minutes · ~22 slides
Slide 1: Title [lavender title slide]
Title: Make the wins stick. Eyebrow: Session 7 of 8 · Standards & AI Governance
Slide 2: Recap [white, headline + body]
Title: The improvements are real. Now we make them last. Subtitle: Where we are in the arc Body: Every fix you've made could be undone tomorrow by a teammate who doesn't know about it. The CI improvements decay if someone disables the cache. The DevEx wins evaporate if the new setup script bit-rots. The AI quality drops without guardrails. Standards are how engineering teams keep wins from leaking away. Today we draft the docs and ship one enforcement together, live, and record it all in your logbook as we go.
Slide 3: Agenda [dark blue, agenda layout]
Title: Agenda Bullets (5):
- 10 min: Technical debt, cognitive offloading, and the risk of unstructured AI adoption
- 10 min: Real-world governance docs and AI usage policies
- 15 min: Draft CI/CD governance, AI usage policy, and coding standards for OrbitTasks
- 15 min: Implement one enforcement mechanism (pre-commit, lint rule, or PR template)
- 10 min: Debate: developer freedom versus engineering standards
Slide 4: Section divider [dark blue]
Big text: The hidden / cost of speed.
Slide 5: Technical debt, revisited [white, headline + body]
Title: Technical debt: the version your team actually has Subtitle: Not the textbook definition Body: Technical debt is rarely the kind people talk about, the "we should have used X instead of Y." It's much more often the kind nobody can see: inconsistent patterns, decisions whose reasoning is forgotten, code that works but no one understands why. Every one of those costs decision-time on every PR. Standards are how you stop accumulating that quietly.
Slide 6: Cognitive offloading [white, 2-col]
Title: AI multiplies your output. / It can also multiply your debt. Left subhead: The benefit Left body: You can produce more code faster. Real, valuable code. The throughput is genuinely higher than it was two years ago, across every team using these tools. Right subhead: The risk Right body: When the AI writes the code, your team's understanding of the code drops. If everyone uses AI and nobody reads the output critically, the codebase grows by hands that don't fully comprehend it. That's not technical debt; that's comprehension debt, and it's worse.
Slide 7: Real-world examples [dark, headline + body]
Title: What happens at scale, without guardrails Subtitle: Patterns from real engineering orgs Body: Teams that adopt AI without standards report: a flood of nearly-identical PRs from different authors (everyone prompted the same way), regressions caused by AI ignoring a non-obvious convention, and security review fatigue because every PR has a few AI-generated lines that nobody fully validated. None of these are hypothetical. All of them are solved by policy.
Slide 8: Section divider [dark blue]
Big text: What good / governance looks like.
Slide 9: Anatomy of a governance doc [white, headline + body]
Title: What a governance doc actually contains Subtitle: The bones Body: A governance doc is short (usually two pages) and it answers four questions: what we require, what we recommend, what we forbid, and how each is enforced. The shorter the better. A 30-page policy is read once and ignored. A 2-page policy with a pre-commit hook is enforced every commit.
Slide 10: Three docs we draft today [white, title + body + bullets]
Title: Three docs / for OrbitTasks Body: Each is one page. By the end of the workshop you'll have all three. Bullets (3):
- CI/CD governance: required workflow file structure, mandatory caching, parallelization expectations.
- AI usage policy: when AI is allowed, when it requires review, what must never be AI-generated.
- Coding standards: formatting (auto-enforced), naming conventions, test coverage expectations.
Slide 11: Workshop: draft the three [white, headline + body]
Title: Workshop, 15 minutes, together Subtitle: We write the three policies live Body: We work through the templates in workshops/07-standards/starter/ together, filling in the bracketed sections for OrbitTasks specifically and recording each doc in your logbook as we go. Don't try to anticipate every case; just write the version that, applied today, would prevent the issues you saw in Sessions 5 and 6. Real policies grow over time.
Slide 12: Section divider [dark blue]
Big text: Policies / aren't enough.
Slide 13: Why enforcement matters [dark, headline + body]
Title: A policy nobody enforces is just opinion Subtitle: The hard truth Body: Every engineering org you'll join has at least one document that says "all PRs must include tests." Every engineering org you'll join has at least one PR shipped without tests. The gap is enforcement. The policies that survive are the ones a machine, not a human, enforces. Today you build one.
Slide 14: Pick your enforcement [white, title + body + bullets]
Title: Pick one. / We build it together, now. Body: Each option is in workshops/07-standards/starter/. We implement one live in this session, alongside the demo. They take roughly the same amount of time. Bullets (5):
- Husky pre-commit hook that runs
lint-stagedon staged files. - ESLint rule that fails the lint step on
// AI-generatedmarkers without an adjacent test. - GitHub Actions check that blocks PRs missing a coverage threshold.
- PR template with an "AI disclosure" checklist that must be filled in.
- Promote the deliberately-lax baseline rules to errors:
@typescript-eslint/no-unused-vars,react-hooks/rules-of-hooks, andreact-hooks/exhaustive-depsare all'warn'today (seeeslint.config.js/apps/web/eslint.config.js); flipping them to'error'is a one-line, testable enforcement.
Slide 15: Workshop: implement [white, headline + body]
Title: Workshop, 15 minutes, together Subtitle: We make the policy enforceable, live Body: Follow along as I demo: pick one mechanism and wire it up alongside me. Test it on a deliberately bad commit/PR; your enforcement should fail. Then test on a good one; it should pass. Commit it and record it in your logbook. Optional polish if you finish early: pair with a neighbor and add a second mechanism. Both of you will use these patterns in your next job.
Slide 16: Section divider [dark blue]
Big text: The debate.
Slide 17: The tension [white, 2-col]
Title: Developer freedom / vs engineering standards Left subhead: The freedom side Left body: Engineers do their best work when they're not fighting a process. Standards become rituals; rituals get blamed for slowness. The best engineers write the cleanest code without any rules at all, so why constrain them? Right subhead: The standards side Right body: Engineering teams are bigger than any one engineer. Consistency makes the code legible to new hires, predictable to maintainers, and reviewable in finite time. Without standards, the codebase becomes a personal museum.
Slide 18: Group debate [dark, headline + body]
Title: Workshop, 10 minutes Subtitle: Split the room Body: Two sides. Each side picks one of the four enforcement mechanisms and argues against having it: what does it cost the team? Then swap sides. The point isn't to win; it's to feel the trade-off. By the end you should have a more nuanced answer than "all rules are good" or "all rules are bad."
Slide 19: The role this maps to [dark, headline + body]
Title: Engineering Managers spend half their time on this Subtitle: The career angle Body: Engineering managers run this debate professionally. The job is reading the team: when to add a standard, when to remove one, when to enforce, when to look the other way. The Build Project gives you a small but real version of this work. Talking about it in an EM interview, with concrete examples from your own week, is high-signal.
Slide 20: Session 8 preview [white, title + body + bullets]
Title: Session 8: Final proposal / and stakeholder presentation. Body: Next session is the synthesis: we assemble your proposal together, live, straight from your logbook, which already holds everything you've built over 7 weeks, framed as a proposal you'd actually deliver to leadership. Bullets (3):
- Current-state analysis, bottleneck diagnosis, the redesigned pipeline.
- DevEx and AI improvements, with measured impact.
- The standards you put in place and the rollout plan.
Slide 21: What to prepare [white, headline + body]
Title: Keep your logbook Subtitle: Final-session continuity Body: Your logbook (/logbook) now holds your W1–W7 outputs: baselines, hypotheses, before/after numbers, rollout plan, and today's three governance docs and enforcement mechanism. Keep it; in Workshop 8 your proposal comes straight out of it, assembled live together. The presentation template is at workshops/08-presentation/starter/proposal-template.md. Optional: practice your ~8-minute story out loud once before the session.
Slide 22: Questions [dark blue, Big Stat layout]
Big text: Questions?