Website of Peter Westerman

There are two fundamentally different relationships a professional can have with AI tools. The first is the user relationship: you give the AI a task, you receive an output, and you evaluate whether you are satisfied with it. The AI is a black box. You are a consumer of its outputs. If the output is not what you needed, you adjust the request or try again.

The second is the director relationship: you have a clear goal, you have thought through the approach before engaging, you are giving the AI a specific brief with defined constraints and success criteria, and you are actively steering the work toward that goal — not just evaluating whether outputs happen to land where you needed them. The AI is a capable collaborator with a defined scope of responsibility. You own the outcome.

The director relationship produces dramatically better results. Not because it makes the AI more capable — the AI’s capability is fixed — but because it changes how effectively you extract that capability. This is not a technical skill. It is a professional judgment skill. It is what distinguishes effective direction of human teams too, and it transfers directly to AI direction.

What Owning the Outcome Means Practically

Owning the outcome means you have done enough thinking before the session begins that you could evaluate any output the AI produces against a clear standard. You may not know how to build what you are asking for. You do know what it should do, what it must not do, what it should feel like to use, and how you will test whether it works.

This is not about technical knowledge. A non-technical person directing the design of a database for a marketing analytics tool does not need to know SQL. They need to know what questions the database should answer, what data goes in, what reports come out, and what performance is acceptable in practice. That is enough to evaluate whether the AI’s proposed design is on track, and to redirect it when the design would work technically but would not support the actual use cases.

The professionals who have the most difficulty making this shift are sometimes those with the deepest technical backgrounds, paradoxically. Experts tend to evaluate output on technical dimensions they understand well rather than outcome dimensions that require stepping back from technical detail. The outcome question — does this do what the user needs — is different from the technical question — is this good code. Both matter, but outcome is primary. The AI handles most of the technical quality. Human judgment is responsible for outcome quality.

The Pre-Session Checklist

Running this four-question checklist before every AI session produces consistently better outcomes. It takes two minutes. The return is measured in fewer corrective iterations.

What specifically am I building in this session? Not “work on the admin panel” but “implement the user preferences save and restore function — specifically, saving five fields to the database on form submit and pre-populating those fields from the database when the form loads.” One concrete deliverable, specified to a level of detail sufficient to evaluate whether it was produced.

What does the AI need to know that is not already in the context file? New constraints identified since the last session. New requirements added. Decisions made during recent testing. Changes to adjacent components that this session’s work must integrate with. The context file handles stable project knowledge; the session brief handles what has changed since the last update.

What failure modes am I most concerned about? For a form that writes to a database: SQL injection through unsanitized input, missing validation on required fields, no error handling when the database write fails, the form not pre-populating correctly when loading an existing record. Naming these in the brief means the AI addresses them explicitly in the implementation rather than leaving them for testing to catch.

How will I test this when the session ends? Knowing the test plan before the build shapes what you specify in the build. If you know you will test the form with empty required fields, invalid data formats, and a simulated database error, you specify those scenarios in the brief, and the AI builds handling for them explicitly. Test-before-build thinking produces implementations that are ready to be tested rather than implementations that need to be augmented before testing.

The Specificity Spectrum

Different types of AI requests benefit from different levels of specificity. Calibrating where on the spectrum to pitch any given request is a judgment skill that develops over time.

High-level exploratory: appropriate when you are in architecture mode and do not yet have enough domain knowledge to specify a solution. “I need to implement rate limiting on API requests from this plugin. What are the standard approaches for doing this in WordPress, what are the trade-offs, and which would you recommend given our current architecture?” The output of this session is information and a recommendation, not code. You make the decision, then direct the implementation.

Mid-level design: appropriate when the architectural decision is made and you want to validate the implementation approach before code is generated. “Based on your recommendation, we are using the token bucket approach. Here is what the rate limiting needs to do. Can you describe the implementation — what classes, what storage mechanism, what behavior at limit — without writing any code yet?” Review and approve the design before directing the build.

Low-level build: appropriate when the design is clear and you are ready to execute. “Build the rate limiting implementation as designed. The storage key is the user’s IP address plus the plugin prefix. The bucket capacity is 100 requests per minute. When the limit is reached, return a WP_Error with code rate_limit_exceeded and a message indicating when the limit resets. Log all rate limit events to the WordPress error log at the debug level.” This level of specificity produces reliable, testable, targetable implementations.

Most professionals new to AI collaboration default to high-level requests because that is how we communicate with colleagues who have years of shared context. With AI, that default produces mediocre results. Moving toward mid-level and low-level specificity for implementation work produces consistently better first-pass quality.

Directing Rather Than Approving

The most important mindset shift in AI collaboration is from approving to directing. In the user relationship, you are always approving — the AI proposes, you assess whether you are satisfied. In the director relationship, you are steering — before the AI builds, you have shaped the direction. The distinction is where in the workflow your judgment enters the process.

Approving happens at the end, after the build. Directing happens at the beginning, in the design conversation and the session brief. Directing is more efficient because it is cheaper to shape a plan than to reshape an implementation. A design conversation that clarifies the interaction model costs ten minutes. Rebuilding a feature with the wrong interaction model costs several hours. The investment in direction at the front of the workflow pays back at a ratio of roughly five to ten to one in reduced correction effort at the back.

This shift requires investing judgment earlier in the process — thinking through the problem before asking the AI to solve it, rather than asking the AI to think through the problem and then evaluating whether you agree with the result. The thinking investment at the beginning of the session is not optional overhead. It is the primary determinant of session quality. The professionals who treat it as optional discover, through expensive corrective iteration cycles, that it was not.

Managing Scope During the Session

One practical challenge in AI direction: the AI’s tendency to add features that were not requested. Ask for a settings form and receive a settings form with validation, help text, a reset button, contextual guidance, inline documentation, and CSS styling — none of which were specified. Most of the time, this is genuinely helpful. Occasionally it creates untested features that will break in unexpected ways, require maintenance you did not plan for, and obscure the scope of what was actually built.

The straightforward management approach: end every implementation request with an explicit scope statement. “Build just the settings form and the save function. Do not add validation, styling, help text, or any other components in this session — I will address those in separate sessions.” AI systems follow explicit scope statements reliably. The alternative is receiving a feature that is technically complete but has untested appendages that become bugs you will eventually need to address.

When the AI adds something useful that was not requested, acknowledge it explicitly before moving on. “The input sanitization you added is correct — keep it. Please note it in the context file.” Uncatalogued additions are the origin of “I don’t know why this is here” incidents months later, when an AI session removes the addition without understanding it was intentional. Context file notes cost thirty seconds. The incident they prevent can cost hours.

How Recent AI Innovations Change This Picture

The technical director frame described in this post — treating the AI as a capable but context-limited engineer who needs clear direction, explicit constraints, and defined scope — remains the right mental model for effective AI collaboration. What changes is the nature of what you are directing and the tools available for establishing shared context.

Agent Teams change the directing role from managing a single AI to managing a coordinated team of AIs. The technical director frame scales directly: instead of directing one engineer on one task, you are directing a lead engineer who coordinates with specialist teammates. The human’s role remains the same — define requirements, evaluate output, make architectural decisions, redirect when scope drifts — but the span of what can be accomplished in parallel expands substantially.

MCP integrations change what a technical director can ask the AI to do. In the methodology described here, asking the AI to “check what the current database schema says about this field” required manually exporting and pasting the schema. With MCP database connections, the AI can query the live schema directly. The directing role becomes more about defining what questions to answer and less about manually supplying the raw information the AI needs to answer them.

Agent Skills formalize the “technical director’s standing orders” concept that was implemented manually through CLAUDE.md files. The conventions, preferences, patterns, and constraints that a technical director communicates at the start of every session are now persistent and automatically loaded. The directing overhead at session start decreases, and the consistency of AI behavior across sessions increases. The technical director’s judgment is encoded in skills that apply automatically rather than being communicated from scratch each session.