AI took the easy work first. What it left on my desk requires judgment, sustained attention, and responsibility when things go wrong. Development got more convenient, and the human part got harder.
At first it only 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, complaint aside. I have learned a little about building 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 to expose what we have not decided, not to produce a solution.
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.
skills/skills/productivity/grill-me/SKILL.md at main · mattpocock/skillsSkills for Real Engineers. Straight from my .agents directory. - mattpocock/skills
github.com
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 help, but boundaries are what matter. 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 is visible, at a heat that does not burn it.
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, and 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, and that space gives us emotion and culture. I value it, though not at a boundary involving authorization, billing, or state transitions. Programming languages 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 and ask for a Pull Request.
Human time moves toward review, refactoring, and documentation. We write less code and, in my experience, read more of it.
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 that the important questions 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, and it is also a reasonable boundary. The aim is to build with AI rather than place it at the center. Humans judge intent and experience while AI accelerates exploration, implementation, and repetition. Each side does the work it does well.
That is why I keep Pull Requests small. Small diffs are for the reader, not the agent.
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.