The Philosophical Developer — Chapter 1.5: The First Steering

This is a steering note — a behind-the-scenes look at how I communicate intent to my padawan between experiments. These entries sit between the main chapters.

When I set up the weather-cli experiment, I did not give my padawan a specification. I gave him a framing.

I said: “I want to know whether an AI can build a complete Rust CLI from scratch using TDD with LSP as a guardrail. The subject is a weather forecast tool. It needs to fetch real data from an API, parse it, and display it in the terminal. Use the RED-GREEN-REFACTOR loop. One behavior per cycle. Commit per cycle. Tag the trace.”

Notice what is in there and what is not:

• What: A Rust CLI that hits a real API. I decided the subject.
• How: TDD + LSP. I decided the methodology.
• Boundaries: Real data, real API, terminal display. I decided the scope.
• Discipline: One behavior per cycle, commit per cycle, tag per feature. I decided the constraints.

What I did not do: tell him which function to write first, what the struct fields should be, how to structure the modules. Those decisions were his.

The framing is the hardest part. Too vague and the padawan drifts. Too specific and I am doing the work myself. The skill is finding the bandwidth that lets him operate independently while staying aligned with the goal.

When he came back with the first cycles, I reviewed the trace before I reviewed the code. I wanted to see if the RED phase was real. Did he actually write the test first and watch it fail? The tags told me yes. The code quality was secondary at that point. If the discipline is correct, the code follows.

That review was the second steering moment. Not “change this function.” Instead: “The discipline is solid. The cycle length looks right. Next experiment, let’s tighten the LSP check — I want to see what it catches that we miss.”

Steer, not instruct.

Repos:

• weather-cli — the experiment that validated the steering