The faster AI writes code, the faster a project can lose control. The real question is not whether a model can generate functions, but whether it understands the requirement, follows the team’s language, and makes small changes inside the existing architecture.
Matt Pocock’s mattpocock/skills repository points in the opposite direction of casual vibe coding: do not let AI take over the whole development process. Put it inside mature software engineering constraints.
Project: https://github.com/mattpocock/skills
This is not about one magic prompt. It is a set of composable agent skills that turn requirement clarification, domain modeling, TDD, debugging, and architecture review into AI-friendly workflows.
Solve alignment failure first
The most common failure in AI coding is assuming the model understood the request when it merely guessed from a vague sentence.
grill-me flips the interaction. Before writing code, the agent acts like a demanding reviewer and keeps asking about branches, boundaries, and unresolved decisions.
If you ask for a login page, it should first ask:
- How should password reset work?
- Should third-party login be supported?
- What should failed-login errors look like?
- Are account lockout, CAPTCHA, or risk controls in scope?
- Where should the user go after success?
This feels slower, but it prevents expensive rework later. The cheaper code generation becomes, the more costly unclear requirements become.
Write domain language into context
Another common problem is generic vocabulary. The model does not know the team’s business terms, so names and documents drift.
grill-with-docs asks questions while also checking CONTEXT.md, ADRs, and domain docs. Once terms and decisions are confirmed, they can be written back into shared context.
This is close to the “ubiquitous language” idea in domain-driven design. If a team says customer instead of user, or transaction instead of order, the model should inherit that language.
Context documents are valuable because they reduce guessing.
Use TDD to slow down generation
AI is risky because it is fast. Bad code used to take time to write; now hundreds of lines can appear in seconds. The problem is not speed itself, but lack of feedback loops.
The tdd skill brings back red-green-refactor:
- Write a failing test for one behavior.
- Implement only enough code to pass.
- Refactor.
- Continue with the next vertical slice.
The key is one behavior at a time. AI executes, while humans keep control of direction and boundaries.
Debug through a loop
When facing a bug, many agents guess and patch repeatedly until the code becomes messier.
diagnose asks the agent to build a feedback loop:
- Reproduce the issue
- Minimize the case
- Form a hypothesis
- Add observations or logs
- Fix the cause
- Add a regression test
This process is old, but it matters even more with AI. The model is good at trying things; the loop keeps it close to the root cause.
Review architecture regularly
A task passing tests does not mean the codebase is healthier. Repeated AI patches can blur module boundaries, make interfaces more complex, and make tests harder to write.
Skills such as improve-codebase-architecture ask the agent to step back and inspect the whole codebase:
- Are responsibilities mixing across modules?
- Which interfaces are too complex?
- Which paths are hard to test?
- Which names conflict with domain language?
- Which duplicate logic should be merged?
This is not automatic large-scale refactoring. It is structured observation and suggested direction; humans still decide whether and how far to change.
What really needs limiting is freedom
The core idea is simple: AI coding is not about letting the model improvise freely. It is about giving it clear goals, context, tests, and stopping conditions.
Humans define the problem, architecture, tradeoffs, and acceptance criteria. AI generates code, fills in tests, repeats edits, and handles local refactors. Used well, AI amplifies capability; used poorly, it amplifies confusion.
Software engineering fundamentals did not become obsolete because AI improved. Requirement clarity, domain language, TDD, diagnosis, and architecture review are becoming more important.
More people will be able to write code. The gap will be between people who can put AI inside a maintainable, verifiable, evolving engineering system and those who cannot.