Developing With AI: From Prompt to Pull Request
An introduction to a practical AI development system built around scope, context, verification, review, and durable reasoning.
AI-assisted development is no longer just autocomplete.
It can help shape issues, inspect repositories, edit files, run commands, write tests, review diffs, and summarize decisions. In the right workflow, that is a real advantage. In the wrong workflow, it turns software development into a private trail of chats, patches, and explanations that nobody else can inspect later.
The question is not whether AI can write code.
The question is whether a team can trust the path from prompt to pull request.
The tool is not the system
ChatGPT, Codex, Claude, Claude Code, and whatever comes next are tools. Some are better for planning. Some are better for repository-aware implementation. Some are better for terminal-first investigation. Some are useful as review scanners.
But the tool itself is not the development system.
The system is everything around it:
- how work is scoped
- how repo context is provided
- how permissions are controlled
- how changes are verified
- how review is performed
- how reasoning is preserved
- how the final decision reaches the team
Without that system, AI can make a developer feel faster while making the organization less informed.
Private chat habits do not scale
A developer can have a useful AI session and still leave the company with almost nothing durable.
The chat may contain the problem statement, rejected options, assumptions, risks, and test reasoning. The commit may contain only the result. The pull request may say "updated validation." Six months later, someone has to reverse-engineer why the change exists.
That is not an AI problem by itself. Teams lost reasoning before AI too.
AI just makes the loss easier because more thinking now happens in temporary, personal workspaces.
If the reasoning matters, it has to move into the repository system: issues, pull requests, architecture decision records, tests, runbooks, and project docs.
AI makes discipline more important, not less
When code is cheaper to draft, review becomes more important.
When suggestions are faster, scope becomes more important.
When the tool can run commands, permissions become more important.
When the chat explores architecture, reasoning capture becomes more important.
The point is not to slow the work down. The point is to keep the speed from erasing the trail.
A healthy AI development workflow should answer four questions:
- What exactly are we asking the AI to do?
- What evidence proves the change works?
- What risks still need human judgment?
- Where does the reasoning live after the chat ends?
If those questions are answered, AI becomes easier to use responsibly.
The operating loop
This series uses a simple loop:
Prompt -> Plan -> Patch -> Test -> Review -> Record -> Pull Request
Each step has a job.
The prompt frames the work. The plan makes the direction visible. The patch changes the code. The tests challenge the patch. The review looks for risk. The record preserves the why. The pull request becomes the handoff.
That loop works across tools because it is not built around a product interface. It is built around software delivery.
What this series covers
The series starts with a practical operating model for AI coding tools: useful, fast, incomplete systems that need boundaries.
Then it moves into choosing the right surface for the work. ChatGPT is not Codex. Codex is not Claude Code. A conversational planning session is not the same as a repository-aware patch. A terminal-first investigation is not the same as a pull request review.
From there, the series gets concrete:
- writing prompts like GitHub issues
- preserving reasoning as a company asset
- making repo context explicit
- using a repeatable AI development loop
- delegating real feature work safely
- using terminal-first tools without losing control
- reviewing AI-assisted code as a risk scanner
- turning the whole thing into an AI-ready development system
The product names matter because developers use real tools. The workflow matters more because the tools will keep changing.
The standard is not perfection
AI-assisted development will still produce wrong turns.
That is normal. Human development does too.
The standard is not that the AI must be right on the first try. The standard is that the work remains inspectable, reversible, testable, and explainable.
If a tool helps draft a good patch, use it. If it helps find a bug in review, use it. If it helps summarize an architectural tradeoff, use it. But do not let the useful parts disappear into chat history.
The output should be more than code.
It should be code plus the evidence and reasoning future maintainers need to trust it.
That is the real path from prompt to pull request.
Common mistakes
- Treating the choice of AI tool as the decision, and never building the system of scope, context, verification, review, and reasoning capture around it.
- Measuring AI's value by how fast a developer feels rather than by whether the change can be inspected later.
- Letting the problem statement, rejected options, and risk notes stay in the chat while only the finished patch reaches the commit.
- Writing pull request descriptions like "updated validation" that force the next maintainer to reverse-engineer why the change exists.
- Assuming AI removes the need for review discipline, when cheaper drafting makes review the step that matters most.
Practical checklist
- Every AI-assisted task starts from a written statement of what the AI is being asked to do.
- The change ships with evidence—tests, commands, or output—that proves it works.
- Risks that still need human judgment are named in the pull request, not left implicit.
- The reasoning behind the change lives in the repository system: issue, pull request, ADR, tests, or docs.
- The operating loop—prompt, plan, patch, test, review, record, pull request—is followed rather than skipped under time pressure.
- The output is code plus the reasoning a future maintainer needs to trust it.
- The change is inspectable, reversible, testable, and explainable, even when the AI was wrong on the first try.
Next in the series: AI Coding Tools Are Not Pair Programmers. They Are Junior Systems With Tools. The next part sets the operating model: AI agents are useful but incomplete collaborators that need scope, permissions, tests, and review.
