How I AISuccessfully coding with AI in large enterprises: Centralized rules, workflows for tech debt, & more
CHAPTERS
- 0:00 – 2:49
Why “vibe coding” breaks in enterprise-scale codebases
Claire and Zach set the tone: tactics that work for a solo dev moving fast don’t translate to a platform powering massive production traffic. They frame the core enterprise challenge as quality, maintainability, and team-scalable workflows—not raw commit velocity.
- •Vibe coding can be fine for side projects but is risky for critical systems
- •Large, long-lived codebases require consistent conventions and guardrails
- •AI adoption must prioritize reliability and maintainability
- •The episode will focus on team workflows, not just individual productivity
- 2:49 – 4:00
LaunchDarkly’s current AI tool stack across design, product, and engineering
Zach shares the breadth of tools the org is actively using or evaluating, showing a pragmatic “try many things” posture. The list spans design prototyping tools, product PRDs, coding IDEs/agents, and AI-assisted code review.
- •Design: Lovable, v0, Figma Make
- •Product: ChatPRD
- •Engineering: Cursor (heavy), Devin (heavy), Windsurf (personal preference), Cursor background agent
- •Evaluations: Augment, Claude Code
- •Review workflows: Copilot for review + Cursor review
- 4:00 – 6:42
AI adoption needs an owner: driving organizational change from close to the code
They discuss why enterprise AI adoption doesn’t happen organically: people have uneven experiences and skepticism builds fast. Zach argues for a dedicated “driver” who actively uses the tools and can diagnose what works in the real codebase.
- •A named owner/responsible person accelerates consistent adoption
- •The driver must be close enough to the code to see failures and friction
- •Early skepticism came from tools working in small projects but not in a monorepo
- •Goal: move from experimentation to operationalized, repeatable success
- 6:42 – 8:07
Making first-time AI experiences successful for skeptical engineers
Zach explains the scaling problem: if every engineer must independently discover prompts, patterns, and constraints, adoption won’t scale. The key is engineering enablement so first attempts produce a real “aha moment,” not a failure that entrenches doubt.
- •Self-directed AI journeys don’t scale in 100+ engineer orgs
- •First impressions matter—early failures create long-lived skepticism
- •Enablement should standardize context, workflows, and defaults
- •Success criteria: predictable usefulness, not occasional hero runs
- 8:07 – 8:37
Centralizing repo documentation so both humans and LLMs can work effectively
Zach walks through repo changes: pulling scattered institutional knowledge (Confluence/Docs) into a structured docs directory inside the codebase. This improves onboarding and makes it easier for LLM tools to retrieve accurate, authoritative guidance.
- •“What’s good for humans is also good for LLMs”
- •Move critical docs into the repo so tools can access them
- •Examples: frontend organization, accessibility guidelines, JS style guide
- •Reducing fragmentation improves default AI output quality
- 8:37 – 11:40
One source of truth for rules: consolidating tool-specific configs into .agentsrules
They address the pain of tool-specific rule files (Claude.md, Cursor rules, etc.). Zach’s approach: create a centralized rules directory and have each tool’s configuration point to it, avoiding duplication and making multi-tool experimentation scalable.
- •Problem: every tool demands its own rules file and format
- •Solution: create a centralized “agents” rules system and reference it from tools
- •Use concise “essentials” plus links to deeper docs
- •Easier to keep guidance consistent across Cursor, Devin, Augment, etc.
- 11:40 – 12:33
Using domain-specific rules (feature flagging) to prevent model confusion and boost accuracy
Zach shows how rules tailored to LaunchDarkly’s domain remove ambiguity—especially around “feature flags,” which LLMs may interpret as product usage instead of code changes. With more precise instructions, agents can reliably implement flagging workflows (even via MCP).
- •LLMs can confuse product feature flags vs code-level feature flag implementations
- •Rules clarify expected behavior, outputs (e.g., returning links), and workflow steps
- •Domain rules significantly improve agent success rates
- •Example: PM successfully used Devin to put a feature behind a flag via MCP
- 12:33 – 14:42
How to decide what rules to write first (and how to generate them with agents)
Zach’s advice: bootstrap your rule set by asking agents to draft docs and structure, then refine carefully. Prioritize rules based on real failure modes—where engineers and agents repeatedly get stuck (e.g., test frameworks mismatches).
- •Ask agents to generate initial docs/rules, then review with a fine-tooth comb
- •Leverage Devin Wiki to understand repo structure and practices
- •Focus rules on common friction points (e.g., Jest vs Vitest)
- •Iterate rules based on observed failures and developer pain
- 14:42 – 16:33
Demo: bringing Devin up in a large monorepo via incremental environment setup
They discuss the practical reality of Devin: it boots its own VM and environment, which can be harder than local IDE tools. Zach recommends starting with a partial setup (frontend-only mode) to get value early, then expanding to full end-to-end as needed.
- •Devin environment setup can be incremental (frontend-only first)
- •Full-stack local parity may take longer and require additional help
- •You can get value without running the full app locally in Devin
- •If setup is hard for Devin, it’s likely hard for humans too—use it to justify improvements
- 16:33 – 21:59
Devin Wiki + doc generation workflow: turning repo knowledge into human docs and agent rules
Zach demonstrates using Devin Wiki to answer specific repo questions (charting libraries) and then spinning up a Devin session to generate both human-readable markdown docs and concise agent rules. They emphasize keeping rules short, link out to detailed docs, and consider tool chunking behavior.
- •Use Devin Wiki to quickly confirm libraries and patterns (e.g., Recharts, VizX)
- •Generate two artifacts: human docs (docs/) and agent rules (.agent/rules/)
- •Review and tighten agent rules; keep them concise and link to full docs
- •Operational considerations: VM boot time, confidence scoring, and file-length chunking (e.g., ~200 lines)
- 21:59 – 28:51
Centralized “knowledge” strategy across tools: avoiding duplication between Devin knowledge and repo rules
They explore Devin’s centralized knowledge feature and how it evolves through team usage. Zach’s strategy is to point Devin knowledge back to the same repo-based .agents directory so all tools benefit from the same source of truth.
- •Devin accumulates shared knowledge across sessions and users
- •Team can accept suggested knowledge or add targeted entries when problems arise
- •Avoid duplicating guidance across Devin and local tooling
- •Repo-based .agents directory becomes the canonical reference for everything
- 28:51 – 30:46
Tech debt as the killer enterprise AI use case: creating a prioritized cleanup plan from noisy test output
Zach shows a repeatable pattern: capture noisy output (e.g., `yarn test` logs), use an LLM to analyze and classify it, then generate a prioritized task checklist. This makes “unowned but painful” debt tractable and easy to chip away at incrementally.
- •Problem: excessive test log noise hides real issues and is hard to justify as a project
- •Workflow: pipe test output to a file, ask Claude/agents to summarize and categorize
- •Produce a prioritized plan (tiers, worst offenders, file targets)
- •Turns a huge cleanup into bite-sized, reviewable tasks
- 30:46 – 37:12
Executing tech debt reduction with agents: task pick-up, PR review, and multiplayer collaboration
They demonstrate assigning the next tier of tasks to Cursor (or Devin via Slack) using the checklist as a lightweight project system. The approach mirrors human teamwork: prioritized tasks, small PRs, reviews, and shared ownership across the team.
- •A markdown checklist becomes a practical task-tracking system inside the repo
- •Any agent can pick up the next item; humans can also contribute similarly
- •Review/merge loop keeps quality high while speeding up cleanup
- •End payoff: clearer test signal, fewer accessibility warnings buried in noise
- 37:12 – 40:35
AI for hiring consistency: using a custom GPT to grade interview scorecards and draft Slack feedback
Zach applies AI outside coding: improving interviewer scorecard quality and consistency. A custom GPT uses the rubric plus good/bad examples to rate scorecards, suggest improvements, and generate a ready-to-send Slack coaching message.
- •Challenge: inconsistent interviewer notes and rubric adherence
- •Solution: custom GPT seeded with rubrics and examples
- •Outputs: scorecard quality rating, strengths, improvement suggestions
- •Practical delivery: drafts a concise Slack message for coaching
- 40:35 – 44:56
Wrap-up principles + lightning round: favorite tool and handling AI failure modes
Claire summarizes the playbook: experiment broadly, centralize context, generate rules/docs with AI, and operationalize tech debt workflows—then apply AI to adjacent processes like hiring. Zach closes with his favorite tool (Windsurf) and a pragmatic approach to knowing when to push harder vs stop and do it yourself.
- •Key approaches recap: experimentation, context, centralized rules, AI-generated plans
- •Most transformational tool for Zach: Windsurf (agent workflow + UX fit)
- •When AI doesn’t listen: add context, adjust approach, or stop and do it manually
- •Find Zach on LinkedIn; LaunchDarkly is hiring and welcomes user feedback
