I’ve spent a while experimenting with AI-assisted software development using tools like Claude Code, Codex and Kiro.
One thing has surprised me.
AI coding assistants receive plenty of implementation context, but very little architectural context.
Typically they can see:
- Source code
- APIs
- Unit tests
- Documentation
- Prompts
What they rarely see is why the system was designed the way it was.
That matters because many security decisions aren’t implementation decisions.
They’re architectural decisions.
Humans infer architecture
Experienced developers usually have advantages that AI doesn’t.
They’ve attended design meetings.
They’ve spoken with architects.
They understand organisational conventions.
They know which systems are trusted, where boundaries exist and why certain technologies were chosen.
Even when documentation is incomplete, experienced engineers can often infer architectural intent.
AI generally can’t.
It only knows what it’s been given.
Security starts before code
Looking back through the history of Secure by Design, one pattern kept appearing.
Whether you’re looking at:
- Microsoft’s SDL and threat modelling
- OWASP’s secure design guidance
- NIST SSDF
- CISA Secure by Design
- the Cyber Resilience Act
they all encourage organisations to consider security before implementation.
The terminology changes.
The mechanisms change.
The principle doesn’t.
Security is strongest when architectural decisions are analysed before software is written.
The gap
Today’s architecture diagrams are usually documentation.
They explain systems to humans.
They rarely provide structured guidance that AI coding assistants can consume directly.
That creates an interesting possibility.
Instead of treating architecture as documentation, perhaps we should treat it as engineering knowledge.
A model could become the source for things like:
- security requirements
- architectural controls
- implementation constraints
- trust-boundary rules
- implementation guidance
- assurance evidence
- evaluation criteria
Those aren’t separate documents.
They’re different views of the same architectural security analysis.
Architecture as executable knowledge
This is the idea I’ve been exploring.
If architectural knowledge became structured enough for tools to consume, AI coding assistants wouldn’t just receive prompts.
They could receive architectural intent.
That doesn’t replace threat modelling.
It doesn’t replace secure coding.
It doesn’t replace DevSecOps.
Instead, it gives those activities a consistent architectural source that remains connected to implementation throughout delivery.
As AI agents become increasingly capable, I think this becomes more important rather than less.
Interested in the history?
I recently researched how Secure by Design evolved from Saltzer & Schroeder’s original engineering principles through Microsoft’s SDL, OWASP, NIST, CISA and recent regulation, and why AI-assisted development may represent the next stage of that evolution.
The full article, including references, is available here:
https://isecurebydesign.com/news/what-is-secure-by-design
I’d be interested to hear how others are handling architectural context with AI coding assistants.
Do you think architecture should remain documentation, or should it become something AI tools can actively consume?
Top comments (0)