Elements of Scalable Web Applications

Specification 02

Challenge
Status
Canonical brief
Application
Work Activity Tracker

Implementation B · foundation model · single agent.

Challenge Project#

Implementation B: Foundation-Model Single Agent#

The common project specification applies to this phase.

1. Purpose#

Challenge creates a fresh implementation of the same Work Activity Tracker using a foundation model through a single-agent workflow.

The purpose is to compare implementation B with the local-model baseline. A more capable model may generate more code, infer more context, or recover from problems differently. It may also introduce unnecessary complexity, plausible-looking defects, greater cost, or more demanding review work.

This is a new implementation, not a refactor of implementation A.

Complete and submit implementation B before lecture 7. The public discussion during lecture 7 will compare the Challenge results before the course introduces the fleet workflow for implementation C.

2. Starting Conditions#

Begin in a new repository or clean implementation directory.

Use:

  • the same common specification and acceptance scenarios;
  • the transfer policy in the common specification;
  • the approved foundation model;
  • one coding-agent process at a time;
  • normally the same primary stack chosen for Establish.

Keeping the primary stack stable makes the comparison easier to interpret. A group may change it with instructor approval when the change supports a clear learning question. The final comparison must then treat the stack change as a confounding factor rather than attributing every difference to the model.

3. Development-System Constraint#

You may:

  • use the approved foundation model for planning, implementation, testing, explanation, and review;
  • begin new agent sessions when needed;
  • use ordinary deterministic development tools;
  • use the permitted shared artifacts described in the transfer policy.

You may not:

  • copy application code or implementation-specific tests from implementation A;
  • use an agent fleet, subagents, or parallel coding agents;
  • describe implementation B as a foundation-model result without recording substantial manual correction.

The group remains responsible for every submitted decision and line of code, regardless of who or what generated it.

4. Required Work#

4.1 Implement the common core again#

Complete a fresh implementation of the required domain model, behavior, harness, and acceptance scenarios.

4.2 Repeat the evidence collection#

Use the same evidence categories and measurement units as Establish. Preserve failed attempts and human corrections that help explain the result.

4.3 Compare the two single-agent workflows#

Compare implementations A and B in terms of:

  • acceptance-scenario completion;
  • architecture and codebase shape;
  • test quality and known defects;
  • setup and audit friction;
  • elapsed and active human time;
  • model latency, usage, cost, or local resource use where measurable;
  • amount and type of human intervention;
  • optional scope completed.

Do not present correlation as proof. The group has more domain knowledge during Challenge, and this practice effect is part of the comparison's limitations.

4.4 Apply runtime pressure#

Apply the same shared scalability scenarios to implementation B. Compare its pressure map with implementation A:

  • Did the new implementation make different architectural assumptions?
  • Does it fail or slow down in a different place?
  • Did the foundation model introduce infrastructure or abstractions that the evidence does not justify?
  • Which implementation is easier to scale, and according to what evidence?

5. Deliverables#

Submit:

  • implementation B in its own repository or implementation directory;
  • the complete common evidence package;
  • acceptance-scenario and automated-test results;
  • architecture and data-flow diagram;
  • an updated capability ownership card for the main event workflow;
  • updated stack decision record;
  • scalability pressure map;
  • a concise A–B comparison;
  • the cross-team audit report and a short response from the authors.

The A–B comparison should distinguish:

  • observed differences;
  • plausible explanations;
  • alternative explanations and confounding factors;
  • what the available evidence cannot establish.

6. Evaluation Emphasis#

This phase emphasizes:

  • a genuinely fresh and complete implementation;
  • consistent evidence across both phases;
  • careful comparison rather than model enthusiasm;
  • architectural and scalability reasoning;
  • awareness of practice effects, scope changes, and human review.

A larger implementation B is not automatically a better implementation.