Building with AI has become ordinary.
At first, it wrote code for us. Now it helps shape requirements, implement them, run tests, and respond to feedback. Calling it a product-development partner no longer feels exaggerated.
I have one complaint.
AI took the easy work first. What remains for humans requires judgment, sustained attention, and responsibility when things go wrong. Development became more convenient. Somehow, the human part became harder.
That is not entirely bad. I have learned a little about building products this way, and this article records the workflow I use today.
Begin by interrogating the specification
Before writing code, I ask AI to question the specification.
Product work still begins with people. I listen to the client and other stakeholders, then give that material to the agent. Its first job is not to produce a solution. Its first job is to expose what we have not decided.
I use a skill called grill-me for this stage. It keeps asking questions until the important branches of a plan or design become visible.
The review is deliberately broad:
- Event storming and the domain model
- Aggregate boundaries and state transitions
- Architecture and external systems
- Decision tables and authorization
- Errors, recovery conditions, and error codes
- Open questions and user stories
- Boundary values and failure behavior, not only happy paths
Examples are useful. Boundaries are better. Where does behavior change? Who may perform the action, and under which conditions? Precise answers here prevent drift when the agent later writes the code.
Reduce the specification until the bottom of the pot becomes visible. Do not burn it. Keep the heat steady and return to it often.
Use specifications to support conversation
I move the result into Miro or a similar shared space and review it with stakeholders. Their feedback returns to the agent. We question it again, revise it, and bring it back. The loop continues until the MVP has a clear outline.
Then the work becomes GitHub Issues. My default is one Issue per Pull Request. For backend work, I often aim for a diff of roughly 200 lines or less.
That number is a heuristic, not a quality standard. Frontend markup grows quickly, and generated files distort any line count. The real requirement is narrower: one purpose, a visible impact, and a diff a person can understand without losing the thread.
Code remains the final specification
The document is not the product. It helps everyone share a destination and reach an MVP without avoidable drift. Once implementation begins, code and tests define the behavior that actually runs.
Natural language contains ambiguity. That space gives us emotion and culture. I value it. I do not value the same ambiguity at a boundary involving authorization, billing, or state transitions.
Programming languages remain powerful for that reason. They are strict about executed behavior in a way prose cannot be.
This workflow is not an attempt to replace established product practice with a fashionable new method. It uses familiar practices and repeats them faster with a capable partner. That is enough.
Let AI implement the Issue
Once the decisions are clear, implementation becomes almost plain. Give the agent an Issue number. Ask for a Pull Request.
Human time moves toward review, refactoring, and documentation. We write less code. We do not read less code. In my experience, we read more.
Keep review rules in the repository
I use GitHub Copilot code review as one layer of review. Repository-wide expectations live in .github/copilot-instructions.md: architecture, testing, security, naming, and other checks that should apply repeatedly.
Longer instructions are not automatically better. Prefer rules that can be checked over vague statements about quality. GitHub also notes that AI review is non-deterministic and may not follow every instruction in the same way every time. It is a guide rail, not the final gate.
Put maintenance into the workflow
Workflows under .github/workflows ask whether a Pull Request needs an Architecture Decision Record. Scheduled workflows look beyond static analysis and tests, identify maintenance candidates, and open Issues for later review.
The goal is simple: important questions should appear even when a person forgets to ask them. Stale documentation teaches the agent stale assumptions. Keeping code and documentation current improves the next change as well as the present one.
More of the process can run automatically now. That does not mean every change should merge automatically. A person still reads each Pull Request and checks the behavior in a browser. Authentication, authorization, billing, and destructive data changes receive stricter review.
This is the bottleneck.
It is also a reasonable boundary. The aim is not to place AI at the center. The aim is to build with it. Humans judge intent and experience. AI accelerates exploration, implementation, and repetition. Each side should do the work it does well.
That is why I keep Pull Requests small. Small diffs are not for the agent. They are for the reader.
Human work remains
AI and humans are good at different things. I like that difference.
AI explores a defined space quickly and repeats without fatigue. People decide what deserves to exist, read the need behind an ambiguous request, and judge whether the result feels right as a product. For now, responsibility remains human too.
That is roughly the workflow.
Building together is enjoyable. I remain a little sad, however, that AI took the comfortable work and left the difficult, troublesome parts arranged so neatly on my desk.