Speaking Script — "Working Effectively with AI"

Presenter: Phuong · Team: C Total runtime: ~14–16 min talk + Q&A Controls: ←/→ change slide · L switch language · N toggle notes · F fullscreen

Tip: rehearse once or twice for timing. Each slide has a suggested minute mark. Bold lines are the punchlines — slow down and land them.

Slide 1 — Title (0:00–0:40)

Hi everyone. Today I want to talk about something I'm pretty sure all of us already use every day: working with AI.

But not "what is AI" or "how to write clever prompts." I want to hit a more practical question: why does the same AI, on the same task, sometimes do great work and sometimes produce something you have to throw away?

The short answer is right on this slide. The model is already smart enough. What decides the outcome is the *context* you feed it — and, more importantly, whether feeding that context stays a manual chore forever or becomes automated.

I've split this into three parts: (1) the problems everyone hits with AI, (2) how we solve them by hand, and (3) how we automate it with a kit.

Slide 2 — The Core Idea (0:40–1:40)

First, the mental model, in one line: Output = f(Context). Output quality is a function of context — not a function of how smart the model is.

The easiest way to picture it: treat AI like a brilliant new developer who just joined. Raw ability, no question — senior level. But on day one, they know nothing about your project: not the codebase, not the conventions, not the domain.

Now if you hand that person a one-line ticket with no explanation — even though they're good, they'll build the wrong thing. Not because they're weak, but because they lack context.

AI is exactly the same. So the real question isn't "is the model good enough" — it's "how do we deliver context to it, reliably and repeatably." That's what the whole talk is about.

Slide 3 — The Problems, overview (1:40–3:00)

On to part one: the problems. I've grouped them into four pains that I believe everyone in this room has felt.

One — missing context: the AI never had your codebase, conventions, or domain, so it guesses.

Two — repetitive context: you re-paste the same files and rules into every new chat, every single day.

Three — the AI forgets: a slightly long chat overflows the context window, and a decision you made an hour ago just vanishes.

Four — prompt luck: everyone prompts differently, so the same task gives different results — you can't reproduce it.

*(Optional — ask the audience)* — Which of these do you hit? … Usually all four. Keep these four in mind, because the rest of the talk is about solving each one.

Slide 4 — Missing & repetitive (3:00–4:15)

Let's go deeper on the first two, because this is what eats your time every day.

A fresh chat always starts from zero. It doesn't know your folder structure, doesn't know "our team wraps every admin route in withAdmin," doesn't know "we archive data, we never hard-delete."

So what do we do? We paste files, explain conventions, restate the ticket. That's about 10 minutes *before* the real work even begins.

Then tomorrow, new chat, we do the exact same thing. Multiply that by every developer, every task, every day.

The root cause: our knowledge lives scattered across docs, tickets, Slack, and people's heads — never where the AI can actually reach it.

Slide 5 — Forgetting & inconsistency (4:15–5:30)

The other two pains are heavier, because they erode trust.

The context window is finite. In a long task, the early decisions get pushed out, and the AI starts contradicting itself.

Worse: close the chat and it's all gone. The next session repeats the exact mistake you already fixed.

And because there's no shared standard, my prompt and your prompt produce different code for the same ticket.

Add it all up, and using AI feels like gambling — sometimes brilliant, sometimes rework. And it's that gambling feeling that kills a team's willingness to adopt AI seriously. This is why we need a system, not just a personal trick.

Slide 6 — Solving it by hand (5:30–6:50)

Part two: solving it manually. And I want to say this plainly — the manual approach genuinely works. A disciplined developer who does these four things gets great results.

One, write a context file by hand: stack, structure, conventions — and paste it into each chat.

Two, keep a reusable prompt template, something like "here's the task, here are the rules," so prompts are less random.

Three, force the AI to research and plan *before* it codes, and review that plan yourself.

Four, log your decisions and gotchas — "we decided X because Y" — to paste back later.

If you're already doing these, congratulations, you're using AI the right way. But… *(advance to next slide)*

Slide 7 — The catch (6:50–8:00)

…but manual discipline doesn't scale. This is the crux.

First, it relies on willpower. And under deadline pressure, everyone skips the context step — right when it matters most, that's when we drop it.

Second, hand-written docs go stale. And a wrong fact is more dangerous than no fact, because it leads the AI astray with confidence.

Third, it's personal. Your discipline lives in your head — you take a day off and the team loses it.

Fourth, it's still copy-paste labor — the very repetition we were trying to eliminate in the first place.

So the fix isn't "try to be more disciplined." The fix is to make that discipline automatic and team-wide — turn it into a system, not a habit. And that's part three.

Slide 8 — Automation intro (8:00–9:00)

This is an open-source kit called *vibecode-pro-max-kit*. It packages up exactly the discipline we just described.

The key point: it's not a prompt file. It installs a whole system — 15 specialized agents, 33 skills, 10 safety hooks, 36 validators, and a knowledge tree called process/.

Its tagline sums up my whole talk: *"Your AI forgets. This remembers."*

How it works: plan first, enforce the process, and keep knowledge on disk so it survives even when you close the chat or reset the session. It installs with one command, and it works across multiple tools — Claude Code, Codex, Cursor, Windsurf — on any tech stack.

The next four slides walk through each mechanism, and each one maps straight back to a pain from part one.

Slide 9 — RIPER-5 harness (9:00–10:00)

First, the workflow harness, called RIPER-5. It breaks work into ordered phases: Research → Spec → Innovate → Plan → Execute → Update.

The beauty is that the phases are *locked* — you can see the padlocks on the diagram. The RESEARCH phase isn't allowed to write code, it can only gather facts. The PLAN phase can't touch source, it can only write to the process/ folder.

That means the AI can't "jump to code" before it understands the requirement — which is the number-one AI failure mode. And it blocks that automatically, not by relying on you to remember. This is the "force a plan first" step from the manual part — now automated.

Slide 10 — Context routing (10:00–11:00)

Next, context routing — this directly solves the "missing" and "repetitive" pains.

Instead of you pasting files, the kit uses router files. For example, all-context.md points to the architecture, tests/all-tests.md points to how you run tests, container/all-container.md points to Docker and deployment.

The AI reads only the router relevant to the work at hand — it doesn't load the entire knowledge base every session, so it doesn't waste the context window.

The result: you stop pasting files. Context is written on disk once, and the AI routes to it every time. When a topic grows large, it auto-splits into its own group; renaming it only touches the router, not your code.

Slide 11 — Persistent memory (11:00–12:00)

The third mechanism, persistent memory — this solves the "AI forgets" pain.

All plans, specs, and reports don't sit in the context window — they sit on disk, in the process/ tree, split into active, completed, backlog.

On top of that, each phase writes a "Context Envelope" — a 10-field snapshot: which feature, which phase, which branch, where the plan file is, how to run tests, and so on. That lets a completely fresh agent read it in and resume exactly where it stopped.

In other words: close the chat, come back tomorrow, and the AI reads the files and picks up mid-task. It stops repeating the mistake you already fixed. That's the direct answer to "the AI forgets."

Slide 12 — Guardrails & consistency (12:00–13:00)

The last mechanism, the guardrails that make results repeatable — that is, they kill the "luck."

Skills and agents auto-discover by keyword. Mention "webhook" and the security skill and scenario skill attach themselves. Everyone runs the exact same routine.

There are two independent quality loops: PVL validates the plan before any code is written; and EVL has a *separate* tester re-run the tests — meaning the coder's "everything's green" is never trusted; there's always a second party to confirm.

Autopilot has three lanes that match ceremony to risk: Quick for a one-line fix, Fast, and Full RIPER-5 — so nobody's forced to run the whole process for a typo. And MCP connects Jira, Drive, and the browser directly as first-class context — no more copy-pasting from other tools.

Slide 13 — Manual vs automated (13:00–14:00)

This is the payoff slide of the whole talk. I put them side by side: each pain, the manual way, and the kit's way.

Missing context — by hand you paste files each time; the kit's routers fetch it automatically. Repetition — by hand you re-type the rules every chat; the kit writes it once on disk. Forgetting — by hand it's lost when the chat closes; the kit resumes via the Envelope and process/. Prompt luck — by hand every dev differs; the kit gives everyone RIPER-5 plus validators. And discipline — by hand it's skipped under pressure; the kit enforces it with phase-locks.

The message in one sentence: it's the exact same discipline — but now it needs no willpower, and it's a shared asset for the whole team.

Slide 14 — Live demo (14:00–14:45)

To make it concrete, here's the same ticket, run two ways.

On the left, the raw prompt: "add an admin API to delete a product." The AI produces: no auth guard, wrong folder, hard-deletes the data, forgets i18n — in other words, rework.

On the right, through the kit: same ticket, but it routes context, plans, validates, and only then executes. The result: it wraps withAdmin, archives instead of hard-deleting, uses the correct convention, and includes i18n and tests.

*(If you have a real recording, open it here)* — This is the most convincing slide, because it shows the difference on the exact same input.

Slide 15 — Getting started (14:45–15:30)

So how does our team get started? Very lightly.

Install once per repo with a single command. A fresh repo runs vc-setup, which auto-detects the stack and scaffolds process/; an existing repo runs vc-update. It never overwrites anything — it backs up first.

Seed the context from what you already have: point the routers at your existing docs, tickets, and conventions.

Then pilot it on just one feature this sprint, and measure the rework against the raw-prompt baseline.

And because the UPDATE phase refreshes context after every feature, you don't pile up stale-doc debt — which is the biggest weakness of the manual approach.

Slide 16 — Takeaways (15:30–16:15)

To wrap up, four points.

One, the AI's output is only as good as the context it has — treat it like onboarding a new developer.

Two, all the pains — missing, repetitive, forgotten, inconsistent — are really one problem: delivering context.

Three, you can solve it by hand, but discipline doesn't scale. Automate it so it becomes a team asset.

Four, the kit turns "prompt luck" into a repeatable system — and humans still decide, and stay accountable for the final call.

My concrete proposal: pilot the kit on one feature this very sprint, measure rework, and report back to the team.

Thank you all. I'm happy to take questions.

Appendix — Likely Q&A & suggested answers

• "What about maintenance cost? Docs still go stale, right?" True, but the difference is the UPDATE phase forces a context refresh after every feature *mechanically* — validators check it, rather than relying on someone remembering. Doc debt doesn't silently accumulate.

• "Isn't this over-engineering? Does a small task also run the whole process?" No. There's a Quick lane for a one-line fix — scout, edit, scoped check, skipping plan and EVL. Ceremony matches risk.

• "Security? Does it leak secrets into context or memory?" Principle: no secret *values* in context — values live in .env, docs only record the variable names. Memory is versioned in git, so every change is reviewable in a PR. And the AI's output still goes through review and CI as usual.

• "Does the AI merge code on its own?" No. The AI drafts; engineers decide and are accountable. Everything still passes review + CI before merge.

• "Do we have real numbers yet?" Honestly: this is an expectation that needs to be measured via the pilot. That's exactly why I'm proposing we try one feature and measure rework before rolling it out.