Sample content: This article exists to exercise the publishing system. It is not presented as Patrick’s writing.

Work with AI Without Outsourcing Your Judgment

A sample field guide to using AI for leverage while keeping problem framing, trade-offs, verification, and accountability in human hands.

A machine producing several candidate components while a hand tests and adjusts one before integration
Generation creates options; judgment connects one option to a real product and its consequences.AI-generated editorial illustration.

AI can make the production of plausible work dramatically cheaper. It can draft code, explore unfamiliar APIs, summarize a repository, generate test cases, and keep working through mechanical details without losing patience.

That leverage is most valuable when it expands what a thoughtful builder can attempt. It becomes risky when plausible output is mistaken for a transferred responsibility.

Before asking for implementation, describe the user, constraint, and outcome. An agent can propose ways to add caching, but it cannot decide whether stale data is acceptable without product context. It can build an analytics event, but it should not choose what user behavior deserves collection.

Problem framing includes deciding what not to build. Fast generation increases the number of solutions available; it does not make every solvable problem worth solving.

Ask the agent to inspect reality before prescribing a design. Repository conventions, existing tests, runtime constraints, and neighboring components are evidence. A detailed answer based on an imagined system is still wrong.

One useful pattern is to request alternatives before a patch:

text
Inspect the current implementation and identify the actual constraint.
Propose two or three viable approaches.
For each, explain accessibility, maintenance, performance, and migration trade-offs.
Recommend one approach and state what evidence could change the recommendation.
Do not edit files until the comparison is grounded in the repository.

This does not require ceremony for every small task. It is valuable when the first obvious implementation could create a durable product or architecture commitment.

AI can also challenge a preferred approach. Ask which assumption is weakest, what failure mode is missing, or how the solution behaves under a constraint the happy path ignores. The goal is not adversarial debate; it is avoiding premature certainty.

Review effort should follow risk. A generated rename needs different scrutiny than authentication, data deletion, billing, accessibility, or a public API.

Verification can include:

  • reading the complete diff rather than a summary;
  • running focused tests and a clean production build;
  • inspecting generated HTML, requests, or data transformations;
  • exercising keyboard and failure paths in a browser;
  • checking current primary documentation for changing APIs;
  • obtaining domain review for legal, security, financial, or medical consequences.

Do not let a test suite make a claim broader than its coverage. Passing tests show that tested behavior passed in that environment. Judgment connects that evidence to the actual release decision.

Generated code should look like it belongs in the repository. Clear names, ordinary patterns, focused dependencies, and documentation at real boundaries make future work possible without the original conversation.

If the agent creates a large abstraction to solve a small task, ask whether the abstraction serves the system or merely made generation easier. If it cannot explain a surprising line, slow down. Speed gained during creation can be lost many times during debugging.

Delegating syntax does not require delegating understanding. Use AI to explain unfamiliar code, compare models, generate experiments, and expose gaps in a mental model. Then test those explanations against the system.

The enduring skill is not typing every line unaided. It is maintaining a reliable connection between intent, implementation, evidence, and consequence.

AI can carry more of the mechanical load. The builder still owns where the system is going and whether it is safe, useful, and worth maintaining when it arrives.