// WORKSHOP
Develop Agency in Agentic Development
Friday 2nd October 2026 · 09:00–15:00 CEST · Lystrup, Denmark
I’m running a hands-on workshop for developers who want more agency over how they work with coding agents. Not just better prompts, but better judgment, feedback loops, and ways to decide what the agent should do next.
My colleagues and I will be on hand for individual coaching & problem-solving, so you leave with a better workflow than the one you arrived with.
// FROM THE FIELD
I kept making the same corrections in my agent chats: do less, reuse what is already there, keep the plan aligned with the actual task, and stop returning speculative work.
Ask for a date input and they may install a picker library. Request a small feature and they may return an architecture design. Ask them to update a plan and they may add phases for work nobody requested.
LLMs are text prediction machines. Given they tend to reinvent the wheel (or at least write a long essay about doing so). The best way to correct that is a skill called Ponytail.
The best code is the code never written.
// WHAT IT DOES
Ponytail gives a coding agent a simple ladder:
Does this need to exist?
Is it already in the codebase?
Does the standard library do it?
Does the platform already provide it?
Can an installed dependency do it?
Can it be one line?
Only then: write the minimum new code.
It is lazy about the solution, not about understanding the problem. It still reads the real flow, fixes root causes, validates trust boundaries, handles errors that prevent data loss, and keeps security and accessibility intact.
// THE SAVINGS
Ponytail’s Haiku 4.5 benchmark ran 12 feature tickets four times each in a real FastAPI + React repository. Compared with the same agent without Ponytail, it wrote 54% less code, used 22% fewer tokens, cost 20% less, and finished 27% faster.
The average hides the interesting part. Where there was room to overbuild, a date picker dropped from 404 lines to 23 and a colour picker from 287 to 23, mostly by using native inputs. Where the existing solution was already small, Ponytail changed almost nothing.
It also passed 20 out of 20 runs across five adversarial security checks. That isn’t proof that it makes every implementation safe; it shows that writing less did not mean throwing away the safeguards being tested.
// PONYTAIL VS CAVEMAN
People ask: are they similar?
Caveman shrinks what the agent says; Ponytail shrinks what it builds.
They work on different halves of the problem. Caveman keeps the conversation terse. Ponytail keeps the implementation small. You can use both.
// TRY THIS
I use Ponytail for two things:
Refining a plan down to the bare minimum that I want, cutting out the extra bloat the agent thought was needed: legacy support for an unreleased project; configuration options up the wazoo; tests for the bloody tests.
“What parts of this project are over-engineered? Use Ponytail to assess” to fix the times I did not do the above. Sometimes it was easier to approve the agent than to nitpick the work, and the project got bloated as a result.
Reply and tell me: does your agent over engineer everything? How have you handled it so far?
— Jordan
If this was useful, share it. Refer three readers and you will receive a single-use voucher for 20% off the workshop.