The Shift Nobody Prepared Me For

My path into engineering was the traditional one. Internships where I touched real codebases for the first time — building internal tools, wrestling with cloud services, shipping things that actual people used. Then Caris, where I worked on production systems and data pipelines, and started understanding what it really takes to ship reliable software at scale. Then Meta — where the codebase is massive, the review culture is relentless, and the velocity expectations force you to level up fast.

At every stage, the loop was the same. Read the ticket. Explore the codebase. Write the code. Debug. Ship. The bottleneck was always me — how fast I could context-switch, how many files I could hold in my head, how quickly I could iterate.

Today it's different. I still read the ticket. But then I describe what needs to happen, and an AI agent explores the codebase, drafts the implementation, runs the tests, flags what it's unsure about. My job shifted from writing code to leading the thing that writes code.

This isn't about AI replacing engineers. It's about what actually changes when you go all-in on AI — and what surprised me.

How Does the Dev Loop Actually Change?

The old loop was linear: plan → code → test → review → ship. One thread. Me.

The AI-native loop is concurrent. I kick off an agent to explore the codebase while I'm still refining the spec. Review its architecture proposal, adjust, let it implement while I think about edge cases. By the time I'm ready to look, there's already a working draft with tests.

The real change isn't speed — though that's real. It's where my attention goes. I used to spend most of my time on implementation mechanics. Syntax, imports, boilerplate, figuring out which file does what. Now I spend that time on design decisions, edge cases, system thinking — the stuff that actually determines whether software is good.

What Building Real Things Taught Me

The shift didn't click in a blog post or a conference talk. It came from building things — inside companies and on my own — and noticing where AI changed the equation.

At Caris, I was deep in data pipelines and production systems. The kind of work where reliability matters more than cleverness, and where you learn that the hard part of engineering isn't writing code — it's understanding systems well enough to change them safely. That instinct turns out to be exactly what you need when an AI agent is proposing changes to your codebase.

At Meta, I work at a scale where you can't hold everything in your head. Internal tools, web apps, services that touch millions of users. The review culture there — rigorous, opinionated, sometimes frustrating — trained me to develop taste for what good code looks like. That taste is the thing AI can't replace. It's what you use when the generated code looks right but isn't.

And this site — I designed it AI-native from the start. Structured data for LLMs, CLAUDE.md files that give agents full context, conversational search. The site itself became a test bed for how I think about engineering now. Not just "does it work?" but "can an AI collaborator understand this codebase well enough to contribute meaningfully?"

What Skills Actually Matter Now?

A few things I didn't expect.

When I write code myself, I can be vague in my head and precise on screen. With AI agents, it's the opposite — you need to be precise about what and why, but you can let go of how. The engineers who struggle with AI aren't the ones who can't code. They're the ones who can't articulate what they actually want.

I review far more code than I write now. And reviewing AI-generated code is subtly different from reviewing human code. Humans make systematic errors based on their habits. AI makes confident-looking mistakes in places you wouldn't expect. You learn to be skeptical of code that looks right — that's where the bugs hide.

The quality of AI output tracks directly with the quality of context you provide. This isn't "prompt engineering" — it's making your entire engineering environment legible to AI collaborators. Good naming, clear structure, well-written docs. The same things that help a new teammate ramp up quickly also help an AI agent contribute meaningfully. Not a coincidence.

And strong fundamentals still matter. AI makes strong engineers stronger. It doesn't make weak engineers strong. You need architecture sense, debugging instincts, and taste. The bar didn't lower. The leverage increased.

How Do You Lead AI Agents?

The most unexpected learning — managing AI agents feels like managing eager, skilled, context-poor junior engineers.

Set clear goals, don't micromanage implementation. Provide context — the system, the history, the constraints. Review with rigor. Know when to take over. The engineers who thrive here aren't the best coders. They're the best leaders — people who decompose problems, communicate intent, and make good calls about when to trust and when to intervene.

How Do You Stay in Rhythm When Everything Is Accelerating?

This is the part nobody talks about. AI-native development is exhausting in a new way.

The old bottleneck was throughput — you could only type so fast. The new bottleneck is judgment. Agents generate code faster than you can review it. New tools, models, patterns drop every week. The firehose is relentless.

I'm an essentialist. That philosophy isn't just some bio line — it's how I survive this.

Not every new tool is worth adopting. Not every AI suggestion is worth merging. I'd rather master one workflow deeply than skim ten. Know which 20% moves the needle, ignore the rest without guilt.

I block time for deep work on one thing, instead of letting agents scatter my attention across five. AI can be parallel. My judgment can't.

Side projects are laboratories. I test new workflows there, break things safely, develop intuition before bringing patterns into production work. Not everything makes it. That's the point.

And honestly, some of my best engineering decisions happen on a ski mountain or behind a camera — not staring at a diff. Creation isn't constant output. It's tension and release.

Where Is This Going?

We're at the beginning of something fundamental.

Individual impact is going way up. This is true whether you're at a big company or a small one. At Meta, the engineers who adopt AI-native workflows are shipping faster and tackling more ambitious projects. The same leverage applies everywhere — it's about how you work, not where.

The math is changing for small teams. Four or five people with strong AI collaboration skills can now do the work that used to require fifty or more. You don't need separate frontend, backend, infra, and data people when each person can operate across the stack with AI. The companies that figure this out — lean teams, massive output, low burn — are going to move incredibly fast. I think the next wave of breakout companies will look shockingly small.

There's a vibe shift happening too. The AI-native startups I'm paying attention to don't look like traditional startups. They're not raising huge rounds to hire huge teams. They're two or three founders who deeply understand a problem, move fast with AI, and ship something real before anyone else even finishes their PRD. The speed gap between people who build with AI and people who don't is becoming the defining competitive advantage. It's not just about code — it's how fast you can go from insight to product to feedback to iteration. That loop is compressing from months to days.

When anyone can generate code, taste becomes the moat. Knowing what to build and how to structure it. System design, user empathy, engineering judgment — those are the scarce skills now. Whether you're leading a team of fifty or a team of five, the edge comes from seeing the whole picture.

And the tools keep getting better. A year ago I was copy-pasting between a chat window and my editor. Now I have agents that understand my entire codebase, run in my terminal, coordinate with each other. The pace is staggering — and it compounds.

The Bottom Line

Going AI-native made me a different kind of engineer. I think more about systems, less about syntax. More about intent, less about implementation. More about judgment, less about speed.

The transition isn't easy — it means unlearning habits built over years. But if you're intentional about it, if you have the discipline to stay in rhythm instead of drowning in the flood, the work gets better. Not just faster. Better. That's what excites me most — the leverage is there for anyone willing to embrace it. My thinking on this is evolving fast, and if you're going through the same shift, I'd love to hear what you're learning.