AI / Agentic
From Claude Code's Creators to a Small Agent-Building Exercise
By Vivek Jalondhara · 5 min read
Published
Use the documented Claude Code origin as inspiration for a small, observable coding-agent exercise with synthetic CRM fixtures.
Boris Cherny identifies himself on his own site as the creator of Claude Code. Anthropic's recorded origin-story event features Cherny, Cat Wu, and Cal Rueb discussing the product's development and its use with codebases. Those sources establish a creator and team context without requiring an invented prototype timeline.
The practical lesson proposed here is a learning exercise: make one development task observable before widening the agent's authority. The exercise uses fictional CRM form definitions and is not a reconstruction of how Claude Code was implemented.
Choose a piece of work you can inspect completely
Imagine a saved form that refers to a field removed from its allowed field registry. A developer currently opens the configuration, finds the broken reference, and reports which block needs attention. That is a useful small task because the inputs, correct finding, and permitted output can all be explicit.
Create synthetic fixtures: one valid form, one missing field reference, and one unsupported block type. Keep them small enough to read manually. Do not begin with a production repository containing customer data. The exercise is about learning what the agent can explain and verify, not maximizing how much it can access.
Build the ordinary check first
A deterministic validator can compare each field reference with the registry and report invalid block types. Write down its expected results before adding a model. This baseline tells you whether the task needs language interpretation at all and gives the agent trustworthy feedback.
The model's proposed contribution might be explaining an unfamiliar configuration or locating relevant documentation. It should not replace an exact membership check with a guess. If the ordinary validator already solves the entire problem clearly, keeping that simpler solution is a successful outcome of the exercise.
Define a narrow interaction contract
Give the agent read-only access to named fixtures and the validator's output. A useful tool contract accepts a fixture identifier and returns bounded text or structured findings. It does not accept arbitrary shell commands or paths supplied by document content.
Ask for a diagnosis that names the fixture, block, failed rule, and supporting evidence. Distinguish an observed invalid reference from a suggested replacement. The agent may propose checking a renamed field, but should not silently declare two fields equivalent because their labels look similar.
Make each trial teach something
Run the same task against the valid and invalid fixtures and inspect the response. A successful explanation should identify the broken reference without reporting a problem in the valid form. Keep a short record of what the tool returned and which conclusion the agent drew from it.
If the explanation invents a field, adjust the output contract or tool description and repeat the relevant fixture. Change one aspect at a time so the result is interpretable. A polished paragraph is not the objective; a traceable diagnosis that a developer can act on is.
Introduce editing as a separate experiment
Once diagnosis is useful, propose a second exercise that produces a patch preview for one synthetic form. Keep the patch unapplied until its meaning is inspected. The validator can establish that references exist, while a human still checks whether the suggested field represents the intended information.
Include a fixture where two plausible replacement fields exist. The correct behaviour may be to ask for a decision rather than choose. This makes uncertainty observable. Expanding from explanation to mutation changes the consequences of a mistake, even when both tasks operate on the same small files.
Use the origin story as encouragement, not evidence of your design
A named creator and a public team discussion make a complex tool feel connected to ordinary engineering work. They do not establish that this exercise matches the team's architecture or that a similar prototype will become a widely used product. The design choices here stand on their own.
The achievable result is a small artefact you understand: fixtures, a baseline check, an interaction contract, and a record of successes and failures. The tradeoff is deliberately limited capability. That limit makes it easier to learn which additional authority or context would help, and which would only create more uncertainty.
A read-only agent learning exercise
This exercise brief can be used with a coding assistant without relying on any particular product API. Fixture identifiers are controlled inputs; the files and validator described here are proposed learning materials.
Illustrative example · Experiment brief · Simplified for explanation
Goal: explain invalid references in synthetic CRM forms.
Inputs: three named fixtures and a fixed field registry.
Baseline: deterministic field and block validation.
Agent access: read fixtures and validation findings only.
Output: fixture, block ID, failed rule, evidence, uncertainty.
Success: identify the invalid reference; accept the valid form.
Limit: propose a correction, but do not modify files.
Next experiment: preview one patch and validate it separately.- Create readable synthetic fixtures
- Establish a deterministic baseline
- Observe the agent's diagnosis
- Compare evidence with expected findings
Conceptual flow for the example above.
Tradeoff to keep in mind
This exercise can teach task decomposition and evidence handling. It does not evaluate a complete coding agent, reproduce Claude Code, or establish safety for access to a real repository.