Dispatches

What Dussehra knows about building with AI

By Kalpak Kale ·

A large illuminated Ravana effigy at a night-time Dussehra celebration.
Photo by Rohan Dewangan on Pexels

Every October the effigy goes up in the ground near my home in Akola, forty feet of bamboo and paper, and every October I watch it burn with a few hundred people and think about nothing at all. This year I thought about work. Not because the festival is about work, but because the story it tells is the most accurate description I know of what goes wrong when capable people, or capable machines, are left to their own devices.

In one line: Dussehra is a yearly review disguised as a festival: a checklist of ten ways judgement fails, a ritual for maintaining your tools, a boundary that must not be crossed, and a public deletion of what you have outgrown.

A word on the title. I am not going to tell you the festival is secretly a physics lesson. Most of what gets called the "science" of Indian festivals is wishful. What I am doing is narrower: reading the festival as a system that encodes practical knowledge, the way a checklist or a runbook does, and asking what that knowledge says to someone who spends their day building software with AI tools. Where I lean on actual research, I say so.

Ravana knew everything

The detail everyone forgets about Ravana is that he was the most learned figure in the epic. A scholar of the Vedas, a composer, an astronomer, a king who ran a wealthy city. The story is not about an idiot losing to a hero. It is about the most capable mind in the room losing because capability and judgement are different things, and he had only one of them.

That is the exact shape of the problem with today's AI tools. A coding agent has read more code than any human. It can produce a working feature in the time it takes me to describe it. And it will, with full confidence, invent a library function that does not exist, skip the input validation it was never asked about, or report "done" on something it has not tested. Not because it is stupid. Because knowing is not the same as judging, and the judging part was never in the model.

The practical consequence is the rule I wrote about in the brief post: read every diff. Not to write the code, to supply the judgement the tool does not have. Ravana had no one reading his diffs.

Ten heads, ten ways to be wrong

The popular reading gives Ravana's ten heads as ten vices: desire, anger, greed, attachment, pride, envy, and the restless mind, the intellect, the memory and the ego turned inward. Different tellings vary the list. The point is not the exact ten. The point is that failure has recognisable shapes, and naming them is most of the defence.

Here are the ten I see most in AI-assisted work, which is my own list, not scripture:

  1. Speed over understanding. Accepting output because it arrived fast.
  2. Scope creep. Ten changes of mind cost ten rebuilds. The agent makes indecision cheap and therefore common.
  3. Confidence without evidence. The answer that sounds right and cites nothing.
  4. Skipping the boring defaults. Encryption, signed links, secrets outside the repository. Always "later".
  5. Trusting the demo path. It works on the one route somebody tried.
  6. Letting the tool choose the architecture. It will pick what it has seen most, not what you need.
  7. Not filing the bug you fixed in the same breath. The record disappears.
  8. Mistaking fluency for correctness. Prose quality says nothing about truth.
  9. No test set. If you cannot name how it fails, you do not understand the corpus yet.
  10. Ego. Believing you no longer need the review because the last ten went fine.

Pin that list above the monitor and you have most of the value of the festival without the bamboo.

Ayudha Puja: honour the tool by maintaining it

On the day before, or on the day itself depending on where you are, families clean their tools and put them away for the day. Carpenters their chisels, drivers their vehicles, students their books. In Akola the auto drivers garland their rickshaws. In our office we have started doing the same with the thing we actually depend on: the evaluation set.

A ritual of maintenance sounds quaint until you notice how rarely maintenance happens without one. The 21-case test that decides whether our chatbot ships only gets run because running it after every change became a rule, not a judgement call. There is good evidence that rituals work this way. A 2018 review in Personality and Social Psychology Review by Hobson, Schroeder, Risen, Xygalatas and Inzlicht found that rituals regulate emotion, performance and social connection largely by making an action fixed and repeatable rather than optional. Make the tool check a festival and it happens. Leave it to willpower and it does not.

So, this week: the proxy that serves AI tools to our developers gets its spend limits reviewed, the evaluation sheet gets its cases re-read, the backups get tested by restoring one. Garlands optional.

The line that must not be crossed

Before Ravana arrives, Lakshman draws a line around the hut and tells Sita not to step over it. The whole disaster starts when she does, for a good reason, to feed a visitor. The guardrail was not wrong. The exception felt reasonable.

Every guardrail I have put around an AI tool has been crossed for a reasonable exception. "Just this once, let it push to production." "Just this once, skip the review, it is a one-line change." The rule for us now is that a guardrail can be changed, in writing, with a reason, but never stepped over in the moment. The agent does not get to decide that the visitor is harmless, and neither do I at 11 at night.

Burn the effigy

The part of the festival people travel for is the deletion. The thing you have been building for weeks goes up in flames, in public, on purpose. Nobody keeps the effigy for next year.

Code does not get this treatment. We keep the prototype "in case", the old prompt "for reference", the branch "we might need". This year the review includes a list of things to burn: the chatbot's first Flask prototype, which has been dead since the FastAPI service shipped; three Claude Code configurations nobody has used since the proxy; and two internal tools that a single spreadsheet replaced. Deleting is a skill, and the festival gives it a date.

Begin

Vijayadashami is also the day children are traditionally started on their letters, and the day new ventures are supposed to begin. The festival that burns things also starts things. The two go together: you cannot start the next thing while the effigy of the last one is still standing in the yard.

So the final item on the list is the one thing I have been deferring. For me this year it is the evaluation template, the 21-case sheet in a form other teams can use, which I have talked about for a month and not written. It starts today.

What this comes to

Capability without judgement loses. Name the ways you fail. Maintain the tools on a schedule, not a whim. Draw the line and do not step over it for a reasonable exception. Burn what you have outgrown. Then begin.

That is the festival, and it turns out to be a decent engineering review. Happy Dussehra.

Sources

  • Hobson, N. M., Schroeder, J., Risen, J. L., Xygalatas, D. and Inzlicht, M. (2018). The psychology of rituals: an integrative review and process-based framework. Personality and Social Psychology Review, 22(3), 260 to 284.
  • The Ramayana, Yuddha Kanda, for Ravana's learning and his defeat; the Lakshman Rekha episode appears in later tellings such as the Ramcharitmanas rather than in Valmiki.
  • The 21-case test that decides whether a RAG chatbot ships and A brief goes in, software comes out, for the evaluation and review practices referred to above.