I follow Gergely Orosz mostly through The Pragmatic Engineer. His book, The Software Engineer’s Guidebook, also spoke to the part of my career spent trying to understand enterprise promotion, scope, and what companies expect beyond the Senior level.
Gergely is good at asking the right questions. That’s one reason I keep coming back to his work. He doesn’t settle for the polished first answer. He follows up until the full story comes out.
So I was happy to see Matt Pocock join him for the episode “AI Skills with Matt Pocock”.
Matt spent six years as a voice coach before moving into software. He now teaches TypeScript and publishes skills for coding agents, including /grill-me and /to-spec. The voice-coach detail made more sense once he started explaining /grill-me.
Thirty-five questions for one endpoint
The /grill-me skill asks an agent to interview you relentlessly before it starts solving the problem. Gergely tried it on a simple API endpoint. The agent asked him 35 questions.
Thirty-five questions for one endpoint would annoy me too. I can also think of work where five more questions at the start would have saved a painful amount of cleanup later.
I have done this to myself with an agent. Earlier this year, I built a Python prototype and focused almost entirely on getting the correct output. I provided the input specification, the expected output, and the data manipulation rules. I said little about implementation boundaries or code quality.
The result worked. It was also about 1,500 lines in one file, with raw SQL inside the Python and functions longer than 300 lines. I only felt the cost when I returned to the prototype a few days later and had to turn it into something maintainable.
The agent had followed the priorities I gave it. I had made “correct output” clear and left most of the other decisions unstated.
That experience is why the 35 questions landed with me. An agent will fill the gaps in a request because it has to. Confidence in the answer does not mean it filled them the way I would have.
The useful detail often appears after the obvious answer, when one more question exposes the constraint behind it. Matt has turned that follow-up question into a reusable step.
The skill file is the small part
Matt’s public skills repository had about 266K stars when I checked it on 20 September 2026. It is an absurd number for a repository full of instruction files.
The files themselves can be short. They make the agent follow a step that would otherwise be easy to skip.
/grill-me asks for missing decisions before implementation. /to-spec turns the answers into a destination document, and /to-tickets breaks that document into pieces small enough for individual agent sessions.
I recognise this pattern from my own work. I wrote Python coding guidelines for agents after cleaning up that 1,500-line prototype. The bad result showed me which instructions I had failed to give. I wrote them down so I would not have to relearn the same lesson on the next project.
Matt has taken that instinct much further. Some of the most useful instructions in those tools come from old engineering books.
Old books, current agents
My favourite moment in the episode is Matt admitting that his copy of The Pragmatic Programmer sat on his shelf, still in the plastic, for years. He opened it because he was stuck: his spec-driven loops made the code worse on every pass.
In The Pragmatic Programmer, Matt found a name for the alternative: a tracer bullet, one thin working path through the system that shows early whether the pieces fit.
Matt put “tracer bullet” into his prompts and saw the agent use the phrase in its own reasoning. He calls this kind of term a Leitwort. In his workflow, the familiar engineering term did more work than another long explanation.
The phrase still has to match the work. Calling three disconnected layers a “tracer bullet” is cargo cult with a newer toolchain.
The agent does not remember the scar tissue
A term such as “tracer bullet” carries some engineering history into a fresh prompt. Matt compares the new session to the main character in Memento. In his workflow, the agent does not carry forward the memory a human builds while living with a codebase.
Humans can survive a confusing codebase by learning where the strange parts are. We remember which name is misleading, which module should not be touched, and which decision was made during a meeting six months ago. That memory lets us work around problems that the repository itself does not explain.
The next agent session sees the files, the instructions, and whatever context is provided that day.
This made me look at documentation and naming from a less comfortable angle. When an agent repeatedly gets the same part of a system wrong, blaming the model is easy. The codebase may also be relying on knowledge that exists only in a few people’s heads.
This reminded me of the knowledge-silo problem. I have seen an Airflow DAG or Snowflake policy become safe to change only after the one person who knows its history explains it. If that history is missing from the repository, the next engineer has to ask. The next agent can only guess.
A note for my next agent session
That brought me back to why I follow Gergely in the first place. He stays with a question until the polished story becomes concrete. Matt’s /grill-me keeps asking until a request is specific enough for an agent to act on.
My Python prototype gives me a concrete place to try this. I gave the agent the input, the expected output, and the data rules, then left too many implementation decisions unstated.
For the next meaningful change, I want the agent to read the specification and question me before it builds. Then we can choose one thin end-to-end path and make it work.
That may feel slower at first. I can live with that; I have already spent enough time cleaning up fast first answers.