DEV Community: Hemanshu Upadhyay

Making a phone agent in Gujarati feel less slow

Hemanshu Upadhyay — Tue, 29 Sep 2026 06:20:20 +0000

On Sunday I built Vaani, a phone receptionist demo for a dental clinic in Surat that doesn't exist. It has a keypad menu for Gujarati, Hindi or English, tools to book, move and cancel appointments in a diary, and a route to the clinic's own front-desk number when a person should take over. The diary lives in memory and resets on restart, and there's no live number yet. So everything below is how it's built and what the tests check, not what callers did.

A lot of the design is about what happens while the model is still working. A turn can include tool calls (look up Tuesday, check which dentist is free, book the slot), and a phone line has no typing indicator to cover the wait.

A turn that outlives the webhook

With Twilio's <Gather> speech input, a call is a series of HTTP requests. Twilio posts what the caller said, you answer with TwiML (say this, listen again), and Twilio allows a request up to 15 seconds.

The simple version holds that request open until the model has finished its whole reply. In Vaani a turn isn't tied to one request. It's an object that lives in memory across several:

interface PendingTurn {
  promise: Promise<TurnResult | null>;
  startedAt: number;
  /** Webhooks answered so far for this turn. */
  waits: number;
  /** Every sentence the agent has produced this turn, in order. */
  sentences: string[];
  /** Server-side cursor into `sentences`. */
  spoken: number;
  // (plus a wake-up callback, trimmed here)
}

When the transcription comes in, the turn starts and the first request gives the model up to 900 ms. If the turn is done by then, its reply goes back. If not, the response carries the complete sentences the agent has written so far, or a short holding line if there aren't any, and ends with a redirect to the server. The next request picks up the same turn and waits again, up to 5 seconds this time, returning sooner if the turn finishes or a new sentence turns up. Round it goes. That spoken counter is bookkeeping on the server, not proof of what a caller heard.

Those are server-side waits, not the moment a caller hears something. Preparing audio can add up to another 1.5 seconds (more on that below), and Twilio still has to fetch and play the response. Measuring what a caller actually hears is the next job.

The first holding line changes from turn to turn ("One moment.", "Let me check.", "Okay, checking."). If a turn needs a second wait with nothing new to say, it's "Still on it, thanks for waiting."

There's a ceiling. The turn has a 20 second budget, checked each time a request picks it up. Run past it, or throw an error, and the call goes to the handoff path, which dials the clinic's number. If there's no number configured or nobody picks up, it notes a callback instead.

Sentences out of a token stream

The best thing to say during the first wait is the agent's own first sentence, if it has written one. A reply that starts "Let me check Tuesday for you" is a perfectly good thing to hear while the tool runs. That means cutting the token stream into sentences as it arrives, in three scripts.

A full stop is the awkward one. It turns up in "499.00", in "Dr. Shah", and at the end of a half-streamed "4." that's about to become "4.30". So a full stop only counts once whitespace has arrived after it, which handles the numbers. Titles need their own check, because "Dr." already has a space after it, so there's an abbreviation list with the English, Gujarati and Hindi ones ("Dr.", "ડૉ.", "डॉ." and friends).

Hindi also ends sentences with the danda, "।", and it can arrive with no space after it. So the whitespace rule is for the full stop only. A danda doesn't need a space after it, though it still waits for a little more input (so trailing punctuation or a closing quote gets absorbed) and for the length check below to pass:

const TERMINATORS = new Set([".", "!", "?", "।", "…"]);
// ...
if (ch === "." && !/\s/.test(next)) continue;
if (ch === "." && isAbbreviation(this.buffer.slice(0, i + 1))) continue;
if (end + 1 < MIN_SENTENCE_CHARS) continue;

Two limits sit around that, both counted in JavaScript string length rather than visible letters. A boundary less than 12 units in is skipped, so tiny fragments don't go out on their own. If the buffer passes 240 with no ending in sight, it's cut at the last space at or before 240, or hard at 240 if there's no usable space, so audio keeps moving. When the model finishes, whatever's left is flushed, short or not.

The voice was the slow part in Gujarati

Voices are picked by language. With an ElevenLabs key set, English and Hindi use their Flash v2.5 model, which my build notes put at about 0.6 to 0.8 seconds a line. For Gujarati I tried eleven_v3, and in that one session it took about 8 seconds a sentence. That's far too slow for a call, so Gujarati goes through Twilio's own Google Chirp 3 HD voice instead, which Twilio synthesises itself.

For English and Hindi, each sentence is queued for synthesis as soon as it's written (two requests to the provider at a time, so one can wait its turn). Before a response goes back, the router waits up to 1.5 seconds for that audio. If a clip is ready it's played. If not, the line is spoken with Twilio's Chirp voice. The fixed prompts (the menu, consent, the holding lines) are queued for synthesis at startup and cached, with the same fallback if a clip isn't ready.

What's tested and what isn't

There are 45 tests, covering things like sentence boundaries, the diary and cancellation rules, and which fields are allowed into diagnostics. A separate eval script has 11 scripted conversations across the three languages, checking which tools the agent called and what state the diary ended up in. They're text conversations, not recorded phone calls.

It's still turn based. Replies from a finished turn go inside the speech gather in the TwiML, which is what lets a caller talk over them. The lines sent during an unfinished turn sit outside it, before the redirect. The tests check the TwiML that's generated; how interruptions behave on a real call is still to be tried. Full duplex audio would mean Twilio Media Streams and a streaming speech stack, and the agent sits behind an interface so that can be swapped in later.

Next is a real number, and timing what a caller actually hears on an Indian mobile network.

I made Claude Code and Codex race on my repo. The rule went against the agent that did more.

Hemanshu Upadhyay — Wed, 02 Sep 2026 08:57:20 +0000

Every week someone asks which coding agent is better, and every answer is a vibe. I wanted a diff.

So I built pairmark. One command in a JavaScript or TypeScript repo:

npx pairmark "add rate limiting to POST /api/login"

It creates two git worktrees at the same commit, gives Claude Code and Codex the identical brief, and streams both live in a split screen. When they finish, your own checks run in each worktree: tests, typecheck, lint, whatever package.json has. Then each agent reviews both patches blind, labelled A and B in random order, and scores correctness, completeness, quality and safety with citations. You get one HTML file with the verdict, the rule that decided it, both diffs, and a receipt image sized for posting.

The rules fit in five lines

If only one agent changed any file, it wins by default and the report says so.
If exactly one patch passes every check without touching the check configuration, it wins.
Otherwise, if both judges pick the same patch, it wins.
If the judges split, or both call it a tie, it is a tie, and the dissent is printed.
If neither judge returns a decision, the report shows the evidence only.

Two of those lines came out of an argument. I asked Codex to attack the first design before writing any code. Its second-round critique said a patch could win the checks by weakening them, and that blind judging by the same two models is only partly blind, since a model can recognise its own style. Both points are in the rules: a patch that edits package.json, tsconfig, or any test or lint configuration is flagged and cannot win on the checks alone, and judges only decide when they agree. A split is never averaged into a winner, because a 0.3 gap between two models grading their own work blind is noise, and calling noise a winner is the fastest way to make a tool untrustworthy. The whole discussion ships in the repo, verbatim.

The first race on its own repository

I asked both agents to add a runs subcommand to pairmark itself: list past runs as a table, newest first, with a unit test.

	Claude Code	Codex
Time	3m 28s	5m 15s
Files changed	4 (+122, -3)	5 (+105, -3)
Shell commands	11	37
Context read	548K tokens	1.23M tokens
typecheck, test, build	pass, pass, pass	pass, pass, pass
Judge score, avg of two blind judges	8.6 / 10	8.0 / 10

Both green. Then the twist. Codex also noticed that my build script would fail on a fresh checkout, because it copied a file into a directory that did not exist yet, and it fixed that. The fix lives in package.json. Rule 2 says a patch that touches the check configuration cannot win on the checks alone, so the win went to Claude Code, and Codex's dissent was recorded on the report: as a judge, Codex would have picked its own patch for matching the requested columns exactly.

That is the tool working as designed, against the agent that arguably did more. I took Codex's fix by hand and shipped Claude Code's patch as the real runs command. You can run it today.

The race before that was a tie

On a demo repo, the task was input validation with a typed error and tests. Both passed. Both judges, reviewing blind, picked their own patch. The rule says that is a tie, and the report says why each judge leaned the way it did: Claude Code's judge valued the broader tests, Codex's judge valued the smaller diff.

I find that more useful than a number. The same task produced two defensible answers, and the report tells you which values produced which answer.

What it is not

It is not a benchmark. It says "on this task, in this repo, today", and it says the rule that decided it. Run it ten times on ten real tasks and you have a basis for a decision about your own codebase. Run it once and you have a receipt.

It also cannot remove model preference from judging. That is why checks outrank judges, why judging is cross-checked, and why the report shows each judge's pick and reason instead of a single score.

Details

No API keys, no accounts. It runs on the Claude Code and Codex subscriptions you already have, through their CLIs.
TypeScript, Node 20, zero runtime dependencies. MIT.
node_modules is cloned into each worktree with copy-on-write where the filesystem allows, so both agents get their own tree in milliseconds.
Dirty working trees are snapshotted into both worktrees as the baseline, so the agents start from what you actually see.
Everything from a run stays on disk: raw event streams from both CLIs, both patches, the judge prompts, the worktrees.

Source: https://github.com/Hemanshu-Upadhyay/pairmark

If you run it on your repo, I would like to see the receipt. And if there is a repo you cannot share, send me the task and I will run it and send you the report.

I have built the same pipeline five times. The fifth took 68 minutes.

Hemanshu Upadhyay — Sun, 16 Aug 2026 11:22:13 +0000

On 11 June I wrote a program to find contract manufacturers for a supplements brand launching in India. The folder was created at 11:35 in the morning. There was a finished, scored report sitting in it at 13:55. Two hours and twenty minutes, most of which was me arguing with the scoring weights.

Three days later I wanted marketing agencies instead of factories, so I copied the shape and repointed it. 13:47 to 15:56.

On 23 June I wanted packaging and branding studios. That folder did not exist at 10:48 and there was a scored report in it at 11:56. Sixty-eight minutes.

Then one for remote jobs priced in dollars, nineteen commits between 14:19 and 15:15 on a Sunday. Then, on 14 August, one that finds companies who might buy from my own studio.

Underneath, they are the same program. Read a brief. Search. Open the actual pages rather than trusting the search snippet. Score each candidate against the brief. Write out the reasoning for every score. Flag the rows that look thin.

I get asked, in a slightly suspicious tone, why I automate so much of my own work. The assumption inside the question is that this is about speed, and that speed is a shallow thing to want.

Speed is real, and it is the least interesting part.

The machine keeps a file. I don't.

Last week I ran a verification pass over the fifth pipeline, the one that finds my own prospects. It went back through what it had already qualified and opened each company properly.

It disagreed with itself. Of the 58 companies it got through, it disqualified 21. Thirty-six percent.

I published that number, and a few people read it as an argument against building the thing in the first place.

Compare it to the handmade version. Earlier in August I wrote six outreach messages by hand. One company at a time, real research, a specific observation about each business, hours of work across a week. Every one of the six was delivered and read. Zero replied.

Now tell me my error rate on those six.

There isn't one. There is no file. There is no column where a past version of me wrote down what he believed about each company and why, so there is nothing to check the outcome against. All I have is a memory of feeling careful, and feeling careful is not evidence of anything.

That is the whole bias in one line. I would rather run a process that is measurably wrong 36% of the time than one that is unmeasurably wrong by an amount nobody will ever know.

A measured error is a Tuesday afternoon of work. The scoring model was reading "no marketing person listed on the team page" as "no marketing person exists," which is a different claim, and once it is written in a file you can see it and fix it. An unmeasured error is not a bug. It becomes a personality. It sits there for years being called judgement.

Human work does not produce receipts unless you force it to, and almost nobody forces it to. Automating a task is the cheapest way I have found to make my own reasoning legible enough to be proven wrong.

What 68 minutes does to which ideas you try

The second half of the bias is more boring and probably matters more.

The first pipeline cost two hours and twenty minutes. The third cost 68. That collapse changes which ideas are allowed to exist.

When a small system costs a week of evenings, you only build the ones you are already confident about, which means you only ever build things you already believed. When it costs an hour, you build the stupid one. In June I built a thing at one in the morning that takes a photo of a dress and finds similar ones across Indian stores, because my girlfriend asked and it was thirty-four minutes of work. It is running. It is genuinely useful. It would never have survived a business case.

Roughly a third of the ones I built on a whim turned out better than the ones I picked carefully, and I do not think that is luck. Careful selection filters for ideas that are easy to justify in advance, and the value in this stuff is rarely where the justification is.

Where the bias is wrong

I want to be honest about the failure, because the version of this argument without it is marketing.

I sent from the wrong stage. I looked at discovery output that had not been enriched or verified, decided the rows looked right, and sent ten emails. Two hard bounced on a sending domain that was nine days old. You do not get to undo that. The system was not wrong there. I was impatient with a system that was still working, which is a specific failure mode automation creates rather than solves.

And a second thing, which is the real boundary. Two of fourteen prospects died at a layer no pipeline can see: one founder wearing an OpenToWork banner, one correct decision maker with five connections and no posts, ever. Neither is discoverable from company data. No amount of pipeline reaches it.

So the rule I hold now: automate the collection, never the conclusion.

Every one of these five stops before the send. The step that has caught more real problems per minute than anything upstream is me opening one human being's profile and reading it for thirty seconds. That step gets more expensive as everything around it gets cheaper, and it should, because it was always the actual job.

The unglamorous version

I am not biased toward automation because it is impressive. Most of what I have built is a few hundred lines that reads pages and writes a CSV with a reasons column.

I am biased because it turns my opinions into artifacts. An opinion in your head cannot be audited, cannot be handed to someone else, and cannot be wrong out loud. The same opinion written as a scoring function can be all three by lunchtime.

Thirty-six percent wrong and improving beats an unknown number and a good feeling. That is it. That is the whole argument.

An AI Agent Found a Bug Nobody Wrote a Test For

Hemanshu Upadhyay — Mon, 03 Aug 2026 19:48:23 +0000

An AI agent found a bug that let a hotel check a guest into a room someone was already sleeping in.

Nobody wrote that test.

Nobody told it where to look.

We pointed it at the repository and gave it no test plan, no selectors, no "click here, assert that."

It figured the product out on its own.

It read the routes, API modules, services, and database schema, then reconstructed the business workflow:

• Book → Check-in → Night Audit → Checkout
• Group Reservations
• Cancellation → Availability Release

Then it executed those workflows end-to-end.

Not fake data.

Not mocked APIs.

Real reservations.

It verified data on the backend—not just whether the UI looked correct.

It completed 364 steps for $1.79.

And it found a critical production bug:

The check-in endpoint never validated room occupancy.

That isn't a broken button.

That's a guest arriving at 11 PM, walking into an occupied room, and your hotel paying for refunds the next morning.

Why this isn't another "AI testing your app" demo

Most browser agents only know how to click buttons and compare screenshots.

If the UI looks fine, they assume everything is fine.

Real products don't fail that way.

They fail in the gap between what the UI claims happened and what the backend actually persisted.

Our approach changes two things.

1. It reads the code before touching the UI.

Instead of following a human-written script, it derives its own test plan from your routes, services, and schema.

2. It verifies the backend, not just the browser.

It drives the UI with Playwright while validating state through authenticated API calls.

A green toast message isn't enough.

If the reservation wasn't actually saved, the test fails.

Three mistakes we made building it

1. Agents aren't deterministic.

One run found zero bugs.

The next found five.

Same repository.

Same commit.

The solution was to execute flows multiple times and merge the findings.

2. Agents hallucinate.

One run invented an API endpoint, received a 404, and confidently concluded the feature didn't exist.

We fixed that by giving it the application's real endpoint map instead of letting it guess.

3. Agents never know when to stop.

"Please wrap up when you're done."

It ignored us.

103 tool calls later, it was still exploring.

The fix wasn't a better prompt.

It was enforcing hard execution limits inside the tooling itself.

That's the real engineering challenge.

Getting an AI agent to click through a website is a weekend project.

Building one you'd trust to file production bug reports takes months of engineering guardrails.

This doesn't replace your existing test suite.

It finds the failures your test suite was never written to look for.

It's open source under the MIT license.

If you have a product with a real backend and want us to run it against your application, comment "run it" and we'll set one up.

Codedamn is changing the way of Learning how to Code

Hemanshu Upadhyay — Sun, 10 Apr 2022 12:00:39 +0000

Web development is one of the highest paying tech domain in 2022.
And there are many Free and Paid Resources are available around the Internet yet so many Developers/students face issues while learning it, because they realize the coursework for the most of programming Resource/Program is too intense/Unstructured, or they don't get satisfactory outcomes from their learning. but there's Perfect Blend of learning Web development and Getting the results of your learning and that is called Codedamn.

Let’s explore how Codedamn can help you to improve your Learning experience and can make you a better developer.

What is Codedamn?

Codedamn is an interactive learn-to-code platform where you can learn different Technologies and languages with structured Learning path. Codedamn is building the largest interactive coding platform. Learn to code, build projects and deploy apps right from your browser. with Codedamn learn different concepts and test what you learn by practicing it on your browser itself.

Advantages of using Codedamn

There are many Advantages that Codedamn provides you over any other learning platform and here are some Key advantages

Detailed Learning Paths
Codedamn's Playgrounds
Track Your Learning Progress
Learn by building Projects
Community Support

Let’s explore the advantages that Codedamn provides and learn how it makes your learning experience Superior.

1.Detailed Learning Paths

As Previously mentioned there are many Resources for Learning Web development but they are not Well structured. Therefore Codedamn provides you very structured Learning path/Curriculum curated by Experienced developers according to the market demand. Now learn Frontend, Backend or FullStack Development in a structured way and the way it matters most.

2.Codedamn's Playgrounds

Codedamn's Playgrounds enables you to have a real development experience minus the development setup. Playgrounds Is a platform which runs in your browser connected to computers in the cloud.
Codedamn playgrounds helps you to get out of Tutorial hell.
Main objective of Playgrounds is to Code and run your own experiments, try things around and build something new from what you have learnt without ever leaving the Browser.

Playgrounds currently supports these Coding languages.

Html/Css
ReactJs
VueJs
NextJs
Nodejs
Solidity
Python and
Swift

3.Track Your Learning Progress

Web development is very broad and complex topic, for that reason keeping the track of what you have learned is very essential.
Codedamn provides you the Dashboard functionality which assists you to keep track the track of what you have learned till now.
Dashboard helps you to track your learning, Track your Learning activity and set learning target for yourself. so you can achieve your goals more quickly.

4.Learn by building Projects

Building Projects is a practical and hands-on way to reinforce your learnings from learning paths. building the Projects to Enhance your skills to is the best practice you can do. On Codedamn Learn the skills by Building Industry standard projects available in your dashboard with detailed guide to how to get started with your preferred Project.

5.Community Support

Learning Web-development alone is difficult. You might run into some error or might not understand the specific topic, Therefore Codedamn has tightly integrated the learning platform with Codedamn's Discord community of learners and teachers. Codedamn's Discord Community will always be with you in your learning journey.

What The Users Think About the Codedamn

Get Started with Codedamn!

Try out Codedamn today, and enjoy the Learning experience like never before.

Getting Started With Codedamn's Playgrounds

Hemanshu Upadhyay — Tue, 05 Apr 2022 08:17:47 +0000

About Codedamn🚀 : Codedamn is an interactive learn-to-code platform where you learn by practicing concepts in-browser on real-world dev environments🧑‍💻.

Overview
Ever got stuck in Tutorial Hell??, Most of developers goes through this phase while Initially learning to code. to Get rid of the Tutorial Hell you can use Codedamn's Playgrounds. With the Playgrounds Build Awesome Stuff while Learning how to code without ever leaving your browser.
Playground Is a Platform which runs in your browser connected to computers in the cloud🌩. With the Playgrounds code in React, NodeJs or any popular language while learning with the codedamn's different [learning paths]🤓(https://codedamn.com/learning-paths).

Getting Started With Playgrounds.

Follow these Simple Steps To get started with Playgrounds

1. First Visit the Playgrounds Page by Clicking This link

2. After Clicking the Link Above You will be Redirected to the Playgrounds Home page which Looks like This image💻.

3.Now You can Select any language in which You want to start coding.👀

4.After Selecting your Preferred you will Be Redirected to the IDE in your browser With The All the Dependencies pre-installed for your Selected language.🚀⚛️

5. After Getting into the IDE You can start the coding And changes will be Reflected live into the secondary(browser Screen) Just like your In-Pc ide.🧑‍💻

Note💡 You can also use all the terminal commands in Playgrounds integrated terminal for example npm/yarn commands for installing any third party packages🤩.

That's all you basically Need to Know about Getting started with the Playgrounds, It's as simple as that🙌.
Try it Now

Thanks for Reading this Article..😊