A millennial who grew up with the internet — before it grew up with us.

There's a generation of developers who didn't start coding with Stack Overflow, let alone AI. We learned by reading, breaking things, and reading some more. We watched the web go from tables and marquee tags to React and edge functions — and we understood each step because we had to. Being born in the 90s isn't about nostalgia. It's about having built intuition the hard way, before shortcuts existed. The tools change. The thinking doesn't.

Frontend, backend, infra. I own the feature, not just my slice of it.

I don't specialize in a layer — I specialize in the outcome. I can design a database schema in the morning, wire up an API by noon, and polish the UI in the afternoon. I lean toward backend — logic, data flow, and systems thinking are where I feel most at home. But I know enough about every layer to make good decisions across all of them, and to avoid the blind spots that come from only owning one piece. You won't need to translate between me and another team.

Prompting until it works is not engineering.

Vibecoding is what happens when someone mistakes output for understanding. You prompt, it generates, you ship — and nobody actually knows why it works or what breaks it. I use AI constantly, but as an accelerator for thinking I've already done, not a replacement for doing it. Before I ask AI to write something, I know what I want and why. The difference shows up in code review, in production incidents, and in the conversations six months later when something breaks. I can have those conversations.

New codebase, no problem — no hand-holding needed.

Starting somewhere new is a skill. A lot of developers need weeks of ramp-up before they touch production. I don't. I've gotten good at reading codebases cold — finding the conventions, understanding the architecture, identifying where to plug in without breaking what's already there. I ask questions when I need to, but I come to those conversations having already done the work to understand the context. Day one isn't about proving yourself. It's about being useful.

AI is the tool. You are the engineer.

The developers who will struggle in the next decade aren't the ones who refuse to use AI — it's the ones who let AI do their thinking for them. AI is extraordinarily useful: it writes boilerplate, suggests approaches, catches errors, and speeds up every part of the development cycle. But none of that replaces the judgment required to know what to build, how to structure it, and whether the output is actually correct. The thinking stays with me. The typing can go to the machine.

No hype, no buzzwords, no overselling. What you see is what you get.

I don't have a personal brand built on LinkedIn, hot takes or conference talks about things I've done once. I don't claim expertise I don't have, and I don't dress up straightforward work in impressive-sounding language. What I do have is a clear-eyed view of what I'm good at, what I'm still learning, and what it takes to actually ship software in the real world. I say what I mean, I mean what I say, and I don't waste time on things that don't matter.

Napkin sketch to deployed product — I can handle the whole pipeline.

A lot of developers can build something. Fewer can take ownership of getting it into the world — and keeping it there. I've set up CI/CD pipelines, configured Docker environments, deployed to Vercel and AWS, and dealt with the unglamorous work of making sure what runs on my machine also runs in production. I'm not a DevOps specialist, but I know enough to not be blocked by the infrastructure side of the job. From the first conversation about what to build, to the moment it goes live, I can own that arc.

A bias toward motion. Ship it, then improve it.

Perfect is a moving target. The codebase you're imagining in your head is always cleaner than the one you're about to write, and waiting until it's ready is how projects die quietly. I ship — not carelessly, I care about quality and readability — but I've internalized that working software in front of real users is more valuable than polished software that never ships. You learn more from the former in a week than the latter in a month. Done is a feature. Iterate from there.

The opposite of human-in-the-loop. I think, I decide, AI executes.

Not a fan of human-in-the-loop. AI does the thinking, human approves — that's not control, that's the illusion of it. Flip it: I think, I decide, AI writes. Simple as that.

I write tests when they matter — and when I do, I write them properly.

Not everything needs tests. A static marketing site doesn't need a test suite. A one-off migration script doesn't either. Knowing when to test is as important as knowing how. When tests do matter — real logic, real edge cases, real consequences for breakage — I write them properly: arranged setup, a single action, clear assertions. No clever fixtures that obscure what's being tested. No mocks that paper over real behavior. ARRANGE / ACT / ASSERT is a pattern, but also a mindset: keep tests focused, readable, and failing for the right reasons.