Beyond Waterfall Prompting: Toward Object-Oriented Prompting with UML
After working with AI coding agents for a while, I reached a conclusion.
Many people compare AI to giving developers “superpowers.” I think the comparison can be more precise.
Imagine a senior developer learning Tai Chi.
Years are spent practicing every movement slowly, understanding balance, force, timing, and body mechanics. Eventually those movements become instinctive, allowing them to execute them quickly without sacrificing accuracy.
Now imagine AI suddenly gives that person a much stronger and faster body.
Their experience still exists. AI simply amplifies it.
The problem is different for junior developers.
Many new developers begin with AI before they have developed the mental models that experienced developers built over many years.
They can generate code quickly, but they often lack:
-
architectural thinking
-
structured problem decomposition
-
logical reasoning
-
requirement analysis
-
design evaluation
-
risk identification
As a result, they frequently accept the first working solution instead of understanding why it works—or what it misses.
I don’t think AI should replace that learning process.
I think we need a replacement for the visualization process that experienced developers naturally perform in their heads.
My proposal is simple:
Introduce UML and model-based design into the prompting workflow.
From Waterfall Prompting to Object-Oriented Prompting
Most prompting today still follows a waterfall process.
Idea
↓
Prompt
↓
Code
↓
Fix
↓
Prompt Again
↓
Fix Again
This creates long conversations, high token usage, and gradually drifting requirements.
Instead, the process should become object-oriented.
Idea
↓
Requirements
↓
Planning
↓
UML
↓
Sequence Diagram
↓
Class Diagram
↓
Flow Chart
↓
Critical Review
↓
Implementation
The goal is not to make AI think harder.
The goal is to make the problem more concrete before AI starts writing code.
Example: “Build me a database query tool”
Most people simply ask:
Build me a database query tool.
The AI will probably generate something comparable to QueryExpress.
It works.
Then the real conversation begins.
Add editing.
Add connection management.
Add schema browsing.
Add SQL history.
Add transaction support.
Add index analysis.
Add dark mode.
Each correction consumes additional tokens.
Eventually people stop because the program is “good enough.”
Not because the design is complete.
Instead, spend time defining the target before asking for code.
For example, think about:
-
database optimization
-
editor capabilities
-
state management
-
SDI vs MDI
-
UI layout
-
maintainability
-
object relationships
-
database schema
-
fallback strategy
-
deployment environment
-
security concerns
-
organizational workflow
-
future extensibility
Once that mental image becomes clear:
-
Ask AI to write a development plan.
-
Generate UML.
-
Generate sequence diagrams.
-
Generate class diagrams.
-
Generate flow charts.
-
Ask AI to produce a critical review checklist.
-
Only then start implementation.
In my experience, this reduces unnecessary iteration, improves design quality, and saves both time and tokens.
Why do prompts consume so many tokens?
One reason is that AI and developers do not share the same mental model.
AI is not a domain expert for your project.
It understands code remarkably well.
But it does not automatically understand:
-
business rules
-
legacy architecture
-
organizational conventions
-
historical decisions
-
hidden assumptions
Those exist inside your head.
Every new chat requires rebuilding that context.
Instead of rebuilding it repeatedly, create a project knowledge base.
For example:
-
ERD
-
UML
-
architectural diagrams
-
code indexes
-
Doxygen documentation
-
design references
-
analysis documents
Think of it like a technical book.
A good book has:
-
a table of contents
-
indexes
-
glossary
-
diagrams
-
references
AI benefits from the same structure.
Once created, these documents become reusable context instead of repeatedly spending tokens rediscovering the project.
Why does Cursor use more tokens?
Many developers notice that the same GPT model consumes significantly more tokens inside Cursor than through other tools.
The reason is not necessarily the model.
Cursor applies additional system prompts, coding rules, planning stages, and internal reasoning before your request reaches the model.
In other words:
Your prompt
↓
Cursor agent
↓
Additional planning
↓
Internal re-prompting
↓
Model
That generally increases token usage.
However, it often also improves output quality.
Different IDEs simply optimize for different trade-offs.
Prompting doesn’t have to be text
People often assume prompting means writing text.
It doesn’t.
Prompts can include:
-
UML
-
diagrams
-
images
-
binary files
-
URLs
-
documentation
-
structured metadata
Instead of repeatedly explaining architecture with paragraphs, we should increasingly communicate using models.
AI understands structured representations remarkably well.
Why does AI-generated code still contain problems?
In many cases, the code itself is not the real problem.
The implementation satisfied the requested objective.
The missing step is developer verification.
One technique I recommend is surprisingly old-fashioned.
Rewrite important code yourself.
Typing the code manually forces you to follow every branch, every condition, and every dependency.
Unexpected design issues become much easier to notice.
Another useful practice is generating Doxygen documentation first and reviewing that documentation before reviewing implementation.
Reviewing architecture is usually easier than reviewing thousands of lines of source code.
Do you really need GPT-5.5?
Not necessarily.
Claude Sonnet, Gemini, DeepSeek, and Qwen are all capable coding models.
The biggest advantage I personally notice in GPT-5.5 is instruction retention across longer conversations.
Recent versions of Claude and Gemini have also improved substantially.
Rather than searching for one “best” model, choose the right model for the task.
Examples:
-
Gemini Flash for high-volume objective processing
-
Claude Sonnet5 for precise reasoning
-
GPT-5.5 when long instruction consistency matters
Artificial Analysis provides a useful benchmark for comparing capability, latency, and cost:
Cursor Auto Mode attempts to make this decision automatically, but I still recommend selecting models based on your actual development environment and workload.
Cursor is much more than a code editor
Many people only use Cursor for writing code.
I think it is better viewed as a development operating system.
Examples include:
-
Git workflow automation
-
Redmine/Jira integration
-
issue migration
-
project documentation
-
Obsidian knowledge management
-
development scheduling
-
service monitoring
-
reusable automation skills
With proper Skills and Profiles, Cursor becomes far more than an AI code generator.
It becomes a structured engineering assistant.
Profiles
Separate projects should use separate Profiles.
For example:
-
Legacy C++ profile
-
Cloud backend profile
-
Web development profile
-
Issue processing profile
-
Documentation profile
Each profile can maintain its own:
-
rules
-
indexed codebase
-
preferred models
-
automation skills
This prevents unrelated projects from contaminating each other’s context and reduces unnecessary token consumption.
Multi-Agent Development
Cursor’s MultiTask mode is also frequently misunderstood.
It is not intended for multiple agents editing the same file simultaneously.
Instead, each agent works independently—often on separate Git worktrees.
Examples include:
-
frontend
-
backend
-
testing
-
documentation
or
-
code analysis
-
refactoring
-
testing
running in parallel.
This can significantly reduce development time while keeping work isolated until review.
Final Thought
AI has dramatically increased the speed of software development.
But speed alone does not create better software.
Experienced developers built internal models over many years.
If AI is going to replace part of that learning process, we need new tools that replace those mental models—not just faster code generation.
I believe UML, diagrams, structured knowledge bases, and model-based prompting are the missing layer.
The future of AI-assisted development is not simply better prompts.
It is better models.