JP Jason Pollard

AI engineering

AI accelerates the work. It does not own the decision.

I use AI throughout the software lifecycle to inspect systems, clarify ambiguous work, generate and revise implementation, test assumptions, investigate failures, and document operational reality. The output remains subject to human judgment, verification, and ownership.

My current tools include GitHub Copilot in VS Code for production engineering, ChatGPT for architectural and product collaboration, and OpenAI Codex for repository-grounded implementation.

Operating principle

Generated output is a draft, not a decision.

Governing standard

The standard is owned software.

AI can inspect, propose, implement, test, and explain. I remain responsible for the architecture, semantics, security boundaries, evidence, and final result.

Read the Owned Software Manifesto

Applied, not ornamental

Useful across the delivery path.

AI is most valuable when it is grounded in the codebase, contracts, constraints, and evidence already present.

Architecture, implementation, and review

A deliberate division of labor.

Different tools support different parts of the work. None of them inherits accountability for product or engineering decisions.

ChatGPT

Frames problems, questions assumptions, compares approaches, shapes implementation plans, reviews evidence, and helps create bounded prompts.

Codex

Works against the repository: inspects code, makes scoped changes, runs verification, and reports exact results.

GitHub Copilot

Supports close-to-code production work in VS Code: inspection, refactoring, implementation, tests, and review.

Jason

Owns the problem definition, constraints, architecture, semantics, security boundaries, decisions, corrections, and shipped result.

Inspectable handoffs

Move context through artifacts, not conversational memory.

Repository archives, review packets, and markdown handoffs act as the shared surface between architectural discussion and implementation. They preserve constraints, decisions, evidence, and unresolved questions so each iteration can be reviewed against the actual system rather than remembered impressions.

Review loop

A disciplined path from context to confidence.

The work is iterative: ground, clarify, plan, implement, review, correct, and document.

  1. 01Ground the task in repository evidence and real constraints
  2. 02Clarify ambiguity and expose open questions
  3. 03Produce a bounded plan or prompt
  4. 04Implement incrementally
  5. 05Review diffs, tests, and behavior
  6. 06Correct errors and challenge assumptions
  7. 07Document the resulting operational reality

Examples from real work

Reduce ambiguity and mechanical effort without outsourcing judgment.

Example: feature-flagged UI spike

Turn an underspecified integration into testable work.

For a production UI integration spike, I broke an ambiguous story into explicit steps and open questions. AI helped inspect API shapes, exercise parameter combinations, and validate data paths involving APIs and Azure Blob Storage before implementation.

The value was not a burst of generated code. It was faster clarification, broader validation, and a smaller set of unknowns entering implementation.

Example: resolving an AI planning review

Turn review questions into accountable decisions.

I exported a pull request and its review questions into a Markdown working document, used AI to inspect the plan and draft responses, revised the answers with project context and engineering judgment, updated the plan, and responded directly to each review comment.

AI reduced the mechanical effort; I reviewed and owned every decision.

Example: reducing decision friction

Give reviewers a concrete decision surface.

For unresolved technical questions, I use AI to generate candidate answers, present explicit options, and propose a default or recommendation. Reviewers can approve, revise, or discuss something concrete instead of starting from a blank page.

The goal is not to automate judgment. It is to remove avoidable friction around exercising it.