After close to a decade of building software, one principle has become clear: good engineering starts not only with asking whether a technology can be used, but whether it needs to be used at all.

This blog records lessons from working on backend systems: designing distributed services, recovering from incidents, modernizing legacy software, and deciding where AI belongs in a production workflow. AI can write code, but architectural judgment, trade-off decisions, and calm incident response still require accountable people.

What I write about

• Backend architecture — systems designed to be operated, not merely to run.
• AI and LLM engineering — agents, RAG, tool use, and the boundaries required to integrate them safely.
• Infrastructure and DevOps — Kubernetes, CI/CD, cloud-native systems, and making deployment less frightening.
• Technical writing and curation — source-backed analysis that exposes trade-offs rather than repeating product announcements.

The editorial approach

Each technical analysis aims to answer three questions:

Why does this matter now? → How does it work? → Can a real team use it safely?

The goal is not a catalogue of technologies. It is practical material for deciding whether a team should adopt something, what can fail, and how to keep the decision explainable.