About / More than the stack
I like following those questions underneath the interface. That curiosity pulled me toward distributed systems, cloud infrastructure, and AI engineering.
Getting it to work is the start of the conversation.
The happy path
01 / Engineering instincts
Strong opinions, with room to change my mind.
I want to trace a system end to end before changing it. Documentation, logs, papers, and the existing code all tell different parts of the story. I often draw the workflow myself: knowing the components is not the same as understanding how they interact.
Where does the request go next, and what state does it leave behind?
I like agentic systems. I do not think every problem needs an agent. If a queue, a batch process, or a deterministic workflow solves the problem more reliably, that is a good engineering choice, not a less interesting one.
Collecting feeds does not need model judgment. Choosing what someone might want to read can benefit from it. I separated those jobs, then put downloads back in a background worker.
A technically correct system can still be a confusing product. I care about whether someone knows what happened, what is still running, and what they can do if it fails. They should not need to understand the architecture to trust the interface.
Why VITAL asks before actingIn a team hackathon project, I noticed five independent sandbox debates were waiting on each other. My contribution was moving them from sequential to concurrent execution. The useful question was not “How do I make each debate faster?” It was “Why are they waiting?”
One debate at a time
Finish A before B starts, and so on through E.
Independent work, together
Start A–E together; join their results afterward.
5+ min → ~2 minObserved in hackathon demo runs; not a controlled benchmark.
Read the engineering noteA faster response may cost more. More automation may need stronger review boundaries. A flexible design may take longer to ship. I find engineering most interesting when several solutions are reasonable, and understanding the constraints is what lets you choose.
What are we optimizing for, and what are we willing to give up?
02 / When I don’t know yet
I learn by moving between words, diagrams, and working code.
Start with the docs, the code, and the architecture. Follow a request until I can explain where it goes.
Sketch the connections. Ask about the parts I cannot explain. A diagram makes gaps in my understanding much harder to hide.
Build the smallest version. Give it a bad input, interrupt a dependency, or try the assumption I am least sure about.
Understand why it broke, change the design, and explain the choice in plain language. Then repeat.
then repeat
Usually accompanied by research papers, GitHub repositories, a YouTube deep dive, and a suspicious number of browser tabs.
03 / Building together
I enjoy building with people more than building in isolation. Explaining a complicated idea to someone else often shows me the part I do not understand yet.
I want the design to be understandable to someone besides its author. That means making room for questions, explaining a trade-off without hiding behind terminology, and listening when another person sees a simpler way.
I do not need my first idea to be the one we ship. I want us to understand why the one we choose makes sense.