How Vikram, The Pragmatic Senior Staff Engineer, Uses WayOfTeams

A step-by-step walkthrough of how a veteran software architect treats AI as a strictly bounded accelerator and uses WayOfTeams to enforce quality, traceability, and architectural control across his team.

Who Vikram Is

Vikram has 15 years of production experience across distributed systems, backend infrastructure, and API design. He does not care about AI hype. He cares about execution speed, type safety, and whether the generated code will hold up at 3 AM under production load. His core rule: "The LLM is an accelerator, not a decision-maker."

He feeds models exact repository subtrees, not vague prompts. He inspects every git diff. He writes integration tests before accepting generated code. He establishes repo guidelines to ensure junior developers using AI tools conform to company architecture standards.

He has watched two AI incidents in his career. One introduced a subtle race condition that took three weeks to find. Another rewrote a file to fix a typo and broke the entire module's supervision tree. He learned from both. AI is powerful. AI is also careless if you let it be.

Phase 1: The Architecture Review (Before He Signs Up)

What Vikram Does

Vikram does not sign up for tools. He evaluates them. He reads the architecture page and checks:

Stack: Elixir/Phoenix on Ash Framework. BEAM VM for concurrency. PostgreSQL 16. Oban for background jobs. OpenTelemetry built in. He knows BEAM handles massive concurrency well. This is a good sign.

Data model: Company -> Organization -> Department -> Team -> Developer hierarchy with JWT-derived tenant isolation. He verifies: can Agent A from Company X write to Company Y's f-rr-d repo? No. Tenant isolation holds.

Code safety: The coordinator role (WOTEAMS-404) cannot write code. It is a track/verify/deploy role only. This is the kind of hard boundary he respects.

Audit: mcp_audit provides per-tool token metrics and write outcome counts. He can trace every action back to its origin.

He signs up.

What He Checks

Does the system enforce architectural constraints?
Can he trace every change from requirement to production?
Does the AI respect module boundaries?
Is there an audit trail for every action?

Why This Works for Vikram

He has been burned by tools that look great in a demo but cannot survive production scrutiny. WayOfTeams passes the architecture check: BEAM for concurrency, Postgres for isolation, Oban for reliability, OTel for observability. The foundation is solid.

Phase 2: Setting Up His Environment (Day 1)

What Vikram Does

Vikram connects Claude Code to the WayOfTeams MCP. He configures his editor with the project's rules. He checks the knowledge base for existing architectural decisions. He does this before writing or reviewing any code.

He reads the project rules through the MCP:

"List all project rules for wayofteams"

He sees coding conventions, naming patterns, and architectural constraints already codified. Some of them match his own standards. Some he disagrees with. He adds his own:

"Create a project rule: 'All GenServer state must be a struct, never a raw map. State structs must be defined in a dedicated lib/wayofteams//state.ex file. This enforces compile-time field validation.'"

"Create a project rule: 'Never use Application.compile_env in lib/. All environment variables must flow through config/runtime.exs. Compile-time attrs bake host values into the BEAM image.'"

"Create a project rule: 'Every public function must have a @spec. Every module must have a @moduledoc. Every public function must have a @doc. This is not optional.'"

The rules are stored in the f-rr-d repo and enforced by agents during implementation. When a junior developer asks the AI to create a new GenServer, the AI follows the rule: struct-based state, dedicated state file, @spec on every function.

He also checks the knowledge base:

"Add project knowledge: 'The MCP server (lib/wayofteams/mcp/) is the only external interface. All business logic must go through Ash actions. Never call domain functions directly from controllers or LiveViews.'"

What He Sees

Rules already codified by the team
Knowledge base with architectural decisions
Ability to add his own rules and knowledge
Rules enforced automatically by AI during implementation

Why This Works for Vikram

He has used .cursorrules and custom system prompts before. WayOfTeams rules are project-scoped, version-controlled, and enforced by the AI during implementation. Not just a suggestion in a config file. A constraint the system respects. The knowledge base gives the AI the context it needs to make good decisions.

Phase 3: Context Window Management (Day 1–2)

What Vikram Does

Vikram's biggest frustration with AI tools is context pollution. The AI pulls in unrelated code and breaks cleanly isolated modules. He does not let this happen.

He uses the knowledge base to define module boundaries:

"Add project knowledge: 'The kanban domain (lib/wayofteams/kanban/) is fully self-contained. It never imports from lib/wayofteams/tickets/. Cross-domain communication happens only through Ash actions and PubSub events. Do not add direct function calls between domains.'"

When the AI plans a change, it reads this knowledge first. It knows the boundaries before it touches any file.

He also uses the thoughts/ directory to store architectural context:

"Read thoughts/wayofteams/docs/architecture/domain-relationships.md"

The AI gets the exact subtree of information it needs. Not the entire codebase. Not a vague summary. The specific architectural document that defines how domains interact.

What He Sees

Module boundaries codified in the knowledge base
AI reads boundaries before planning changes
Architectural context stored in f-rr-d, accessible via MCP
No context pollution from unrelated code

Why This Works for Vikram

He feeds models exact repository subtrees and architectural constraints. WayOfTeams gives him the tools to codify these constraints in the knowledge base and rules, so every AI session starts with the right context window.

Phase 4: The Plan-Validate-Implement Loop (Day 2–3)

What Vikram Does

Vikram does not let AI implement anything without a validated plan. Every change goes through three control points.

Step 1: Create plan

"Create a plan for WOTEAMS-XXX. The change adds rate limiting to the MCP server. Constraints: must use ETS for the rate limit store, must not block the supervision tree, must degrade gracefully if ETS is full. Must not change the MCP protocol handler."

The AI generates a phased plan:

Add rate limiter module with ETS backing store
Add config option to config/runtime.exs
Integrate rate check into HTTP transport
Add tests for rate limiting, ETS full degradation, and config
Update documentation

Each phase has file changes, success criteria, and a commit point.

Step 2: Validate plan

"Validate this plan"

The AI checks feasibility, dependencies, and risks. It flags: "The proposed ETS table has no max size limit. Under memory pressure, this could crash the node. Add :setopts with {:heir, ...} configuration. Also, the plan does not address what happens when the rate limiter crashes. Add a supervisor strategy."

Vikram agrees. He tells the AI to add both constraints.

Step 3: Implement

"Implement this plan"

The AI executes phase by phase. After each phase, Vikram inspects the git diff:

git diff HEAD~1

He checks five things:

Surgical edits: Did the AI rewrite entire files? If it changed 3 lines in a 200-line file, the diff should show 3 lines, not 200.
Type safety: Are types preserved? No any() creeping in?
Abstractions: Are there unnecessary abstractions? Did the AI add a behaviour where a simple function would do?
Test coverage: Does the test scope match the change scope?
Module boundaries: Did the change respect the domain boundaries defined in the knowledge base?

If the AI rewrote a 200-line file to change 3 lines, he reverts and tells it: "Make surgical edits only. Do not rewrite files."

What He Sees

Plan with phases, file changes, and success criteria
Validation catching issues before code is written
Diff inspection after each phase
Control at every step

Why This Works for Vikram

The plan-validate-implement loop gives him three control points. He validates the plan before any code is written. He inspects the diff after each phase. He reviews the tests before merge. The AI is an accelerator, not a decision-maker. Vikram decides what gets built and how. The AI does the typing.

Phase 5: High-Throughput Refactoring (Week 1–2)

What Vikram Does

Vikram uses AI for the tedious work that would take him days:

Legacy migration: He feeds the AI a deprecated API endpoint, the new endpoint signature, and a list of all call sites. The AI migrates every call site in minutes. Vikram reviews each diff. He finds that the AI handled 47 out of 52 call sites correctly. The other 5 had edge cases the AI missed: dynamic dispatch, pattern matching on the old return type, and a recursive call that needed manual adjustment. He fixes the 5 by hand. Total time: 20 minutes instead of 2 days.

Test suite generation: He gives the AI a module and says "write integration tests for every public function. Use ExUnit. Cover edge cases: nil input, empty lists, malformed data, concurrent access." The AI generates 40 tests. Vikram runs them. 38 pass. The other 2 fail because the AI assumed a function returned {:ok, result} when it actually returns {:ok, result, metadata}. He fixes the 2 tests. Total time: 15 minutes instead of 4 hours.

Regex and parsing: He describes a log format, gives 10 examples, and asks for a parser. The AI generates the regex and the parsing logic. Vikram feeds it 100 real log lines. 97 parse correctly. The 3 failures are log lines with malformed timestamps. He tells the AI to handle those as unparsable and flag them. Total time: 10 minutes instead of an afternoon.

Deprecation updates: "Find all uses of deprecated function X across the codebase and replace with the new function Y. Preserve type safety. Do not change any function signatures." The AI finds and replaces 23 call sites. Vikram runs the type checker. All pass. Total time: 5 minutes instead of a morning.

In each case, the AI does the volume work. Vikram does the quality work. The ratio is consistent: AI does 90% of the typing, Vikram does 100% of the thinking.

What He Sees

AI handles volume work in minutes instead of days
He catches edge cases the AI misses
Type safety verified after every change
Time savings quantified for each task type

Why This Works for Vikram

He does not let AI replace his judgment. He lets it replace his tedium. The AI does the 90% that is mechanical. He does the 10% that requires engineering judgment. This is exactly how he wants it.

Phase 6: Enforcing Standards Across the Team (Week 2–3)

What Vikram Does

Vikram establishes guidelines so junior and mid-level developers using AI tools produce code that conforms to company standards.

Project rules via the MCP:

"Add a project rule: 'Every public function must have a @doc string. Every module must have a @moduledoc. This is not optional.'"

"Add a project rule: 'Never use IO.inspect in production code. Use Logger.debug instead. IO.inspect is for development only.'"

"Add a project rule: 'All external API calls must go through Wayofteams.Http.fetch_url/1. Never use :httpc directly. TLS cert chains fail in production.'"

Knowledge base entries:

"Add project knowledge: 'When adding a new Ash resource, always define the domain module first, then the resource. Ash resolves domains at compile time. The domain must exist before the resource can reference it.'"

TDD enforcement:

He tells his team to use the tdd skill for every change. The red-green- refactor loop ensures tests exist before implementation. He reviews the test coverage, not just the code.

What He Sees

Rules enforced automatically by AI during implementation
Knowledge base prevents repeated architectural mistakes
TDD ensures test coverage before code ships
Junior developers produce better code without constant supervision

Why This Works for Vikram

He has used .cursorrules and custom prompts before. WayOfTeams rules are project-scoped, enforced by agents during implementation, and stored in the f-rr-d repo with version history. They are not suggestions. They are constraints.

Phase 7: Code Traceability (Ongoing)

What Vikram Does

Vikram enforces ticket reference comments in every change:

# [WOTEAMS-001] Add rate limiting to MCP server
defmodule Wayofteams.MCP.RateLimiter do

Every modified file must have at least one reference. He verifies:

grep -rn "WOTEAMS-001" --include="*.ex"

The ticket contains the problem statement, acceptance criteria, and technical notes. The plan contains the implementation phases. The git commit references the ticket. The f-rr-d change log tracks the file modification.

If something breaks in production six months from now, he can trace it from the error back to the ticket, the plan, the commit, and the original requirement.

What He Sees

Ticket references in every modified file
Full traceability from requirement to production code
Git history linked to tickets and plans
f-rr-d change log for every decision

Why This Works for Vikram

He has worked on codebases where nobody knew why a function existed. WayOfTickets + f-rr-d gives him full traceability from requirement to production code.

Phase 8: Review Queue and Quality Gates (Ongoing)

What Vikram Does

Vikram does not merge his own PRs. He does not let anyone else merge theirs without review.

The review queue shows:

PR status and ticket linkage
Test coverage for the change
Whether the plan was followed
Whether project rules were violated

He reviews with a checklist:

Did the AI make surgical edits or rewrite entire files?
Are types preserved?
Are edge cases covered?
Does the change respect module boundaries?
Are there unnecessary abstractions?

If the AI introduced an unneeded abstraction, he requests changes with a specific instruction: "Remove the abstraction layer. Call the function directly. YAGNI."

What He Sees

Review queue with structured approval flow
Checklist for every review
Rule violations flagged automatically
Test coverage linked to each change

Why This Works for Vikram

He has seen AI-generated code that looks clean but introduces subtle bugs. The review queue gives him a structured place to catch these before they reach production.

Feature Adoption Order

Based on Vikram's profile, here is what he uses and when:

Priority	Feature	Why Vikram Cares
1	Project rules	Enforce architectural constraints across all AI tools
2	Knowledge base	Codify module boundaries and design decisions
3	Plan-validate-implement	Control points before and after code generation
4	Git diff inspection	Verify surgical edits, not full file rewrites
5	TDD workflow	Tests before implementation, always
6	Code traceability	Ticket references in every change, full audit trail
7	Review queue	Structured quality gate before merge
8	f-rr-d change tracking	Version history for every decision and modification
9	MCP audit	Per-tool token metrics and write outcome counts
10	Coordinator role	FREEZE/GO protocol for merges and deploys

What Makes WayOfTeams Different for Vikram

Problem Vikram Has	WayOfTeams Solution
"AI rewrites entire files instead of surgical edits"	Plan-validate-implement loop with diff inspection at each phase
"Context pollution breaks isolated modules"	Knowledge base codifies module boundaries, AI reads them first
"Junior devs use AI without following standards"	Project rules enforced by agents during implementation
"I cannot trace why a function exists"	Ticket references, f-rr-d change tracking, full audit trail
"Model hallucinations introduce subtle bugs"	TDD workflow, review queue, verification at every step
"AI tools ignore architectural constraints"	Rules and knowledge base are part of the project context
"I need to prove generated code is correct"	mcp_audit, test coverage, diff inspection, review queue
"Over-eager agents try to rewrite everything"	Coordinator role cannot write code, work visibility prevents conflicts

The Core Loop

For Vikram, WayOfTeams enforces one engineering discipline:

Constrain -> Plan -> Validate -> Implement -> Inspect -> Test -> Merge
     ^                                                            |
     +------------------------------------------------------------+

Every iteration strengthens quality:

Constrain defines the rules, boundaries, and architectural context
Plan produces a phased approach with file changes and criteria
Validate checks feasibility, dependencies, and risks before coding
Implement executes the plan phase by phase with commits
Inspect verifies the diff is surgical and types are preserved
Test ensures coverage through TDD and integration tests
Merge requires review queue approval and quality gate pass

The loop runs through a system that respects his constraints, tracks every change, and keeps the AI in its lane as an accelerator.

That is the system Vikram would trust with production code.

← Back to all personas