Story

I gradually realised that understanding a concept and being able to use it are very different things. Real projects bring constraints, incomplete information and trade-offs that textbooks naturally remove. That gap between theory and practice became something I started actively looking for rather than avoiding.

A convincing AI demo can hide a surprising amount of uncertainty. Once real users depend on the result, validation, recovery, reproducibility and trust become part of the product itself. I learned that production AI is often less about making the model more impressive and more about making the system around it dependable.

Over time, I started looking less at individual features and more at the relationships between them. Data, interfaces, services and infrastructure can each make sense locally while still creating problems elsewhere. I learned to think about boundaries earlier — not to over-design the system, but to make complexity visible before it starts spreading.

Skills, MCP, workflows and agents are often presented as separate choices. I came to see them more as stages of the same process: gradually moving work that once lived in a person's head into a system. Each layer hands over a little more — first an action, then an interface, then a sequence, and eventually some of the judgement about what should happen next. The useful question is not which label is newest, but how much responsibility the system is actually ready to take on.

Working closer to real business problems changed what I considered good engineering. Users rarely care how sophisticated the architecture is; they care whether the product makes their work clearer, faster or easier. I started to see technical complexity as something the product should absorb rather than expose. The better I understand the business problem, the less technical complexity the user should have to see.