Median Trap: Why AI Builds the Same App Twice

The median trap is why two people can point the same problem at a coding agent and get near-identical software. Hariprasad Sudharshan, a product manager with almost two decades in software, spent two years building a calculator alone, then found other people had independently built the same thing. The models and harnesses were the same, so the answers converged.

What Is the Median Trap in AI-Assisted Software Building?

The median trap is the tendency of AI-assisted development to produce the same solution for everyone who starts from the same model, harness and problem. Hariprasad Sudharshan, a product manager with roughly two decades of software experience, named the effect after two years of solo building produced a calculator his own circle had already seen in other products.

The mechanism is simple. A rented model does not know who is typing or from which country or which engineering level. Point the same problem at the same agent and it returns roughly the same scaffold, the same chunking strategy, the same vector store wiring. Sudharshan calls that shared answer the median, and he notes it rises with every release cycle because solved problems get absorbed into the next model generation.

That rise is useful and also a trap. A rising median means the starting line keeps improving for everyone equally. It is good enough to ship, and it is hard to tell apart from whatever the next builder ships. The AI Engineer conference talk where Sudharshan presented this argument is a personal reflection, not a controlled study, so treat the conclusion as one builder's pattern rather than measured market data.

One Project, Two Years, 244 Calculators

Sudharshan built more than a dozen applications in public over roughly three years, and he presents the calculator project as the clearest example of the median trap. He skipped social events and movie nights, ran several paid AI plans at once, and built the whole thing alone. When he soft launched it, his circle told him they had already seen similar calculators.

He then examined the alternatives. Some were not just similar, they were close to identical, and none of the 244 calculators he reviewed addressed the cost question he eventually pivoted to. Nobody had copied anyone, which is the point. The same models, the same tooling and the same familiar problem pulled independent builders toward one answer.

The same convergence shows up in LLM routing products, where competing tools occupy a narrow feature space and compete for a small slice of the market. When several products solve a problem the same way, the deciding factor moves away from the product itself.

Why the Median Is Free and Distribution Is the Moat

Once a problem is solved by a model, the solution is free for everyone who can prompt. Sudharshan argues this could not have happened before 2023, when the median product required a team, time and a stack. Today the same output arrives in a demo within hours and a launch within about four weeks.

The consequence is that the median loses durability in open competition. A dozen near-identical products chase the same users, and the product itself stops being the differentiator. Distribution becomes the moat, because the crowd of similar tools has to reach people somehow.

Sudharshan's framing of the flood of AI-built software is worth keeping. He rejects the term AI slop for the bulk of it, arguing the word is used without empirical analysis and that many of these projects succeed on their creator's own terms, whether that means revenue or something to show a colleague.

Model, Harness and Product Are Not the Same Thing

A recurring error Sudharshan describes is comparing products while believing you are comparing models. Claude Code, Cursor and Codex are not models in a head-to-head test. Each bundles a model with a particular harness: the tools, context handling, instructions, orchestration, memory, workflows and MCP tool calling wrapped around the underlying capability.

His analogy is a sprinter and a training program. The model is the athlete or the engine. The harness decides how that engine is driven. The product decides why anyone should care. Comparing a harness against a model is closer to comparing a country's track program against one runner.

This matters for benchmarking too. A leaderboard score such as 1503 for one model and 1460 for another is a relative rating derived from pairwise comparisons inside a specific evaluation environment, not an absolute intelligence scale. An 87-point gap does not mean one model is 87 points smarter in your workflow.

What Has Not Changed About Deterministic Software

The world still runs on deterministic software, and Sudharshan argues that has not changed. Build systems, operating systems, schedulers and databases were handcrafted over decades by humans, each layer feeding the next. A pacemaker and a flight control system are trusted because they do the same thing reliably every time.

The harness around a modern model is itself deterministic software. Agents, tool calls, orchestration and MCP layers are ordinary programs written in ordinary languages. The model supplies probabilistic judgment at particular steps, and the surrounding code supplies the reliability.

Sudharshan's two stated roles for AI follow from that split. It accelerates the writing of deterministic software at lower cost, and it makes previously uneconomical software possible because the budget constraint that killed those projects no longer applies.

Four Rules for Working Above the Median

Sudharshan's practical response is a set of rules he asks teams to run as a quarterly roadmap rather than as side-project advice. The common thread is that the median produces a working twin, and often that twin is already open source, so building it from scratch rarely pays.

• Be opinionated. In a field of medians, an opinion is the cheapest novelty you can own, and a model cannot supply it.
• Treat prompt-to-production as a median path. It is fine for internal tools and learning projects; it is not a differentiator.
• Treat "done" from an agent as the starting line. The agent produces a median artifact, and your work begins there.
• Leverage or fork what exists. If a mature project already solves your problem, adopting it beats rebuilding it.

The third rule carries a specific claim. Sudharshan argues coding agents deliver the last great design for free, meaning they are excellent at reproducing established patterns and poor at inventing the next Kafka or Kubernetes. Finding that next building block stays a human job.

The Novelty Budget: Name the One Distinctive Thing First

A novelty budget is one unit of genuine distinction, named before the build starts and reviewed as deliberately as any other project spending. Sudharshan adapted the term from the idea of a creative budget: if you can identify at least one true novelty, you have a chance of crossing the median for a meaningful stretch of time.

The test is whether you can state the novelty in a sentence. If you cannot name it, Sudharshan's advice is to concede that the project is a learning exercise, which is a legitimate goal. It is not a durable product advantage.

He applied the budget to his own calculator. Instead of another variant on the same solved problem, he rebuilt it around the cost difference between running open weights inside an enterprise and buying tokens from a provider. He reports feedback from enterprises exploring that path, and the resulting tool is open source and free to use.

Three Questions for Leaders Watching AI Demos

Leaders are seeing demos that would previously have taken a team a quarter to deliver, and Sudharshan argues their instincts are miscalibrated because those instincts formed when the same artifact implied far more effort. Recalibration by reading posts or watching videos does not work, in his account. It happens by building.

For leaders who do not build, he proposes three questions to ask after every demo.

Question	What it forces	Why it matters
Who has already done this?	A search before a build	Tames the build-first reflex
What do we have that competitors do not?	Novelty as a first-class concern	A better prompt still yields a median answer
Where will this application live?	Outcome-based thinking	A demo is an expensive way to discover you have no distribution

The three questions are not a decision procedure, and Sudharshan presents them as a habit rather than a method. Applied over the last year of his own work, they redirected the calculator from a median build into the inference-cost comparison it became.

FAQ

• What is the median trap in AI software development? The median trap is the convergence of AI-assisted builds toward the same solution when everyone rents the same model and harness. Hariprasad Sudharshan named it after two years of solo work produced a calculator other builders had independently arrived at. The answer is useful and very hard to differentiate.

• Why does the median rise with every model release? Solved problems get absorbed into the next model generation, so the shared starting point moves up and every builder gains the same capability. Sudharshan describes this as a good thing for capability and a trap for differentiation, because the improvement applies equally to your competitors.

• Is the median the same as AI slop? No. Sudharshan rejects the slop label, arguing it is applied without empirical analysis and that many of these projects succeed on their creator's own terms. He distinguishes between quality and distinctiveness: a median build can be good software and still have no durable advantage.

• What is a novelty budget? A novelty budget is the one distinctive thing a project will do, named before the build starts and tracked in the roadmap like any other line of spending. Sudharshan treats one genuine unit of novelty as enough to cross the median for a while.

• Can a coding agent replace human judgment? Agents reproduce established patterns well and do not invent new architecture, according to Sudharshan. He describes the agent's output as the last great design delivered for free, with the next building block still a human task.

• Why does the model-versus-harness distinction matter? Because comparing Claude Code, Cursor or Codex compares a model plus the tools, context and orchestration around it, not two models. Sudharshan argues this confusion explains why leaderboard gaps get mistaken for product advantages in planning meetings.

• Do leaderboard scores measure absolute model intelligence? No. A score such as 1503 or 1460 is a relative rating derived from pairwise model comparisons inside a specific evaluation environment. Sudharshan's warning is that small moving gaps should not be written into a product roadmap as an advantage.

• What did Sudharshan build after applying these rules? He rebuilt his calculator around the cost difference between running open weights inside an enterprise and buying inference from a provider. The earlier version competed with 244 near-identical calculators; the rebuilt version addresses a question none of them asked.

• Is prompt-to-production ever the right choice? Yes, for internal tools and learning projects. Sudharshan is explicit that these uses are fine and that the mistake is counting them as a differentiating factor when the product goes to an open market.

• What is the single most important takeaway? Novelty is scarce and the median is free. Sudharshan's closing argument is to spend effort on the one thing that cannot be copied from a prompt, because the shared starting point is available to everyone at the same price.

Bringing the Novelty Budget Into Your Own Work

The uncomfortable part of Sudharshan's argument is that the median is not a failure of effort. He spent two years and millions of tokens on architecture, agent design and prompt chains, and the result still had a twin. What changed was where the effort went: almost all of it into the one question his competitors had not asked.

That pattern applies to knowledge work outside software too. The distinctive part of an explanation is usually the specific thing a practitioner learned by doing it, and that is exactly the part that gets lost when a talk stays in video form. If you have that kind of material sitting in a recording, Skala Blog at skalablog.com takes a YouTube URL, transcribes the video, and turns it into a written draft you can edit and publish. The transcript becomes the raw material; the novelty in what you said stays yours.

Source video