AI tools make it cheap to produce reliable deterministic software, but they also make similar products easy for everyone to build.
2
A working demo usually sits at the median unless its creator can name a specific novelty and reach users through distribution.
3
Teams evaluating AI demos should search for existing solutions, identify their distinct advantage, and ask where the application will live.
Summary
Hariprasad Sudharshan argues that AI changes how software is produced without changing what the world ultimately needs: reliable deterministic software. Models provide capability, while harnesses provide tools, context, orchestration, memory and workflows. Since these resources are increasingly rented by everyone, different builders often reach similar products. Sudharshan calls this shared outcome the median. It is useful for internal tools, learning projects and many personal launches, but it is difficult to defend in an open market. He describes his own two years of solo building, including a calculator that converged with many other calculators. His remedy is a novelty budget. Before building, name the distinctive element, put it in the roadmap and review it like project spending. Leaders should ask who has already solved the problem, what their team has that others do not, and where users will find the product. His revised calculator compares the cost of running open model weights inside an enterprise with buying inference.
AI-assisted development still produces deterministic software for the world
Sudharshan begins with a city-wide software failure, from grounded flights and stopped subways to broken elevators and phones. He distinguishes the traditional deterministic software that runs these systems from the probabilistic models now used to build software. In his view, AI will mainly accelerate the production of deterministic software and make previously unaffordable projects possible. The final systems still need to perform the same way reliably. The tool chain around the model, including agents, tools and MCP, remains deterministic software built by engineers.
Small model leaderboard gaps do not make a product advantage
Sudharshan compares model rankings with elite athletics. In the 2015 race he cites, nine athletes were separated by only 27 hundredths of a second, and Usain Bolt beat Justin Gatlin by a hundredth. Model leaderboards also move with each release, with scores such as Anthropic at 1503 and Mistral at 1460. He says these are relative ratings from a comparison environment, not an absolute intelligence scale. Teams can compare models, but they should not turn a small, moving frontier gap into the basis of a product roadmap.
A model, its harness and its product are different things
Sudharshan separates the model from the harness and the product. The model is the underlying engine or capability. The harness controls how it is used through tools, context, instructions, orchestration, memory, workflows and MCP calls. The product answers why a customer should care. Comparing Claude Code with Cursor or Codex therefore compares more than models, much like comparing an athlete with the training system around that athlete. Since builders can rent both models and many harnesses, the old differences created by engineers' judgment become harder to preserve.
The median is a useful shared answer that competitors can reproduce
Sudharshan calls the common solution produced by the same models and tools the median. It moves upward as models absorb previously solved problems and improve through new releases. That is useful because it lets people ship working software quickly. It is also a trap in an open market, since another person can use the same source and produce something similar or identical. He says this was harder before 2023 because the median required a team, time and a technology stack. Now the solved starting point is free to everyone, so distribution may matter more than the product itself.
The build first reflex replaces search with immediate construction
Sudharshan says builders used to search more because building was costly. Now the easier move is to open a coding agent as soon as a problem appears. The agent can produce scaffolding in two minutes, a working demo in two hours and, in his estimate, a real product within four weeks. Only later may the team discover that it built the 400th or 4,000th retrieval-augmented generation system even though mature open-source options already existed. He calls this habit the build first reflex. The remedy starts with searching before committing to construction.
A functioning demo can still be a successful learning project
Sudharshan rejects the blanket use of AI slop for every similar application. He says AI-assisted development brings people into software who have never built before, and their success may mean showing a website to colleagues rather than earning revenue. He names Lovable and Replit as places where millions of people have done this. A generated application can be useful for its creator or for internal use even when its finished artifact resembles other products. His warning is narrower: teams should stop counting that common starting point as a differentiating factor.
A novelty budget makes distinctiveness an explicit project expense
After two years of spending time on architectures, agent designs, prompt chains and workflows, Sudharshan changed how he built his calculator. He spent his effort on differentiation instead of demonstrating his Claude Code skills. His novelty budget asks builders to name one novel element before work begins, add it to the roadmap and review it like other project spending. If they cannot name one, he says they should call the work a learning exercise. His four rules include being highly opinionated, accepting the median path for internal software, and treating an agent's 'done' as the point where the human's work starts.
Leaders should test demos against existing solutions and distribution
For leaders reviewing a stream of impressive demos, Sudharshan proposes three questions. Who has already done this? That forces the team to search before building. What does this team have that another team or competitor does not? That makes novelty explicit. Where will the application live? That shifts attention from the demo to users and distribution. He says leaders cannot recalibrate their judgment by reading posts or watching videos alone. They need to build, because the same deliverable that once required a team and a quarter can now appear from a new engineer much faster.
Open model weights do not remove the cost of inference
Sudharshan revised his calculator after asking what sits between open weights and a token-generating system, and what an enterprise must pay for that system. He describes ten layers between the weights and generated tokens, including ML operations, site reliability engineering, precision, KV cache, batching, execution parallelism and utilization. Some layers require specialists, while utilization is structural and cannot simply be purchased. The revised calculator compares the cost of running identical weights inside an enterprise with purchasing tokens from the cloud. His point is that open weights alone do not cross the median.
"The bottom line is we will be using a probabilistic gear to crank out a reliable deterministic software by augmenting or somebody will go to an extent say replacing human judgment."06:06
Who should watch
You are deciding whether an AI-generated demo deserves product investment, and you need questions that expose existing solutions, distinctiveness and distribution.
You build internal tools or learning projects with coding agents and want to know when a useful result should be treated as a median solution rather than a market advantage.
You are considering open model weights for enterprise deployment and need to think about inference infrastructure, specialist skills and utilization.
