Thank you to this week's presenters for two excellent demos. These sessions are a key part of our AI transformation — each week, two teams showcase ideas that move us from basic AI usage into the AI fluency zone. Here are the highlights.

The Claude Kitchen — "Here's How We Cook"

Presented by: Valentin-Cristian Mosor

A portable tooling repo that gives any project opinionated Claude workflows, a visual MCP installer, and two powerful multi-agent capabilities: Socratic Symposium (specialist agents debating architectural decisions with cross-examination) and RQR / Evolve (adversarial agents stress-testing solutions for outages and performance failures, then proposing concrete improvements). In a live demo, RQR caught a shared-error-boundary flaw in their MFE architecture and proposed per-MFE isolation — AI driving architectural resilience, not just code generation.

Demo: TGIF-20260227_110521-Meeting Recording.mp4

Q: Where is the human in the loop?
A: In Symposium, only at the start when framing the problem. In Evolve/RQR, the director agent pauses after each cycle for human review, allowing weight adjustments and direction changes.
Q: How many iterations did it take to build, and how does the team handle failures?
A: Continuously refined with near-daily commits driven by friction points. Example: parallel agents collided on shared file names — resolved by prefixing with timestamps and summary slugs.
Q: What is the token cost, and is the number of agents optimal?
A: Symposium runs 300K–600K+ tokens with 3–8 agents auto-selected based on complexity. Evolve uses a fixed 5 adversarial agents, deemed sufficient for meaningful coverage.
Q: How are permissions handled — do you skip them or whitelist commands?
A: A broad whitelist allows read operations; all write/update/delete operations require manual approval as a quality gate.
Q: How do you mitigate LLM sycophancy?
A: A curated CLAUDE.md file with explicit anti-sycophancy instructions is auto-installed via make install, adapted from an internally shared template.

Claude Bedrock PR Reviewer

Presented by: Florian-Luis Micu

A custom AI PR reviewer running Claude on AWS Bedrock as a GitHub Action — reviews full diffs in under 60 seconds, proposes actual code changes with five severity levels, and auto-trains on the repo's docs and config files. Built because third-party bots aren't available on Adobe R&D personal accounts, it outperformed GitHub Copilot head-to-head: on a 20K-change PR, Copilot returned zero suggestions while this bot surfaced critical bugs and actionable feedback. Already in production across two Elmo DRS repositories and a strong candidate for broader Adobe R&D adoption.

Demo: TGIF-20260227_110521-Meeting Recording.mp4

Q: How do you prevent overly eager or noisy reviews?
A: A two-stage prompt: the first pass is intentionally aggressive to avoid lazy skipping on large diffs; the second pass filters out irrelevant findings before posting.
Q: Does it use external scripts or overlap with tools like SonarQube?
A: No external libraries. Standalone Python script with a structured pre-prompt, relying on Claude's native language understanding. Future plans include pluggable "skills" for language-specific review logic.
Q: Where is it available — GitHub Corp or GitHub.com?
A: Currently Adobe R&D on github.com only. Extending to git.corp.adobe.com would require hosting the bot as a service with webhooks.
Q: How does it handle multiple repositories?
A: Each repo runs its own GitHub Action instance with isolated context. Currently used across 2 repos (~4–5 PRs/day each) with no performance issues.
Q: Can the bot also generate tests for its suggested code changes?
A: Not yet in a single pass. The pre-prompt checks test coverage, and since the bot blocks merging until a fresh review passes, a follow-up cycle can flag missing tests.
Q: Which Claude model/context window is being used?
A: Currently using the team's AWS Bedrock instance — the exact config (256K vs. 1M context) is managed by the team lead. The larger context window would benefit very large diffs.
Q: Can it target specific folders in a monorepo?
A: Not as a built-in feature yet. A workaround exists via a skill file in .github that instructs the bot to focus on specific paths. Deterministic folder-scoping is on the roadmap.

Have feedback, a demo proposal, or a topic you'd like to see covered? Submit it here.