AI Product / Technical Lead
AI Is A Tool, Not The Product Strategy
I use AI extensively.
I also do not trust it blindly.
Those two statements belong together.
The value of AI in product development is not that it can generate more output faster. The value is that it can expand what a person or team can explore, analyze, prototype, test, and deliver—provided someone remains accountable for determining whether the output is actually correct.
My approach is therefore not “ask AI to do the work.”
It is to define the problem, establish constraints, give the system appropriate context, evaluate what comes back, correct it when necessary, and verify the result against reality.
AI accelerates the loop.
It does not eliminate responsibility for the outcome.
From Prompting To Orchestration
Building djamespoer.com has become an experiment in a different kind of software development.
Rather than working with a single AI assistant, I have been coordinating multiple AI systems with different roles in the product process.
One may concentrate on implementation and repository evidence. Another may work through product, UX, content, or creative decisions. Their output can be independently compared before a decision is accepted.
My role increasingly resembles the person coordinating a cross-functional team.
I establish the objective. I provide context. I define acceptance criteria. I assign work. I review the result. I challenge unsupported assumptions. I send work back when it is wrong. And I decide what reaches production.
The interesting skill is no longer simply prompting.
It is orchestration.
Different Agents Can Play Different Roles
AI systems do not have to perform identical work.
A useful workflow can deliberately assign different responsibilities.
An engineering-focused agent can inspect implementation details, tests, repository state, and deployment evidence.
A product-oriented agent can concentrate on requirements, user experience, content, prioritization, and whether the work solves the intended problem.
For creative work, multiple agents can independently interpret the same approved brief. Their results can then be compared, critiqued, and synthesized into the next iteration rather than accepting whichever image happened to be generated first.
That separation creates useful tension.
Agreement can increase confidence.
Disagreement exposes something worth examining.
Context Is Infrastructure
AI output is highly dependent on the context surrounding the task.
That makes context management an engineering problem.
Requirements need to survive between conversations. Decisions need durable records. Approved copy needs to remain distinguishable from drafts. Evidence needs a source of truth. Handoffs need enough information for the next agent to work without reconstructing the entire project from memory.
On djamespoer.com, Jira, Git history, repository documentation, tests, production evidence, and structured handoffs all contribute to that context layer.
This is not administrative overhead added around AI.
It is part of the system that makes AI-assisted work dependable.
An agent with incomplete context can produce an extremely polished wrong answer.
Acceptance Criteria Matter More With AI
AI is very good at filling gaps.
That is useful when exploration is the goal.
It can be dangerous when precision is the goal.
If requirements leave room for interpretation, an AI system may confidently invent the missing decision and continue.
Clear acceptance criteria constrain that behavior.
They establish what must remain unchanged, what can change, what evidence is required, what counts as complete, and what should happen when something unexpected occurs.
The tighter the boundary around the task, the easier it becomes to distinguish useful initiative from unwanted invention.
That makes familiar product and engineering disciplines even more important in AI-assisted development, not less.
Make The Agents Show Their Work
A generated answer is not evidence that the task was completed.
When an implementation is handed off, I want the receipts.
Which files changed?
What tests ran?
Did the complete suite pass?
Did the production build succeed?
What commit was created?
Did that exact SHA deploy?
Does production actually serve the expected result?
What remains for a human to inspect?
This turns an AI interaction from “the agent says it worked” into an auditable delivery process.
The same principle applies outside code.
Career claims should be grounded in source material. Design decisions should be connected to requirements. Research should distinguish evidence from inference.
AI can participate in the work.
It should not become the source of truth simply because it produced the sentence.
Independent Work Can Improve The Result
One of the more useful experiments in this project has been allowing multiple AI systems to solve the same problem independently.
For creative work, each system can receive the same frozen design brief and produce its own interpretation.
The outputs are then compared rather than averaged blindly.
What did each interpretation understand correctly?
What did it miss?
Which ideas are worth preserving?
Where did several systems independently reach the same conclusion?
The next brief can incorporate those observations and repeat the process.
That creates an iterative design loop in which AI provides alternatives while human judgment controls convergence.
The goal is not consensus between machines.
The goal is a better product.
AI Needs Review, Not Deference
AI can be remarkably capable and remarkably wrong within the same task.
It can misunderstand a requirement, use stale context, invent evidence, modify something outside scope, or confidently solve a different problem than the one assigned.
The appropriate response is not to stop using AI.
It is to design workflows that expect those failure modes.
Constrain the task.
Preserve source material.
Compare the result to acceptance criteria.
Run the tests.
Inspect the diff.
Check production.
Reject unsupported claims.
When necessary, throw the result away and start again from the approved source rather than repeatedly patching a corrupted direction.
Human review is not a temporary inconvenience we tolerate until AI becomes better.
It is part of responsible AI product design.
Automation Should Remove Repetition, Not Judgment
AI and automation are especially useful for work that is repetitive, searchable, comparable, or evidence-heavy.
They can help inspect repositories, organize research, identify patterns, prepare drafts, evaluate alternatives, maintain backlogs, and assemble verification evidence.
That frees human attention for the decisions where judgment has the most value.
What problem should we solve?
Which tradeoff is acceptable?
Is this claim actually supported?
Does this experience make sense?
Is the design distinctive or merely novel?
Is the product ready to ship?
Automation should reduce the cost of reaching those questions.
It should not pretend the questions no longer need to be answered.
AI Changes The Shape Of Technical Leadership
As AI becomes more capable, technical leadership becomes less about personally typing every line and more about maintaining coherence across the system.
Someone still has to understand enough engineering to recognize a dangerous implementation.
Someone still has to understand UX well enough to recognize a technically correct but unusable experience.
Someone still has to understand the business problem well enough to know whether the team is solving the right thing.
And someone still has to decide what gets shipped.
AI increases leverage for people who can operate across those boundaries.
That is where my background in UX, front-end engineering, accessibility, product thinking, and technical leadership becomes particularly useful.
Innovation Requires Experiments
Not every AI idea deserves to become a product feature.
Some should remain experiments.
djamespoer.com gives me a production environment where I can test ideas about agent orchestration, AI-assisted development, structured handoffs, evidence management, automated analysis, content generation, and human-in-the-loop workflows.
Some experiments succeed.
Some reveal limitations.
Both outcomes are useful if the result is captured and incorporated into the next decision.
Innovation is not demonstrating that a new technology can do something.
It is discovering where that technology creates enough value to justify changing how we work.
What This Perspective Demonstrates
I am interested in AI because of what it can enable, not because adding AI automatically makes a product innovative.
I use it as a collaborator, accelerator, researcher, critic, generator, and implementation partner while maintaining human ownership of requirements, evidence, quality, and production decisions.
I structure work so that agents can operate independently without becoming authoritative simply because they produced an answer.
I compare outputs. I preserve source material. I define acceptance criteria. I demand evidence. I verify production.
The result is not autonomous software development.
It is human-directed, AI-amplified product development.
That distinction matters.
Technologies & Practices
AI Product Development · Agent Orchestration · Human-in-the-Loop Systems · Prompt & Context Engineering · Multi-Agent Workflows · AI-Assisted Software Development · Structured Handoffs · Acceptance Criteria · Evidence Management · Independent Evaluation · Comparative Synthesis · AI-Assisted Research · AI-Assisted Design · AI-Assisted Engineering · Automated Testing · Git · GitHub · Jira · Angular · Production Verification · Technical Leadership