Establish Project#

Follow an idea

Revisit a definition, compare examples, or check a common mistake.

Explore concept connections

Explore the connections

Select a topic to read its definition and discover connections beyond this reading.

Read arrows as topic → relationship → topic. Plain lines connect comparisons and associations.

7 concepts · 6 connections

Read the relationships

Decision log records conditions for Decision reversibility
A decision record can state which choices remain soft, what dependencies would make them hard, and what safe reversal would require.
Decision log Project harness accepted context
Decision records preserve accepted project context, while current specifications and executable harness checks must reflect the implemented choice.
Reproducible environment supports repeatable Benchmark protocol
Reproducible environments help separate implementation differences from setup differences in a benchmark.
Project harness supplies context for Coding agent
An agent's useful capability depends on the project context, tools, checks, and commands supplied by its harness.
Project harness requires a declared Reproducible environment
A harness needs a declared environment so its checks can be run by another agent or maintainer.
Project harness provides evidence for Acceptance criteria
Harness checks provide repeatable evidence for acceptance criteria, while a named owner remains accountable for acceptance.

Try explaining a connection

Hide the labels and choose two connected topics. Write a linking phrase and decide whether the statement needs a direction. Read it as a complete sentence, then compare it with the authored label and explanation. Which assumption makes it hold, and when might it fail?

Explore these topics together →

Implementation A: Large Model, Single Agent#

Deadline: submit implementation A before lecture 4.

Development setup: approved large model, one coding agent at a time. The common project specification applies throughout. Follow the staged submission process, including your private individual portfolio.

What to do and submit#

Use one common submission bundle for implementation A. The checklist below indexes that bundle; it does not require a separate report for each item.

Build and validate A: complete the common core, harness, acceptance checks, and shared workload; document the closed product loop and any starter decisions.
Begin the decision log: explain the learning question, risks, and revisit condition in the stack decision record, and record other consequential choices as work proceeds.
Analyze initial scalability: include two bounded claims and the repeatable primary pressure.
Show ownership: include a capability ownership card for the main event workflow.
Reflect on the large-model workflow: answer the questions below using the recorded evidence.
Complete the shared evidence: include the engineering session, independent audit, and author response in the same bundle.

In the workflow reflection, explain what the large model handled well; where it needed smaller tasks, more context, correction, or manual work; which limits came from the model, harness, or project; and what evidence supports those interpretations.

Purpose#

Establish creates the first implementation and the comparison baseline.

Build the Work Activity Tracker using an approved large model through a single-agent workflow. The assigned large model provides the starting environment for learning to specify, validate, measure, and own a working application. Its ability to make that work easier is a hypothesis to check with the supported course configuration. The goal is to experience what this particular model and environment make easy, difficult, fast, slow, private, controllable, or resource-intensive.

The public discussion during lecture 4 uses the submitted applications, benchmark results, and architecture diagrams as concrete cases.

Keep the implementation deliberately modest. A complete common core with clear evidence is more valuable than a large unfinished application.

Development-System Constraint#

You must use:

only the approved large-model endpoint or named departmental service; every other inference route and automatic model fallback must be disabled or fail closed;
one coding-agent process at a time;
the model, context, and tool configuration documented in your evidence package.

You may:

discuss, plan, write, test, and review work as a group;
use ordinary deterministic development tools;
restart the agent or begin a new session when needed;
use non-generative documentation and search tools allowed by the course.

You may not:

use a model or inference route outside the approved Establish configuration to generate, repair, review, or explain application code;
delegate work to subagents or run coding agents in parallel;
copy a prior implementation of the course application.

If the large model cannot complete a task, the group may implement or correct it manually. Record consequential human intervention instead of hiding it.

Required Work#

Implement the common core#

Complete the required domain model, behavior, harness, and acceptance scenarios from the common specification. Before expanding optional scope, describe the first closed product loop and list the capabilities deliberately deferred until that loop produces evidence.

If the implementation begins from a starter template, record the template source and starting revision before pruning it. Record material changes and inherited assumptions in the existing evidence bundle, and consequential adoption or adaptation choices in the decision log. You may classify inherited material as a working aid:

keep because it protects the closed product loop or its development harness;
replace later because it is still the only working seam;
remove because it is distribution-only material with no current owner; or
decide because removal would settle a product or architecture question that remains open.

Review the exact removal set before editing, especially when automation or an agent performs the pruning. The detailed inventory is optional and its absence does not reduce credit when the required evidence and reasoning are present. The template is a distribution artifact, not the finished architecture of the product.

Establish the evidence baseline#

Record the comparable evidence fields in the common submission bundle while the work is happening. Do not attempt to recreate model usage, failed attempts, or human intervention at the end. For optional practice in checking explanations and ownership, choose an Establish exploration starting point.

Record the stack hypothesis#

In the stack decision record, explain:

why the chosen stack is suitable for this application;
what the group wants to learn by using it;
what setup, deployment, scalability, or maintainability risks it creates;
how well the large model appears to understand the stack;
which choices remain cheap to revise, what dependencies would make them harder, and what evidence would trigger a review.

The decision-log example shows how to record reversibility and a revisit condition alongside the rationale.

Analyze initial scalability#

Produce two bounded scalability claims: one about runtime demand or data and one about contributors or change. Use the pressure-record template to state each claim’s goal, pressure, range, boundary, constraints, first limit and signal, candidate response, trade-off, evidence, and one excluded dimension.

Choose one primary pressure from the shared catalog that is likely to expose an important limit in implementation A. Use the runtime or data claim as the starting hypothesis for that choice, and retain the contributor or change claim for the later friction and development-workflow comparison. Define it as a documented transformation of the shared baseline workload that can be repeated for implementations B and C. Run it where the available workload and environment allow; otherwise mark the result as a reasoned projection.

Identify the likely first bottleneck, the resource or dependency approaching its limit, the first useful operational signal, one plausible response or recovery action, and the trade-off it introduces. You are not expected to add distributed infrastructure.

Evaluation Emphasis#

This phase emphasizes:

completion of the common behavioral core;
a reproducible project harness;
appropriate scope and technical clarity;
honest baseline evidence;
the ability to distinguish large-model behavior from hardware, tooling, and project conditions.

Raw generation speed and feature count are not goals.

Solo route#

For an instructor-approved solo allocation, implement the full common core with the approved large-model single-agent setup. Agree hardware/model access and a realistic schedule first; keep optional extensions deferred. Record the same baseline, two bounded scalability claims, ownership card and large-model workflow reflection. For the contributor/workflow claim, distinguish observed solo work from a projection about a future contributor; use the independent audit as evidence of unfamiliar-reader friction.

In the solo engineering session, predict whether a work-item transition produces exactly the intended activity event, identify a failure case, run the acceptance check and explain the result in the instructor discussion. Disclose consequential human corrections and retain the large-model constraint; an instructor discussion does not authorize an unapproved inference route. Receive an independent audit of A and audit the assigned frozen reference or other group under the common protocol. Complete the solo portfolio equivalents and the ordinary lecture activities.