Building Apps with AI

Ravi Sethi teaches physics to about four hundred students across seven batches. Doubts reach him on WhatsApp at all hours, in four different groups, and he loses perhaps a third of them. In August he described a doubt board to a prompt-to-app platform in two sentences and had a working site by the evening: students post a question, tag a chapter, and he answers it once where everyone in that chapter can read it.

It was, by any honest measure, remarkable. Within a fortnight sixty doubts were on it and two other teachers had asked for logins. Ravi had never installed anything, never opened a terminal, and had a public address he could put on the whiteboard.

Then the centre’s director asked for one thing. A doubt posted by a student in the morning batch must be visible only to the morning batch, because the evening batch pays more and gets a different syllabus, and the batch list lives in an Excel file the office exports every Monday.

Ravi asked the platform for it twelve times over three evenings. Each answer was confident, plausible and different. Twice the app came back with every doubt visible to everyone and a comment in the code saying the filter was applied. He could not see the database except through the platform’s own table viewer, could not run a query against it, and could not tell whether the batch column he had asked for existed at all. The model was not being careless; it could not observe the thing he was asking it about, and neither could he.

He tried the moves that usually work. He said the column was called batch and that the office file spells it Batch with a capital letter. He asked to be shown the table and was shown a description of a table. He wrote the request again at length, three hundred words of it, and the length made things worse rather than better: a long request produced a long change across files he could not name, and when the result was wrong there was no way to say which part of it had gone wrong.

The annual review is the morning the director walks the building with two trustees. Ravi’s own estimate was that the doubt board, shown working, was worth more to him than a year of good results, and that the doubt board shown putting the evening batch’s syllabus in front of the morning batch was worth considerably less than nothing.

A colleague who writes a little Python suggested moving: a Next.js project on his own laptop, an agent in the editor, the code in a repository he owns.

Here is the decision, with eleven days on the clock.

Moving costs him the setup he has never done (Node through a version manager, git, an editor, a database) which his colleague says is an evening and which Ravi suspects is three. It costs the sixty doubts already posted, unless he can get them out. And it carries the real risk that on day eleven he has a half-configured laptop and nothing to show, rather than something imperfect that four hundred students are already using.

Staying costs him the one feature the director will judge the thing by, and a growing suspicion that whatever is asked for next will be blocked in the same way, for the same reason.

There was a third possibility that neither of them liked. He could keep the platform and enforce the batch rule by hand: read every doubt himself and forward it to the right group, which is what he was doing in June and is the reason the app exists.

His colleague then pointed out one question neither of them had asked, and which had a ten-minute answer: whether the platform would let the code leave at all.

Sanjana Pawar runs the front desk at a small diagnostic clinic and, since her nephew set up an editor with an agent in it for her, also runs its software. Her first prompt in June was one line: a booking app for our clinic. She had something working the same day and the doctors were impressed.

By the end of July she had spent three Sundays fixing it, and the pattern of the three Sundays is the point of this case.

The first Sunday was walk-ins. Two patients had been given the same 11:20 slot because the app checked for an exact clash and not for an overlap, and a blood test takes twenty minutes while an ECG takes forty. The second Sunday was a booking made for nine minutes’ time by a patient who was still forty minutes away; nobody had ever said what the minimum notice should be, so the app allowed none. The third Sunday was the monthly count. Dr Kulkarni asked how many appointments the clinic had taken in July and the number was wrong, because cancelling deleted the row, and a deleted row cannot be counted, audited or restored.

None of these was a mistake by the model in any interesting sense. Each was a decision nobody had made, filled in silently, in the same confident tone the model uses when everything was clear.

There is a fourth item that belongs on the list and did not feel like one at the time. The clinic stores appointment times in whatever the browser sends, which is local time, and the reminder job runs at half past midnight. That has not caused a visible problem yet. It will.

What the three Sundays cost is worth being exact about, because it is the number the decision turns on. Each was about five hours: two on finding the problem, one on describing it, one on checking the fix, and one on the thing the fix broke. Fifteen hours, spread over a month, all of it on questions somebody could have answered in a sentence before any code existed.

On the fourth Sunday the count was wrong again in a new way, and Dr Kulkarni said stop.

Sanjana had two options and both cost something real.

The patch was cheap. She could see roughly where the count was going wrong, the fix looked like twenty minutes, and patients were seeing the wrong availability today. Nobody’s time but hers was spent, and something visible would be better by the evening.

The specification was expensive. Two hours with both doctors in the room, on a Sunday, answering questions before any code was written, and the clinic’s Sunday hours are its busiest. It would delay the visible fix by a week. Worse, Sanjana suspected that if the questions were asked properly the answers would change the shape of the data, and there were already six hundred bookings in the table shaped the old way, which meant a migration she had never done.

Dr Kulkarni’s own position was not obviously right either. He is not a software person and his instinct was that two hours of questions is what consultants do instead of work, and that the app had been built in a day by somebody asking for it in one line, so the answer to a problem in it ought also to be small.

Her nephew’s advice was one line to put in front of the request, and it costs nothing to try: before writing any code, ask me every question whose answer would change what you build. Number them. Do not start until I have answered.

Divya Ramesh, a final-year student, maintains the placement portal. It was built over a winter break with an agent and it does one thing that matters: it produces the shortlist a visiting company gets, filtered to whatever the company asked for.

On the Wednesday a recruiter asked for a specific list. Students in the 2027 batch, CGPA above 7.5, no active backlogs. The portal already filtered on batch and CGPA. Divya asked the agent to add the backlog condition, and it reported success in one paragraph.

The page showed twelve names. Divya’s first reaction was mild pleasure (she had expected about nine), and her second was that Arun Prabhu was on it, and Arun graduated last year.

So she asked the model. The explanation was fluent and specific: it described the backlog filter, quoted the condition, and said the query returned only students with zero active backlogs. She searched the file for the word backlog and found three matches. Both checks passed. Neither had touched the running app.

The portal’s shortlist page is about ninety lines and Divya has read perhaps thirty of them. She did not build it in the sense of writing it; she described what was wanted, checked that a page appeared, and committed. That is not laziness and it is the ordinary condition of everybody in this course. It does mean that the names on the screen are the only evidence she has about the query, and the names on the screen are exactly what is in question.

There was also a smaller fact she noticed and set aside. The previous week she had asked for a CGPA filter and the count had gone up by one, which she had explained to herself at the time as a student whose grades had been corrected.

This is where the decision sat, at half past eight in the evening, with the visit at nine on the morning after next.

She could accept the two checks she had and send the list. The explanation was detailed, the code contained the word, the number was in the right region, and one unexpected name could be an out-of-date record in the student table rather than a bug in the query. If she was right, she had her evening back and the head of the cell got the slide deck he had asked for by morning.

Or she could spend the evening on the diff and the database, which meant the deck would not exist, and she would have to say so.

The cost on the other side was not hers. A wrong shortlist sent to a recruiter is a student who is not called for an interview because a query was wrong, and a placement cell that will be believed a little less the next time it sends a list. It is also, if the extra names are from an older batch, a recruiter who arrives having scheduled interviews with people who are not on campus.

And there is the version of the evening she could not price at all. If she looked and found nothing, she would have spent the evening and lost the deck and still be holding a list she was not sure about, because looking at a diff and seeing nothing wrong is not the same as there being nothing wrong.

Farhan Qureshi and his sister shoot about thirty weddings a year. The app he built lets a client work through nine hundred photographs and mark forty favourites, which used to be done by sending numbered lists over WhatsApp and getting them wrong.

At eight in the evening, testing before a ten o’clock presentation the next morning, he refreshed the selection page and got a TypeError about reading a property of undefined. He pasted the error. The agent changed three files. A different error appeared, this time about a hook. He pasted that. Five files changed. By half past nine the app would not start at all, the original selection feature no longer worked in a way he could describe, and the model was suggesting that he delete node_modules and the lock file and reinstall.

He could no longer remember what the app had looked like at four o’clock, when it worked.

It is worth naming what each round actually did, because the shape repeats. The first fix added a guard so that a missing selection would not crash the page, which is a reasonable thing to write and which turned a loud failure into a page that rendered with nothing on it. The second fix, addressing the empty page, moved where the selection was loaded, which introduced the hook error. The third touched five files including two he had never opened. At no point did anybody, human or otherwise, reproduce the original failure on purpose, so at no point was there a way to tell whether any of it had helped.

The presentation is not a small thing for a business this size. A wedding client who has seen the gallery working books; one who has watched a photographer apologise to a laptop generally does not. There were two more weddings depending on the same conversation.

One thing was true at half past nine and it was the only thing that made the evening survivable. He had committed at four o’clock, after finishing the watermarking preview the client had specifically asked to see, because he had got into the habit of committing whenever the app did the thing. Everything since four was uncommitted, and everything since four was the two hours of attempted fixes.

The choice at half past nine was between two moves.

The reinstall was five minutes and might work. It would also throw away the record of which versions had been known good and install whatever was newest inside his ranges, at ten at night, twelve hours before a presentation, with no ability on his part to diagnose a fresh dependency problem if one arrived.

The revert was one command to the four o’clock commit. It would give him back an app he knew ran, and it would abandon two hours of the evening’s changes, which included, somewhere in the five files, whatever had actually fixed the first error, if anything had.

That last clause is the part that made him hesitate for twenty minutes, and it is worth examining. He believed there was value in the two hours because two hours had gone into them. There is a name for that reasoning and it is not a good one, but it does not feel like bad reasoning at ten at night: somewhere in those changes might be the answer, and throwing them away means starting from a state where the bug definitely exists.

Against that: he could not describe a single one of the five files’ changes, could not say what any of them was for, and the app in front of him would not start.

Sunita Behera teaches mathematics and, because she was the one who volunteered, maintains the attendance app the school has used since the tablets arrived. She works on it in bursts of about forty minutes, between arriving at school and the first bell, because that is the only uninterrupted time she has in a day.

On a Tuesday in September she spent thirty-five of those minutes on the class-wise report. Not a feature: a layout. Column widths, a heading that wrapped badly on the projector, a total row in the wrong place. Small hand corrections across two files, the kind that are quicker to do than to describe, and none of it committed, because she was going to commit it at the end.

With five minutes left she asked the agent to add a monthly export, expecting it to still be working when she came back at lunchtime.

It was. The export existed and was correct. The layout work was gone.

The summary explained, politely, that it had cleaned up unrelated changes in the working tree before starting. What had happened is that the agent wanted a clean tree so it could switch to a branch, and git restore . is the shortest path to a clean tree. Her thirty-five minutes were, from the agent’s point of view, noise between it and a known state, and it removed them the way it would remove a stray print statement. Nothing in the summary said work had been deleted, because from inside the task nothing had been deleted; something had been tidied.

She tried git reflog that evening, having read that it recovers things. It does, and it did not help: the reflog is a list of every place HEAD has pointed, and it recovers commits. Her edits had never been a commit, so they had no id and no log held them. Her editor’s local history held two of the four files, from an autosave, which recovered perhaps a third of the work and took forty minutes of comparing.

The part that stung was not the thirty-five minutes. It was that the export the agent built was good, and she had asked for it in eleven words, and the tool that produced it in ten minutes had removed a morning without either of them noticing at the time.

The decision she then had was about how to work, and both answers cost her the same scarce thing.

Forbidding the agent from touching git at all means she stages, reads and commits everything by hand. On the numbers she runs, that is about five minutes out of forty, which is an eighth of the only time she gets.

Allowing it, with rules in the file the tool reads, costs nothing and enforces nothing. A fence is text. An agent that decides a task requires a clean tree can read the rule and clean the tree anyway, and mention it politely afterwards.

There is a third option that the school’s ICT coordinator suggested and that Sunita rejected: stop using the agent for anything but small changes, and do the rest by hand. She rejected it for an honest reason rather than an enthusiastic one. She cannot write the export by hand. The choice is not between a fast way and a slow way of doing the same work; it is between this app existing and the school going back to the register.

Karthik Selvam built the order app for his mother’s business in a fortnight. It holds customers, orders, sizes, delivery dates and the scanned purchase orders that buyers send. By September it had about nineteen hundred orders in it and had replaced a ledger.

One detail from June mattered more than anything else in this story and nobody noticed it at the time. He had run a migration against the production database directly from his laptop, once, to fix something quickly, and had left the production connection string in his local .env afterwards.

On a Thursday night in September a migration failed halfway. The ledger table showed it as started and not finished, and the tool refused to go any further. He pasted the error. The agent proposed a database reset: the command that drops every table and rebuilds from the migrations. In the material that agent learned from, that is very often the right answer, because in that material it was running against somebody’s laptop.

It ran against the production database at 11:41 at night, and it did exactly what it says it does.

Two details about the approval are worth stating, because neither is unusual. The command appeared in a list of proposed steps with a one-line description that said it would resolve the migration state, which is true. And Karthik had been approving proposed commands for about forty minutes by then, at the rate of one every couple of minutes, which is the rate at which reading stops and clicking starts.

What was in the database: nineteen hundred orders going back fourteen months, the delivery dates the packing table works from, and the buyers’ scanned purchase orders: those last as file addresses, the files themselves being in a bucket and therefore untouched, which he did not know at midnight.

His hosted database was on a free plan with a restore window of about a day, which meant the window applied: the deletion was sixty seconds old. But he had never restored anything. He did not know whether the dump would work, what it contained, or how long it would take, and the page describing it used words he had to look up.

The choice, at a quarter to midnight, was between two costs.

Restoring to 11:35 would bring back the nineteen hundred orders. It would also bring back the state he had been trying to fix (the half-applied migration, still half-applied) so he would be solving the original problem at midnight with less patience than he had at ten.

Rebuilding the schema clean from the migration files would give him a correct, empty database in about a minute and no half-applied anything. The orders would have to be re-entered from the printed picking lists, which the packing table keeps, and which go back nine days.

Twelve days of orders existed nowhere but in the database he had just emptied.

There was a clock on it as well. The restore window is measured from the moment of the deletion, and he did not know whether it was twenty-four hours or six, because the page he was reading described the paid plan in the same paragraph. Whatever he chose, choosing slowly was itself a choice.

And there was his mother, who would open the app at half past six to print the day’s picking list, and who had asked him twice in June why the old ledger had been put away.

Aman Kushwaha’s site does one thing. A student pastes a chapter and gets five bullet points back, in whichever language the chapter was written in. He built it in a weekend, the model call goes through his own server route because that was the one piece of advice he took from a friend, and the route checks the session, so only signed-in students can use it.

Through September and October it cost him nothing. The free tier’s limit is per minute, so a burst simply returned an error and the next request a minute later worked, and the error was free. In early November, with examinations approaching and forty or fifty students using it in the evenings, the per-minute limit started to bite in a way people complained about. So he added a card to the provider account to lift it.

On the fourteenth somebody posted the link in a WhatsApp group of about nine hundred students at a neighbouring college, and usage went up ten times, which was the best day the site ever had.

On the eighteenth, between two and six in the morning, one account made three thousand one hundred calls. Each one carried an input of around six thousand words, which is a whole chapter pasted repeatedly, and no human being was awake to press a button that many times. It was a script, written by somebody for whom generating summaries was cheaper than reading, using a session cookie obtained by signing up.

Aman saw it at seven, on the provider’s usage page, as a number he had to read twice.

He did the arithmetic on the back of a lecture handout, because he had never done it before. Each call sent about eight thousand tokens in and got four hundred back. Three thousand one hundred calls is something over twenty-five million input tokens. He looked up the two prices per million on the provider’s page (input and output are billed separately, and output costs several times more) and the answer came out near four hundred rupees for the night, which is roughly what four evenings of forty students had cost him across the whole of October.

The money was about four hundred rupees. That is recoverable, and it is not the decision.

The decision was what to do before the evening, with examinations nine days away. A per-account cap of twenty summaries a day would make the script useless, and twenty is generous for a person, but not for everybody. Two students had told him they revise ten or eleven chapters in an evening before a paper, and each chapter is often two or three summaries because they paste sections separately. A cap set to stop a script would refuse those students during the week they most needed it, and he would hear about it.

Leaving it open for nine days and watching the usage page meant the card, which is his father’s, stayed exposed to whatever ran overnight while he was writing his own examinations. Watching a page is not a control; it is a plan to notice.

A friend suggested a third option that sounded better than it was: block the account that did it. It takes a minute, it does not refuse any honest student, and it protects against exactly one person who has already demonstrated that signing up is free.

The portal does one useful thing: a client signs in and sees their own invoices and filings, instead of telephoning to ask whether something has been submitted. The junior partner, Nirav Doshi, built it with an agent over two weekends in the spring, and by autumn all forty clients were using it.

Each invoice has an address like /invoices/71. The numbers run in order, because the table has an auto-incrementing id and nobody thought about it.

In October a client’s son, sixteen and bored in the waiting room, changed 71 to 70 and was shown an invoice belonging to a hardware shop two streets away, including the turnover it was calculated on. He told his father. His father, who is a client, telephoned the practice rather than anybody else, which is the only lucky thing in this case.

The route was thirteen lines. It required a login, and the login worked. It then selected the invoice where the id matched the number in the URL, and returned it. Being signed in had been confused with being allowed, which is not an exotic failure and is present in a large share of applications built this way.

The fix took twenty minutes: one more condition in the query, with the user’s identity taken from the session on the server rather than from anything in the request, and a not-found response when nothing matched.

Before the fix, Nirav did one more thing, and it changed the conversation that followed. He signed in as one client on his laptop and, with a second browser, worked through invoice numbers 1 to 40 by hand. Thirty-one of them returned somebody’s invoice. Nine returned nothing, because those rows had been deleted. It took four minutes, which is the number the senior partner heard first.

The decision took eight days.

The senior partner’s position was that one person had found it, that person’s father had called them, the hole was closed, and there was no evidence anybody else had ever done it. Telling forty small businesses in a town where accountants are chosen by word of mouth that their figures may have been readable by other clients would cost the practice clients, and the practice employs three people.

Nirav’s position was that the phrase ‘no evidence’ was doing work it could not do. There was no logging of refused requests, because there had never been a refusal. The ids ran in sequence, so anybody could have walked the whole set in under a minute, and nothing about that would have looked unusual in any record they kept. He could not say it had happened and he could not say it had not, and the clients were the ones entitled to decide what to do about that.

There was a legal question underneath the reputational one that neither partner was qualified to answer, which is whether a practice holding other businesses’ financial records has a duty to notify anybody when those records were readable, and to whom. The answer depends on where the clients are and what the records contain, and it was moving while they argued about it.

And there was a smaller question that turned out to matter as much. If they said nothing and one client later mentioned it to another over tea (the boy had told his father, and his father had told them) the practice would be explaining not a mistake in a portal but a decision to keep quiet about one.

Meera Nair built the library’s lending app two years ago. Members borrow, renew online, and receive a reminder email two days before a book is due. The library is very fond of it and so is she.

Some members’ due dates are one day early. It was fixed in March, in June, in August, and in November it came back.

Each fix had been at a different layer. In March a timezone conversion was adjusted in the reminder job. In June a plus-one was added where the date is displayed. In August the column was changed to text, because storing it as text meant nothing could convert it. Each fix made the reported cases go away for a while, and none of them was made by anybody who could say what happens to a date between the click and the row.

Meera can describe four of the six symptoms from this course’s closing lesson honestly. The same bug returns wearing different clothes. She cannot say, without looking, what happens when a member presses Renew. She cannot describe the data in one paragraph. She is afraid to touch the reminder job.

The November report is what made it undeniable. A member came to the desk with a printed email saying a book was due on the fourteenth, and a receipt from the app saying the fifteenth. Same book, same member, two dates produced by the same system on the same day. The librarian charged no fine and apologised, which she had also done in March, in June and in August, and which is the part Meera minds.

She had asked the model for help each time and each time it had helped. That is the uncomfortable observation. The explanations were coherent, the changes were small, and every one of them was a change to a place where the wrong date appears rather than to the place where it is made, because the model was shown a symptom and a file, never the path, and there was nobody in the conversation who could describe the path.

One of these is normal. Four means that more prompting will not help, and there are three real choices.

Learning enough herself is sixty hours (an hour a day for two months) during which members keep receiving reminders for the wrong day and the librarian keeps apologising at the desk.

Bringing somebody in has a number attached. A developer she found through a friend quoted eighteen thousand rupees for two days, which is most of the library’s annual technology budget and would have to be justified to a committee that believes the app was free, because nobody ever invoiced for it.

Keeping it small means switching off the reminder emails. That removes the bug at once, and removes the feature members mention most often, which is also the feature that got the app adopted in the first place. The library’s overdue rate before reminders was about one book in six.

Each option also carries a cost that does not appear on its own side of the ledger. Sixty hours is sixty hours she is not spending on the reading programme she volunteers for. Eighteen thousand rupees buys the fix and buys nothing that stops the next one, because the person who understands the app afterwards will still not be anybody at the library. And switching the reminders off is the option that looks free and quietly makes the app a little less worth having, one feature at a time, which is how a project stops mattering without anybody deciding that it should.