I am a software architect.
My job doesn’t start with code.
It starts with uncomfortable questions.
How do you build a CMS that can actually support a newsroom?
How do you design access control that is flexible and enterprise-grade?
And more importantly: how do you build something that will still make sense five years from now?
This is the story of how I designed Hyperion, an enterprise CMS platform, and how I used AI to help me build it — without letting AI make the architectural decisions.
I didn’t open an IDE.
I opened a blank page.
I wrote down three non-negotiable principles:
- Access control must be separated from the CMS
- Public and admin traffic must never share the same boundary
- Everything must be auditable
Those three constraints shaped everything that followed.
From them, the architecture emerged naturally:
- IAM Center — the single source of truth for users, roles, policies, and permissions
- Hyperion CMS Core — content, editorial workflow, media, crawler, SEO
- Public Gateway — a read-only microservice for rendering and caching
- Public Frontend — a Medium-style, reader-first website
At this point, I still hadn’t written a single line of code.
But the system already stood on its own.
Only after the architecture was clear did I bring AI into the process.
Not with prompts like:
“Build me a CMS”
But with prompts like:
“I have an AWS-IAM-style policy engine, category-scoped permissions, mTLS between services, default-deny authorization, and mandatory audit logs.
Implement this backend without shortcuts.”
That’s when AI stopped feeling like a chatbot.
It became a parallel engineering team.
I used AI to:
- Generate RBAC enforcement layers
- Implement policy evaluation logic
- Build a public read-only gateway optimized for caching and SEO
- Produce C4 architecture diagrams
- Draft ISO 27001 / SOC 2 security checklists
I didn’t blindly copy the output.
I reviewed boundaries.
I challenged assumptions.
I tightened constraints.
AI wrote the implementation.
I owned the architecture.
AI excels at:
- Boilerplate that follows strict rules
- Repeating patterns consistently
- Implementing well-defined designs
- Writing tests once expectations are explicit
- Catching edge cases I might overlook
But there are things I will never delegate to AI:
- Deciding to split the public site into a separate microservice
- Choosing mTLS + service identity between CMS and IAM
- Designing deny-by-default authorization
- Enforcing audit trails on every publish and permission check
- Deciding that Vietnamese content must keep its identity — while slugs must be ASCII-safe
Those decisions define the system’s integrity.
That responsibility belongs to the architect, not the tool.
This project made something very clear to me:
AI doesn’t replace software architects.
It replaces people who write code without understanding the system they’re building.
My role changed:
- Less typing
- More decision-making
- More responsibility
- More thinking about long-term consequences
I no longer “code features.”
I design constraints, and let AI accelerate execution within those constraints.
Hyperion is the result of:
- Clear architectural boundaries
- Correct security assumptions
- Auditability built in from day one
- A new way of collaborating with AI
Could I have built this system without AI?
Yes.
Did AI make it faster, safer, and more consistent?
Absolutely.
But only because I treated AI as a force multiplier, not a decision maker.
I didn’t use AI to design my system.
I designed the system —
and then used AI to bring it to life.
That’s the difference.
If you’re a software architect today, your value is no longer measured by how much code you write.
It’s measured by how well you design systems that others — including AI — can safely build.

