In February, I started working on a full-stack development contract. As a solo developer with a deadline, I’ve felt the pressure to take advantage of AI tooling, not just to improve my speed, but also my capabilities: most of my software development experience has been on the frontend. It’s been a balance of letting AI build without leaving me with cognitive debt. AI is unpredictable and opaque; the past few months have also been about building processes I can trust.
To that end, I’ve been using Matt Pocock’s /grill-me skill a lot.
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
Ask the questions one at a time.
If a question can be answered by exploring the codebase, explore the codebase instead.
A few weeks after I started using it, he published a new version that makes and makes use of context docs, but I like the simplicity and flexibility of the original skill. It’s short, but it’s incredibly useful. I use it whenever I start a new feature, but I also use it to kick off debugging or refactoring sessions.
/grill-me let’s solve issue #38
Good – I've got the full picture. Issue #38 is about adding CAPTCHA to your unauthenticated forms. The primary attack surface is:
POST /api/work-objects– the public form submission endpoint (called from/memberand/advocate)GET /api/plans– public plans listing (lower risk, but still open)- Confirmation endpoints already have HMAC token protection, so less concern there.
Let me grill you.
1. CAPTCHA Provider
The issue mentions two options: AWS WAF CAPTCHA and Google reCAPTCHA.
My recommendation: Google reCAPTCHA v3 (invisible).
Reasoning:
- AWS WAF CAPTCHA requires WAF in front of your app (you'd need CloudFront + WAF, which adds infra complexity and cost). Your CDK infra doesn't appear to have WAF set up currently.
- reCAPTCHA v3 is invisible (no user friction – critical for a Medicare form where users may be elderly), scores requests 0.0–1.0, and is free up to 1M assessments/month.
- reCAPTCHA Enterprise is also an option if you want more control, but v3 is simpler to start.
The tradeoff: Google reCAPTCHA sends data to Google, which could be a concern given your HIPAA posture. However, reCAPTCHA only sees the domain and user interaction patterns – no form data or ePHI is transmitted to Google.
Question: Are you okay with reCAPTCHA v3 (invisible), or do you have a preference for AWS WAF CAPTCHA / reCAPTCHA Enterprise / something else like Cloudflare Turnstile?
/grill-me the plans page takes too long to load
I've explored the page. Before I start grilling, here's the picture I'm working from: PlansPage.tsx:46-54 fetches the plan list and then issues one fetchPlanDetail per plan in parallel (Promise.all), but the UI only renders three fields from each detail: pdfTemplateKey, contactMethods.length, and the name. Everything else in the detail payload (fieldMappings, workObject count) is thrown away.
Question 1 – have you actually measured the bottleneck, or are we inferring from "feels slow"?
I can see the shape of the problem from code alone, but the fix branches hard on where the time actually goes:
- If most time is the N+1 waterfall of detail requests (likely, given per-request auth + Lambda cold starts on each), the fix is to stop making them – enrich the list response with the 2 fields the UI needs.
- If most time is backend query cost on a single
findAll(e.g., a slow_countor missing index), enriching the list won't help much and we need to look at the query plan. - If most time is auth / network RTT on the initial list call, neither of the above matters. My recommendation: open DevTools Network on the admin plans page once, note (a) number of requests, (b) total load time, (c) slowest individual request's waterfall. If detail requests dominate, we proceed down the "enrich the list" branch. If a single request dominates, we pivot.
Have you measured – and if so, what did you see? If not, can you grab a Network HAR (or just eyeball it) before we pick a fix?
I usually start it with a reference to an issue or a brief description of what I want to build, but I’ve also started it with longer specs, or even an excerpt (or screenshot) of my notes from a client meeting.
When you send the initial message with /grill-me, it will come up with a list of questions and start asking you one by one. If your answer to a question necessitates a follow-up question, it will ask that. For each question, it will present two or three choices.
/grill-me provides a recommended answer for each question. This actually wasn’t a part of the first version of this skill, but it’s a welcome addition. I usually end up going with the recommended answer, which means that /grill-me is largely a way to force AI to think deeply and in a structured way (walking down the branches of a design tree) and to make that thinking transparent to me. In the process of presenting choices and its recommendation, the AI is explaining what it sees to me, closing the gap between its decisions and my understanding.
/grill-me feels profound to me because it inverts control. It is no longer me that is utilizing the AI to facilitate my thought process; I have asked AI to control the thought process and use me to fill gaps. Using /grill-me feels like more than the usual concession to AI: not just admitting that I don’t know how to do something, but accepting that I don’t even know what I want to do.
I can feel myself working less when I use /grill-me. I give it a one-line prompt and it takes over, reading the codebase and organizing the planning session for me. I don’t always think critically about the questions that the AI is asking or ask it follow-up questions myself. I trust it because the structure I gave it, and that it mirrors back to me, makes it seem confident, more than it did when it was spitting out plans in one go. It is indeed better than plan mode, much better, but I’m also surprised to find myself really wanting to put my trust in it.
I think this inversion of control is where agentic coding will go. First, we prompted AI directly. Then, we used plan mode to have AI generate plans, which we then reviewed and iterated on. With /grill-me, we tell AI to own the planning process, but we still own the overall development cycle (we choose when and what to plan). But I can see a world where we kick off a project and then AI owns it, only delegating decision points to us that it thinks come down to our taste.
Like everything with AI, it sounds both like a miracle and a threat.