From full-stack engineering to applied AI
How I learned to value systems people can trust—and why that led me from full-stack product engineering to applied AI.
Most software work looks local from the outside: a feature, a ticket, a screen, an endpoint. The work becomes more interesting when those pieces have to hold together over time—across users, teams, integrations, and the inevitable edge cases.
That has been the thread running through my career. I started as a full-stack engineer because I liked seeing a product end-to-end: from the interface someone uses, through the API and data model, all the way to the infrastructure that makes it dependable. Over time, the specific technologies changed, but the kind of problems I wanted to work on became clearer.
Learning to think in systems
Early work in product engineering taught me that reliable software is rarely about one clever technical decision. It is about the boundaries between decisions: how services communicate, how a change is released, what happens when an external dependency fails, and whether people can understand the system six months later.
I have worked across telecom, consumer products, Web3, identity, and document workflows. Each environment sharpened a different part of that instinct. A migration needs safe seams. A financial or identity workflow needs explicit trust boundaries. A product team needs systems that are fast enough to evolve, not only correct on launch day.
Why applied AI became the next step
AI did not change my interest in product engineering; it gave that interest a new set of constraints. An agent that calls a tool needs permissions. A retrieval system needs grounding and a clear way to say it does not know. An integration needs durable auth, schema validation, observability, and graceful recovery when something changes outside your control.
Those are engineering problems, not just prompting problems.
That is why I am most interested in applied AI: systems where models are useful because the surrounding product makes them safe, understandable, and dependable. The work spans agent orchestration, MCP and third-party integrations, identity, multi-tenant architecture, and the interfaces people use to stay in control.
What I care about now
I care about building AI products that earn trust through their behavior. That means making the happy path useful, but also handling the uncertain path well: scoped access, source-backed answers, typed contracts, idempotent actions, and feedback loops that make the system better over time.
This is the first note in a growing collection. I will use it to document practical lessons from building systems—not as universal rules, but as useful field notes for people working at the same boundary between product engineering and AI.