Week 2 is where experimentation becomes a delivery system
Week 1 of most AI enablement programs looks the same: people try tools, share prompts, and ship a few quick wins. That phase has value. It surfaces who is curious, which workflows are slow, and where the codebase fights back. But it also creates a pattern we see in delivery teams: a few people get fast, others get stuck, and the output becomes hard to review.
Week 2 is different because it introduces constraints on purpose. Not “process for process,” but the minimum structure needed to make AI assisted work predictable. The goal is simple: the team should be able to repeat the good outcomes from week 1 without repeating the mess. That means shared artifacts, role track workshops, and rules that make review and risk visible.
At Apptension, we run enablement in a way that matches how we deliver software: small batches, explicit standards, and feedback loops you can measure. Week 2 is the first time we can measure whether AI is improving flow metrics like Cycle Time (median time from “in progress” to “deployed”) and Change Failure Rate (percentage of deploys that cause rollback or urgent hotfix). It is also where we see whether support load rises, which is often the hidden cost of “fast” work.
What we mean by “vibe coding” vs “agentic engineering”
“Vibe coding” is not an insult. It describes a real behavior: you ask an assistant for code, paste it in, tweak until tests pass (or until the UI looks right), and move on. It works best in low risk areas like prototypes, internal tools, or greenfield features with little integration. It fails when the work touches security, payments, permissions, or anything with long lived maintenance.
In vibe coding, the main control is the developer’s intuition. The assistant is treated like a fast pair who does not know your system. Review becomes subjective (“looks fine”) because the reasoning and constraints are not captured. When the original author is away, the team has to reverse engineer intent from code.
“Agentic engineering” is the opposite posture. You still move fast, but you treat AI as a worker inside a system with guardrails. You define inputs, expected outputs, and stop conditions. You capture decisions in artifacts so others can inspect them. The key change is that the team stops relying on personal prompt styles and starts relying on shared standards.
How to tell which mode your team is in
You can usually spot vibe coding by looking at pull requests. If PRs have large diffs, thin descriptions, and reviewers asking “why are we doing this?” you are in vibe mode. Another signal is test behavior: either tests are missing, or they are shallow snapshot tests that do not catch regressions in business logic.
Agentic engineering shows up as smaller PRs with explicit intent. You see checklists, links to acceptance criteria, and clear boundaries like “this PR only changes the pricing calculation, no UI refactor.” You also see measurable outcomes: fewer review cycles, fewer “fix forward” patches after release, and a stable MTTR (mean time to recover) when something breaks.
The harness artifacts: the boring documents that stop chaos
Week 2 starts with a harness. A harness is a small set of artifacts that define how the team uses AI in daily work. It is not a wiki dump. It is a working kit that is referenced in PR templates, used in workshops, and enforced in review.
The harness exists because licences do not create alignment. If ten people have access to the same model, you still get ten different outputs, ten different risk tolerances, and ten different definitions of “done.” The harness is the shared contract that makes outputs comparable.
In practice, we keep the harness short and operational. If it cannot be applied in under five minutes during a PR, it will be ignored. The best harness artifacts are the ones that remove decisions from the critical path, like “which files should the assistant read” or “what tests must exist before merge.”
Core artifacts we introduce in week 2
These are the artifacts that tend to pay off fastest in delivery teams. Each one is small, but together they create a system where AI output is reviewable and repeatable.
- AI usage policy (team level): what is allowed, what is restricted, and what must be logged. Example: “No customer PII in prompts,” “No copying third party code without licence checks,” and “Security sensitive changes require a second reviewer.”
- Prompt and context template: a standard way to provide constraints. Example fields: goal, non goals, relevant modules, performance constraints (like “p95 API latency must stay under 200 ms”), and test expectations.
- Definition of Done (AI aware): concrete criteria beyond “tests pass.” Example: “Unit tests cover edge cases,” “No new lint warnings,” “Error states handled,” “Telemetry added for critical flows.”
- PR checklist and review rubric: what reviewers check every time. Example rubric items: security (auth checks), correctness (boundary conditions), observability (logs/metrics), and maintainability (naming, duplication).
- Risk register for AI assisted changes: a lightweight table of risks and mitigations. Example entries: “Model suggested insecure regex,” mitigation: “run security lint + add input validation tests.”
The point is not paperwork. The point is to reduce the number of “invisible assumptions” in AI generated work. Invisible assumptions are what make teams slow: reviewers have to guess intent, QA has to guess risk, and PMs have to guess whether a change is safe to ship.
Role track workshops: same goal, different responsibilities
Week 2 is also where enablement stops treating “the team” as one audience. AI changes the work differently for engineers, QA, product, and design. If you run one generic workshop, you get generic outcomes: some tips, some prompts, and no shared operating model.
Role track workshops create alignment where it matters: at handoffs and boundaries. For example, a developer can generate tests quickly, but QA still needs to decide what to trust and what to probe manually. A PM can draft acceptance criteria with AI, but engineering needs those criteria to be testable and unambiguous.
We usually run 60 to 90 minute sessions per track with a shared case. A “shared case” means everyone works on the same feature slice, like “add discount codes with usage limits,” so the differences in output are visible and discussable.
Engineering track: from prompts to repeatable patterns
The engineering workshop focuses on patterns that reduce review cost. We prefer concrete practices like “generate code in small steps” and “write tests first for edge cases,” rather than prompt tricks. A good exercise is to take a messy week 1 PR and rework it into three smaller PRs with clear boundaries.
We also introduce measurable flow targets. For example, if your median PR review time is 18 hours, the goal might be to get it under 8 hours by improving PR descriptions, adding a checklist, and reducing diff size. Another target could be reducing Rework Rate (percentage of tasks reopened after code review or QA) from, say, 25% to 10% over a month.
QA track: trusting less, verifying faster
QA workshops in week 2 focus on risk based testing, not “test everything.” AI can generate a lot of tests, but quantity is not coverage. We teach QA to look for missing classes of risk: boundary conditions, permission checks, data migrations, and concurrency issues.
We also define quality metrics that the team can track. Examples include Defect Escape Rate (bugs found in production per release), Test Flakiness (percentage of test runs with non deterministic failures), and MTTR. If AI increases speed but also increases defect escape, the program is not working yet.
Product and delivery track: making requirements testable
Product workshops often reveal the real bottleneck: vague requirements. AI can produce plausible output from vague input, which is dangerous because it looks correct. We focus on writing acceptance criteria that can be tested. For example, “Discount code should work” becomes “Code applies only to items in category X, excludes gift cards, and fails with error message Y when usage limit is reached.”
We also introduce metrics that connect delivery to outcomes. If you ship faster but users do not adopt the feature, speed is not helping. Concrete metrics include Feature Adoption Rate (percentage of active users using the feature within 14 days), Support Ticket Rate (tickets per 1,000 users), and Customer Effort Score (CES) for key flows like checkout or onboarding.
Shared rules: the minimum standards that prevent friction
Week 2 ends with shared rules. These are not aspirational statements. They are rules that change daily behavior and reduce arguments. Without rules, teams fight about style, risk, and “what good looks like” in every PR. With rules, the argument becomes smaller: “Does this PR meet the rule, yes or no?”
We keep the rules short and enforceable. If a rule cannot be checked in review or CI, it becomes a suggestion. Suggestions are fine, but they do not reduce friction. Rules do.
Here are examples of shared rules that work in practice, especially in mixed seniority teams where AI can widen the gap between fast authors and overwhelmed reviewers.
- Scope rule: one PR, one intent. Example: “No refactors inside feature PRs unless approved.” This prevents AI from “helpfully” rewriting unrelated code.
- Context rule: every AI assisted PR includes a short “context used” note. Example: “Assistant was given modules A and B, not the whole repo.” This helps reviewers judge missing constraints.
- Testing rule: critical logic requires explicit edge case tests. Example: for pricing, test rounding, negative values, and max discount caps. For auth, test role boundaries and forbidden access.
- Observability rule: changes that affect key flows must add telemetry. Example: log structured errors, add a counter for “discount code rejected,” and track p95 latency for the checkout endpoint.
- Security rule: any change touching permissions, payments, or data export requires a security review checklist. Example items: input validation, authorization checks, and secrets handling.
How shared rules show up in delivery metrics
Rules should improve measurable outcomes, not just “feel better.” After week 2, you should see review time drop because reviewers stop debating basics. You should also see less rework because authors know the constraints before they start.
Two practical measures we use are Spillover Rate (percentage of sprint items not finished) and Change Failure Rate. If AI increases throughput but spillover rises, you may be starting too much work or producing work that is hard to finish. If change failure rises, your rules are not strong enough around testing and review.
Why licences without standards create team friction
Buying licences is the easy part. You can give everyone an assistant in a day. The hard part is that the assistant amplifies differences in habits. One developer writes careful acceptance tests. Another pastes code and hopes. One reviewer blocks everything. Another waves it through. Week 2 exists to stop those differences from turning into conflict.
In teams without standards, we see predictable friction points. Reviewers feel they are doing unpaid risk management. Authors feel blocked by “opinionated” feedback. QA feels squeezed because more changes arrive with less clarity. Delivery managers see more “done” tickets but also more production noise.
Here are the common failure modes when licences arrive before standards, with concrete examples of what they look like.
- PR inflation: diffs get bigger because AI suggests broad refactors. Example: a feature to add a field to a form also rewrites state management across the page. Review time doubles, and bugs hide in noise.
- Test theater: many tests exist, but they assert the wrong things. Example: snapshot tests for a pricing table that never validate the calculation rules. Bugs escape because “coverage” was mistaken for correctness.
- Inconsistent security posture: some people prompt with production data, others do not. Example: a support engineer pastes a customer email thread into a tool to draft a response, creating a compliance risk.
- Style wars: the assistant produces code in different patterns depending on who prompts it. Example: half the codebase shifts to a new validation library because the model suggested it, without a migration plan.
What week 2 changes in day to day behavior
Week 2 does not try to stop people from using AI. It makes usage legible. That means reviewers can see what context was used, QA can see what risks were considered, and PMs can see what “done” includes.
In practice, the change is small but noticeable. Standups include “what rule did we rely on” instead of “the assistant did something weird.” PRs include a checklist. Workshops produce shared examples of good and bad outputs. The team stops treating AI as personal productivity software and starts treating it as part of the delivery system.
How we anchor week 2 in measurable outcomes
If week 2 ends with documents but no behavior change, it failed. We prefer to define a small set of metrics that the team can track weekly. The point is not surveillance. The point is to see whether the new harness and rules reduce friction and risk.
We usually split metrics into three groups: flow, quality, and product outcomes. Flow metrics tell you whether work moves faster. Quality metrics tell you whether you are buying speed with defects. Product outcomes tell you whether the shipped work matters to users.
Flow metrics: speed with fewer bottlenecks
Flow metrics are easiest to measure because your tools already track them. The key is to define them precisely so people do not argue about the numbers. For example, Cycle Time should be measured as the median time from “in progress” to “deployed,” not from “ticket created,” because backlog time is a different problem.
- Cycle Time: median time from “in progress” to “deployed.” Watch for a drop after rules reduce rework.
- PR Review Time: median time from PR opened to first meaningful review. A practical target is to reduce it by 20% to 40% by improving PR clarity and scope.
- Deployment Frequency: releases per day or per week. More frequent deploys often mean smaller batches and easier rollbacks.
Quality metrics: fewer surprises after merge
Quality metrics keep the program honest. If AI makes it easy to produce code, it also makes it easy to produce subtle bugs. We track outcomes that show whether the harness is working, especially around testing and risk review.
- Change Failure Rate: percentage of deploys that cause rollback, hotfix, or incident. If this rises, tighten testing and review rules.
- Defect Escape Rate: bugs found in production per release or per week. Pair this with severity (P0, P1, P2) so you do not treat cosmetic issues like outages.
- MTTR: mean time to recover. If MTTR improves, your observability and runbooks are getting better, not just your coding speed.
Product outcomes: speed that users can feel
Shipping faster is not the same as improving the product. In week 2, we ask teams to pick one or two outcome metrics for the features they ship. This keeps the conversation grounded in user behavior, not internal activity.
- Feature Adoption Rate: percentage of active users who use the feature within a set window (often 7 or 14 days). Example: “20% adoption within 14 days” for a new dashboard widget.
- Support Ticket Rate: tickets per 1,000 users, segmented by topic. Example: “checkout discount code issues” should not spike after shipping discounts.
- Customer Effort Score (CES): a 1 to 7 score from a short survey like “It was easy to apply a discount code.” Track changes after releases.
Conclusion: week 2 is where teams stop arguing and start repeating
Week 2 is not about learning more prompts. It is about building a shared operating model so AI assisted work is reviewable, testable, and safe to ship. The harness artifacts make intent visible. The role track workshops align responsibilities at the boundaries. The shared rules reduce the number of recurring arguments in PRs.
Licences without standards create friction because they amplify differences in habits and risk tolerance. Week 2 fixes that by making “how we work” explicit. The success signal is not excitement. It is boring consistency: smaller PRs, faster reviews, stable change failure rate, and fewer production surprises.
If you want one practical takeaway, it is this: pick three enforceable rules, add a PR checklist, and track two flow metrics and two quality metrics for a month. When the numbers move in the right direction and the team argues less in review, you are no longer vibe coding. You are operating a system.
