The 1x, the 10x, and the 100x: Three Types of Engineers in the Age of AI

And why I don't care which one you are today — I care which one you want to become.

---

I've spent 30 years in consulting, the last several building and leading Data Engineering teams across Canada and Latin America. I've done hundreds of interviews with engineers. I've watched technology waves come and go (client-server, web, cloud, big data, and now AI). And I'm going to be direct with you: this one is different.

The discipline of writing code is being disrupted in ways most people aren't ready for. The barrier to producing working software has dropped to nearly zero. Anyone with a laptop and access to an LLM can generate a functioning application in an afternoon. People celebrate this as democratization. I see it differently: producing code and engineering software have never been the same thing. AI just made that gap so wide that nobody can pretend otherwise anymore.

What I'm seeing across the industry (in my teams, in the talent pipeline, in the open source community) is the emergence of three distinct archetypes of people writing code. Years of experience and academic credentials have surprisingly little to do with it. What separates them is mindset — how they think about the craft, and critically, how they use AI.

Let me break it down.

---

The Coder — The 1x Engineer - The Vibe Coder

Let's start here because this is where many people live now. That's fine — just don't get comfortable.

The Coder knows enough. Enough Python. Enough JavaScript. Enough to be dangerous. They can hack something together through sheer, relentless trial and error. Copy this snippet from Stack Overflow, paste that block from a ChatGPT response, bang on it until it runs. Ship it. Move on.

They write everything in one file. Maybe two if they're feeling organized. Functional programming — though let's be honest, they didn't study the paradigm and make a deliberate choice. It's just all they know. No classes. No modules. No separation of concerns. Code quality? Performance? Long-term maintainability? Those are someone else's problems. Source code control? CI/CD pipelines? They've heard of Git. Maybe they have a GitHub account. They push to main and pray.

How they use AI: This is the vibe coder. They throw a prompt at an LLM, get back code they don't fully understand, run it, hit an error, and their next prompt is literally: "Fix this error." Over and over. They treat AI like a magic box that should just work. They use VS Code with a couple of plugins, maybe Cursor, maybe Lovable or v0. The tool doesn't matter because their approach is always the same: generate, fail, ask the AI to fix it, repeat. There's no architecture. No specification. No intention beyond "make it work."

And look — they do make it work. That's the scary part. You can vibe-code your way to a working prototype. You absolutely cannot vibe-code your way to a production system that serves real users at scale.

---

The Programmer — The 1 < x < 10 Engineer - The Context Engineer

This is where things start getting interesting. The Programmer has a builder mindset. They came up through a bootcamp, maybe a CS degree, and they've been in the industry long enough to get burned by bad code, probably their own. That scar tissue matters. It's where craft begins.

They understand some best practices. They know what SOLID principles are, even if they don't apply all of them consistently. They appreciate testing: unit tests, maybe some integration tests because they've lived through the 3 AM production incident caused by untested code. They're familiar with architectural patterns: MVC, event-driven, maybe microservices. They have an opinion about monoliths vs. micro-services, and it might even be a good one.

They use CI/CD pipelines. They automate deployments. They track everything in source control and would never push directly to main without a pull request. They create repeatable, documented processes. They care about code reviews because they've seen what happens when nobody reviews anything.

Most importantly, they have appreciation and interest in the craft. They read technical blogs. They watch conference talks. They're genuinely aware of the long-term impact that bad design and sloppy code have on a codebase. They've inherited someone else's mess, and they swore they'd never inflict that on another team.

How they use AI: The Programmer writes longer, more deliberate prompts. They understand that context engineering matters: that the quality of the output is directly proportional to the quality of the input. They use agent personas, one at a time, giving the AI a specific role: "You are a senior Python developer reviewing this function for edge cases." They work through manual run-test-fix loops using VS Code plugins, Cursor, or similar tools. It's methodical and intentional — a real step up from vibe coding.

But it's still fundamentally interactive and manual. They're using AI. They haven't yet learned to orchestrate it.

---

The Software Engineer — The 100x Engineer - The AI Accelerated Software Engineer

Now we're talking.

The Software Engineer doesn't see code as the goal. Code, to them, is a necessary liability. Every line of code you write is a line of code you have to maintain, debug, secure, and eventually retire. The goal is to solve business problems, period. Code just happens to be the current medium for doing that.

These people think in systems. Distributed systems, domain-driven design, bounded contexts, event sourcing. They understand the full software lifecycle — especially the unglamorous part where you instrument observability, plan for failure modes, and design rollback strategies. Anybody can write features. These people think about what happens when the features break at 2 AM. They define clear boundaries, interfaces, and contracts between system components. They're masters of abstraction — the practical kind that makes systems decoupled, testable, and scalable, not the ivory-tower kind that lives on whiteboards and dies on contact with production.

They treat infrastructure and configuration with the same rigor as application code. Infrastructure as Code is a non-negotiable. They pick boring, stable technology every time because boring reduces cognitive load and technical debt. They know that the sexiest architectural choice is the one that lets the team sleep through the night.

How they use AI: This is where it gets truly transformative. The 100x engineer has moved way past "chatting" with AI. They orchestrate it.

They move beyond single-agent interactions to multi-agent systems where distinct AI personas: Architect, Coder, Reviewer and Tester to collaborate on the same problem. The engineer acts as the conductor. They write high-fidelity specifications using Spec-Driven Development: you define the what and the why with surgical precision, and then you review the AI's how. You become the Product Manager for the AI. The code is a byproduct. What you're really defining is the contract that code must fulfill.

They let AI automate the TDD loop. The AI generates test cases first, then writes implementation code to pass them, then refactors for optimization. The engineer reviews, challenges assumptions, and validates against the broader system context. They leverage AI for the highest-leverage tasks: generating documentation from code, refactoring legacy codebases safely, performing semantic search across entire repositories to understand system-wide impact before making a change.

And above all they are the Human in the loop. The Human is the one who makes the final call. The Human is the one who owns the system. The Human is the one who is responsible for the long-term health of the system. They are commited to understand every change that is being made to the system, and to understand their impact before making a pull request. Their leverage comes from using the SDLC to generate specs and letting the AI handle implementation.

And here's the part that separates them from everyone else: they treat spec documents as composable, version-controlled software artifacts. Their spec documents live in repos. They're reviewed in pull requests. They're iterated on like any other piece of the system. Because they understand that in the age of AI, the prompt is the specification, and specifications deserve the same discipline as code.

---

So What?

Here's why this matters. We're entering an era where the total volume of code being produced is going to explode exponentially. AI makes it trivially easy to generate code. But generating code without understanding the system it lives in, without thinking about the contracts it must honor, without planning for the failure modes that will inevitably happen — that's just typing with extra steps.

The 1x Coder produces code. The 10x Programmer builds features. The 100x Engineer designs systems that endure.

And the brutal truth is that most of the code being produced by AI today is being generated by 1x Coders who have no idea they're accumulating technical debt at a pace that will cripple their teams in 12 to 18 months. The illusion of velocity is intoxicating. The hangover is coming.

---

A Note to Those Who Find Me Online

If you're reading this because you're interviewing to join my Data Architecture and Engineering team (whether in Canada, Mexico, or Colombia, or the United States), here's what I want you to know.

I would love for you to be a 100x engineer. But you don't have to be. Not yet.

What you do have to be is a 1 < x < 10 engineer who wants to become a 100x engineer. Someone who is passionate about the craft. Someone who is relentlessly dedicated to sharpening the saw. Someone who understands that working smarter requires hard work, dedication, and a real commitment to continuous improvement.

I'm not looking for people who can generate code with AI. I have 8 billion potential candidates for that.

I'm looking for people who understand why the code exists, what system it serves, and how to make sure it doesn't become a liability the moment it hits production. People who use AI to amplify their engineering judgment — because they have engineering judgment worth amplifying.

If that sounds like you or more importantly, if that sounds like who you're becoming, I want to talk to you.

Bring your curiosity. Bring your hunger. We'll build the rest together.