What is applied AI?

Applied AI is the practice of using artificial intelligence models to solve real-world problems and build practical tools, rather than researching or training the models themselves. If AI research is inventing a new building material, applied AI is constructing a house with it.

I write about this regularly. You can read all my case studies and posts on applied AI here.

Most writing about AI is about the models. Most of the value is in the building.

What applied AI is not

It is not research. Someone writing a paper about a new transformer architecture is doing AI research. Someone using an existing model to build a code review bot, a search pipeline, or a content moderation system is doing applied AI.

It is not prompt engineering alone. Writing a good prompt is a skill, but applied AI includes the infrastructure around the prompt: the retrieval system that feeds it context, the guardrails that keep it from generating nonsense, and the monitoring that tells you when it starts to drift.

It is not a chatbot wrapper. If you wrap a model in a thin UI and call it a product, you have built a demo, not an applied-AI system. Applied AI involves integration — with existing tools, with data sources, with the workflows people already use.

Why the term matters

Right now the gap between what AI research can do and what most organisations can use is wider than it has ever been.

This creates a peculiar situation: the technical frontier moves daily, but the practical frontier — where someone actually benefits — moves much more slowly. Applied AI bridges that gap. It is the discipline of taking something that works in a paper or a demo and making it work in a codebase, a product, or a business process.

The term also filters out a lot of noise. When someone says their product uses AI, the useful question is: applied to what, with what evidence, and with what constraints. A system that applies AI to code review and shows a measurable reduction in shipped defects is applied AI. A system that promises to “revolutionise your workflow through AI-powered insights” is a marketing page.

What applied AI looks like in practice

Applied AI shows up in concrete, named tools and specific outcomes.

A coding assistant that runs locally, integrates with a developer’s editor, and speeds up their work without phoning home is applied AI. The open source tool Aider did this early and well. The product Cursor took a different approach, embedding the model directly into the editing experience. Both are applied AI: they take a model someone else built and make it useful in a specific context. I have written about the lessons from using these tools day to day.

An agentic coding system — one that can write, test, and iterate on code across multiple files — is applied AI at a higher level of ambition. Tools like OpenCode, OpenClaw, and Claude Code each make different trade-offs between autonomy and control. The applied part is the integration with a developer’s actual environment: the file system, the test runner, the version control system.

A retrieval-augmented generation pipeline that searches a company’s own documents and uses a model to synthesise answers is applied AI. So is a local AI tool that runs entirely on a developer’s machine, keeping their data private.

For example, I built WordFloor — a writing environment designed to explore how AI assistance changes the craft of writing itself. It is not a new model; it is an applied integration of existing models into a specific workflow.

What connects these examples is not the technology — different models, different architectures, different trade-offs — but the outcome: someone got something done they could not have done without the system.

How to think about applied AI

When you encounter a new AI tool or claim, three questions separate the applied from the aspirational:

What is it applied to? If the answer is vague — “workflows”, “productivity”, “business outcomes” — the thing has not been applied yet. If the answer is specific — “code review for TypeScript monorepos”, “migrating PostgreSQL schemas with zero downtime” — the application is real.

What is the evidence? Applied AI ships with numbers. A 40% reduction in time spent on code review. A 3x improvement in search relevance. A specific before and after, measured, with a methodology you can inspect.

What are the constraints? Every real AI application has limits. It works for certain languages but not others. It needs a specific model version. It degrades above a certain input size. The presence of named constraints is actually a signal of maturity: someone has tested it enough to know where it breaks.

The applied-AI boundary moves

One measure of applied AI is that it stops being “AI” after a while and becomes infrastructure. Spellcheck was once an AI feature. Now it is a solved problem nobody thinks about. Recommendation algorithms, fraud detection, email spam filtering — all were frontier AI problems once, all are now just how the internet works.

The same process is underway at a faster pace. Coding assistants were experimental two years ago and are now table stakes for developer tooling. Retrieval-augmented generation went from research project to production pattern in under three years. The applied-AI frontier today will be infrastructure tomorrow.

What matters is not whether something counts as AI, but whether it actually works. The term “applied AI” is useful because it shifts the question from “is this AI?” to “does this do something?” — which is the only question that matters.

If you are looking for more examples of this in practice, my applied AI topic archive documents what works, what does not, and what I am building.