DEV Community: Onkar Deokate

4,300 tests, written by an AI: how they were planned, run and enforced

Onkar Deokate — Mon, 02 Nov 2026 04:30:00 +0000

If an AI writes your code, your tests are the only thing standing between "it compiles" and "it's right". So in ParkEase, tests weren't a phase at the end. They were the contract the generated code had to meet.

By the end: 3,246 unit tests and 1,080 integration tests, plus browser end-to-end suites. Here's how they came to exist, and how they were kept honest.

1. Tests first, every time

The build phase of the workflow is test-driven development: write the failing test, watch it fail, write the code, watch it pass. That order matters more with an AI than with a person. An agent writing tests after the code tends to write tests that describe what the code does, bugs included. A test written first describes what the code should do.

2. Every task gets a test plan before it gets code

ParkEase was built as 22 tasks, and each one has an entry in a test registry: what will be tested, at which level, and why. That file reached 2,357 lines. It's what made "is this feature tested?" a lookup instead of an opinion, and it's updated as part of shipping, not afterwards.

3. Real infrastructure, not mocks

Integration tests run against a real PostgreSQL 18 with PostGIS in a throwaway container. No mocked database.

A mock is a second implementation of your database written by the same author, AI or human, with the same assumptions. ParkEase's most important rules live in the database itself: overlapping bookings are refused by an exclusion constraint, the ledger must balance. You can't test those against a mock that doesn't have them.

4. Four suites that can never be red

Four integration suites are mandatory on every change:

booking concurrency: the last slot sells exactly once. One test drops the database constraint and checks that the double-sell comes back, proving the constraint is what's doing the work.
ledger balance: debits equal credits for every transaction.
idempotency: a retried request never charges twice.
search performance: p95 under 200 ms over 10,000 spaces, and the test fails if the query plan stops using the spatial index.

Plus stress tests: 100 drivers racing for 10 slots must produce exactly 10 bookings and 90 clean conflicts, no server errors, p95 under 2 seconds.

5. Test at the level the bug lives

Two lessons became rules after they let defects through:

API tests go through HTTP. Tests that call a command directly skip the guards, interceptors, status codes and error envelopes. Now API tests send real requests through the real stack.
New screens need new tests. The mobile app ended with 1,466 component tests, plus a table-driven test that checks every data screen has a loading, an error and an empty state.

The web and admin apps get Playwright end-to-end runs at phone and desktop sizes, with an accessibility scan on every page.

6. Green locally, before the PR

The last gate before any pull request: lint, typecheck, every unit suite, the four mandatory integration suites, a dependency audit and a secret scan, run locally, with the output pasted into the PR. "CI will catch it" isn't a reason to open early.

Where the tests weren't enough

Two honest gaps.

Fixtures can lie. The first deploy found three bugs that every test agreed with, because the test fixtures and the code shared the same wrong assumption about the API. The fix was making tests use the real response shapes, imported from the shared contracts instead of hand-written.

No phone, no test. The end-to-end mobile flows were written but need a real Android device to run. That gap is logged, not hidden.

Next: harvesting. How every mistake, review finding and deferred idea became a written row somewhere, and the hook that won't let a task finish until it does.

ParkEase is a peer-to-peer parking marketplace for India, built solo with Claude Code.
Code: https://github.com/Deonkar/parkease

The SDLC is turning into an ADLC. Here's what changes.

Onkar Deokate — Sun, 01 Nov 2026 04:30:00 +0000

This one is an opinion, from someone who just built a five-app product mostly by directing an AI. Argue with it in the comments.

I think the software development life cycle we all learned (requirements, design, build, test, deploy, maintain) is turning into something I'd call an AI development life cycle. Not because the phases disappear, but because the weight moves. The phases that used to be expensive got cheap, and the cheap ones got expensive.

Where the effort went

In the SDLC, build is the big phase. Most of the hours, most of the people.

Building ParkEase, build was the fast part. An agent could write a feature in an hour. What took the time was everything around it:

Context. Writing down the rules, decisions and constraints the agent works under, and keeping them current.
Choosing. Picking between rendered design options, reviewing a plan, deciding what not to build.
Verifying. Proving the output was right: tests, reviews, a real build against a real API.
Harvesting. Turning every mistake into a rule so it doesn't happen next session.

The ADLC, as I'd draw it

Context engineering replaces requirements gathering. Requirements still exist, but the real deliverable is the context the agent reads: instruction files, decision records, task files. If it isn't written down, the agent doesn't know it.
Direction replaces design. The human picks from options the AI generates, rather than drawing from scratch.
Generation replaces build. Fast, cheap, and not to be trusted on its own.
Verification replaces testing, and gets bigger. Tests are no longer just checking code someone carefully wrote; they're the contract that generated code has to meet. Evidence before any "done".
Harvest is new. Every session ends by capturing what was learned into files the next session reads. In the SDLC that was a retro once a sprint. In the ADLC it's continuous, because the model forgets everything every time.
Deploy and operate stay much the same, and are where generated code meets reality. My first deploy found three bugs every test had agreed with.

What this means for engineers

If I'm right, the scarce skills shift:

Writing precise constraints matters more than typing speed.
Judgment and taste ("that one, not those two") matter more than producing the first draft.
Verification design (knowing what proves correctness) becomes a core engineering skill, not QA's job.
Systems thinking matters more, because the AI is very good locally and has no idea what your system is supposed to be.

None of that is less engineering. It's engineering with the typing moved to a machine.

Where I might be wrong

One project, one person, one five-week build. On a large team with a legacy codebase, context engineering might be the whole job, and that might not look like a "cycle" at all. And models are improving fast enough that today's verification burden could shrink.

But I'd bet on the direction. The teams that win won't be the ones whose AI writes the most code. They'll be the ones whose AI writes code they can trust, and that's a process problem, not a model problem.

Next: the verification half, in detail. How tests were written, run and enforced, from the four mandatory suites to the race of 100 drivers for 10 slots.

ParkEase is a peer-to-peer parking marketplace for India, built solo with Claude Code.
Code: https://github.com/Deonkar/parkease

12 habits that got more out of AI-assisted development than any model upgrade

Onkar Deokate — Sat, 31 Oct 2026 04:30:00 +0000

People ask which model or which tool. After five weeks building ParkEase with an AI agent, my answer is that the setup around the model mattered more than the model. Here are the habits that made the biggest difference, roughly in order of payoff.

Before you write a line

1. Write the rules down once. One instruction file the agent reads every session: your stack, the five to ten rules that matter most, and what's forbidden. Especially what's forbidden. "Drizzle, NOT TypeORM" saves an argument every single session.

2. Record decisions, not just code. When you decide something structural (money is integer paise; the database enforces double-booking), write a short decision record with the why. The agent will otherwise re-decide it, reasonably and differently, next week.

3. Make it think before it types. A brainstorming step before any feature surfaces the questions the task description didn't answer. It's the cheapest bug you'll ever fix.

While it builds

4. Tests first, real infrastructure. Have it write the failing test, then the code. And run integration tests against a real database in a container, not mocks. Mocks are a second implementation that agrees with your first.

5. Make it read before it guesses. The most expensive pattern I saw was the agent guessing an API, failing, guessing again. One rule ("read the docs and type definitions before writing code against a library") cut whole loops of retries.

6. Ask for the lazy version. AI over-builds by default. A "does this need to exist?" pass before every feature deleted more code than any refactor.

7. Show the UI, don't describe it. For anything visual, make it render two or three options and pick. You'll judge a picture in seconds; a paragraph about a picture, never.

Before you call it done

8. Demand evidence, not adjectives. "Thoroughly tested" isn't evidence. The test command and its output is. Make "verify before claiming done" a fixed step.

9. Review with narrow lenses. "Review this" gets a polite skim. "Find every swallowed error" or "find every query missing an index" finds things.

10. Run the real build, against the real thing, once. Every test in ParkEase was green when three bugs reached the first deploy. Booting the built image and clicking through it found them in minutes.

Across sessions

11. Keep a learnings file. Every fix that cost more than fifteen minutes becomes an entry the agent reads next time. The model has no memory; the repo can.

12. Turn repeated corrections into rules. If you've told the agent the same thing twice, the second time belongs in its instruction file, not the chat. "Never skip visual verification" started as me being annoyed and ended as a gate.

And one anti-habit

Don't parallelise for the sake of it. It's tempting to fan out five agents on every task. Each one rebuilds its context from scratch, and on one task that ate most of a week's usage limit. Use specialists for the diffs that deserve them, not by default.

Next: an opinion piece. I think the software development life cycle is quietly becoming something else, an AI development life cycle, and the parts that grow are not the ones you'd guess.

ParkEase is a peer-to-peer parking marketplace for India, built solo with Claude Code.
Code: https://github.com/Deonkar/parkease

I counted every skill my AI invoked across 55 sessions. Here's the leaderboard.

Onkar Deokate — Fri, 30 Oct 2026 04:30:00 +0000

I had over a hundred skills installed while building ParkEase. Which ones actually pulled their weight?

Instead of guessing, I counted. Claude Code keeps a transcript of every session, so I searched all 55 ParkEase sessions (10 September to 19 October) for every time the agent explicitly invoked a skill.

One caveat up front: this counts explicit invocations only. A skill already loaded keeps shaping the work without being re-invoked, so these are "times it was called on", not "times it mattered".

The leaderboard

Skill	Invocations	What it does
`flow`	28	The project's workflow router: phases, gates, which skills apply
`brainstorming`	17	Settles how before any code
`impeccable`	12	Frontend design critique and polish
`writing-plans`	10	Turns a task into small, checkable steps
`ui-ux-pro-max`	10	Palettes, type pairings, UX guidelines
`postgres-migration-reviewer`	10	Checks every migration for locking and breaking changes
`mobile-app-design`	8	Mobile UI conventions and accessibility
`security-review`	7	Reviews the branch's pending changes for vulnerabilities
`ponytail`	6 (+9 typed by me)	The YAGNI pass: delete before adding

Behind those: test-driven development, archify (architecture diagrams), executing plans and code review.

What surprised me

The router came first. flow doesn't write a line of code. It decides which other skills run. That it topped the list says something: the most-used tool in an AI workflow was the one that sets up the workflow.

Design skills outnumbered code skills. impeccable, ui-ux-pro-max and mobile-app-design together: 30 invocations. A code review can tell you code is wrong; it can't tell you a screen looks generic. The design skills existed because the AI's default UI output was competent and forgettable.

The boring safety net ranked high. Ten migration reviews. Every database migration was checked for things that lock a production table or break running code. No migration review ever made a demo exciting, which is exactly the point.

test-driven-development ranked low by count, high by effect. Only 4 explicit calls, because it was loaded once per build phase and stayed loaded. Its output, 3,246 unit tests and 1,080 integration tests, is the clearest proof that invocation counts undersell the skills that stick.

The specialists

Separate from skills are subagents: single-lens reviewers the agent can dispatch. Ranked by dispatches, the specialists that ran most were the security reviewer, the silent-failure hunter (swallowed errors, empty catches, lost stack traces), the TypeScript reviewer, the test-coverage analyzer and the database reviewer.

The silent-failure hunter is the one I'd recommend to anyone. AI-written code is very good at "handling" an error by catching it and doing nothing, and a lens that only looks for that finds things the general reviewers skim past.

What I'd install first, if starting again

A workflow router for your project (write your own; it's mostly a table).
Brainstorming and a planning skill: think before typing.
Test-driven development.
A verification skill that demands evidence before "done".
One design skill, if anything you build has a screen.
A YAGNI skill like ponytail, to keep the volume honest.

Everything else is situational. And more isn't better: post 13 is about being offered 292 skills and installing 21.

Next: a practical guide. How to get more out of AI-assisted development, from the habits that made the biggest difference here.

ParkEase is a peer-to-peer parking marketplace for India, built solo with Claude Code.
Code: https://github.com/Deonkar/parkease

I put a second AI in front of my AI. It answers in probabilities, not paragraphs.

Onkar Deokate — Thu, 29 Oct 2026 04:30:00 +0000

Most of this series is about one AI: the coding agent that wrote ParkEase. This post is about a different kind of model, and an experiment in putting it in front of the coding agent.

The model is Jev, from TypeSafe. It's what they call a System One model: instead of generating prose, it answers a question with a typed judgment and a probability. A yes/no comes back as a number between 0 and 1. A pick from a list comes back as a choice plus a probability for every option. A rating comes back as a score.

That makes it a different tool from a chat model. You don't parse its answer; you branch on it.

The two hooks

Claude Code lets you run a script every time you submit a message. I built two of these hooks, with Jev doing the deciding.

A model router. Not every message needs the biggest model. "Rename this variable" and "design the payout reconciliation" deserve very different horsepower. The router asks Jev one question with four described options: is this message tiny (a lookup or rename), everyday (a routine single change), large (a multi-step build or a feature across files), or hardest (strategy, or anything where a wrong call is expensive)? Each size maps to a model, from the smallest to the strongest. Jev returns its pick and a probability for each.

A skill picker. Given my message and the list of installed skills, which one fits? Same shape of question, a choice over skills, a probability on each.

The parts that made it trustworthy

A router that guesses wrong is worse than no router. So the design leaned hard on Jev's numbers:

A confidence floor. If Jev's top pick is below 60% sure, the hook stays quiet. No suggestion beats a coin-flip suggestion.
It fails open. Any error, timeout or malformed answer, and the hook outputs nothing; the message reaches the coding agent exactly as if the router weren't installed. It gets a 2.5-second budget, then gives up.
Every answer is validated. The response is checked for the right type, a known option, and real probabilities before anything acts on it.
It suggests, it doesn't override. The workflow's gates always win. Money, ledger, migration and auth work stays with the main model regardless of what the router says.
It never logs what I typed. Only the decision and its numbers.

Off by default, on purpose

Both hooks are switched off unless I say "router on" or "skill picker on". While they're on, every message I type goes to a third-party API. That's fine for building a parking app in public. It isn't fine for anything private, so the default is off.

Cost was handled by construction, not discipline: the account runs on a small prepaid credit with no card attached. If it runs out, the hooks fail open and nothing gets billed.

What it didn't do

Honesty, because this series is supposed to be useful.

Jev was also approved for use inside ParkEase's API and job worker, for small judgment features such as sorting support tickets. That never shipped. The product has no Jev calls today. Its real contribution was to the development workflow, not the app.

And the router's value isn't that it picks better than I would. It's that it makes the choice explicit and cheap on every message, without me having to think about it.

The takeaway

There's a whole category of decisions in AI-assisted development (which model, which skill, is this risky, is this done) that don't need a paragraph. They need a calibrated yes, no or pick. Putting a small judgment model in front of a big generative one is cheap, fast, and easy to keep honest, as long as it fails open and you respect its uncertainty.

Next: I counted every skill the AI actually invoked across 55 sessions. The top of the list wasn't what I expected.

ParkEase is a peer-to-peer parking marketplace for India, built solo with Claude Code.
Code: https://github.com/Deonkar/parkease

learnings.md: how I gave an AI with no memory 246 memories

Onkar Deokate — Wed, 28 Oct 2026 04:30:00 +0000

Here's a pattern that'll be familiar if you've coded with an AI agent for more than a week.

Monday, it hits a strange error. It tries six things, finds the real fix, and you move on. Thursday, a new session, the same error. It tries the same six things in the same order.

The model doesn't remember Monday. It never will. Every session starts from zero.

So ParkEase has a file called learnings.md, and the first instruction in the project file is to read it before every task. By the end of the build it had 246 entries across 1,550 lines.

What goes in it

Not documentation. Not "how the system works"; the code and the architecture records cover that. learnings.md holds one specific kind of knowledge: non-obvious fixes that cost real time to find.

Each entry is a heading that states the lesson, then the symptom, the cause and the fix. A few real ones:

React version alignment is mandatory. When workspace packages use different React versions, pnpm hoists the newer one to root. Packages depending on the older version get nested copies in their own node_modules, causing the classic "two React instances" crash at runtime.

A Metro dev server degrades after repeated reloads, and looks exactly like a broken app. A few navigations in, every route rendered an empty root with zero console errors.

That second one is worth its weight in gold. Without it, an AI sees a blank screen with no errors and starts "fixing" code that isn't broken.

pip install --user for a dev tool broke three unrelated tools. It put 47 packages into the shared user site-packages and shadowed the system copies of three libraries.

A tool installer will rewrite your context files — diff before trusting it. One installer wrote into the root CLAUDE.md, created a second context file, registered two hooks and edited .gitattributes.

Read the headings alone and you get a map of every trap the project fell into.

The rules that keep it useful

A 1,550-line file could easily become noise. Four habits kept it sharp:

1. Title it as the lesson, not the topic. "Metro" is a topic. "A Metro dev server degrades after repeated reloads, and looks exactly like a broken app" is a lesson; reading the heading alone is enough.

2. Write the symptom the next person will actually see. "Empty root, zero console errors" is what you'd search for in the moment. Nobody searches for the cause; they don't know it yet.

3. Group by surface. pnpm, TypeScript, NestJS, Expo, testing, migrations, the agent harness itself. The AI reads the sections that touch its task.

4. Write it when it happens. Not at the end of the task, when the details are gone. A hook enforces this (post 12): a complex task that never touched the learnings file isn't allowed to finish.

Why this beats "the AI will figure it out"

It will figure it out, every time, at full price. A learnings entry turns a 40-minute debugging session into a 4-second read. Across a five-week build, that compounds into days.

There's a second effect I didn't expect: the file made the AI more cautious in the right places. An entry like "the graph answers what calls what, never what we're allowed to do" doesn't fix one bug; it stops a whole class of confident mistakes.

Start yours today

You don't need a framework. A markdown file, one line in your agent's instruction file saying "read learnings.md before every task", and the discipline to add an entry every time something costs you more than fifteen minutes.

Next: Jev, a model that answers with typed judgments instead of prose, and how I put it in front of my own prompts to pick the model and the skill. Honestly, including what it didn't do.

ParkEase is a peer-to-peer parking marketplace for India, built solo with Claude Code.
Code: https://github.com/Deonkar/parkease

A defined workflow beat every clever prompt I wrote

Onkar Deokate — Tue, 27 Oct 2026 04:30:00 +0000

When I started ParkEase I spent a lot of energy on prompts. Long ones. "You are a senior engineer who…", step lists, examples, warnings in capitals.

They helped for about one session.

The thing that actually changed the quality of the AI's output wasn't a better prompt. It was a workflow the AI couldn't talk its way around: fixed phases, named gates, and a rule that skipping one had to be said out loud. Here's why that works better, and three times it caught something I'd have shipped.

Why prompts don't scale

A prompt is a request. The model weighs it against everything else in its context, including its own momentum toward "done". Late in a long session, "remember to run the security review" competes with a nearly finished feature and a model that would very much like to report success.

A workflow is different in three ways:

It's the same every time. I don't have to remember to ask for tests; the build phase is "tests first".
It's specific at the moment it matters. The verification instructions load when the agent is about to claim it's done, not 40,000 tokens earlier.
It produces evidence, not assurances. The ship phase is a table: each line has a command, an output, a pass. A prompt gets you "I've thoroughly tested this". A gate gets you the test output.

Three times a gate caught it

1. The palette that failed accessibility. The design gate made the AI render three visual directions before building screens; I picked one, called Wayfinder. It came with a vivid cobalt and a vivid green. A token test then computed every colour pair against white: the vivid cobalt measured 4.10:1, the green 3.77:1, both under the 4.5:1 minimum for normal text. Fourteen-pixel button labels would have failed. The fix was a two-tier palette: darker tones for anything with text on it, the vivid ones only for map pins and large fills that carry their own label. Now a palette change that breaks contrast fails a test before anyone sees it.

2. The checkout page that could run another user's code. Payments open Razorpay's checkout in a WebView. The first version built the checkout page by putting the booking details, including the space title, into a script block. Space titles are written by owners. Then a test tried the nasty case, a title containing </script><script>…, and it broke out of the block. That's cross-user script injection, in the payment path. The fix wasn't better escaping; it was never putting another user's text into a document we build at all. The values now travel through the WebView's typed channel.

3. The security control that protected nothing. An earlier version of that same checkout file exported an origin allowlist, with a test proving it was all-Razorpay. It was never wired to the WebView. The security review pass caught it. The comment it left behind is the most useful sentence in the file:

A control that is defined, tested and unused is worse than no control: the test reads as assurance and there is none.

None of these needed a smarter model. They needed a step where someone, or something, was required to look.

What a workflow costs

It isn't free. Every gate is tokens, and gates that dispatch separate reviewer agents are a lot of tokens. I learned that the expensive way (post 14). And it adds latency: a two-line fix still passes through verify.

The trade is worth it for one reason. With AI, producing code is cheap and trusting it is expensive. A workflow moves effort from the cheap side to the expensive side.

Next: a 1,550-line file of mistakes. How learnings.md gave an AI with no memory a memory, and the entries that saved the most time.

ParkEase is a peer-to-peer parking marketplace for India, built solo with Claude Code.
Code: https://github.com/Deonkar/parkease

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

Onkar Deokate — Mon, 26 Oct 2026 04:30:00 +0000

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.

The ladder

Ponytail is a list of questions, asked in order. The agent stops at the first rung that works:

Does this need to exist at all? Speculative need means skip it, and say so in one line.
Is it already in this codebase? Reuse the helper three files over.
Does the standard library do it?
Does a native platform feature cover it? A database constraint over app code; <input type="date"> over a date-picker library.
Does an already-installed dependency solve it?
Can it be one line?
Only then: the minimum code that works.

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.

It isn't "cut corners"

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.

Where it earned its keep

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.

Where it needed a leash

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

SKILL.md, CLAUDE.md, and why my repo has no AGENTS.md

Onkar Deokate — Sun, 25 Oct 2026 04:30:00 +0000

An AI coding agent starts every session knowing nothing about your project. No memory of yesterday, no idea that you banned floats for money, no clue the API runs on Fastify and not Express.

Whatever it needs to know, it has to read. So the files it reads became the most important code in ParkEase that isn't code.

There are three kinds.

1. CLAUDE.md: the project's constitution

Claude Code loads a file called CLAUDE.md from the repo root into every session automatically. Mine is short on prose and long on rules. The core of it is a section called "The ten rules that matter most":

1. Money is integer paise, and the ledger is the truth.
2. Controllers authorise and delegate. Nothing more.
3. One transaction per write, with the outbox inside it.
4. Never call an external service inside a transaction.
5. The database enforces invariants the application cannot be trusted with.
...
10. Loading, error, and empty on every screen.

Plus the stack (and what it's not: "Drizzle ORM, NOT TypeORM", "NestJS on Fastify, NOT Express"), the code layout, a "Don't" list, and the commands.

The "NOT" lines matter more than they look. A model's prior is the average of the internet. Ask for a NestJS validation layer without saying otherwise and you'll get class-validator, because that's what most tutorials use. One line in CLAUDE.md moves the default.

The file also sets the order of authority: the architecture decision records override the rules, which override the product spec. When a tool's advice contradicts a decision record, the decision wins, and the AI has to say so out loud.

2. SKILL.md: instructions that load on demand

You can't put everything in CLAUDE.md; it would be enormous, and most of it irrelevant to any one task. Skills solve that.

A skill is a folder with a SKILL.md inside. The top of the file is a name and a description:

---
name: flow
description: "Use when working on ParkEase — any of its 22 tasks, or any"
  feature, bugfix, refactor, review, UI or motion work...
---

The agent sees only the descriptions until a task matches one; then it loads the whole file. So the description is effectively a trigger, and writing a good one ("use when…", naming the situations) matters more than the body.

ParkEase used two layers: general skills installed for every project (brainstorming, test-driven-development, systematic-debugging, verification-before-completion, the design skills), and project-local skills in .claude/skills/ that only exist inside this repo, like a delivery gate and a curated set of stack-specific skills (Postgres, Redis, Docker, error handling). On top sat flow, a routing skill that says which skills apply at which phase for which part of the stack.

3. Agent files: specialists with one lens

.claude/agents/ holds subagent definitions: a security reviewer, a TypeScript reviewer, a database reviewer, a test-coverage analyzer, and my favourite, a "silent failure hunter" that only looks for swallowed errors, empty catch blocks and lost stack traces. Each is a markdown file with a focused prompt and a restricted toolset.

They turn "review the code" into several narrow reviews. More on how that went, including the bill, later in the series.

Why there's no AGENTS.md

AGENTS.md is becoming a cross-tool convention for exactly what CLAUDE.md does. I considered adding one, and decided against it, in writing, so the AI wouldn't keep re-proposing it:

CLAUDE.md is the single source of truth for this project. A second context file carrying the same governance chain is how the two drift apart, and a partial copy is worse than none.

Two files saying the same thing will eventually say two different things, and an agent that reads the stale one will follow it confidently. If you use several tools, pick one canonical file and point the others at it. Don't maintain two copies of your rules.

What I'd tell you before you start

Treat these files like code. Review changes to them. Delete rules that no longer apply. When the AI makes the same mistake twice, the fix belongs in one of these files, not in your next prompt. A prompt lasts one session; a rule lasts the project.

Next: the skill I typed by hand more than any other, and the one with the funniest name: ponytail, the lazy senior developer who deleted more code than he wrote.

ParkEase is a peer-to-peer parking marketplace for India, built solo with Claude Code.
Code: https://github.com/Deonkar/parkease

Seven phases, four gates: the process every AI-written change went through

Onkar Deokate — Sat, 24 Oct 2026 04:30:00 +0000

Yesterday I said process beat prompting. Here's the process.

Every change to ParkEase, from a one-line fix to a whole admin panel, went through the same route. It lives in one file the AI loads at the start of any ParkEase work. I called it flow.

The seven phases

#	Phase	What has to happen before moving on
0	Orient	Find the skills that apply before answering, asking or reading anything
1	Think	Brainstorm the approach, then a "does this need to exist?" pass
1b	Direction	UI only: render 2–3 options and let the human pick
2	Plan	A written plan, steps small enough to verify
3	Build	Tests first
4	Debug	Root cause before any fix
5	Review	Not one review: a stack of them
5b	Design audit	UI only: touch targets, hierarchy, type, motion
6	Verify	Evidence before any "done" claim
7	Ship	An 18-line checklist, every line done, before the PR opens

Each phase names the skill that runs it. "Think" is brainstorming. "Build" is test-driven-development. "Verify" is verification-before-completion. A skill, as I'll explain in the next post, is a short instruction file the agent loads when the task matches. So each phase isn't a vague intention; it's specific instructions the AI follows at that moment.

The four gates that never drop

Phases can scale down. A typo fix doesn't need a brainstorm. Four things never drop, whatever the size:

Brainstorm before creative work. The task file says what. Brainstorming settles how, and surfaces what nobody wrote down.
Tests before implementation code.
A design gate for anything that changes how something looks, feels or moves. Code review can't tell you a screen looks templated.
Verification before any "done", "fixed" or "passing". Run the command, read the output, then make the claim.

The 18-line pre-PR gate

Phase 7 is where most AI workflows quietly fall apart, because the agent is eager to finish. So the last phase is a literal checklist: backend review, frontend review, HTTP-level API tests, frontend tests for the new code, security review, the UI audit, migration review, the four mandatory integration tests, lint and typecheck, pnpm audit, a secret scan, and updates to the learnings, test-case and decision files.

It's reported as a table with evidence per line. "I'll note it in the PR body" doesn't count. A gap written into a PR description is a gap nobody re-reads.

Two lines are there because skipping them already let a real defect through:

API testing means HTTP-level. Tests that call a command directly can't see the interceptor, the status code or the error envelope.
Frontend testing means the new frontend code. Six new screens with zero new tests is a failed gate, not a style choice.

The rule that stopped it becoming ceremony

Any process this size decays into box-ticking. One line in my instructions does more than any phase:

When skipping a phase, say which and why. Silent skipping is how this decays into nothing.

The AI is allowed to skip. It isn't allowed to skip quietly. "Skipped the design gate: no UI changed" is fine. A missing phase with no sentence about it is a bug in the process, and I treated it like one.

The other half came later, the hard way: process costs tokens. At one point the workflow told the AI to send a separate reviewer agent per lens per task, and one task burned most of a week's usage limit. The fix wasn't dropping review. It was doing it inline and dispatching specialists only when a diff deserved it. That story gets its own post.

Next: the files that make all of this stick: SKILL.md, CLAUDE.md, and why ParkEase deliberately has no AGENTS.md.

ParkEase is a peer-to-peer parking marketplace for India, built solo with Claude Code.
Code: https://github.com/Deonkar/parkease

I built a parking marketplace in five weeks. The AI wrote most of the code. I did the other part.

Onkar Deokate — Fri, 23 Oct 2026 04:30:00 +0000

For the last eleven posts I showed you what ParkEase does: a peer-to-peer parking marketplace for India, with drivers, owners, valets, car washers and an admin panel, all live as a demo.

I left something out. Almost every line of it was written by an AI.

Not autocomplete. Not "it suggested a function and I tweaked it". An AI agent, Claude Code, opened files, wrote features, ran the tests, read the failures, fixed them, and opened the pull requests. Five weeks, 29 merged PRs, roughly 86,000 lines of TypeScript, 3,246 unit tests and 1,080 integration tests against a real Postgres.

So the honest question is: what did I do?

The part that isn't typing

Here's how the work actually split.

I decided what to build, and what not to. ParkEase has 34 architecture decision records. Money is integer paise in a double-entry ledger. Double booking is refused by the database, not by application code. The app never computes a price. Every one of those is a decision a human made and wrote down, because an AI will happily make a different, reasonable-sounding decision every session if you let it.

I picked between options, not from a blank page. Before any significant screen was built, the AI had to render two or three design directions and show them to me. ParkEase's look, "Wayfinder", was chosen from three rendered options. I'm not a designer. I am very good at saying "that one".

I wrote the rules the AI works under. A project file the agent reads at the start of every session: the stack, the ten rules that matter most, what's forbidden ("don't use floats for money", "don't call external APIs inside database transactions"), and where the deeper documents live.

I caught it when it lied. Not maliciously. But an AI that has written a payment path "security-consciously" will describe the security properties of its own code and call that a security review. It isn't one. More on that in a later post.

I kept the receipts. Every hard-won fix went into a file the AI reads before every task. By the end that file had 246 entries.

The part that is typing

The AI did the volume: scaffolding a monorepo with five apps and six packages, writing NestJS commands and Drizzle schemas, Expo screens, Zod contracts, migrations, tests, Dockerfiles, CI workflows. It debugged its own failures, usually well, sometimes by trying random things until I stopped it.

And it was fast in a way that changes what "a side project" means. Things I'd normally cut for time, like an admin panel with an audit log nobody can edit, a surge heat map, or load tests with 100 drivers racing for 10 slots, all fit.

What surprised me

Speed wasn't the bottleneck. Trust was. The AI could produce a feature in an hour. Knowing whether that feature was right took the rest of the day. Most of what I built around the AI, the workflow, the gates, the learnings file, exists to make its output trustworthy without me re-reading every line.

It forgets everything, every session. The model doesn't remember last Tuesday's mistake. The project has to. That turned out to be the most important design problem of the whole build.

Process beat prompting. Clever prompts helped a little. A fixed, enforced workflow helped enormously.

That's what this series is about. Not "AI wrote my app, wow", but the machinery that made AI-written code something I'd put my name on: the process, the instruction files, the skills, the learnings loop, the tests, and the places it all went wrong.

Next: the seven-phase workflow every change went through, from "think" to "ship", and the one rule that stopped it from turning into ceremony.

ParkEase is a peer-to-peer parking marketplace for India, built solo with Claude Code.
Code: https://github.com/Deonkar/parkease · Demo: https://parkease-app-six.vercel.app

ParkEase in 77 seconds: one app, five roles

Onkar Deokate — Thu, 22 Oct 2026 04:30:00 +0000

Eleven posts in, I've shown ParkEase one role at a time, and yesterday one bug at a time. Today, none of that. Just the whole thing, end to end, in a little over a minute.

ParkEase is a peer-to-peer parking marketplace for India. Someone has an empty driveway from 9 to 6; someone else is circling the block looking for a place to stop. ParkEase puts them on the same map. Valets and car washers work on top of the bookings.

The five roles

Drivers see which driveways near them have a slot free right now, filter for a car or a bike, see the price before they book, hold the slot while they pay, and show a QR code at the gate.

Owners list a space in five steps, set their own hourly price, scan drivers in when they arrive, and watch the earnings come in line by line: base price, ParkEase fee, what they earned.

Valets take jobs near them, photograph the car at the bay as proof, and get paid per trip.

Car washers set their own menu and prices, go online to take jobs, record before and after photos, and see every wash on one statement.

Admins run it all from one panel: every rupee in one ledger, approvals for new spaces and partners, a surge heat map, and an audit log nobody can edit.

And the website sits in front of all of it, quoting prices from the same code the app charges with.

Every screen is real

Nothing in the video is a mockup. The app and admin screens are the real software running on sample data; the website is the live site. If you'd rather click than watch:

App: https://parkease-app-six.vercel.app (tap a role, then any 6-digit code)
Admin: https://parkease-admin.vercel.app
Website: https://parkease-web-navy.vercel.app

It's a demo: payments, SMS and photo uploads are switched off, so nothing real can be charged.

Behind the minute

The parts that took the longest are the parts you can't see: overlapping bookings refused by the database itself, money kept as integer paise in a double-entry ledger, every job handler safe to retry, every boundary validated against one shared schema. Earlier posts in this series cover most of those. The code is all public.

Next: the demo is live; a real launch isn't yet. What's left between the two, and why most of it isn't code.

ParkEase is a peer-to-peer parking marketplace for India, built solo.
Code: https://github.com/Deonkar/parkease · Music: ende.app (CC BY 4.0)