How I use AI to build faster without shipping garbage

The studio is called Tavzuran, which is a claim I should probably back up. AI is genuinely central to how fast I can work. It is also nowhere near the thing making the decisions. Here is the actual division of labour.

What the machine does

• Boilerplate. Project scaffolding, form validation, CRUD endpoints — code that has been written a million times and has one right shape.
• Repetitive refactors. Renaming a concept across sixty files. Tedious, error-prone by hand, and exactly what a machine is for.
• Test data. Realistic fixtures in bulk.
• First drafts of tests, which I then read carefully, because a test that asserts the wrong thing is worse than no test.
• Explaining unfamiliar libraries faster than reading the docs end to end.

What it does not do

• Decide what to build. That comes out of a conversation with you, and it is the part of the project with the highest leverage.
• Decide the data model. Get this wrong and every week afterwards is more expensive. It is worth a human afternoon.
• Own anything to do with money, authentication or personal data. I write those slowly, by hand, and then read them again.
• Go live unread. Every line is reviewed by me before it ships. Not skimmed — read.

Why the line sits there

Modern models are excellent at producing code that looks right. That is precisely the danger. Confidently wrong code passes a quick glance in a way that obviously-broken code never does, and the failure modes cluster in the worst places: an authorisation check that is subtly too permissive, an edge case in a refund path, a race condition that appears only under load.

So the rule is simple. AI is allowed to be fast where being wrong is cheap and obvious. Where being wrong is expensive or silent, a human writes it and a human checks it.

The machine does the typing. A person does the thinking, and answers the phone when it breaks.

What you get out of it

Concretely: more of your budget goes into the parts users feel. If AI absorbs the mechanical third of a build, that third of the money goes into the flow that actually decides whether someone comes back — instead of into me typing out a login form for the hundredth time.

The part that matters when something breaks

At 11pm on a Saturday, when payments are failing, you do not want a tool. You want a person who understands why the code is shaped the way it is, because they shaped it. That is the difference the name is pointing at, and it is why I read everything before it ships.

A day, in practice

Abstract policy is easy to state and hard to check, so here is what it actually looks like on a normal working day.

Morning is usually the part with no AI in it: reading what a client sent, deciding what the next piece of work is, and — if it touches the shape of the data — drawing it out and thinking about what happens in a year. That work is slow on purpose and it is the highest-value hour of the day.

The middle of the day is where the tools earn their place. Scaffolding the screens, the endpoints, the forms, the test fixtures. I read every diff as it lands rather than at the end, because reviewing four hundred lines at five o'clock is how things get waved through.

The end of the day is review and deletion. A surprising amount of what gets generated is technically fine and unnecessary — an abstraction for one use, a config option nobody asked for, error handling for a case that cannot occur. Removing it costs nothing today and saves whoever reads this in two years.

The things I do not let it touch

• The data model. Get it wrong and every week afterwards is more expensive. It is worth a human afternoon and a whiteboard.
• Authorisation. Not “is this a real user” but “is this user allowed this record”. The single most common place I see plausible, wrong code.
• Money. Payments, refunds, invoice numbering, anything with a currency in it. Slowly, by hand, then read again the next morning.
• Anything with personal data. What is stored, for how long, who can see it, and what the access log records.
• Deletion. Any code that removes something permanently gets written by a person and tested against a copy first.

Why the review is not optional

The uncomfortable truth about reviewing generated code is that it is harder than reviewing a colleague's. A colleague's mistakes have a grain to them — you learn where a particular person tends to slip. Generated code is uniformly confident, and the errors are distributed differently: rare, but with no tell.

So the review has to be systematic rather than instinctive. Where did this value come from. What happens if this fails halfway. Who is allowed to call this. That is a checklist rather than a feeling, and running it is the actual job now.

What you are paying for

It is worth being direct about this, since it bears on the price. You are not paying me to type. You are paying for the decisions about what should exist, the judgement about which parts are dangerous, and the fact that someone read all of it and will answer for it.

The typing being cheap is why a first version can start at ₹20,000 rather than at several lakh. The reading being expensive is why it is not free, and why I would be suspicious of anyone quoting as though it were.