The Tale of Two Engineers
AI-assisted coding is now the norm. It’s part of the workflow, part of the job, and for some, it’s part of a professional edge. This blog post is about two fictional engineers who work at a technology company—both use the same AI and other tools, both have similar job descriptions, and yet their career trajectories couldn’t be more different.
Let me tell you about them.
Jake exemplifies the mindset and skillset that define a great engineer.
He’s sharp, thoughtful, and has this uncanny ability to understand the intent behind every line of code—whether it’s his own, team code, or AI-generated code. He doesn’t just write software; he designs systems with foresight, always keeping maintainability, readability, and performance in mind. Jake uses AI like a second brain. He uses prompts with precision—asking it not just to generate a function, but to explain tradeoffs, offer alternatives, or generate test cases he then carefully evaluates. AI never writes Jake’s code for him; it collaborates with him.
He'll sometimes paste in a snippet and say, “This works, but I don’t love the abstraction. Can we refactor this together?” You can tell he treats the AI not as an all-knowing, Yoda-like oracle, but as a collaborative partner—someone to engage with, question, and build alongside. The result? Clean, thoughtful code that fits naturally into the broader architecture. He documents, reviews, and teaches—our junior dev’s go to Jake to understand why something works.
His code reviews are a joy to read: not just technical but insightful. You learn from them. Management notices too. His recent performance review called him “a force multiplier” and “a mentor through code.”
Then there’s Alex.
Alex isn’t a bad person. In fact, he’s friendly and easygoing. But as a developer? He’s... middling. He leans heavily—too heavily—on AI. Where Jake uses AI to explore ideas, Alex uses it as a crutch. He copies code from the assistant into our repo with minimal understanding and rarely questions its structure. If a bug appears, he pastes it back into the tool hoping for a quick fix. When asked to explain how a chunk of logic works, he usually shrugs or recites what the AI wrote, word for word.
I’ve seen him submit pull requests with functions so convoluted that even the AI gets confused when we paste it back in for clarification.
His code reviews are often a formality. “Looks good to me” is a phrase he overuses, even when the code clearly doesn’t. Worse, his changes have introduced bugs—subtle ones, the kind that slip through until a real user stumbles over them. Our senior engineers now double-check anything he touches.
Management has noticed. During our last team meeting, a rumor circulated that some underperformers might be let go in the next cost-cutting cycle. Alex’s name came up quietly, uneasily.
It’s not AI that sets Jake apart from Alex—it’s his craftsmanship.
Jake earns the trust of both team members and engineering management because he takes full ownership of his work. He understands the fundamentals—how memory is managed, why certain APIs behave the way they do, and which edge cases to anticipate. He’s not afraid to speak up—whether it’s, “This needs to be rethought,” “This could be written differently,” or, more pointedly, “This is just plain wrong!” To Jake, code is a form of communication—not just with the machine, but with every future engineer who will read it.
Alex, on the other hand, treats AI like a vending machine: enter a prompt, get code, ship it. He struggles to earn trust from the team. His work is often met with skepticism, as others see him more like a student who copies homework from smarter classmates rather than someone who truly understands the material.
Is Jake aware that he’s becoming even more valuable in the age of AI? What’s on his mind as he considers the opportunities ahead—and what new challenges might he be eager to take on?
Does Alex realize he’s becoming replaceable? If the AI can write his code—and explain it better than he can—what value is he really bringing?
Stories like this may well shape the future of software engineering teams.
AI won’t eliminate developers, but it will expose the ones who don't understand the systems they build. It will widen the gap between those who think critically, who design and architect, who ask why—and those who merely execute.
Jake is what I’d call “AI-augmented.” Alex is “AI-dependent.” One’s being accelerated by AI-as-a-tool; the other’s being displaced by it.
We’re entering a new era—one that echoes the old age of guilds and craftsmanship, where mastery, attention to detail, and pride in one's work define excellence. In this AI-powered world, craft in coding matters more than ever. The abundance of powerful tools doesn’t diminish the role of the engineer—it raises the bar. Tools can accelerate output, but they don’t replace judgment, creativity, or deep understanding.
Great software engineers today see coding not just as a technical skill, but as an evolving art form. They recognize its elegance and complexity, and they approach it with care, intention, and discipline. In a world where anyone can generate code, what sets true professionals apart is their mindset—their commitment to clarity, structure, and long-term quality. The craft is the differentiator now. And those who embrace it will define the future.