The Hidden Skill Behind Great Hires and Reliable AI Code: Writing Better Tests for Intent

What if a job description and an AI coding prompt are the same kind of document?

Both appear to be instructions. One tells a person what a company wants. The other tells an agent what software to build. Yet both routinely produce disappointing results for the same reason: they describe a desired outcome without making the surrounding reality legible.

A job description may list ten qualifications, three personality traits, and a sweeping promise about impact. An AI agent may receive a request to “build the feature cleanly” and immediately generate hundreds of lines of plausible code. In both cases, the recipient is expected to infer the missing context. When the result falls short, the recipient is blamed for misunderstanding what was never made explicit.

The deeper issue is not that people write poor job descriptions or that AI writes poor code. It is that ambiguous specifications create systems that optimize for appearance rather than intent.

The hidden contract inside every request

A specification is often treated as a list of requirements. In practice, it is a contract between an intention and an execution system.

Consider a company looking for a “strategic, hands on product leader who thrives in ambiguity.” This sounds informative, but it may conceal several incompatible expectations:

• The company needs someone to establish a product strategy.
• The founders still want to approve every meaningful decision.
• The team lacks basic operating processes.
• The new hire is expected to deliver immediate results without much authority.
• “Thrives in ambiguity” may mean “will tolerate unclear priorities without asking for organizational change.”

The words are not necessarily false. They are simply underspecified. They describe the company’s ideal self image more clearly than the work the employee will actually perform.

AI coding requests have the same weakness. “Add authentication,” “refactor this module,” or “build a dashboard” may communicate a destination while omitting the map. Which users matter? What should happen when data is missing? What existing conventions must be preserved? What counts as failure? What tradeoffs are acceptable?

An agent can fill these gaps rapidly. That is precisely the danger. A human may pause, ask questions, or recognize that the assignment is incoherent. An AI system can produce a polished answer before anyone notices that the problem itself was never defined.

The more capable the executor, the more expensive an ambiguous specification becomes.

A weak specification slows down a competent person. A powerful agent can accelerate the wrong interpretation so efficiently that the mistake becomes expensive to reverse.

Why wish lists fail in both hiring and software

A wish list confuses attributes with evidence.

Employers often request communication skills, leadership, ownership, adaptability, technical fluency, and domain expertise. These are not useless requirements, but they are broad categories. They do not tell a candidate what behavior will be observed or what success will look like after six months.

The same error appears when a developer asks an agent to produce “high quality code.” Quality is not a single visible property. It may include correctness, readability, performance, security, compatibility, test coverage, type safety, and alignment with the existing architecture. A solution can be elegant in one dimension and disastrous in another.

In both settings, the wish list creates a false sense of precision. The document looks detailed because it contains many words. But detail is not the same as operational clarity.

A useful way to distinguish them is to ask three questions:

1. What must be true when the work is complete?
2. How will we know whether it is true?
3. What constraints must not be violated along the way?

A job description that says “drive growth” fails the first question unless it identifies the relevant growth problem. It fails the second unless it names measurable outcomes or observable decisions. It fails the third unless it explains constraints such as budget, authority, regulatory limits, or existing systems.

A coding request that says “make the API robust” fails in exactly the same way. Robust against what? Invalid input, outages, concurrency, malicious requests, or future changes? How will robustness be tested? Which latency, compatibility, and security constraints matter?

The remedy is not to create longer documents. It is to convert vague attributes into behavioral tests.

Instead of “strong communicator,” specify: “When engineering and sales disagree about a launch date, this person can produce a written recommendation that identifies the tradeoffs, proposes a decision, and makes the unresolved risks visible.”

Instead of “write maintainable code,” specify: “The change must preserve the public interface, pass the existing test suite, add coverage for the reported failure, satisfy static analysis, and explain any architectural exception.”

These statements are powerful because they expose the evaluator’s model of success. They give both humans and machines something to reason about.

The overlooked technology of hiring: evaluation loops

Software teams improve AI generated code by surrounding generation with feedback. They use static analysis to catch structural problems, pre commit checks to enforce standards, automated tests to detect regressions, and human review to judge whether the implementation actually matches the intent.

Hiring rarely receives the same level of engineering discipline.

A candidate may be evaluated through an unstructured interview, a vague impression of “fit,” and a conversation with people who each hold different definitions of success. The organization may then be surprised when the hire performs differently from the imagined candidate. In effect, the company runs a production deployment with no test suite.

This comparison is more than a metaphor. A hiring process is an evaluation system, and every evaluation system has failure modes.

Static analysis in hiring means checking observable prerequisites before the interview: has the candidate solved the relevant class of problem, operated at the needed scale, or worked within the constraints that matter? This does not mean reducing a person to keywords. It means distinguishing genuine signals from decorative requirements.

Unit tests in hiring are structured questions tied to the actual work. If the role requires prioritization under limited resources, ask the candidate to rank three competing initiatives and explain the choice. If it requires stakeholder alignment, present a disagreement and examine how the candidate would make the decision legible.

Integration tests in hiring simulate the environment in which the person must operate. A candidate may be excellent in isolation but ineffective when working across product, engineering, finance, and customers. The relevant question is not merely whether they possess a skill. It is whether the skill survives contact with the system.

Human review remains essential. Automated checks can verify that a function returns the expected value, but they cannot fully judge whether the feature belongs in the product. Likewise, an interview scorecard can improve consistency without replacing judgment about character, learning ability, or unusual potential.

The key is to make judgment inspectable rather than pretending it can be eliminated.

Context is not decoration, it is the operating system

One of the most important practices in reliable AI coding is giving the agent the context it needs every time: repository conventions, setup instructions, tools, tests, and reminders of best practices. This prevents the system from having to reconstruct the environment from incomplete clues.

Organizations should treat candidates similarly.

A job description should not merely announce what the company wants from a person. It should provide enough context for the person to decide whether the role is viable. What decisions will this person own? Which decisions remain with the founder or manager? What is currently broken? What resources exist? What has already been tried? Which outcomes matter most during the first quarter?

This is not excessive transparency. It is an efficiency mechanism.

When context is hidden, candidates optimize for getting hired rather than determining mutual fit. They perform the expected identity. Employers optimize for finding an impressive generalist rather than exposing the actual operating conditions. Both parties enter the relationship with incompatible assumptions.

The result resembles code that passes a superficial demo but fails in production.

A better job description behaves like a well configured development environment. It includes:

• The mission of the role in one concrete sentence.
• The recurring problems the person will encounter.
• The decisions they can make without permission.
• The constraints that will shape their choices.
• The evidence that would indicate meaningful progress.
• The behaviors that have previously caused failure in this environment.

That final item is especially valuable. A repository’s tests often encode lessons from past bugs. An honest hiring document should encode lessons from past organizational mistakes. If previous leaders failed because priorities changed weekly, say so. If a role requires unusual tolerance for incomplete information, explain the source of that incompleteness rather than hiding it behind a phrase about ambiguity.

The agent invoker and the hiring manager

There is a subtle role in high quality AI assisted development: the person who invokes the agent reviews the work before passing it to a second reviewer. This person holds the full context of the request and is therefore responsible for catching obvious mismatches before the code travels further.

Hiring has an equivalent responsibility, and it is often neglected.

The hiring manager is not merely the person who approves a candidate. They are the context owner. They know which parts of the job are genuinely essential, which requirements are negotiable, and which attractive qualities are irrelevant to the real bottleneck. If they delegate evaluation without transferring that context, the process becomes a chain of lossy interpretations.

Recruiters may screen for keywords. Interviewers may assess their favorite competencies. Executives may respond to confidence or familiarity. By the end, the organization has combined several partial signals and mistaken the result for a coherent decision.

The context owner should therefore perform an explicit first review:

• Does this candidate’s evidence address the actual problem?
• Are we rewarding polished language instead of relevant behavior?
• Are we rejecting someone for lacking a preference that was never truly necessary?
• Have we changed the role while evaluating candidates without updating the criteria?

This is analogous to reviewing generated code before merging it into a shared system. The first reviewer is not checking every line. They are checking whether the work is pointed at the right problem and whether it respects the local rules.

The same principle applies to AI. An agent should not be judged only by whether it produced code that compiles. Someone with full context must ask whether the feature is correct, necessary, and compatible with the surrounding product.

A practical framework: turn wishes into tests

The most useful shared framework for hiring and AI work is a five layer specification.

1. Intent

State the underlying problem, not the requested artifact.

“Build a dashboard” is an artifact. “Help support managers identify unresolved customer issues before they become escalations” is intent. “Hire a product leader” is a title. “Reduce the time between customer evidence and a defensible product decision” is closer to intent.

2. Observable outcome

Define what changed in the world.

For software, this may be a failing test that now passes, a reduced error rate, or a preserved interface. For a role, it may be a decision process that becomes faster, a recurring operational failure that disappears, or a measurable improvement in customer retention.

3. Constraints

Name what cannot be sacrificed.

Security, backward compatibility, budget, legal requirements, team capacity, and existing conventions all belong here. Constraints turn generic competence into situational competence.

4. Feedback loop

Specify how errors will be detected early.

Use tests, type checking, linting, code review, trial projects, structured interviews, reference questions, and early performance checkpoints. The goal is not to create bureaucracy. It is to reduce the distance between a wrong assumption and its discovery.

5. Context owner

Assign responsibility to the person who can interpret ambiguity.

Someone must decide whether an apparent failure reflects poor execution or a flawed request. Without a context owner, organizations punish executors for specification errors and then rewrite the specification after the fact.

This framework also clarifies what AI can and cannot do. AI is increasingly capable at transforming a clear intent into an implementation. It is much less reliable at deciding which unstated organizational tradeoff matters. The same is true of candidates. A talented person can solve the problem presented to them, but cannot reliably infer the problem the company refuses to articulate.

Key Takeaways

• Replace adjectives with evidence. Turn “strategic,” “robust,” or “collaborative” into behaviors that can be observed and evaluated.
• Write the test before requesting the solution. Define how success and failure will be recognized before asking a candidate or an AI system to act.
• Expose constraints and authority. People and agents perform better when they know what they may change, what they must preserve, and which tradeoffs are unacceptable.
• Create a context owner. The person closest to the real intent should review interpretations before they become expensive decisions.
• Treat feedback as part of the specification. Tests, structured interviews, static analysis, and review are not afterthoughts. They are how an organization makes its intentions executable.

The real competitive advantage is specification quality

The popular story about AI coding is that machines are making software creation faster. The less obvious story is that they are exposing the quality of the instructions surrounding software creation. An agent that produces bad code may be revealing weak tests, unclear architecture, missing conventions, or an unstable product decision.

Hiring reveals the same organizational truth. A company that cannot explain what a role must accomplish will struggle to recognize the right person, no matter how sophisticated its recruiting process becomes. It may keep adding requirements, interview stages, and scoring rubrics while preserving the original ambiguity.

Every execution problem contains a specification problem until proven otherwise.

This does not absolve people or AI systems of responsibility. Executors still make mistakes. But before improving the executor, inspect the contract. Ask whether the request contains an intended outcome, a way to test it, the relevant constraints, and enough context to choose intelligently.

The future of work will not belong simply to those who can write the best prompts or attract the most impressive candidates. It will belong to organizations that can translate tacit judgment into usable systems without stripping judgment of its humanity.

A good specification is not a cage. It is an invitation to exercise intelligence in the right direction. It gives a person or an agent enough structure to avoid preventable errors, and enough freedom to discover a better solution than the requester imagined.

The question is no longer only, “Who can do this work?” or “Can the machine generate the code?” The more important question is: Have we made the work clear enough for competence to become visible?