I’m Arun, a Senior Technical Architect. My work sits at the intersection of architecture and engineering leadership: defining how systems are structured, governing the non-functional side, guiding teams, and staying close enough to the code to make those decisions well.

Day to day I work with product and engineering teams to turn business goals into a design people can build against. Often that means being in the middle of the hard production problems: working out why something is slow, or fragile, or failing only under load, and making sure the fix holds rather than moves the symptom somewhere else.

A fair share of the job is people rather than systems, so much of my week goes on reviews, mentoring, and getting teams to a shared understanding before the code gets written.

AI runs through most of what I do now: at work, in the side projects I build for myself, and in what I end up writing about here. At work that mostly means spec-driven development and AI-assisted delivery: specification first, tradeoffs recorded, then AI agents on the parts they are genuinely good at. What interests me is not whether it feels faster, but whether the rigour survives the speed.

What I work on

• Hard production problems: root-cause analysis on live issues, and fixes that hold
• Performance and resilience: tuning across the application and data layers, idempotent integrations, and systems that degrade sensibly instead of falling over
• Microservices and API design: service boundaries, versioning, and contracts that other teams and third parties can depend on; decomposing systems that have outgrown their original shape
• Observability and NFRs: making performance, security, and reliability first-class concerns rather than afterthoughts, and instrumented well enough to prove it
• Architecture as written artifacts: decision records, models, and migration strategies, because a decision nobody recorded is a decision nobody can revisit
• Guiding teams through delivery: architecture and code reviews, mentoring, hiring and interviewing, and coaching engineers toward decisions they can defend

Experiments

I’m curious about a lot of things, so I run experiments on my own workflows and projects. Some of them turn out to be useful to other people:

• A plugin that manages my stock portfolio: daily briefings, stop-loss audits, and risk checks, in about five minutes a day.
• Coding agents running entirely on free-tier models, with routing and compression layered on top, to find the practical limits.
• A two-line status line for my terminal showing the model, folder, git state and session cost at a glance.

Most of what I know about using these tools in practice came from side projects rather than from a roadmap. Tools and platforms change quickly, and AI has cut the cost of picking up a new one, so I care more about learning fast and delivering than about which stack a problem arrives in.

Certifications: SAFe® 6 Architect, Microsoft Azure (AI Fundamentals, Data Fundamentals, Fundamentals), Agentic AI.

On this blog I write mostly about applying AI to real engineering work: the tools I’m testing, what held up, and what didn’t. Occasionally architecture, when I have something concrete to say.