This week after reading some social media posts and discussing with customers and partners some AI-related issues in real-world projects, I started thinking…
People are getting very good at using GitHub Copilot, Claude, ChatGPT, and other tools. They’re learning prompt engineering. They’re understanding token limits and context windows. They’re figuring out how to iterate on a prompt to get better code output. This is a real skill, and people are shipping impressive things with it.
But using AI as a coding tool is not the same as architecting an AI application for a real business problem. And almost nobody is talking about this gap.
Using AI as a coding tool.
This skill set is what most of the conversation is about right now:
• Prompt engineering and iteration.
• Understanding model capabilities and limits.
• Writing effective context and instructions.
• Evaluating code quality from AI output.
• Knowing which model to use for which task.
• Recognizing hallucinations and catching them
• Building effective chains of prompts.
These are useful, acquirable skills. And they’ve created a generation of developers who can ship faster because they have an AI co-pilot.
But here’s the thing: none of this teaches you how to build an AI system that makes decisions in a real business.
Architecting a real-world AI application.
A real-world AI application (one that orchestrates decisions across multiple agents, integrates with transactional systems, and handles actual business workflows) requires a completely different skill tree.
This is systems design applied to AI:
• Agent orchestration: designing which agents call which other agents, in what order, with what dependencies, what pattern to use.
• Failure mode analysis: mapping what happens when an agent hallucinates, times out, or returns ambiguous output.
• Integration patterns: understanding how AI sits between your application logic and your databases, ERPs, and external APIs.
• Error classification and routing: learning that not all failures are equal; some retry, some escalate, some need human judgment.
• Async decision flows: building systems that don’t block on AI calls; that queue work, handle callbacks, and manage eventual consistency.
• Cost boundaries in architecture: taking cost constraints into the design, not discovering them after the system runs; knowing which calls are expensive and designing around them.
These aren’t tips. They’re architectural patterns.
You acquire them by building systems that fail, seeing what breaks in production, and learning how to structure the system to handle it.
A developer excellent at using an AI tool for coding hasn’t necessarily learned systems design. They’re orthogonal skill trees.
Why this matters now?
Because companies are starting to want and ship real applications. Multi-agent systems. Things that make decisions. Things people depend on. And many AI projects fail!!!
The teams that will succeed are the ones with people who understand not just how to prompt an AI model, but how to architect a system where multiple agents interact reliably, integrate with real systems, handle failures gracefully, and scale without surprising anyone.
That’s a learned skill. It’s not taught in most AI courses. It’s not covered when people talk about “prompt engineering.” It comes from shipping systems, breaking them, and fixing them structurally.
Right now, there’s a shortage of people who have this skill. Everyone’s an expert in using AI and creating AI frameworks. Few are architects of AI systems.
That gap matters more than you’d think.
I’d like to know your thoughts, and apologies for the bluntness. 😝
Stefano Demiliani 