Systems architecture is evolving with LLMs and agentic workflows: the fundamentals still apply, but we’re now designing systems that include probabilistic components and automation that must be controlled, audited, and operated.
This blog is where I’ll document my journey from Senior Software Engineer to Systems Architect: staying grounded in robust system design, and using AI where it genuinely earns its place.
As a Senior Software Engineer, I’m always adapting: learning new technologies, picking up new languages when needed, and tackling problems that don’t come with neat answers. It’s not just part of the job — it’s what keeps the work interesting. I genuinely enjoy the challenge of improving my skills over time, and I’m now applying that same mindset to systems architecture.
The foundation: finance + high-performance computing
I started in financial software, where you live with the consequences of technical decisions: performance, auditability, uptime, and change control. After building experience across the full software lifecycle — requirements through to delivery — I moved into a Research Software Engineer role in a high-performance computing (HPC) environment.
That role forced versatility. Students and researchers would come to me with problems across different programming languages and stacks, and my responsibility wasn’t just to make something work — it had to be efficient, scalable, and maintainable by teams with different preferences and constraints.
It taught me one of the most important skills for becoming a Systems Architect: listening first — then designing and delivering with the team, not around them.
The realisation: systems architecture is a daily practice
When I returned to financial software as a Senior Software Engineer, I started noticing my role naturally shifting. Systems architecture isn’t a future job title — it’s a daily discipline.
It shows up in decisions we make every day:
- Intentional technical debt: choosing what to defer, what to fix properly now, and what you’ll come back to clean up.
- Observability that answers questions: logs, metrics, traces, and alerts that help you get to root cause — not just noise at 3 AM.
- Trade-offs in the open: writing down the “why” while it’s still fresh, so you’re not reverse-engineering decisions from git history later.
- Operational reality: designing for safe change, incident response, and supportability — not just “it works on my machine”.
The goal: fundamentals first, AI second
My original plan was simple: document the transition from Senior Software Engineer to Systems Architect. But the rapid rise of AI has added a new focus.
AI is transforming the industry — from automating workflows to powering intelligent systems. I use AI tools myself, and I see them as powerful assistants — not replacements. They can help turn ideas into code, but they still need oversight, direction, and human judgement to succeed.
My goal is to become a Systems Architect who can design and deliver robust systems with or without AI components.
Many systems — like payment processing pipelines — don’t need AI; they need correctness, idempotency, clear failure handling, and strong observability. But when a product genuinely benefits from decision support, recommendations, triage, or other “intelligence”, that’s where AI components earn their place.
Systems Architect first. AI as a tool when the problem calls for it.
I apply the same rule to my own workflow. My default is to write and reason first, then use AI to review, challenge assumptions, and explore alternatives. The risk isn’t “AI wrote some code” — it’s teams losing system comprehension. If you can’t explain how your system behaves under failure, you don’t really own it.
What to expect from this blog
This blog is more than a career diary. It’s a practical resource for developers and engineers navigating the intersection of systems architecture and AI.
One note before we get into the projects: I treat these posts the way I treat real systems — iteratively. As the implementation evolves, as industry expectations shift, and as postmortems reveal better approaches, I’ll update earlier posts so the documentation reflects what I’d stand behind in production.
I’ll share project-based tutorials where I build real systems end-to-end and document them the way a Systems Architect should: the problem framing, constraints, trade-offs, diagrams, security considerations, and the operational plan.
Each project will include:
- A working build: code, configs, and a clear “how to run it”
- Architect-style documentation: context, requirements, assumptions, non-goals, and decisions (with rationale)
- System design artifacts: diagrams, data flows, failure modes, scaling approach, and observability
- AI where it fits: if an AI component adds value, I’ll include it responsibly; if it doesn’t, I won’t force it
- Testing and verification: repeatable tests, performance checks where relevant, and lessons learned (including what didn’t work)
Before I start building, I’m locking in the foundational tooling and the decision filter I’ll use across every project — Terraform for infrastructure, Ansible for automation, and Eraser.io → Mermaid for design that lives alongside the code.
Next post: The Tools of the Trade: Infrastructure, Automation, and Design
If you’re curious about what it takes to design systems that embrace the tools of tomorrow, or you’re on your own journey from Senior Software Engineer to Systems Architect, I hope you find this useful.
Let’s explore the future of system design together.