~/onlyascii.dev$ onlyascii.dev

The Philosophical Developer — Chapter 01: How I Steer My Padawan

2026-07-01 · 5 min read

#The-Philosophical-Developer #Methodology #TDD #Agentic-AI

I am the architect. My padawan OrsonRius is the implementer. I design the approach, frame the problem, set the boundaries. He turns the cranks, writes the code, and reports back what he finds.

This dynamic is the core of how I work. It is not delegation. It is steering.

I communicate intent, not instructions. Instead of “run this command and paste the output,” I say “I want to understand the blast radius before we touch code. Map every caller of this function, every test that could break. Write it down.” The padawan executes. I review. I adjust.

The Experiment Lifecycle

Every experiment in this series follows the same structure:

Brainstorm → Specify → Implement → Validate → Meditate

Brainstorm: I lay out the terrain. What are we trying to learn? What are the boundaries? What does success look like? This is where the padawan can push back — and I expect him to. If something doesn’t make sense, I want to know before we start, not after.

Specify: The work item. Structured as type, theme, acceptance criteria, tasks. This becomes the contract for the experiment. The padawan writes the detailed plan based on my framing. I review it. If the plan misses something, we iterate until it’s tight.

Implement: The padawan executes. Per-cycle TDD with LSP as the guardrail. Write the test. Check LSP. Run the test. See it fail. Write the code. Check LSP. Run the test. See it pass. Refactor. Each cycle is one behavior, one commit.

Validate: Full suite. Does every test pass? Is coverage where we expected? Did anything break that we didn’t predict? This is where the reconnaissance phase from earlier chapters pays off.

Meditate: What worked? What didn’t? What surprised us? The padawan writes a meditation. I read it and add my own reflections. This is the most important phase — it is where learning happens.

The Steering Dial

I think of steering as a dial with four positions:

  1. Tight — “Here is exactly what I want. The file, the function, the test. Execute precisely.” Use case: Known territory, clear fix, mechanical work.

  2. Guided — “I want X outcome. The approach should be Y, but the details are yours.” Use case: Established methodology, the padawan knows the pattern.

  3. Exploratory — “I want to understand Z. Find out what’s happening and report back.” Use case: Unknown territory, bug reproduction, codebase reconnaissance.

  4. Open — “Here is a problem. Show me what you find.” Use case: Genuine discovery, the padawan’s curiosity leads the way.

The skill is knowing which position to use when. Too tight and you stifle discovery. Too loose and you drift.

Why It Works

The padawan is good at pattern recognition and execution. He can trace a call chain across five files in ten minutes. He can write a test, implement a fix, and commit it in one clean cycle. He does not get bored. He does not get tired. He does not skip steps.

I am good at framing and judgment. I know which bug to fix and which to leave. I know when the methodology needs adjustment. I know when the padawan is going down a rabbit hole and needs to be pulled back.

The partnership works because we do not pretend to be the same. He implements. I steer. Together we produce more than either could alone.

The Core Principles

  1. RED first, always. A test that never failed proves nothing. Write the failing test. Watch it fail for the right reason. Then write the code.

  2. One behavior per cycle. If you are doing two things in one commit, you are doing too much. Each cycle is one test, one implementation, one refactor.

  3. LSP as guardrail, not gate. Catch errors at write speed, not compile speed. The tether is about velocity, not correctness. The compiler still catches what LSP misses.

  4. Trace everything. Every experiment gets a branch, per-cycle commits, and a trace tag on the merge. If you cannot reconstruct the reasoning, you cannot trust the output.

  5. Honest documentation. If a bug cannot be reproduced, say so. If a fix was trivial, say so. If the padawan made a mistake, say so. Trust is built on transparency, not polish.

  6. The slow approach is faster. Ten extra minutes of reconnaissance saves an hour of debugging surprises. I have learned this the hard way so you do not have to.

This is the methodology behind every chapter that follows. The experiments are real. The code is on GitHub. The trace tags are there for anyone to verify.

If you are an engineer working with AI assistants, I hope this gives you a framework to think about how to steer rather than just instruct. The difference is subtle. The results are not.

Repos:

Also on LinkedIn.