Where I Stand as an Engineer

Anyone Can Learn, Anyone Can Build

AI has become ordinary.

Code completion, sure—but ask for a spec and you get an outline back. UI prototypes take minutes, not days. My English is still rough, but with translation in the loop I can work with people overseas. Things that used to mean “spend a few years first” increasingly mean “just try it and see.”

That’s not a bad thing. I design by sparring with LLMs and I’m building TerraDart while writing this post. I feel the convenience.

For someone who has lived by technology, though, it also feels like a threat somewhere in the background.

Anyone can learn the tech now. Anyone can build what they want, faster than before. What used to be obvious no longer is. Being an engineer is less and less about whether you can write code.

For a long time I thought of myself as “someone who only has technology.” I loved programming and believed that going deep was the whole point. As I wrote in Everything Has Meaning, I meant it in my first job.

That belief is shaking.

It feels like AI is thinning out the value of what I’ve built. Or maybe it isn’t—I don’t know. But the anxiety that it might is real. And sometimes I wonder if I’m still clinging to the “tech-only” frame to escape that anxiety.

Days Further from Writing Code

At my current job I also do pre-sales. I work with sales to hear customer problems and propose what our technology can do. If it lands, we get the deal. It’s not enough for the technology alone to stick. As I wrote in Everything Has Meaning, when the person across the table isn’t an engineer, you have to raise the level of abstraction. You listen in business language and propose change in business terms.

AI is pushing engineers into more of those conversations. I’m in that flow too. I still think of technology as the goal, so even in proposals I end up anchored on “what can this technology solve?” The hours I spend translating into business language are unlike my old self.

I’m also a team lead. Weekly 1-on-1s with my reports matter to me. It’s not a role for steering technical direction. People are scattered across different projects, so the conversations are about careers and what they want to learn next.

It’s not that I dislike 1-on-1s or the team. If anything, I think I’ve been lucky with the people around me—my manager who does 1-on-1s with me, and the people I lead.

Still, something in me catches. I defined an engineer as someone who writes code. Less time writing still feels off.

I don’t want to walk away from the technology I’ve spent years growing. In the AI era, I can’t always tell whether I want to protect the “tech-only” identity because I genuinely love the work or because I’m afraid.

That doesn’t mean I’m walking away from what I’ve been given. I’m still showing up.

What Came from Going Deep

Maybe I’m clinging to “tech-only” out of anxiety. When I think that way, everything I do starts to look defensive.

But it’s also true that going deep on technology led to meaningful connections.

Through Genkit, a product I love, I connected with an engineer overseas, co-authored a book, and finally met in person. I wrote more in Reflections on 2025, but my story with Xavi Portilla, based in Spain, started online. Last summer he DM’d me out of love for the product, and for about four months we traded drafts across the time zone.

We first met in person at Google Cloud Next ‘26 in Las Vegas. I posted about it on LinkedIn.

Xavi is deeply involved in the Genkit community and OSS. He works on Kubernetes-related OSS too. He’s a Google Developer Expert in AI, and I hear he was recently recognized in Go as well. During the book he was blunt about structure. I remember him saying there’s no need to rush. I see him as someone who practices how to deliver technology—not just someone with a good personality.

I don’t want to believe this happened only because I ran from anxiety into technology. For me, at least, this connection came from choosing to go deep.

What Makes Up Who I Am Now

Writing this far, I feel like things are sorting themselves out a little.

Technology is not a means to me. It’s the goal. I want to go deep on what I love, and when something is missing, I want to build what helps the developers who use it. OSS, internal tooling, articles—the shape changes, but the root is the same.

On top of that, there’s me as a person. Blogging, posting on social, speaking, making slides—putting my thinking out there. I think of that as self-branding. Criticism scares me a little. Still, if feedback can flow back into the product, that’s a good thing.

Another layer is putting specific technology out into the world. I love Genkit, so I wrote on Medium, contributed to an Awesome list, and co-authored a book. I think of that as tech branding. It comes from wanting the technology to be used more and understood more.

None of this finishes alone. Meeting Xavi is the obvious example. You enter a community, talk, and build something together. It’s not one-way broadcasting. There’s a back-and-forth.

These four things overlap into the engineer I am now, I think. Craft. Self-branding. Tech branding. Connection with community. They don’t separate cleanly. They’re all tangled.

Toward Better Developer Experience

Of those four, the direction that fits best is making developer experience better.

It’s close to what people call platform engineering. Less about the application feature itself, more about the environment where the people who build that feature can move without getting lost—safely and quickly. On a new project, that might mean cloud architecture, application architecture, and the development foundation: test environments, static analysis, linters, CI/CD. Lately, for building with AI, it’s also close to making tools that make developers’ lives easier. contextlint and gcp-cost-mcp-server are what I have in mind.

I’m not formally assigned to work in that direction, though. Pre-sales and management fill the days, so catching up on technology mostly happens outside work hours. That feeds the anxiety. Maybe I never quite know what the goal is.

Within days that lean business-side, the place I want to stand as an engineer is close to here. Less about shipping end-user features directly, more about laying groundwork so developers can build more easily. That doesn’t contradict the feeling that technology is the goal.

TerraDart, which I’m advancing while writing this post, sits on the same line. I’ll write more about it another time, but this is the center of what I’m working on with my hands now.

How I Work Now

I write far less code myself than I used to. More time goes to designing from scratch and sparring with LLMs. A large share of my day goes there. Working on TerraDart while writing this article and gathering demo material is a typical day lately.

That doesn’t mean I hand everything to the LLM. As long as the audience is human, I think some judgments still have to be human.

For OSS, there’s developer experience: the experience of the user and the experience of the maintainer. For blog posts, talks, and internal or external docs, I think in terms of readability, editability, presentation, who I’m talking to and how, and how deep to go. Machines don’t optimize all of that in one shot. Not yet, at least.

LLMs have unknown unknowns too, like humans do. Missing context, limits of training, shallow understanding of niche domains. Humans aren’t the only ones who don’t know what they don’t know. So I try not to swallow recommendations or reject them outright—I push back to understand. Even in areas I think I know, I may only be seeing the tip of the iceberg.

For that dialogue I use grilling, a skill from Matt Pocock. One question at a time instead of a wall of output. The LLM still proposes. I answer with things like “from experience, isn’t this missing something?” or “for security, wouldn’t this be better?” Without domain knowledge you’d probably just follow the recommendation. Experience matters, of course—but I think what keeps me questioning is also the assumption that we may both have blind spots.

---

I’m facing anxieties I can’t fully see while pursuing the developer experience this AI era calls for. Building TerraDart and contextlint is part of that. I plan to keep updating who I am now—not only by building, but by putting things out there.

I think that’s where I stand today.