The coder who taught the model to ship.

The riyaz room my friend's father teaches in is on the fourth floor of a flat in Mirpur 11, behind the masjid the local political party rents out for weddings. The lessons start at five in the morning, before the muezzin, while the rest of the building is still asleep. The ustad sits with his legs crossed on a thin cotton mat, his back against the wall, a kaida sheet on his lap with the bols pencilled in his own hand from the seventies. The rosewood tabla is on a cotton ring in front of his apprentice, a boy of fourteen from the next building who is here because his mother thinks the discipline will help with school. The brass jhanj sits within reach of the ustad, but he rarely picks it up.

The thing I noticed, the first morning I sat in on a lesson, is that the ustad never plays the drum. Not once across forty minutes. He claps the pulse on his thigh. He says the bol out loud. The apprentice plays it on the puri. The ustad listens, says "no, the dha is from the wrist, not the elbow," resets, claps again, listens again. The apprentice's hand is doing all the moving. The ustad's only job is to hear when the bol is wrong and to know what kind of wrong, and the entire economic value of the lesson rests on that hearing.

I have come to think this is the right shape for what people are calling "vibe coding," the idea that an engineer can talk to a model in plain English and the model will produce shippable code. The phrase sounds true the first time you watch a senior engineer use Cursor or Claude Code and pull a working middleware out of forty seconds of typing, and it stops sounding true the moment you keep watching, because the same engineer will ignore the model's first three suggestions, accept the fourth with two edits, and reject the fifth without bothering to explain why. What that engineer is doing in the gaps between keystrokes is the actual job, and it is an older job than the model by about thirty years, with a name that long predates the agent. We used to call it code review, back when reviewers were rare enough that a senior at Microsoft Research could get a whole book out of describing them properly.

bol

DHA

The model does the playing while the reviewer does the listening, and the economic value of the lesson, in both rooms, rests on that second skill. It is the one nobody is hiring for yet, because it does not show up in any interview loop where the candidate writes code on a whiteboard.

Andrej Karpathy described the shift in 2017 as Software 2.0, where the engineer's job moves from writing the program to curating the dataset and the loss function that produces the program. He was talking about neural nets at the time, but the shape generalises. By 2026, Software 2.0 has turned out to mean writing English so precise the model can compile it into TypeScript. Simon Willison has been keeping a careful log of this on his blog since 2022, and the most useful thing he says, repeatedly, is that the model produces something that looks like the answer well before it produces the answer, and the discriminating step is yours. He uses the word "discriminator." The ustad on the cotton mat in Mirpur uses the word "kaan," which is Bangla for ear, and the two of them are pointing at the same muscle that no junior interview I have ever sat in on has tried to test for.

What is hard about the muscle is that it does not announce itself. A junior reviewer reads a diff that compiles and ships clean tests and concludes the code is good. A senior reviewer reads the same diff, notices that the window for the rate limit is being recalculated on every request instead of cached, and sends it back.

The compile is the floor a tabla apprentice clears in week one of riyaz.

Every bol the apprentice plays makes a sound. The question is whether it is the right sound, and the only person in the room who can tell is the one with thirty years of listening behind him.

The pattern that has held up best in my own use of the model, on the small projects I run alongside the day job, is the one the riyaz room uses. The ustad calls a bol, the apprentice plays it, and the ustad either says "kept" or names one specific thing the wrist did wrong before calling the bol again. The cycle is short and the feedback is concrete enough that the apprentice's wrist learns one correction at a time. The same loop, mapped to a code review, is the one I find myself running forty times in an afternoon when I am building anything serious.

The reason the cycle works, in both rooms, is that the apprentice and the model both have the same defect. They will produce a confident answer whether or not they understood the question. The model is not going to say "I don't have enough context, the rate limit is bound by a Redis instance whose connection pool I haven't seen." The apprentice is not going to say "I don't actually know which finger you wanted on the syahi." Both will produce something that looks like the requested artefact and pass it back across the loop, and the reviewer's whole job is to notice the gap between the artefact and the request, in language the producer can act on next time around.

The other thing the ustad does, which the engineering profession has not yet borrowed, is repeat the correction even after the apprentice has played the bol cleanly, sometimes ten or twelve times in a row before he is satisfied. The repetition is not there to confirm the bol but to wear the correction into the apprentice's nervous system, so that on the morning of the public recital at the Bengal Foundation hall, when the boy is nervous and the wrist wants to cheat, the muscle remembers. Engineers tend to accept a fix on the first pass and move on, which is why the next pull request from the same agent makes the same mistake the previous one did. The ustad would have known to ask for it again. The engineer treats the green CI as the recital and the recital is six months later, on a public stage, with everyone watching.

bol

NA

The mistake worth not making is treating the model as a colleague. It is an apprentice of fourteen with very fast hands and no ear yet, sitting on the cotton mat at five in the morning, waiting for you to clap the next bol and say whether the last one was kept or redo.

What this means in practice, for the engineer who is trying to figure out how to actually use these tools without ending up a vendor of plausible code, is that the time investment is in the reading, not the typing. A reasonable rule, the one I have been holding myself to since February, is that for every minute spent prompting, there should be three minutes spent reviewing the output, and the reviewing should happen with the same care a magazine subeditor used to give a feature on its way to print. If the diff is too long to read carefully, the prompt was too long, so break it into the next bol you can hear cleanly and call that one instead. Listen for whether the wrist cheated. Then either nod or say "no, again," and mean it, which is the part almost nobody does, because saying it properly costs you the next twenty minutes and nodding costs you nothing today.