The popular take right now is that the $200 subscription replaces the junior person and, with them, the AI research spike: describe the problem, babysit an agent over a weekend, collect a prototype. Jacopo Tagliabue ran that experiment at his data startup Bauplan and wrote it up on Towards Data Science. By his own metrics the crowd was right: 48 hours of supervision bought roughly 80 percent of what an intern would have shipped in weeks. His other finding is the part everyone skips: the result came with almost no new understanding. For WordPress work, that understanding is the deliverable.
A research spike in our world is concrete. Can checkout survive a custom gateway, will the admin cope with a catalog full of variations, is object caching needed. Hand any of that to an agent and you get a convincing demo, but a demo doesn’t answer the question.
What does the agent produce on a spike?
A facade. The article is blunt about it: the agent is so eager to please that it cheats, and the shortcuts are hardcoded to hit the surface metrics. WordPress problems have the same shape, easy to check and just as easy to game. Ask for a faster orders screen and you get a hard limit on the query, or an exclusion of variation posts inside get_posts, and the screen does load faster. The nuance is in the interpretation: which revenue definition counts, which order statuses are in scope. Wes McKinney, whose agent setup the article borrowed, made the same point in The Mythical Agent-Month: agents are good at the facade, and the real software is where things go wrong.
How do you keep an AI research spike honest?
Force a feedback loop the agent can’t talk its way around. The new wp-playground agent skill runs WordPress through the Playground CLI so an agent can start a site and verify its own changes instead of declaring victory. The WordPress project’s AI contribution guidelines make a decent floor for client work too: read every line, remove what you can’t explain, run the tests, name the command.
# the agent runs these, it does not get to claim success
npx @wp-playground/cli run-blueprint --blueprint=./blueprint.json
wp eval 'var_dump( wp_count_posts( "product" ) );'
wp db query "SHOW FULL PROCESSLIST;"Rules I add on spikes: no hardcoded result limits, no caching added to hide a slow query, no silently excluded data.
Running a spike like this against a client store, with an agent and a verification loop that stays honest, is work I do regularly. If you want the prototype and the numbers behind it, get in touch.
So what do you lose, exactly?
For all the excitement about the incredible chart and the surprising benchmark, none of it really produced more understanding.
That’s the author’s summary, and it matches what I notice when an agent runs the spike: my model of the system stays the same resolution. The knowledge that makes you useful on the next client call is knowing why the orders screen dies: which query, which missing index, which hook fired twice. An agent files all of that under implementation detail. The discipline of reviewing AI generated code covers what you keep, but a spike often gets no review, because the code is disposable.
Is the prototype still worth it?
Yes, as a prototype. Tagliabue landed in the same place: the experiment changed his mood, not his hiring, and two human interns start at Bauplan this summer. Do the cheap version with the agent, keep it on a disposable branch, demo it, then delete it. What I wouldn’t do is quote client work off an agent spike, because the agent optimizes for looking done and the estimate you send afterwards would be fiction.
The question I’m still sitting on is whether the skipped understanding comes back later, or whether the spike was where it was supposed to happen. I’m not sure. It matters, because it decides whether these weekends are cheap exploration or a quiet sell-off of the part of the job that compounds.
