Writing

Build Notes: An AI Feature with Edge Functions

Every AI feature in my products follows one pattern, and after shipping it enough times I trust it completely: the client calls a Supabase Edge Function, the Edge Function calls the Claude API, shapes the response, and returns it. Nothing AI-related lives in the browser. This post is the working detail of that pattern, including the parts that only reveal themselves in production.

Why the seam goes where it goes

Two things live server-side that people are often tempted to put in the client, and both placements matter.

The API key, obviously. But also the prompt, and that's the underrated one. When the prompt lives in the Edge Function, improving the AI's behavior, tightening its output format, or handling a newly discovered edge case is a one-function redeploy. The app doesn't change, the client doesn't update, and the feature gets smarter in place. I've fixed production AI behavior in the time it takes to deploy a single function, which is the entire argument for the seam.

The shape of a feature, concretely:

client:        POST /functions/v1/extract-invoice  { fileUrl }
edge function: fetch file -> build prompt -> call Claude API
               -> validate/shape the response -> return JSON
client:        render structured result; nothing AI-aware

The client's ignorance is the design. It sends inputs and renders outputs, and everything intelligent stays behind the seam where it can evolve.

The JSON discipline

Most useful AI features need structured output, not prose, and structured output is where the pattern earns its scars. Three rules, all learned the expensive way:

Demand raw JSON in the system prompt, explicitly. No preamble, no markdown fences, no "Here's the extracted data:". Say it plainly and the model complies almost every time.

Parse defensively anyway. Almost is the operative word. Strip markdown fences before parsing, wrap the parse in a try, and have a defined behavior for the failure case. The one time in fifty that the response arrives wrapped will otherwise be a production bug, and it will happen at the worst possible volume.

Log every malformed response. This is the rule that pays compound interest. Each captured failure is exactly the example you need to tighten the prompt, and a month of failure logs turns prompt improvement from guesswork into engineering. My prompts are good because my logs made them good.

The two production lessons

Timeouts are real and generation is slow. Long AI generations bump against Edge Function limits. Anything heavy either streams to the client or gets decomposed into smaller calls. I learned both versions of this lesson with users watching, and now anything that might run long is designed for it from the start rather than discovered at the limit.

Validation belongs on your side of the seam. The model returns plausible output, and plausible is not the same as valid. Whatever the feature extracts or generates gets checked against your own rules in the function (required fields present, numbers in range, enums legal) before the client ever sees it, with a review lane for anything that fails. The AI proposes; the function disposes.

Where this pattern stops

Honesty requires a boundary. This pattern is built for request-and-response AI features: extract this, classify that, draft the other. It is not the pattern for real-time collaborative AI, long agentic workflows, or anything where the model needs to hold a conversation across minutes of state. Those need different architecture, and stretching this seam to cover them is how clean patterns get bad reputations.

For the request-and-response class, though, which covers most of what an operations product actually needs, this is the whole recipe. One seam, server-side prompts, JSON discipline, failure logs, and validation before display. This function sits inside the same pipeline I run end to end, and it's the pattern behind most of the use cases worth shipping this quarter.

If you're running a similar stack and have scars I haven't collected yet, I'd genuinely like to compare notes; the contact form on the main site reaches me.


Rosemarie Withee has spent thirteen years helping operations teams get real work out of their software, first Microsoft 365, now AI. She’s written six books for Wiley and builds AI products at Portal Integrators.