A few years ago, the main question was simple:
Which model is the best?
Today the same question appears in different forms:
- GPT or Claude?
- Gemini or Grok?
- Local model or cloud model?
- 200k tokens or one million tokens?
It is natural to be fascinated by model performance. Larger context windows, better reasoning, multimodal input and faster inference all matter.
But the more I use AI on real projects, the more obvious one thing becomes.
The model is no longer the most important part of the result.
The real difference is increasingly created by something else.
Process.
The future of AI will not be only about better models. It will be about better engineering around them.
The model is not the product
Many people say today:
AI built an application for me.
But that is rarely true.
The model generated a draft.
Someone still had to:
- prepare the context,
- explain the architecture,
- choose between alternatives,
- fix errors,
- run tests,
- check security,
- update documentation,
- prepare the release,
- and verify that the result actually works.
Only the combination of those steps creates a usable outcome.
The model is one part of the process. It is not the whole product.
The same model can produce excellent or dangerous results
Imagine two developers using the same AI model.
The first writes:
Add authentication.
The model generates code. The developer commits it. The task is considered done.
The second developer works differently.
They first prepare project context. They ask the AI to propose a plan. They review the architecture. They approve the implementation approach. They run automated tests. They ask for an independent review of the diff. They check security assumptions. Only then do they accept the change.
The model was the same in both cases.
The result may be completely different.
The deciding factor was not the model.
The deciding factor was the process.
Prompt engineering is not enough
For several years, we talked about prompt engineering.
How to write a better prompt. How to use the right wording. How to force the AI to answer in a more useful structure.
That is still useful.
But it is becoming less decisive.
Modern AI systems need much more than a good prompt. They need:
- context,
- memory,
- rules,
- tools,
- planning,
- feedback,
- verification,
- and learning.
A prompt is becoming only one input into a larger system.
The important question is no longer only: What did you ask the model?
The more important question is: What engineering system surrounds the model?
AI needs workflow
Professional software development is not usually done by saying:
Write the whole system.
Development is composed of many steps. The same should be true for AI-assisted work.
A practical AI workflow may look like this:
Requirement
↓
Project context
↓
Analysis
↓
Plan
↓
Approval
↓
Implementation
↓
Automated tests
↓
Review
↓
Documentation
↓
Stored lessons learned
This is no longer just prompting.
This is workflow engineering.
AI needs memory
One of the biggest problems in AI-assisted work is amnesia.
Every new conversation often starts from zero.
Again and again, we explain:
- the architecture,
- naming conventions,
- the technology stack,
- previous decisions,
- known problems,
- failed approaches,
- and project-specific rules.
Yet these are exactly the details that make the difference between useful assistance and random code generation.
Future AI systems will need durable project memory.
Not because they should remember everything.
Because they should remember what matters.
AI needs rules
A good developer does not only know programming syntax.
They also understand project rules.
They know, for example:
- which modules should not be changed,
- how classes and files are named,
- which security rules apply,
- which libraries are allowed,
- what must always be tested,
- and what kind of changes require review.
AI needs the same kind of rules.
Not as a temporary sentence in one prompt.
As a durable part of the project.
Without rules, AI may be productive and still unsafe.
AI needs evidence
I often see AI-generated answers such as:
The tests should pass.
Or:
This looks correct.
That is not enough.
Software does not need assumptions.
Software needs evidence.
Instead of:
The build should work.
we need something closer to:
Build completed successfully.
154 tests passed.
0 tests failed.
Static analysis completed without errors.
Security checks passed.
AI should not only claim.
It should be able to prove.
This is where AI-assisted development connects directly with governance, compliance and auditability. If a system changes production code, infrastructure, documentation or security settings, we should be able to show what happened and why it was accepted.
AI needs review
The biggest mistake would be to let one AI system:
- analyze the task,
- design the solution,
- implement the code,
- test the result,
- and approve its own work.
We would not accept that in a human team.
We should not accept it in an AI workflow either.
Review remains important in the age of AI.
Probably even more important.
Independent review helps detect:
- regressions,
- security risks,
- hidden side effects,
- changes outside the requested scope,
- incorrect assumptions,
- and missing verification.
The goal is not to slow AI down.
The goal is to make speed safe.
AI needs learning
Every fixed mistake has value.
Not only for today.
Also for the future.
If a developer corrects the same AI mistake ten times, the system should not lose that experience after every session.
The correction should become a new project standard, a reusable rule, or a documented skill.
The future of AI will not only be about larger models.
It will be about systems that can learn from their own work.
AI needs software engineering
The more I use AI in development, the more I believe that the main challenge is changing.
The hardest problem is not only building a more intelligent model.
The harder practical problem is building better engineering around the model.
Models will continue to improve.
But without:
- workflow,
- memory,
- rules,
- verification,
- review,
- documentation,
- and evidence,
we will keep moving between impressive demonstrations and chaotic projects.
That is not enough for serious software, security or infrastructure work.
The question will change
In a few years, I do not think the most important question will be:
Which model do you use?
The better question will be:
What AI engineering process do you use?
Because that process will decide the quality of the outcome.
The model will increasingly become a commodity.
The process will become the competitive advantage.
So maybe the next phase is not prompt engineering.
Maybe it is AI engineering.
{"research-secure-ai-assisted-development":{"title":"Secure AI-Assisted Development","summary":"Engineering methodology for using AI coding assistants, code generators and agentic development workflows while preserving security review, traceability, testing, dependency control and deployment accountability.","url":"/research/secure-ai-assisted-development/","links":[{"title":"NIST SP 800-218 Secure Software Development Framework","type":"official-documentation","url":"https://csrc.nist.gov/pubs/sp/800/218/final"},{"title":"OWASP Top 10 for Large Language Model Applications","type":"official-documentation","url":"https://owasp.org/www-project-top-10-for-large-language-model-applications/"},{"title":"OWASP Top 10","type":"official-documentation","url":"https://owasp.org/www-project-top-ten/"},{"title":"AI-Assisted Development Needs Security From Day One","type":"my-blog","url":"/blog/ai-assisted-development-needs-security-from-day-one/"},{"title":"Vibe Coding Can Build Your Application. But Who Builds Its Security?","type":"my-blog","url":"/blog/vibe-coding-builds-applications-who-builds-security/"}]}}