DEV Community: Tushar Vashishth

The Navier–Stokes Problem Has Survived for a Century. Did AI Find Something New?

Tushar Vashishth — Fri, 18 Sep 2026 10:37:38 +0000

Imagine dropping a small stone into a perfectly calm lake.

You see the ripples moving outward.

It looks simple.

Now imagine trying to predict the exact position of every ripple, every tiny swirl, every change in speed, and every interaction between those ripples several minutes later.

Suddenly, it doesn't look so simple.

Now make the problem even harder.

Instead of a calm lake, imagine ocean waves, smoke coming out of a chimney, air moving around an aircraft, water flowing through a pipe, or turbulent air around an F1 car.

All of these are fluids.

And fluids are surprisingly difficult to predict.

For more than a century, scientists have had a set of equations that describe their motion remarkably well.

They are called the Navier–Stokes equations.

They are used everywhere in modern engineering and science.

And yet, there is a basic mathematical question about these equations that remained unanswered for decades:

If a fluid starts out smooth and well-behaved, will it always remain smooth?

Or can the mathematics eventually produce something so extreme that the solution effectively breaks down?

That question became one of the famous Millennium Prize Problems.

And now, in September 2026, OpenAI says an internal AI system has produced a solution.

But the interesting part isn't simply:

"AI solved a 100-year-old problem."

The interesting part is understanding what the problem actually is, how we got here, what OpenAI claims to have proved, what other mathematicians were working on, and how we should decide whether an AI-generated mathematical discovery is actually correct.

Let's start from the beginning.

Before Navier–Stokes, there was Newton

To understand why Navier–Stokes became necessary, we need to go back to one of the biggest ideas in physics.

In the 17th century, Isaac Newton developed his laws of motion.

His famous second law is usually written as:

F = ma

Force equals mass multiplied by acceleration.

This is an incredibly powerful idea.

If you know the forces acting on an object, you can calculate how its motion changes.

It works beautifully for things like a thrown ball, a moving car, or a planet orbiting the Sun.

But there is a problem.

What happens when the thing you're studying isn't one object?

What happens when it is water?

Or air?

A glass of water isn't really one object.

It contains an enormous number of molecules.

Each molecule is moving.

Each molecule interacts with neighboring molecules.

And all of those interactions collectively produce what we see as fluid motion.

Trying to calculate the position and velocity of every individual molecule would be hopeless for any practical problem.

So scientists needed another way to think about fluids.

The clever idea: stop looking at individual molecules

Instead of following every molecule, imagine dividing the fluid into extremely tiny imaginary boxes.

You don't care about the exact molecule inside each box.

You care about the average behavior of the fluid in that small region.

You can ask:

How fast is the fluid moving here?
Which direction is it moving?
What is the pressure?
How much is the fluid resisting motion?
How is the motion changing with time?

This is the basic mathematical view behind fluid dynamics.

And it is an incredibly powerful simplification.

We don't need to know what every molecule is doing.

We can describe the large-scale behavior of the fluid.

Euler took Newton's ideas into fluid mechanics

In the 18th century, mathematician and physicist Leonhard Euler developed equations describing the motion of an ideal fluid.

Euler's equations were a major step forward.

But there was something missing.

Real fluids aren't perfect.

They have viscosity.

And viscosity turns out to be extremely important.

So what exactly is viscosity?

You've probably experienced viscosity without knowing the word.

Pour water.

It flows quickly.

Pour honey.

It moves much more slowly.

The difference is largely related to viscosity.

In simple terms:

Viscosity is a measure of a fluid's resistance to flowing or to layers of fluid sliding past each other.

Think about putting your hand into water and moving it.

The water pushes back.

Now imagine doing the same thing in something much thicker.

There is more resistance.

Inside a flowing fluid, different layers can move at different speeds.

Viscosity describes the internal friction between those layers.

And this becomes very important in Navier–Stokes because viscosity tends to smooth out differences in motion.

If one region of a fluid is moving much faster than another, viscosity tends to reduce that difference.

You can almost think of it as nature's internal smoothing mechanism.

Then came Navier and Stokes

In the 19th century, Claude-Louis Navier and later George Gabriel Stokes developed equations that incorporated this viscous behavior into the mathematical description of fluid motion.

This gave us what we now call the Navier–Stokes equations.

They combine several basic ideas:

Velocity — how fast the fluid is moving.

Acceleration — how that motion changes.

Pressure — how pressure differences push the fluid around.

Viscosity — how the fluid resists changes in motion.

External forces — things such as gravity or other forces acting on the fluid.

Put very simply, Navier–Stokes is trying to answer:

Given what the fluid is doing now, what will it do next?

That sounds straightforward.

It isn't.

The equation itself is not the real mystery

You may see the Navier–Stokes equation written like this:

Change in fluid motion = Fluid’s own motion + Pressure + Viscosity + External forces

\frac{\partial u}{\partial t} + (u \cdot \nabla) u - \frac{1}{ρ} \nabla p + ν \nabla^{2} u + f

Don't panic.

We don't need to understand every symbol to understand the story.

Very roughly:

u represents velocity.
p represents pressure.
ρ represents density.
ν represents viscosity.
f represents external forces.

The left side describes how the fluid's motion changes.

The right side contains some of the things causing that change: pressure, viscosity, and external forces.

The important part isn't memorizing the equation.

It is understanding that the equation creates a feedback system.

The fluid's current motion affects its future motion.

And its future motion affects the flow again.

That is where things become difficult.

Why fluids become so unpredictable

Let's imagine a tiny swirl inside a fluid.

That swirl moves.

As it moves, it changes the surrounding fluid.

The surrounding fluid then pushes back on the swirl.

The swirl stretches.

It may become smaller and faster.

That changes the surrounding flow again.

Now imagine millions of these interactions happening simultaneously in three dimensions.

This is where nonlinearity enters the story.

"Nonlinear" sounds intimidating, but the basic idea is simple.

In a linear system, doubling something might simply double the result.

In a nonlinear system, doubling the input can produce a much more complicated change.

Fluid motion contains nonlinear interactions.

And those interactions can amplify small changes.

This is one reason turbulence is so difficult.

What is turbulence?

Think about smoke rising from a cigarette.

At first, the smoke may rise in a fairly smooth column.

Then, a few centimeters higher, it starts wobbling.

Then it develops little swirls.

Those swirls break into smaller swirls.

The flow becomes chaotic.

That is turbulence.

Turbulence is not simply "random movement."

It is the result of complicated interactions across many different sizes and time scales.

Large structures can break into smaller structures.

Those smaller structures can break into even smaller ones.

This process is sometimes called an energy cascade.

Energy moves from larger scales of motion toward smaller scales.

And suddenly we have a huge mathematical problem.

How do you describe all of this exactly?

The butterfly effect makes this even harder

You've probably heard of the butterfly effect.

The popular version is:

A butterfly flaps its wings and eventually causes a hurricane.

That sentence is more of an illustration than a literal scientific claim.

The real idea is about sensitivity to initial conditions.

If two systems start almost exactly the same, their future behavior can eventually become very different.

Fluid systems can show this kind of sensitivity.

A tiny difference in the initial flow can grow over time.

That means even if our equations are perfect, prediction can still become difficult.

And this gives us an important distinction:

A system can be governed by deterministic equations and still be extremely difficult to predict in practice.

The equations may tell us exactly how the system evolves.

But tiny differences in the starting conditions can make long-term prediction incredibly difficult.

So where does Navier–Stokes actually get used?

Pretty much everywhere fluids matter.

Aircraft

Engineers use fluid dynamics to understand how air moves around wings and aircraft bodies.

That helps with questions about lift, drag, stability, and efficiency.

Cars and F1

Air moving around a car affects aerodynamic drag and downforce.

Engineers can simulate airflow around different designs before physically building them.

Weather

The atmosphere is a giant fluid system.

Understanding air movement is fundamental to weather and climate modelling.

Ships

Water flowing around a ship affects resistance and fuel efficiency.

Medicine

Blood is a fluid.

Fluid dynamics can help researchers study blood flow through arteries and other biological systems.

Industrial systems

Pipelines, pumps, turbines, engines, cooling systems and chemical processes all involve fluid movement.

Space and aerospace

Airflow around spacecraft and atmospheric vehicles creates complex fluid-dynamic problems.

So Navier–Stokes isn't some equation that exists only inside mathematics departments.

It is part of the mathematical foundation behind a huge amount of modern engineering.

The Clay Mathematics Institute describes it simply: these equations govern the flow of fluids such as water and air.

Then why is there still a Millennium Prize Problem?

This is the part people often misunderstand.

Engineers can use Navier–Stokes.

Computers can simulate Navier–Stokes.

Scientists can calculate approximate solutions.

So what exactly remains unsolved?

The mathematical question is much deeper.

Imagine starting with a perfectly smooth fluid.

No infinite values.

No weird discontinuities.

Everything behaves nicely.

Now let the Navier–Stokes equations evolve that fluid forward in time.

The question is:

Will the solution remain smooth forever?

Or:

Can a singularity develop in finite time?

That is the famous existence and smoothness problem.

The Clay Mathematics Institute describes the central questions as whether solutions exist and whether they remain smooth; the official problem concerns three-dimensional incompressible flow.

What is a singularity?

This word sounds dramatic.

But in mathematics, it has a very specific meaning.

A singularity is a point where the mathematical solution develops behavior that becomes unbounded or otherwise ceases to remain regular.

In this particular problem, one possible scenario is that the velocity becomes arbitrarily large in a finite amount of time.

Again, this doesn't mean a real piece of water literally travels at infinite speed.

It means the mathematical solution develops an infinite quantity.

That raises a fundamental question:

Does the mathematical model permit this to happen from perfectly reasonable starting conditions?

Nobody had been able to prove the answer.

Why three dimensions matter so much

You might wonder:

"If we can study fluid flow on a computer, why can't mathematicians simply solve the equation?"

One major reason is three-dimensionality.

A two-dimensional fluid is already complicated.

A real fluid has three dimensions.

Now a vortex can stretch, twist, bend and interact with other vortices in ways that simply don't exist in the same form in two dimensions.

Imagine taking a rubber band and stretching it.

Now imagine that rubber band is actually a spinning tube of fluid.

Stretching the vortex can intensify the rotation.

That creates more complicated motion.

That complicated motion feeds back into the rest of the fluid.

This is one of the key difficulties in three-dimensional fluid dynamics.

The million-dollar problem

In 2000, the Clay Mathematics Institute announced seven Millennium Prize Problems.

Each problem came with a $1 million prize.

The goal wasn't to create seven difficult puzzles for mathematicians to solve for fun.

These were fundamental questions at the edge of mathematical knowledge.

Navier–Stokes was one of them.

The prize exists partly because solving such a problem can create new mathematical ideas that become useful far beyond the original question.

And there is an interesting historical detail here.

The Navier–Stokes equations themselves are more than 150 years old.

But the precise mathematical question about existence and smoothness has remained open for roughly 90 years.

So the equation isn't "100 years old and nobody knows how to use it."

Quite the opposite.

We use it constantly.

What remained mysterious was what the equations guarantee mathematically under all allowed conditions.

Then AI entered the story

Now we arrive at September 2026.

OpenAI announced that an internal AI system had produced what it describes as a solution to the Navier–Stokes existence and smoothness problem.

According to OpenAI, its system produced an analytical proof showing that a smooth three-dimensional fluid can develop a singularity in finite time.

The proposed mechanism involves a vortex.

The vortex becomes increasingly elongated and concentrated.

Its central region shrinks while the velocity increases.

At the same time, the construction keeps the total energy finite.

That is important because simply inserting an infinite force into the system would not demonstrate the kind of breakdown the problem is asking about.

OpenAI says the singular behavior instead emerges from the dynamics of the fluid itself.

If the argument survives mathematical scrutiny, it would mean the correct answer to the Millennium Problem is not:

"Smooth solutions always remain smooth."

Instead, it would establish that finite-time breakdown can occur.

And this wasn't just one AI prompt

This part is almost as interesting as the mathematics.

OpenAI says it used a large system of coordinating AI agents.

The agents explored different approaches, communicated with each other, ran code and consolidated useful ideas.

The group working on Navier–Stokes involved roughly 10,000 concurrent agents.

OpenAI says the agents generated around 2.7 million messages and approximately 130 billion output tokens during the Navier–Stokes effort.

The result reportedly emerged after about 88 hours.

Then a separate formalization process used Lean to verify the proof structure, taking another 17 hours.

That is very different from asking ChatGPT:

"Can you solve Navier–Stokes?"

This was closer to building a giant virtual research team.

What is Lean and why does it matter?

Suppose I give you a 100-page mathematical proof.

You read it.

It looks convincing.

But somewhere on page 67, I accidentally make a logical mistake.

You might not notice.

Computers can help here.

Lean is a formal proof system.

Instead of simply writing:

"Therefore this result follows."

you express mathematical statements in a precise formal language that Lean can check.

It doesn't replace mathematical understanding.

But it can verify that formalized logical steps actually follow according to the rules of the system.

OpenAI says it released both a written proof and a Lean formalization of its proposed Navier–Stokes result.

That makes this episode particularly interesting.

AI isn't only generating text.

It is being used to generate mathematical reasoning that can then be translated into a machine-checkable form.

But here is the important part: a claim is not the same as acceptance

OpenAI says its system has resolved the Millennium Prize problem.

But the Clay Mathematics Institute has its own process.

Its rules say that before it considers awarding a Millennium Prize, a proposed solution must be published in a qualifying outlet, at least two years must pass, and the solution must receive general acceptance from the global mathematics community.

And this is exactly how mathematics is supposed to work.

A company announcing:

"We solved it."

is not the final step.

Other mathematicians need to inspect the argument.

They need to try to break it.

They need to reproduce the logic.

They need to look for hidden assumptions.

They need to understand whether the proof actually establishes the exact statement required by the problem.

Interestingly, the Clay Mathematics Institute itself published an announcement on September 11 saying the problem had "apparently been settled", while emphasizing that its evaluation process is deliberately unhurried.

So the story is moving very quickly.

But mathematics moves slowly for a reason.

And then there is another piece of the story

Around the same time, mathematicians Tristan Buckmaster and Levent Alpöge, with Alpöge associated with Anthropic, were working on a related problem.

Their work concerned the forced Euler equations.

Remember Euler?

He gave us an important version of fluid equations before viscosity was incorporated into Navier–Stokes.

So we can think of the relationship roughly like this:

Euler equations → idealized fluid without viscosity

Navier–Stokes → fluid with viscosity

The difference sounds small.

Mathematically, it is huge.

Buckmaster and Alpöge produced a result showing a form of finite-time blow-up for a forced Euler problem.

OpenAI says its own Navier–Stokes result is different: its construction does not rely on external forcing in the same way.

Why did this become controversial?

Because the timing was unusual.

OpenAI says that on September 1 it heard rumors that two Millennium Prize problems had been resolved.

Those rumors turned out to be connected to Alpöge and Buckmaster's work.

OpenAI then decided to test its internal model against open Millennium Prize problems.

The Navier–Stokes effort eventually produced its claimed solution.

OpenAI says it later investigated whether Buckmaster's earlier Codex prompts could have influenced its internal system and concluded that they could not.

It also says the two proofs are significantly different.

This is an important area where we should be careful.

There are multiple claims being made by different researchers.

The safest way to understand the situation is not:

"AI stole the mathematicians' work."

Nor:

"AI independently solved everything with no connection whatsoever."

Instead:

There was concurrent research on closely related mathematical problems, unusual timing, and a dispute about possible influence. OpenAI says its investigation found no access to the relevant unpublished work and says the proofs differ significantly.

The mathematics itself needs to be examined.

The deeper question is bigger than Navier–Stokes

Suppose the proof is eventually accepted.

Then something remarkable has happened.

A machine-assisted system has helped solve a problem that humans have struggled with for generations.

But that creates another question:

What does it mean to understand a proof that a machine discovered?

Imagine an AI gives mathematicians a proof containing hundreds of pages of complicated reasoning.

The proof is formally verified.

Every individual step checks out.

But perhaps only a small number of people can actually understand the big idea behind it.

Is that still mathematics?

I think this is going to become one of the most interesting questions of the AI era.

Because mathematics isn't only about getting the correct answer.

It is also about understanding why the answer is correct.

The Clay Mathematics Institute itself describes the value of proof in terms of not just certainty, but understanding.

And this is where AI changes the role of the mathematician

For centuries, mathematicians did most of the exploration themselves.

They calculated.

They experimented.

They wrote proofs.

They searched for patterns.

They tried again.

AI changes the economics of that process.

You can potentially have thousands of agents exploring different approaches simultaneously.

One agent searches for counterexamples.

Another tries a geometric argument.

Another works with inequalities.

Another tests numerical examples.

Another searches for connections with known theorems.

Another tries to formalize the proof.

Another tries to destroy the whole argument.

This last one is particularly important.

Maybe the future of mathematical AI isn't simply:

AI → produces proof → humans accept it.

Maybe it becomes:

AI → proposes proof → other AIs attack it → mathematicians inspect the surviving ideas → formal systems verify them.

That would look much more like a scientific research ecosystem.

And suddenly, critical thinking becomes even more important

There is a lesson here that has nothing specifically to do with fluid mechanics.

We are entering a world where machines can produce answers much faster than humans can verify them.

That is both incredibly useful and slightly uncomfortable.

Imagine an AI gives you a beautiful explanation.

It has equations.

It has references.

It has graphs.

It sounds confident.

It may even be completely wrong.

The Navier–Stokes story gives us a very good rule for the AI age:

A convincing answer is not the same thing as a verified answer.

And this applies far beyond mathematics.

If AI writes your code, test it.

If AI summarizes research, check the sources.

If AI gives you financial information, verify the numbers.

If AI gives you scientific conclusions, look at the evidence.

If AI gives you a mathematical proof, ask:

Can someone independently verify it?

Maybe this is the real lesson of Navier–Stokes

There is something almost poetic about this problem.

For decades, mathematicians have been asking whether a mathematical system describing fluids can suddenly develop behavior that our equations cannot keep under control.

Now AI is entering the picture and creating a similar question for us.

Can humans keep our understanding under control when machines become capable of producing mathematics that we cannot easily reproduce ourselves?

The answer doesn't have to be scary.

It could actually be exciting.

Maybe AI will become a new kind of mathematical microscope.

Something that lets us see structures that were always there but were too complicated for humans to discover.

Maybe it will help mathematicians solve problems that once seemed impossible.

Maybe it will also make mistakes that take years to uncover.

Probably both.

And that is why the most important part of the Navier–Stokes story may not be whether an AI has finally solved a Millennium Prize Problem.

It may be what happens after the AI gives us the answer.

Because the real test isn't:

"Can AI produce an answer?"

We already know it can.

The much harder question is:

"Can we understand, verify, and trust what it has produced?"

And perhaps that is the next great problem AI has given mathematics.

Not another equation.

Not another million-dollar prize.

But a question about how humans and machines discover knowledge together.

AI Solved the Problem Perfectly. There Was Just One Problem.

Tushar Vashishth — Tue, 08 Sep 2026 10:59:46 +0000

It wasn't the problem we actually had.

![AI solving the wrong problem]

There is something slightly funny about working with AI today.

We have incredibly capable models. They can write code, analyze data, summarize documents, reason through problems, call tools, and even take actions on our behalf.

So naturally, when something doesn't work, our first instinct is often:

“Maybe we need a better model.”

Then we try a bigger model.

Still not working?

“Maybe we need an agent.”

Still messy?

“Let's add RAG.”

Still not quite there?

“Maybe we need more tools, memory, or a more complicated pipeline.”

And before we know it, we've built a very sophisticated system...

for the wrong problem. 😅

The AI system can be technically correct and still be wrong

This is something I've been thinking about more while learning about AI-native systems.

Imagine asking an AI system:

“Help me reduce customer support response time.”

And it comes back with a beautifully designed solution for improving customer acquisition.

The solution might be:

logically sound
technically impressive
well researched
perfectly implemented

But it doesn't matter.

It solved a different problem.

This distinction is easy to miss because modern AI is extremely good at producing convincing outputs.

A bad answer used to look bad.

Now, a bad answer can look professional.

That's a much more interesting engineering problem.

Intelligence isn't the same as direction

A highly capable model still needs the right direction.

Think about a very smart employee.

You don't just give them access to every company document, every software tool, and the freedom to make decisions and say:

“Go do something useful.”

You first explain:

what we're trying to achieve,
what information matters,
what they're allowed to do,
what tools they should use,
and how we'll know whether the work was successful.

AI systems need similar thinking.

The model is only one component.

The surrounding system determines how that intelligence is actually used.

This is where things get interesting

When building AI applications, it's tempting to start with technology.

For example:

“Which model should we use?”

But perhaps a better starting point is:

“What problem are we actually trying to solve?”

Then we can work backwards.

Do we need external information?

→ Maybe we need retrieval.

Does the system actually need to take multiple steps or interact with tools?

→ Maybe we need an agent.

What kind of reasoning or generation is required?

→ Now we can think about the appropriate model.

And once the system produces an answer or takes an action:

→ How do we know it worked?

That's where evaluation, verification and proof become important.

More components don't automatically mean a better system

This is probably one of the easiest traps to fall into with modern AI.

Because there are so many interesting technologies available, we can start adding them simply because we can.

Need a chatbot?

Add RAG.

Need RAG?

Add a vector database.

Need more flexibility?

Add an agent.

Need the agent to do more?

Add tools.

Need better reasoning?

Use a bigger model.

Need reliability?

Add another layer.

Eventually, the architecture looks incredibly sophisticated.

But complexity should have a reason.

Every component should solve a problem.

Otherwise, we're just making the system harder to understand, maintain and debug.

The model isn't always the problem

Suppose an AI application is giving poor answers.

There are many possible reasons.

Maybe the model doesn't have the information it needs.

Maybe retrieval is returning irrelevant context.

Maybe the context is too large or poorly structured.

Maybe the agent is choosing the wrong tool.

Maybe we're using an unnecessarily expensive model for a simple task.

Maybe our evaluation process isn't catching failures.

Or maybe...

we simply misunderstood the original problem.

Replacing the model might fix none of these.

This is why I think AI engineering is becoming less about “which model are you using?” and more about how the entire system is designed around the problem.

A useful mental model: Retrieve → Agents → Models → Proof

One framework I've been exploring through RAMP is:

Retrieve → Agents → Models → Proof

I like this because it encourages thinking beyond the model itself.

Retrieve

Give the system the information it actually needs.

The goal isn't simply to retrieve more information.

It's to retrieve relevant information.

Agents

If the problem genuinely requires actions, decisions, or multiple steps, then agents can become useful.

But not every problem needs an agent.

Sometimes a simple workflow is better.

Models

Choose the model based on the actual requirement.

The biggest or newest model isn't automatically the right choice.

Sometimes speed matters more.

Sometimes cost matters.

Sometimes reasoning capability matters.

Sometimes a smaller model is perfectly sufficient.

Proof

Finally:

How do we know the system worked?

This is arguably one of the most important questions as AI systems become more autonomous.

An answer isn't automatically trustworthy just because it sounds convincing.

We need ways to evaluate, verify and measure system behavior.

The real goal isn't “make AI smarter”

Of course, better models matter.

Model capabilities have improved dramatically, and they will continue to improve.

But there's another layer to the problem.

A smarter model can produce a better answer to the wrong question.

And that's still the wrong answer.

So perhaps the goal shouldn't simply be:

Make AI smarter.

It should be:

Build systems that use intelligence in the right direction.

That means understanding the problem first, choosing the right architecture second, and selecting the technology that actually supports it.

One question I'm trying to ask more often

Whenever I see a new AI technique, framework or model, instead of immediately asking:

“How can I use this?”

I'm trying to ask:

“What problem would this actually solve?”

That small change in perspective can make a surprisingly big difference.

Because the AI ecosystem is moving extremely fast.

There will always be another model.

Another framework.

Another agent architecture.

Another tool.

Another technique that everyone is talking about.

We probably don't need to use all of them.

We need to understand why we'd use them.

The takeaway

AI can be incredibly smart.

It can reason.

It can retrieve information.

It can use tools.

It can write code.

It can take actions.

But none of that guarantees that we're solving the right problem.

So before asking:

“Which model should I use?”

Maybe ask:

“What exactly am I trying to solve?”

Because sometimes the best AI solution isn't a bigger model.

It's realizing that the problem was defined incorrectly in the first place.

And honestly...

“Cool. But that's not what I asked.”

might become one of the most important debugging messages in AI engineering. 😄

I'm currently exploring these ideas as part of my RAMP learning journey, and this shift—from thinking primarily about models to thinking about the complete AI system—is one of the perspectives I've found particularly useful.

From Learning the Stack to Understanding the System

Tushar Vashishth — Tue, 25 Aug 2026 13:30:40 +0000

Why AI-native development may require a different way of thinking about technology.

The way we learned software for years
LAMP → MEAN → MERN → other stacks.
Learning the stack gave developers a practical mental model for building applications.
Then AI changed the shape of the application
We're no longer just choosing frontend, backend and database technologies. A modern AI application may involve retrieval, agents, multiple models, tools, memory, evaluation, and human intervention.
The problem with thinking only in terms of tools
Models change quickly. Frameworks change quickly. Tools come and go. If your understanding is tied too closely to one particular stack, it can become outdated quickly.
So what should we understand instead?
This is where we introduce the four RAMP areas naturally:

Retrieve — How does the system get the information it needs?
Agents — How does it decide, act, and interact with tools?
Models — Which intelligence is appropriate for each task?
Proof — How do we know the result is reliable?

RAMP isn't another programming stack
This distinction is important. It's a way of organizing the major pieces of an AI-native system, rather than telling developers which programming language or framework to use.
What this could mean for developers
Instead of only asking “What technologies do I know?”, developers may increasingly need to ask “Can I design and reason about an AI system?”
What happens to MERN, MEAN, LAMP, etc.?
Don't say they are obsolete. They still solve the application-stack problem. RAMP is addressing a different layer.
The bigger question
Could RAMP become a common vocabulary for describing AI-native engineering, in the same way that stack names gave developers a shorthand for web development?

Then finish with something conversational:

I'm still exploring this idea, but I think there's an interesting shift happening here.

We're not necessarily moving away from stacks.

We're adding a new layer of thinking on top of them.

Most RAG Problems Don’t Start With the LLM

Tushar Vashishth — Fri, 21 Aug 2026 10:46:30 +0000

If you've worked with RAG, you've probably seen this:

The answer is wrong.

So you change the prompt.
Try another model.
Increase the context window.
Maybe even switch to a bigger LLM.

And somehow...

the answer is still wrong.

I've started to think that we sometimes look at the wrong part of the system.

The problem may have started before the LLM ever saw the question.

First, look at the whole flow

A simple RAG system can be thought of as:

User Question
      ↓
   Retrieval
      ↓
    Context
      ↓
     LLM
      ↓
    Answer

The LLM is only one part of this.

Before it generates anything, the system has already made several decisions:

What information should be searched?
How were the documents split?
Which results are relevant?
How many results should be returned?
Should some results be filtered out?
Which results should appear first?
What finally goes into the model's context?

So when the final answer is bad, the model isn't necessarily where things went wrong.

Here's a simple example

Imagine you're building an internal support assistant.

Someone asks:

“What's our refund policy for prepaid orders?”

The company has the answer somewhere in its documentation.

Your LLM is capable of understanding the policy.

But your retrieval system returns these:

Refunds are available for eligible purchases.

Customers can contact support regarding refunds.

Refund requests are reviewed within 5 business days.

Prepaid orders are processed immediately.

Refunds may be issued to the original payment method.

Everything looks relevant.

But there's one problem:

The actual rule for prepaid orders wasn't retrieved.

Now the LLM has incomplete information.

It might still produce a very confident answer.

And we might say:

“The LLM hallucinated.”

Maybe.

But the problem actually started earlier.

We gave the model the wrong context.

Where can things go wrong?

There are a few common places.

1. The document was split badly

A policy might say:

Customers can request a refund within 30 days.

And immediately after:

Prepaid orders are subject to different conditions.

If those two statements are split into different chunks, retrieval might find one without the other.

The model gets half the story.

2. The right document wasn't retrieved

This is probably the easiest one to overlook.

The answer may be sitting inside your knowledge base.

But your search never brings it back.

So you:

change the prompt → change the model → change the temperature → try again

...while the correct document is still sitting in the database.

Sometimes the model isn't failing.

The system simply didn't give it the information it needed.

3. Similar doesn't always mean useful

Suppose your system retrieves the five most similar chunks.

That sounds reasonable.

But imagine all five are about refunds while the one chunk containing the actual prepaid-order exception is ranked sixth.

You've technically retrieved relevant information.

But you haven't retrieved the right information.

That's where things like better search, filtering and re-ranking start becoming important.

4. Old information can look very relevant

Imagine your knowledge base contains:

2022 Refund Policy
2023 Refund Policy
2024 Refund Policy
2025 Refund Policy

A question about the 2025 policy might still retrieve the 2023 document because the wording is almost identical.

This is where metadata can matter:

date → source → department → document type → version

Sometimes the system needs more than semantic similarity to find the right answer.

So... should we just use a bigger model?

Not necessarily.

A bigger model can certainly help with reasoning and generation.

But it can't reliably answer from information it never received.

Think about it this way:

Bad context
     ↓
Good model
     ↓
Bad / unreliable answer

versus:

Good context
     ↓
Appropriate model
     ↓
Much better chance of a useful answer

That's why I'm starting to look at RAG less as:

“Search + LLM”

and more as:

“Getting the right information to the right model at the right time.”

What I would check first

If a RAG application is giving poor answers, I'd be tempted to check the retrieval pipeline before immediately replacing the LLM.

A simple checklist:

1. Retrieval
Did we actually find the right information?

2. Chunking
Did we split the information in a useful way?

3. Ranking
Did the useful result make it near the top?

4. Metadata
Are we filtering by things like date, source or version?

5. Context
Is the model actually receiving enough of the right information?

6. Generation
Only then — is the model struggling to turn that context into a good answer?

The Chapter 2 material I've been going through goes quite deep into these areas, including embeddings, vector databases, chunking, hybrid search, re-ranking and retrieval evaluation.

The bigger takeaway

The more I work through this, the more I think:

Building a good RAG system isn't just about choosing a smart model.

It's about building a good path between:

the question → the information → the model → the answer.

If the information going into that path is wrong, incomplete or badly ranked, throwing a smarter model at the end of it may not solve much.

And that's probably the part of RAG I find most interesting right now.

What has caused more trouble in your RAG projects?

Retrieval or generation?

I'd genuinely be interested to hear what others have run into.

Your ML model isn't the whole AI system anymore

Tushar Vashishth — Thu, 20 Aug 2026 07:59:49 +0000

For a long time, when we talked about an ML project, the model was usually at the center of everything.

Get the data.
Train the model.
Improve the accuracy.
Deploy it.
Monitor it.

Pretty straightforward.

But AI applications are starting to feel different.

Imagine you build a system that answers questions about your company's internal data.

Having a good model is important, but that's only the beginning.

Where does the information come from?

What if the answer isn't in one document?

What if the system needs to search, think through a few steps, use a tool, and then come back with an answer?

What if a smaller model is better for one part of the job and a larger one is better for another?

And probably the hardest question:

How do you know the answer is actually good?

Suddenly, the model isn't doing everything.

There's a whole system around it: information, different models, actions, checks, and people when needed.

I think this is one of the biggest changes in how we should think about building AI applications.

We're not just building a model anymore.

We're building a system that knows how to use intelligence.

We're getting really good at adding AI to things.

Tushar Vashishth — Wed, 19 Aug 2026 13:33:15 +0000

Add an LLM here.
Add a copilot there.
Put an agent in the workflow.

Done. “AI-native.” 😅

But building around AI feels like a different problem.

Where does the right information come from?
Which model should handle the job?
What should an agent actually do?
And probably the biggest one — how do we know the result is good?

I've been looking at an idea from AiDOOS around this called RAMP — Retrieve, Agents, Models, Proof.

Still early, but I think there's something worth exploring here.

Maybe being AI-native is less about adding AI...

and more about rethinking how the whole system works.