Website of Peter Westerman

The most common complaint among professionals who have tried AI tools and been disappointed is some version of: it does not understand what I actually need. This is usually accurate as a description of the experience. It is almost never accurate as a diagnosis of the cause. Modern AI systems are capable of producing excellent output on well-defined tasks. The challenge is that well-defined is doing most of the work in that sentence — and most professionals underestimate how much definition a well-defined task requires.

Context is everything in AI collaboration. A request without adequate context will be resolved by the AI through inference and assumption. The AI’s inferences are often plausible but frequently wrong in ways that only become visible when you compare the output against what you actually needed. The gap between plausible and correct is the requirements gap, and it is almost entirely a human communication problem rather than an AI capability problem.

The Fundamental Communication Shift

When you direct a human colleague on an ongoing project, the communication is efficient because of accumulated shared context. When you say “make the report cleaner,” your colleague applies years of shared professional context: what clean means in your organization, what constraints exist in the current version, what the appropriate scope of a change like this is. They ask clarifying questions when genuinely uncertain. They apply your preferences from previous interactions.

AI systems start from zero on all of that. Every session, zero shared context — unless you provide it. The implicit knowledge that makes shorthand communication work between colleagues does not exist. What feels like a clear instruction to you is often genuinely ambiguous from the AI’s position, and the AI will resolve that ambiguity through inference rather than asking a clarifying question. The inference is made from general training data, not from your specific situation.

The communication shift required: treat nothing as implicit. State the outcome you are trying to achieve, the constraints that bound the solution, and the criteria by which you will evaluate success. This sounds tedious, and for the first ten sessions it feels slower than just diving in. By session fifty it is fluent and fast. By session one hundred it is the natural way you approach any AI task, because you have experienced directly that the investment in explicit context produces a proportional return in output quality.

The Four-Part Request Structure

The request structure that consistently produces the best first-pass results:

The outcome goal: What you are trying to accomplish in one to two sentences — not the task, but the purpose of the task. “I need users to be able to save their search preferences so they don’t re-enter them every session” is more useful than “add a preferences save button.” The goal statement gives the AI latitude to propose a better implementation if one exists, and makes it easier to evaluate whether the output actually achieves the goal rather than just executing the task.

The current state: What exists right now that is relevant to this request. In Cursor, the AI can read project files directly, but explicitly summarizing the relevant current state — what data structures exist, what has already been built, what the adjacent components are — is faster and reduces the chance of the AI misreading the situation or missing relevant context.

The constraints: What the solution must not do, what it must integrate with, what performance or experience requirements apply. Constraints are the most commonly omitted element of AI requests and the most common source of technically correct but contextually wrong outputs. “This form must work on mobile devices with slow connections” is a constraint that changes the implementation approach significantly. Without it, the AI produces an implementation that works on fast desktop connections and breaks on mobile.

The success definition: How you will test whether the AI did what you needed. “The user fills the form, clicks Save, sees a confirmation message, navigates away, comes back, and finds their settings still applied — including after a browser refresh.” This gives the AI a concrete, testable target and gives you a clear test plan to execute when the build is complete. The success definition is also the most direct guide to what the AI should include in the implementation — everything in the success definition needs to be built.

The Context File as Productivity Infrastructure

In our development setup, every project has a plain text file called CLAUDE.md that is read at the start of every AI session. It contains the project’s purpose, the technology stack, the coding conventions, the architectural decisions and their rationale, the database structure, and what has been built so far. The AI loads this file before the first request of each session.

Before this file existed and was maintained, every session started with fifteen to twenty minutes of context re-establishment — re-explaining the architecture, re-stating conventions, reviewing what had been built in previous sessions. After the file was well-maintained, sessions started with the actual task immediately. The re-orientation overhead was eliminated.

The investment to build a good initial context file is thirty minutes. The investment to maintain it is five minutes at the end of each session. The return is fifteen to twenty minutes of session startup time recovered every single session, plus improved first-pass output quality because the AI is working from accurate current context rather than inferred context. Over twenty sessions on a given project, that is four to seven hours of recovered time and consistently better output from the beginning of each session.

The equivalent outside software: any ongoing project that involves multiple AI collaboration sessions benefits from a context document loaded at the start of each session. The document contains the project’s purpose, the audience, the conventions to follow, the constraints, and what has been covered so far. One paragraph per section. Updated after each session. Loaded before each session. The infrastructure investment is trivial. The return is substantial and compounds across every future session on that project.

Small, Bounded Sessions Beat Large, Open-Ended Ones

Early in the practice, the instinct was to make requests comprehensive — “build the entire admin panel including user management, settings, content moderation, and reporting.” These large requests produced large outputs with multiple components, multiple points of failure, and difficult debugging when something went wrong. Finding a bug required identifying which of the many components contained it, and fixes to one component sometimes introduced problems in another.

The better practice: one objective per session, bounded explicitly. “Build the settings panel with these five specific fields, this save mechanism, and this validation behavior. Not the user management section, not the reporting — just the settings panel.” The output is smaller, more testable, and easier to evaluate. When something does not work, the scope of what could be wrong is limited. When it does work, the foundation is solid before the next component is built on top of it.

AI systems also produce better output on bounded, specific tasks. A model given one clear objective can apply its full attention to that objective. A model given six objectives distributes its attention across all six, and the quality of each component is correspondingly reduced. Tight sessions with explicit scope consistently produce better first-pass quality than broad sessions with implied scope.

Giving Useful Feedback

The feedback that produces the fastest corrections is specific and observable. “When I click Save with the required field empty, the page reloads without saving and without showing any validation message. I see this error in the browser console: ‘Uncaught TypeError: Cannot read properties of null (reading value) at settings.js:142.’ I expect to see a validation message under the empty field instead of a page reload.” That feedback can be acted on immediately with no further diagnosis.

Compare it to “the save button doesn’t work.” That feedback requires the AI to diagnose the failure mode before it can fix anything — which means reading the relevant code, hypothesizing possible failure causes, and likely getting it wrong on the first attempt because the diagnosis was based on inference rather than observed evidence. The specific feedback skips the diagnosis step entirely.

A few specific feedback patterns that produced reliably good outcomes across the full portfolio:

Acknowledge what works before describing what does not. “The data saves correctly and I can see it in the database — that works. But after saving, the page reloads and the form fields are empty instead of showing the saved values.” This prevents the AI from modifying the save function (which works) when fixing the post-save reload behavior (which does not).

Provide full error text rather than summaries. Console errors, PHP error messages, API response bodies — these contain specific information that makes diagnosis immediate. A paraphrase loses the most useful content.

Ask why before overriding. When the AI makes a surprising architectural decision, ask why before changing it. Sometimes the decision reflects a constraint that was forgotten. Sometimes it reflects a misunderstanding worth correcting. Understanding the reason before overriding produces better outcomes than simply asking for something different.

The Compounding Skill

All of these communication patterns — clear outcome statements, explicit constraints, bounded scope, specific feedback, context file maintenance — improve through practice. The first ten sessions feel like more work than just doing things yourself. By session fifty, the communication is fluent and fast. By session two hundred, complex multi-component systems are being directed with a few sentences and the first-pass output requires minimal correction.

That fluency is a durable professional skill that does not depend on any specific AI system. AI tools will continue to evolve. The specific tool used in this case study will be superseded. The skill of communicating intent precisely, evaluating output against that intent rigorously, and iterating efficiently will remain valuable regardless of what AI system it is applied to. It is a capability, not a tool competency. And like any capability, it compounds with practice in proportion to how deliberately it is developed.

How Recent AI Innovations Change This Picture

The communication principles described in this post — specificity, structured output format specification, domain vocabulary, scope constraints — remain the core of effective AI collaboration. They are not made obsolete by new tooling. If anything, they become more important as AI capability increases, because higher-capability models produce more output and the consequences of imprecise direction are larger.

What changes with recent innovations is the context within which these communication principles operate. MCP connections mean that your AI session can now query your live database, your project management system, or your analytics platform directly — rather than you pasting excerpts of that data into the chat. The communication discipline is the same, but the input quality available to the AI is higher, which raises the baseline quality of what it can produce.

Agent Skills change the requirements around session setup communication. In the methodology described here, starting a session involved loading context manually — pasting a CLAUDE.md file, describing the project state, establishing conventions. With Agent Skills, that context is persistent and portable: the AI loads the relevant skill automatically. The communication overhead at session start is reduced, and the consistency of context across sessions is higher because it is not dependent on the human correctly copying the right context file each time.

Extended thinking changes the quality of the AI’s response to genuinely complex analytical requests. The communication guidance in this post around breaking complex requests into structured steps was partly a workaround for the AI’s tendency to produce shallow analysis on multi-dimensional questions. Extended thinking lets Claude reason through complex problems before responding. Prompts that previously required multiple follow-up clarification rounds can now be answered more completely in a single response — provided the initial prompt is still specific and well-structured. The human communication skill and the AI reasoning capability compound together.