How I work

I like moving fast.

Not by cutting corners, but by figuring out which corners actually matter.

Most slow projects are not slow because the code is difficult. They are slow because the problem is vague, ownership is unclear, decisions are reversible but treated as permanent, or too much is being built before anyone has learned anything.

I try to remove that friction early.

I want to understand the mechanism quickly: what goes in, what should come out, who owns what, what can fail, and how we know when it has. Once that is clear, I would rather build something useful today than spend a week designing the perfect version of it.

Speed and quality are not opposites. Good structure is what lets you have both.

I build systems with clear states, explicit ownership, sensible failure paths, and verification where it matters. That means I can iterate aggressively without making the system fragile. Ship, observe, correct the assumptions that were wrong, and keep going.

The same thinking shapes how I use AI.

I have worked with agents, LLMs, SLMs, retrieval systems, embeddings, classifiers, and the infrastructure around them. One of the more useful things that experience has taught me is that AI is not automatically the best solution to a problem.

Knowing how to use a model matters. Knowing when not to use one matters more.

If a rule can solve something reliably, I use the rule. If code can guarantee an invariant, I do not ask a model to remember it. If a database can enforce the truth, I let the database do that. AI earns its place when the problem involves ambiguity, language, interpretation, ranking, or reasoning that would otherwise be brittle or impractical to encode.

The best AI systems I have built are rarely AI all the way down. They are ordinary, well-engineered systems with probabilistic components placed exactly where they are useful.

Models handle uncertainty. Software handles guarantees.

That boundary is important.

An agent doing impressive work is not enough. I want to know whether it finished, what it changed, whether the result is valid, and what happens when it gets something wrong. Autonomy without observability is just a faster way to lose control of a system.

The goal is not to build the most sophisticated system.

It is to understand the problem well enough that you do not need to.