salil, Author at appening

Build Model-Agnostic: Where Your Real AI Moat Lives

July 13, 2026 in AI Engineering

A new model tops the benchmarks every few weeks. The one you built on six months ago is probably not the best option anymore, and the one you would pick today likely will not be the best option six months from now. This is not a temporary phase that settles down once the dust clears. For the foreseeable future, it is the weather.

So here is the question worth sitting with, because your architecture has already answered it whether you meant to or not: if a better model dropped tomorrow, how long would it take you to switch to it?

If the honest answer is “that would be a rewrite,” then the bet was placed in the wrong spot. Not because the model you chose was wrong, but because your system was built as though the choice were permanent, in a world where it is anything but.

The ground under AI products has shifted

For a while it made sense to treat the model as the heart of an AI product — the hard-won center everything else attached to. That assumption is quietly expiring. The context that makes a model useful for a specific user is increasingly portable. In many setups you can now export what the system knows about a user — their history, their preferences, the accumulated state that makes the experience feel tailored — and carry it to a different model in a short amount of time.

When you do, you often recover most of the performance almost immediately. Not because all models are identical, but because a large share of what felt like the product’s intelligence was never really living in the model. It was living in the context wrapped around it. The model was doing the reasoning, but the context was doing the personalization, and only one of those two is hard to move.

That changes what the model actually is in your stack. It is no longer the irreplaceable core. It is the cheapest, most swappable part — a component you should expect to replace more than once over a product’s life. Architecting as though it were permanent is building on the one piece that is guaranteed to change.

Your moat is the context layer you own

If the model is not the moat, it is fair to ask what is. The answer is the part that does not travel to your competitors: the context layer you own. Your data. Your workflows. The history you have accumulated about your customers and the specific problems they are trying to solve.

That layer is genuinely yours in a way a model never is. Any competitor can call the same model you call, often on the same day you get access to it. What they cannot do is instantly reproduce the years of workflow refinement, the proprietary data, and the deep record of customer behavior that make your product fit its users the way it does. Two products can sit on the identical model and deliver completely different value, and the difference is almost entirely in the context and the system around it.

This is why the model being swappable is good news rather than a threat. When the intelligence is a commodity you can buy from several vendors, the competition moves to the layer where you actually have an advantage — and that is the layer you build and own, not the one you rent.

Why the abstraction has to sit in the right place

Models leapfrog each other every few months. Given that, the goal is an architecture where adopting a better one is a configuration change and an evaluation run, not a project. When switching a model costs you a rewrite, it is a sign the abstraction was built in the wrong place — that model-specific assumptions leaked into parts of the system that should never have known which model they were talking to.

A model-agnostic architecture keeps that boundary clean. The model sits behind a thin, well-defined interface. Your prompts, your orchestration logic, your context assembly, and your evaluation suite all live on your side of that line and do not care which vendor is answering. When something better appears, you point the interface at it, run your evaluations to confirm the behavior holds, and move on. The cost of switching drops from months to an afternoon, and you get to actually take advantage of a fast-moving field instead of being trapped by the last good decision you made.

None of this is exotic engineering. It is the ordinary discipline of putting the volatile thing behind a boundary and keeping the durable things — your context, your logic, your tests — independent of it. The teams that do this quietly benefit every time the frontier moves. The teams that do not pay for the same upgrade with a rebuild.

Build versus buy, pointed the right way

All of this reframes the oldest question in the book. For AI products, the useful version of build versus buy is this: buy the intelligence, and build the system around it.

Buy the intelligence, because the model is a commodity input produced by vendors spending enormous sums to push it forward, and you cannot and should not try to out-build that. Build the system, because the system is where your advantage actually lives — the context layer, the workflows, the evaluations, the accountability, the parts competitors cannot copy by signing up for the same API.

Get this backwards — treat the model as the thing you carefully build around and permanently commit to, while the system stays thin — and you sign yourself up to rebuild annually, chasing a frontier you structured yourself to fall behind. This connects to a distinction we keep coming back to in production-ready AI and in the unit economics of AI agents: the impressive part and the durable part of an AI product are rarely the same thing, and the durable part is almost always the system, not the demo or the model powering it.

How we think about it at Appening

When we help teams build with AI, we try to treat the LLM as a commodity input from the very first architectural decision — something to keep behind a clean boundary and swap without ceremony — and to pour the real engineering into the part competitors cannot copy. That means investing in the context layer, keeping orchestration and evaluation independent of any single vendor, and designing so that the next great model is an upgrade you get to enjoy rather than a migration you have to survive.

The frontier is going to keep moving. That is a gift to the teams built to absorb it and a tax on the teams built to resist it. The difference between the two is almost entirely a matter of where the abstraction sits and where the engineering went.

So it is worth asking plainly: is your moat in the model, or in the system you wrapped around it? If you are not sure, or if the honest answer is that switching models today would hurt, we are happy to help. Book a free 30-minute consultation and we will look at where your architecture is betting on the model staying still, and how to move that bet somewhere it can actually pay off.

The AI Agent Demo Looks Great. What Are Its Unit Economics?

June 8, 2026 in AI Engineering

A slick AI agent demo is a genuinely exciting thing to watch. The agent takes a messy request, reasons through it, calls a few tools, and hands back something useful in seconds. It is easy to walk away from that moment convinced the product is basically done. But there is a question the demo never answers, and it is the one the business actually rests on: what are the agent’s unit economics?

A demo shows that something is possible. Unit economics show whether it is viable. Those are not the same finding, and the gap between them is where a lot of promising AI products quietly get into trouble.

What does one run actually cost?

The first question is the most concrete one. Every time the agent completes a task, it consumes tokens, and those tokens have a price. So what does a single successful run really cost once you add up the model calls, the retries, the tool usage, and the context it has to carry?

The number matters most when you set it next to what you charge. If the agent burns four dollars of tokens to do a task the product charges three dollars for, the demo still looks flawless while every single use loses money. Nothing on screen tells you this. It only shows up when someone works out the cost per run and compares it to the price, and that arithmetic is easy to postpone in the excitement of a working prototype.

Does the cost hold when it scales?

The second question is what happens to that math as usage grows. A cost that is comfortable at a hundred runs a week can behave very differently at ten thousand users. Some costs stay flat, some fall with volume, and some quietly climb as usage patterns get heavier and edge cases multiply.

The outcome you want to rule out is the one where the margin inverts the moment the product succeeds — where growth, the thing you were aiming for, is exactly what turns a healthy-looking feature into a loss. Understanding whether your economics improve or decay with scale is not a detail to sort out later. It is the difference between a product that gets stronger as it grows and one that gets more expensive to keep alive.

Who is accountable when the agent gets it wrong?

The third question is not about money, and it is often the one skipped entirely. When an agent acts on a customer’s behalf and gets it wrong — books the wrong thing, sends the wrong message, makes a decision with real consequences — who owns that outcome? The company that shipped the agent, the customer who trusted it, or the vendor whose model produced the result?

A demo runs in a friendly environment where mistakes are harmless. Real use does not. The moment an agent can take actions that affect someone, accountability stops being a philosophical question and becomes a practical one that shapes your design, your terms, and your support. Deciding it deliberately, before the first real mistake, is far better than discovering the answer during one.

The demo is a feature. The business case is something else.

It is easy to fall in love with a demo and skip every one of these questions, because the demo feels like proof and the questions feel like friction. But the demo and the business case are two different things.

The demo shows that the feature works. The business case is whether that feature has positive margin at the scale you are aiming for, and whether there is someone clearly accountable when it fails. A feature can be technically impressive and commercially unworkable at the same time, and only the second set of questions will tell you which one you have.

This is a close cousin of a theme we return to often: the distance between something that demonstrates well and something ready for the real world. We wrote about the engineering side of that gap in moving from vibe coding to production-ready AI. Unit economics and accountability are the business side of the very same gap.

How we think about it at Appening

When we help teams build with AI agents, we try to treat the demo as the start of the evaluation rather than the end of it. That means working out the cost per run early, pressure-testing whether the economics survive scale, and being clear about who is accountable when an agent acts and gets something wrong. These are not reasons to avoid building agents. They are how you build one that still makes sense as a business once real users arrive.

The exciting part and the durable part of an AI product are rarely the same thing, and the work is in making sure the exciting demo is backed by economics and accountability that hold up.

If you are building an AI agent and want to know whether the business case is as strong as the demo, we are happy to help you work through the numbers and the risks. Book a free 30-minute consultation and we will look at what a run really costs you, how it behaves at scale, and where accountability needs to sit.

AI Writes Code Faster. Here’s What That Does to Code Review.

May 11, 2026 in Product Engineering

AI is making developers write code faster. Not a little faster — a lot faster. And that speed lands somewhere specific in a team: it lands on the people who review the code. Senior engineers and tech leads who used to see a manageable stream of pull requests are suddenly facing a flood of them.

When the volume climbs past what careful review can keep up with, something has to give. Usually it is the review itself. Reviews get shallower. Approvals get faster. And slowly, almost without anyone deciding it, the codebase stops being watched the way it used to be.

The quiet trap

This is the trap, and it is easy to walk into because every individual step looks reasonable. A reviewer with forty pull requests waiting cannot give each one the attention they gave when there were four. Approving quickly feels like helping the team move. No single fast approval causes a problem. It is the accumulation of them, over weeks, that changes what a team actually knows about its own system.

We have been so focused on making code generation faster that it is easy to forget what code review was doing all along. It was never only about catching bugs.

What code review was really for

Catching defects is the part of review that is easiest to name, so it gets treated as the whole point. It is not. A good review has always done quieter, more important work underneath.

It is knowledge transfer. When a second engineer reads through a change and understands why it was made this way, the understanding of that part of the system now lives in more than one head. Review is how a team keeps a shared mental model of its own codebase alive — how the person who wrote a module and the two people who reviewed it all carry a piece of the same picture.

That shared picture is what lets a team move confidently. It is why someone can pick up a teammate’s work when they are out, why a change in one corner does not quietly break another, and why the system stays comprehensible as it grows. Review is one of the main ways that understanding gets distributed instead of trapped in one person.

What actually breaks

So when review thins out under the weight of AI-generated volume, the loss is bigger than a messier codebase. You get a team where nobody fully understands what they are sitting on.

The code still runs, which is what makes this so easy to miss. Everything looks fine right up until the moment someone needs to change something important, and discovers that the understanding required to change it safely was never shared — or worse, never existed, because the code was generated and approved without anyone truly reading it. A system that no one understands is fragile in a way that does not show up on any dashboard until it fails.

Keeping review meaningful when code is cheap

The answer is not to slow code generation back down. The speed is worth having. The answer is to be deliberate about protecting what review was quietly providing, now that the volume has changed.

Part of that is right-sizing what review focuses on. When a machine can produce a hundred lines in seconds, reading every line with equal attention is neither possible nor the point. The attention is better spent on intent and structure: does this change fit the architecture, is the approach sound, will the next person understand why it exists. The reviewer’s judgment matters more than ever, applied where it counts most.

Part of it is cultural. A team can decide, explicitly, that shared understanding is something it will not trade away for throughput — that generated code still gets read by a human who can explain it, and that keeping the mental model alive is part of the job rather than an afterthought. This connects directly to a rule we keep coming back to in production-ready AI: don’t ship code no one on the team can explain. Review is where that rule is enforced in practice.

How we think about it at Appening

In our own work, we treat review as one of the places where engineering judgment earns its keep, not a checkbox to clear on the way to merging. As AI raises the volume of code, we lean on review even more deliberately — to keep the architecture coherent, to keep understanding distributed across the team, and to make sure speed at the keyboard does not quietly become fragility in the system.

The pattern underneath all of this is the same one we keep seeing. AI changes what is cheap, and in doing so it puts new pressure on the human practices that were holding quality together. The teams that do well are the ones that notice which of those practices still matter and protect them on purpose.

If your team is generating code faster than it can meaningfully review it, we are happy to help you find a rhythm that keeps both the speed and the shared understanding. Book a free 30-minute consultation and we will talk through where AI can accelerate your team and where human review still needs to hold the line.

Everyone Can Build Now — The Hard Part Is Maintaining It

April 13, 2026 in Product Engineering

“Everyone’s a builder now.” It has become the rallying cry of the AI era, and there is a lot of truth in it. Vibe coding, no-code agents, AI-generated apps — the barrier to turning an idea into working software has never been lower. For anyone who has spent years helping founders get from idea to launch, this is genuinely exciting. More people can make more things, and many of those things would never have existed otherwise.

There is a part of this story, though, that gets far less attention than it deserves. Building has been democratized. Maintenance has not.

The gap between building and keeping

It is easy to hand someone the ability to build. The tools do that on their own now. It is much harder to hand someone the ability to keep what they built running well as it grows, changes, and meets real users. Those are different skills, and only one of them has been made abundant by AI.

We have watched this pattern play out with clients more than once. The prototype gets built over a weekend and it looks great. Then the cleanup takes months. The gap between “it works on my screen” and “it works reliably for everyone, and we can safely change it next quarter” is where the real cost lives, and it rarely shows up in the excitement of the first demo.

Where the debt quietly accumulates

When a working prototype appears in a few hours, it is tempting to keep going in the same mode — add another feature, then another, until the token budget runs out and the project is handed off with a quiet “good luck.” The problem is that the code underneath was written to prove an idea, not to be lived with. Left unexamined, it turns into debt that someone pays down later, usually at a worse time and a higher price.

Two questions tend to separate the teams that stay ahead of this from the teams that get buried by it.

The first is whether there are guardrails that stop prototype-grade code from quietly making its way into production. Prototype code is a wonderful thing in its place. It becomes a liability the moment it slips into the system real users depend on without anyone deciding, on purpose, that it is ready. A clear line between “this was built to explore” and “this is built to keep” is one of the most valuable boundaries a team can hold.

The second is who owns the abstraction layer that keeps the whole thing from spiralling. As a product grows, something has to hold its shape — the shared structure that lets new features slot in without every addition making the next one harder. That ownership does not appear on its own, and AI will not volunteer it. It is a human responsibility, and naming who holds it early is what keeps a fast-moving codebase from turning into a tangle no one wants to touch.

Engineering culture is the deciding factor

This is the heart of it. AI gives almost everyone the power to build. What decides whether that power creates lasting value or just creates debt is the engineering culture around it — the habits, standards, and judgment that a team brings to the code an AI helps them write.

A team with that culture treats a fast prototype as a beginning: something to learn from, then to harden deliberately if it earns the right to stay. A team without it treats the prototype as the finish line, and inherits the maintenance bill without having planned for it. The tools are the same in both cases. The outcome is not. This is the same idea we explored in moving from vibe coding to production-ready AI: the model is rarely the constraint, and the people and their standards usually are.

None of this is an argument for slowing down. The speed AI gives you is real and worth using fully. It is an argument for spending a little of that speed on intent — on deciding, deliberately, which code is meant to last and who is responsible for keeping it coherent.

How we approach it at Appening

The way we tend to work is to let prototyping run fast at the front of a project and then bring real engineering discipline to bear the moment an idea is worth keeping. That means drawing a clear line between exploration and production, owning the structure that holds a growing product together, and making sure the code we leave behind is code a team can understand and change without fear.

The goal is simple to state and harder to live by: build fast, and build with intent. The speed is what gets you to a good idea quickly. The intent is what makes sure that idea is still an asset a year later rather than a bill.

If you are building quickly with AI and want to make sure you are creating value rather than quietly accumulating debt, we are happy to help you put the right guardrails in place. Book a free 30-minute consultation and we will look at where your prototypes can move fast and where a little engineering discipline will save you months later.

Prototyping Is Free Now: How Founders Should Make Better Product Decisions

March 9, 2026 in Design Thinking Product Engineering

There is a shift happening in how products get built that does not get talked about enough, and it is easy to understate. The instinct is to say prototyping has gotten cheaper, or faster. That undersells it. For a growing range of ideas, prototyping is now essentially free.

Not free as in low cost. Free as in the effort of turning an idea into something real and clickable has dropped close to zero. That single change quietly rewrites how good product decisions get made.

What “free” actually means here

Consider the loop most teams have lived inside for years. You have an idea. You write a spec. You hand it to engineering. You wait two or three weeks. Something comes back. You look at it and realize the idea needed to change the moment you could finally see it. Then the loop starts again.

That loop still exists. What has changed is its length. The same cycle that used to take three weeks can now take a few hours. When the cost of seeing your idea running drops that far, you stop rationing prototypes. You stop treating them as a scarce resource you have to justify. And once prototypes are abundant, the smart way to make product decisions changes with them.

Build the versions instead of arguing about them

Teams spend a surprising amount of energy debating which direction to take before anyone has seen any of the directions. Should the onboarding be a single screen or a guided flow? Should the dashboard lead with the chart or the list? These conversations can run for days, and they are often decided by whoever argues most confidently rather than by evidence.

When a working version of each option takes an afternoon, the debate becomes unnecessary. Build all three. Click through them. The right answer usually announces itself the moment the options are sitting side by side, because judgment about a real thing is far more reliable than judgment about a described thing. The discussion moves from opinion to observation, which is where product decisions belong.

Let a working prototype carry the spec

A written specification is an attempt to describe an experience in words so that someone else can rebuild that experience in their head. It is a lossy format. Two people read the same PRD and picture two different products, and the gap only surfaces weeks later when the built thing does not match what anyone imagined.

A working prototype closes that gap. It communicates the idea directly, with no translation step in between. Everyone in the room is reacting to the same concrete thing, which means the feedback is about the actual product instead of about competing interpretations of a paragraph. Written detail still matters for the parts a prototype cannot show, but the prototype now does the heavy lifting of alignment that documents used to do poorly.

Put something real in front of users

For a long time, early user feedback meant showing people wireframes or static mockups and asking them to imagine the rest. People are gracious in those sessions, and they are also guessing. Asking someone how they feel about a picture of a product tells you far less than watching them try to use the product.

Now you can hand users something real to click on well before you have committed to building it properly. The feedback you get from that is a different category of useful. You see where they hesitate, what they tap that does nothing, which step they abandon. That is the kind of signal that actually redirects a product, and it arrives early enough to act on cheaply.

What does not become free

It is worth being clear about the edge of this. Prototyping becoming free does not make everything free. Two things in particular still ask for real skill and real work.

The first is judgment about what is worth building at all. A tool that generates ten prototypes in a morning does not tell you which of the ten deserves to exist. Taste, market understanding, and a clear sense of the problem still come from people, and they matter more now, not less, because the volume of options has gone up.

The second is everything that happens after a prototype earns the right to become a product. A convincing demo and a system real users can depend on are separated by testing, security, architecture, and code someone actually understands. We wrote about that gap in more detail in our piece on moving from vibe coding to production-ready AI. Free prototyping gets you to the right decision faster. It does not carry that decision the rest of the way to production.

How we work with founders on this

The founders we work with at Appening who have internalized this are, in our experience, making better product decisions and making them faster than before. The change is less about any single tool and more about a habit: when you are unsure, you build the thing and look at it, rather than debating it in the abstract.

Our role tends to sit on both sides of that line. We help teams use prototyping to explore quickly and decide well, and then we bring engineering judgment to the parts that turn a chosen direction into something dependable. The speed at the front of the process is only valuable if the fundamentals hold up at the back of it.

If you are building a product right now and want a faster, more honest way to decide what to build, we are happy to help you set that loop up. Book a free 30-minute consultation and we will walk through where prototyping can save you time and where careful engineering still earns its keep.

From Vibe Coding to Production-Ready AI: What Changes When Real Users Depend on Your Code

February 9, 2026 in AI Engineering

Andrej Karpathy gave a name to something a lot of people were already feeling. In early 2025 he described “a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” You describe what you want, the model writes it, and something real appears on the screen minutes later.

The term spread because it captured a genuine shift. Building a working prototype used to take weeks. Now it can take an afternoon. That change is worth celebrating, and it has opened the door for far more people to turn an idea into something they can click through and react to.

It also raises a quieter question that matters a great deal once an idea starts to work: what has to be true before other people can depend on it?

Vibe coding is a real superpower for the early stage

There is a version of this conversation that treats vibe coding as a shortcut people should feel bad about. We see it differently. For exploration, it is one of the most useful things to happen to software in years.

Simon Willison, co-creator of the Django web framework, has written some of the clearest thinking on this. His take on the early stage is direct:

If you’re vibe coding something for yourself, where the only person who gets hurt if it has bugs is you, go wild.

A prototype is close to free now. You can describe an interface, watch a model build a convincing version of it, and learn more in an afternoon of clicking than in a week of planning documents. When the stakes are a personal tool or a throwaway experiment, speed is the whole point, and reviewing every line would only slow down learning. Teams that use this well move through ten ideas in the time it used to take to build one.

What changes the moment other people depend on it

The picture changes when the same code moves from your screen to someone else’s hands. Willison draws the line clearly:

The moment you ship your vibe coding code for other people to use, where your bugs might actually harm somebody else, that’s when you need to take a step back.

That is the sentence worth sitting with. A bug in a weekend project costs you a little time. A bug in software that handles a customer’s payment, a patient’s record, or a founder’s launch can cost someone else something real. The code did not get more complicated between those two moments. The consequences did.

This is why Willison later proposed a companion term, “vibe engineering,” for what happens when experienced engineers use these same AI tools with care rather than abandon. Same tools, different discipline. The difference is not the model you prompt. It is what you do with what it gives back.

The bottleneck moved, and it moved somewhere specific

For most of software’s history, the hard question was “can we build this?” Building was slow, so the ability to build was the scarce thing.

AI coding tools have largely answered that question. For a wide range of products, yes, it can be built, and quickly. So the scarce question has shifted to a different one: “is this ready for real use?” That is now where projects get stuck, and it is a genuinely harder question than it sounds.

Getting to a convincing demo and getting to production-ready are separated by a set of problems that a fast first draft tends to skip. What happens under real load? What happens when a user does something unexpected? Where does sensitive data live, and who can reach it? When an AI agent takes an action on a user’s behalf, what stops it from taking the wrong one? None of these show up in a five-minute demo, and all of them show up in week three of real usage.

What production-ready actually asks of you

Production readiness is less a feature and more a set of habits applied to the code an AI helps you write. A few of them carry most of the weight.

Code you can explain. Willison offers a golden rule that travels well: “I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else.” A model can produce a working function you have never read. That is fine for a sketch and risky for a system, because you cannot safely change, secure, or debug code you do not understand.

Testing that reflects real conditions. A demo proves the happy path works once. Test coverage proves the unhappy paths are handled every time, which is what real users generate constantly.

Security and safe agent design. AI agents are powerful precisely because they can act, which means the design has to define clearly what they are allowed to do, what they never do without a human, and how secrets and private data stay protected. This is architecture work, and it is difficult to retrofit after the fact.

Architecture that can hold weight. The structure that lets a prototype run for one person is often not the structure that lets a product serve thousands. Deciding where that line is, and building past it before it breaks, is judgment that comes from having shipped real systems.

None of these replace the speed AI gives you. They are what let you keep that speed without paying for it later.

The real gap is the people who can wield the tools

Here is the pattern we keep coming back to. The AI models and the platforms built on them are already strong enough to generate production-grade code. The constraint is rarely the tool. It is whether someone in the room can direct that tool with clear intent, recognize when its output is quietly wrong, and make the architecture and security decisions the model will not make on its own.

AI amplifies engineering skill. Where that skill is present, the results compound: more value, in less time, at lower cost. Where it is absent, the same tools produce something that looks finished and behaves unpredictably the moment it meets real users. The teams shipping well right now are not simply the ones moving fastest. They are the ones moving quickly while keeping the fundamentals intact, because they have people who know which fundamentals cannot be skipped.

How we think about it at Appening

We have worked with AI coding agents since the early days, when they were rough and needed a lot of steering. For over a year, our team has built primarily through app builders, coding agents, and AI-native tooling rather than writing code by hand, using engineering fundamentals to guide those tools toward code that holds up. That approach is why we can take an early idea and make it production-ready in weeks: lower cost, faster time to market, and a short loop from feedback to release.

The goal is not to move faster for its own sake. It is to move quickly on the parts that should be quick, and to bring real engineering judgment to the parts that protect the people who will eventually depend on the software.

If you are integrating AI into your product right now, a fair question to ask yourself is which side of the line you are on: exploring freely with a prototype, or building something your users are about to rely on. Both are valid. They just call for different care.

If you would like to talk through what production-ready AI looks like for your specific product, we’re happy to help. Book a free 30-minute consultation and we’ll walk through where you are and what it would take to ship with confidence.