My AI over-engineered everything. So I gave it a ponytail.

A solo developer building ParkEase, a peer-to-peer parking marketplace for India, created a Claude Code skill called "ponytail" that forces AI coding agents to pick the simplest working solution instead of over-engineering. The skill runs an ordered ladder of questions and stops at the first rung that works, while refusing to simplify input validation, error handling, security, or accessibility, and requires a labeled comment wherever a real corner is cut. Applied to deployment, it replaced a proposed OpenTelemetry/Sentry exporter setup with an environment variable pointing the existing exporter at Sentry's OTLP endpoint, and shipped a 20-line launcher to run the API and worker in one container on a free hosting tier.

Ask an AI coding agent for a cache and you'll get a cache class. With a TTL. And an eviction policy. And an interface for the cache, in case you ever want a second cache. And a factory for the interface. AI doesn't get tired, so it doesn't get lazy, and good engineers are lazy in exactly the right way. Every extra abstraction it writes is code I have to read, test, and one day debug at 3am. So ParkEase has a skill called ponytail . It turns the agent into a lazy senior developer who has seen every over-engineered codebase and been paged at 3am for one. It was the slash command I typed most often. Ponytail is a list of questions, asked in order. The agent stops at the first rung that works: <input type="date" over a date-picker library. There's also a matching rule: a bug fix goes at the root cause, in the shared function every caller routes through, not as a guard in the one caller the bug report named. The part that makes it work is what ponytail refuses to simplify: input validation at trust boundaries, error handling that prevents data loss, security, accessibility, anything explicitly asked for. And it never shortens the reading, only the solution. Understand the whole flow first, then be lazy. And when it does cut a real corner, it has to leave a note in the code saying where the ceiling is and what the upgrade looks like. ParkEase has these all over: // ponytail: one participants lookup per booking. A driver completes a handful a week; batch // this if the window or the volume grows. ponytail: one Razorpay call per unreconciled capture. Switch to transfers.all { from, to } when daily volume makes that slow. ponytail: FOREGROUND ONLY. JS timers stop when Android backgrounds the app, so a washer who switches apps stops beating and falls out of dispatch after WASH ONLINE HEARTBEAT WINDOW SECONDS 90s while their switch still reads online. The upgrade path is an expo-task-manager background location task, That's not technical debt hidden in the code. It's technical debt with a label, a reason and a known exit. A companion command can harvest every ponytail: note into a list later. Deployment. The spec for the last task called for observability with an OpenTelemetry SDK, a Sentry SDK, a separate exporter setup. The API already exported OpenTelemetry traces. Sentry accepts OTLP. The lazy answer was zero new code: point the existing exporter's environment variable at Sentry's OTLP endpoint. That's the documented setup; the free demo hasn't needed it switched on yet. The free demo. The free hosting tier has no background workers. The over-built answer is a job-runner abstraction that works in-process or out. The ponytail answer was a 20-line launcher that starts the API and the worker as two processes in one container, and exits the container if either dies so the host restarts it. Docker. The textbook production image uses a slimmed production-dependencies deploy. That needed the workspace packages to ship compiled output first, a refactor across the monorepo. Ponytail shipped the image running TypeScript directly, with a comment naming the ceiling and the exact upgrade path. Ponytail can be too lazy if you let it skip understanding . A small diff in the wrong place isn't lazy; it's a second bug. The rule I leaned on: the ladder runs after you've traced the real flow end to end, never instead of it. Next: why a defined workflow beat clever prompting, and the three times a gate caught something I'd have shipped. ParkEase is a peer-to-peer parking marketplace for India, built solo with Claude Code. Code: https://github.com/Deonkar/parkease https://github.com/Deonkar/parkease