Picture a D2C brand in Gurugram that adds an AI coding assistant, moves its order API to serverless functions and puts an edge network in front of the site, all in one year, because each came recommended. By Diwali the developers are typing faster, the cloud bill is bigger and checkout is slower than before. Each of the three fixes a real problem, and each moves a cost somewhere you were not looking. Knowing where that cost lands is what lets you adopt one without losing track of the others.
What an AI coding assistant changes
An assistant such as GitHub Copilot, or a chat model in the editor, suggests code while a developer types. It is good at the dull parts. Form handlers, mapping one JSON shape onto another, test scaffolding, the eleventh copy of a pattern the codebase already has ten of. It will sometimes point at a likely bug before you finish the line.
We treat its output as a first draft that a person reads properly, the way they would read a colleague's pull request. Tests matter more with an assistant, because the test is how you find out whether the draft does what you meant or what it guessed.
What it does not change is who owns the code. Suggested code compiles and looks plausible, and that is exactly why review gets skipped. A junior developer can now open a nine-hundred-line pull request before lunch, and a senior developer still has to read all nine hundred lines that afternoon. If the review habit was weak to begin with, the assistant grows the pile of unreviewed code faster.
What serverless changes
With serverless functions you deploy a piece of code and the provider runs it when a request arrives. No server to patch, and you pay for the time the function runs instead of a machine idling all night.
That fits uneven or low-volume work well. A contact form. A payment gateway webhook that fires when a UPI settlement completes. A GST report that runs on the first of the month and does nothing for the other thirty days.
The costs show up later. Cold starts add a delay to the first request after a quiet spell, which is fine for a webhook and annoying on a login screen. Functions are stateless, so anything that must survive between calls goes into a database or queue. Execution time limits make long jobs awkward, like a bulk import of a supplier's price list with forty thousand SKUs. A steady, high-volume API that gets hit every second through business hours can cost more as functions than as one small always-on server. And when an order passes through six functions and fails in the fourth, finding out why is harder than reading one application's log.
What the edge changes
Edge platforms run your code in many locations near visitors instead of in one region. That cuts latency for anything that can be answered without a trip to your database: redirects, header changes, sending a visitor in Kochi to the Malayalam pages, serving cached HTML.
The limit is data. If the edge function still queries a database in Mumbai on every request, the distance has only moved from the browser to the function. The visitor gains nothing.
- Browservisitor anywhere
- Edge locationredirects, cache, rules
- Serverless functionruns in one region
- Databaseone region, slowest hop
An edge function is quick only when it can answer without calling the origin.
Take a Diwali sale page. The banner, category grid and product images can all come from the edge, so a shopper in Guwahati gets them from somewhere close. Live stock and the price after a coupon code still come from one database, and no edge network shortens that hop. You probably do not need edge functions for this. A CDN with sensible cache headers on the static parts gets you most of the way.
Where teams pick the wrong one
Most of the trouble comes from choosing by trend instead of by workload.
A steady API moves to serverless to save money, the monthly bill rises, and the team spends a sprint chasing cold starts. Logic that needs fresh data goes to the edge, so every request crosses the country anyway. Assistant-written code goes in without tests, handles the common case, misses the odd ones, and the bug turns up three weeks later as a customer's WhatsApp screenshot.
Two more. Someone pastes proprietary code, or worse a customer export, into a tool nobody has checked for data handling terms. And a team adopts all three at once, so when checkout slows down nobody can say which layer did it.
A decision rule for each
| Option | Reasonable when | Wait when |
|---|---|---|
| AI coding assistant | Work is repetitive and every change is already reviewed | There are no tests and no review habit |
| Serverless | Traffic is uneven or the job is short and event-driven | Load is steady or jobs run long |
| Edge | Responses can come from cache or simple rules | Each request needs current data from one database |
The three sit at different layers, so you can try them separately. An assistant changes how code gets written. Serverless changes where it runs. Edge changes how close to the visitor part of it runs. Our post on AI pair programming and other tools changing developer work goes further on the first.
Measure first, then change one thing
Before adopting anything, find out where the time goes on one page or API call that matters. The checkout, or the order status screen your field staff open on patchy 4G. Measure on the real page, not the homepage. A quick first look from the terminal:
curl -o /dev/null -s -w "dns %{time_namelookup}\nconnect %{time_connect}\nfirst byte %{time_starttransfer}\ntotal %{time_total}\n" https://shop.example.in/checkout
If first byte is most of the total, the server or database is the slow part and edge will not help. Then open the network tab in the browser and check what the page loads after the HTML. Often the real fix is to ship less JavaScript, and none of the three is needed. Our guide to optimising a web app for speed, security and scale covers those fixes.
If servers sit idle most of the month and wake up for one job, test serverless on that job. If reviews are already thorough, give one team an assistant for a month and compare how many review comments come back against the month before. Pick one of the three, apply it to one workload, and leave the rest of the stack alone until you can see what it did. On our web development projects, that measurement comes before any change to the hosting.
