My mother has seen my handwriting. Against all available evidence, she still believes it belongs in her greeting cards – preferably in cursive.
It’s not that I don’t appreciate a handwritten card. Quite the opposite. I understand why Mom loves them. There’s something intimate about recognizing someone’s handwriting, knowing they sat down with a pen and took a moment to write something just for you. To her, those little marks on the paper are evidence that a real person cared enough to make the effort.
The problem is that my handwriting has spent so many years in retirement that even I have trouble reading it. So I make my cards digitally. And I don’t mean picking a generic template, typing “Happy Birthday,” and calling it a day. I mean designing the card, choosing the artwork, incorporating personal photographs, getting the layout just right, and spending an unreasonable amount of time rewriting a message until it actually says what I want it to say. I can even make the typography look handwritten, although apparently that’s where the fraud begins.
Mom, meanwhile, can walk into Target, pick out a card designed by someone she’s never met, containing a sentimental message written by another complete stranger, add a few handwritten sentences, and consider the result personal. I can spend an entire evening creating something specifically for her, filled with our memories and words I’ve agonized over, and she’s still a little disappointed because the words came out of a printer.
I love my mother. I even appreciate the tradition she’s trying to preserve. But there’s something wonderfully upside-down about the idea that a mass-produced greeting card becomes personal when you add a few pen strokes, while something conceived, designed, and written entirely for one person somehow loses its personal credentials because a computer was involved.
To me, the thought is the personal part. The medium is simply how I deliver it.
And lately, I’ve been noticing a remarkably similar disagreement in the world of software engineering.
Many of my friends and colleagues have spent most or all of their careers as software engineers. Like nearly everyone else in technology, they’re figuring out what it means to work with AI now that the question has moved beyond whether to use it and toward how completely it should become part of the way we work. We use many of the same tools, talk enthusiastically about many of the same possibilities, and occasionally use the same phrase – AI-native engineering – to describe what we’re doing. The more we talk, though, the more I suspect we’re using the same words to describe two fundamentally different journeys. We’re heading toward roughly the same place, but we’re approaching it from opposite sides of the fence.
For many traditional software engineers, the journey begins with implementation. These are people who spent years learning programming languages, algorithms, frameworks, runtimes, databases, types, memory, networking and all the wonderfully specific things computers have historically required humans to understand before they’ll reliably do what we want. AI enters that world as an extraordinary accelerator. The engineer who already knows how to write the code can now describe some of it instead. The engineer who once spent an afternoon implementing a routine can ask an agent to produce a first version in minutes, inspect it, correct it and move on. The interface to the work changes dramatically, but the engineer’s underlying model of the work doesn’t necessarily change with it. AI allows them to spend less time manually implementing things they already understand how to build.
I seem to have arrived from the other direction. I started my career as a software engineer, but the parts of the job that interested me most were always closest to the human being on the other side of the screen. I loved figuring out what a product should do, how information should be organized, what an interaction should feel like, how one system should connect to another, and how something technically complicated could become simple and intuitive when it reached the person actually using it. I could write code, and I did, but I never fell in love with the ritual of coding itself. I didn’t enjoy staring at thousands of lines of implementation, mentally tracing my way through loops and branches, or spending an afternoon discovering which obscure technical detail was responsible for something behaving differently than I intended. Eventually my career moved toward product, experience, architecture, creative technology, media, and leadership – not because I stopped enjoying building things, but because I moved closer to the parts of building that I actually loved.
That instinct predates my career in big technology companies. Years ago, when I was building websites for small businesses, the work began long before I opened an editor. Many owners were still deciding whether the Internet mattered to their business at all. I would sit with them and talk about what the company was, who its customers were, what those customers needed, what the website should communicate, and why anyone would want to use it. Then I would design the experience, create the visuals, and build the site. Front end, back end, design, customer conversation, and business purpose were not separate departments in my head. They were all parts of the same thing. And I loved that.
When I later joined a much larger engineering organization, I discovered how thoroughly mature software companies can divide that whole into specialties. I remember arriving expecting some version of the work I had already been doing – design the experience and then build it – only to discover design belonged to another team. My job was implementation. The division made organizational sense, but something important had disappeared for me. I was no longer making the whole thing; I was making my assigned portion of it. Looking back, I suspect that was at least as important to my eventual burnout as the thousands of lines of code themselves.
For most of software history, there was a practical reason implementation expertise held so much power. You could understand a customer beautifully. You could design an extraordinary experience, map every workflow, anticipate every edge case, and know precisely what the product should do. Eventually, someone still had to write the code. Implementation knowledge wasn’t merely one useful skill among many; it was admission to the factory. If you couldn’t translate the idea into the languages and frameworks computers understood, you either needed someone who could or you weren’t shipping much of anything. That gave implementation expertise an unusual authority over the entire act of software creation, even though knowing how to implement a product has never been quite the same thing as knowing what product ought to be implemented.
I learned that distinction early. As a full-stack engineer with a focus on the front-end, I occasionally encountered pages and interfaces that had been created primarily by backend engineers. Sure, they worked. Every necessary piece of information was technically present. Buttons could be clicked. Data went where it was supposed to go. They were also, to put this charitably, not particularly well designed from a visual or usability standpoint. The people who built them could run circles around me in areas of computer science that simply weren’t where my own interests and strengths were, but none of that knowledge automatically told them where a button belonged, which information deserved visual priority, why an interaction felt awkward, or why a technically functional page could still be frustrating to use. Implementation expertise and product judgment overlapped, but they were never the same thing.
AI hasn’t created that distinction. What it has done is make it possible to cross it in ways that weren’t previously practical. For the past year and a half, I’ve been building complete software products again, but I haven’t returned to the way I built software twenty years ago. I work conversationally with AI agents. I define what the product needs to do, establish architecture and constraints, describe the behavior I expect, interrogate decisions, test results, reject approaches I don’t like, and keep pushing until the thing behaves the way I believe it should. If a field should accept only a particular kind of information, that’s the contract I care about defining precisely. If a duration needs one level of precision internally while displaying another to the user, I care deeply about specifying that behavior correctly. If an operation must continue after the user leaves a page, if two records must change together or not at all, or if a user must never be able to manipulate an identifier and see somebody else’s data, those are requirements I am exceedingly particular about. What I increasingly don’t care about is personally remembering every language-level mechanism used underneath them.
That can sound cavalier, but only if we assume rigor must reside in the same place it always has. Mine hasn’t disappeared; the mechanism producing it has changed. I can ask one agent to implement a specification and another to review the implementation without touching it. I can ask a third to search specifically for failure cases, another to examine security boundaries, and another to generate tests designed to break the assumptions the first agent made. I can isolate agents so they don’t inherit one another’s conclusions, ask for competing implementations, force each approach to explain its tradeoffs, and build independent checks for results that matter. The human responsibility shifts from personally performing every implementation and review task to designing a process in which implementation, criticism, testing, and verification can challenge one another. “Trust me, it compiled” was never a sufficient quality strategy for human-written code; “trust me, the model said it works” isn’t one either.
This is where I think the phrase AI-native begins to split into two meanings. For the traditional engineer, AI often performs work the engineer already knows how to do. If a requirement changes, that engineer may already know exactly how the algorithm needs to change and could write the modification by hand; AI simply makes the change faster. That’s powerful, but it is primarily an acceleration model. The engineer still knows how to do the work AI is doing.
For the AI-native builder, that isn’t necessarily the bargain. I may know precisely what I need the software to do without knowing precisely how I would implement it. If I decide that a process now needs to track how many times a state changes, I don’t necessarily need to stare at the existing function until I can personally devise the new variables and control flow. I can specify the new behavior, ask an implementation agent to modify the system, require an explanation of the change, add tests for zero, one, and multiple transitions, have another agent review the implementation, and verify that the new capability hasn’t changed the original result. AI isn’t merely accelerating an implementation I already know how to perform. It is extending my ability to build beyond the boundary of what I personally know how to implement.
That distinction matters because a rule that says you may delegate work to AI only when you could have done the work yourself would neuter one of the most consequential properties of the technology. We already accept AI extending people into disciplines they haven’t mastered. Software engineers now use AI to generate interface concepts, copy, graphics, and front-end experiences without first becoming professional visual designers, writers, or creative directors. The results vary wildly, because generating something and exercising good judgment about it are different skills. But the premise itself rarely seems shocking: AI can extend an engineer outward into adjacent disciplines. It is curious that the reverse movement – a product, design, or architecture person using AI to move inward into implementation – is still so easily treated as suspect unless that person can prove they could have written the implementation manually.
This creates an interesting contrast in what each group considers precision. Imagine that we’re both building a feature involving a numerical value. A traditional engineer’s questions may naturally travel downward: What type is this? How is the decimal represented? What happens if an integer becomes a floating-point value? How does the runtime perform this comparison? My questions tend to travel outward: Why is the customer entering this number? What precision actually matters to the person using it? What should we store, what should we display, and should those be the same thing? What happens at the boundaries? Where else does this value appear in the product? What would make the result misleading or confusing? Both are forms of precision. They’re simply aimed in different directions. The traditional engineer’s precision often travels deeper into implementation. Mine tends to travel further into the product.
AI has not made me want to become the kind of software engineer I deliberately stopped being years ago. What it has done is remove an activity I actively disliked from the critical path between I can conceive this product and this product exists. That lets me spend more of my finite attention on architecture, product behavior, user experience, visual design, workflows, feature strategy, integration, language, failure behavior, and the thousand small decisions that determine whether something merely functions or actually feels like a coherent product. I don’t want someone to hand me a Python repository and say, “Here’s your piece.” I also don’t particularly want to design an experience and throw it over a wall to an engineering team. I want the thing – the whole product – and AI increasingly lets one person retain ownership across boundaries that organizations historically had to divide among specialists.
That doesn’t mean those specialties disappear. It means one person can increasingly direct capability across more of them. I can move from customer problem to product strategy to interaction design to architecture to implementation direction to testing to deployment to positioning without pretending that I’ve suddenly become the world’s deepest specialist in every one of those areas. The connective tissue is no longer the programming language. It’s the product. The human increasingly holds the intent, judgment, and coherence while specialized machine collaborators supply capabilities on demand.
This is why I find some of the current conversation around “vibe coding” simultaneously useful and inadequate. There absolutely are people asking an AI to make something, accepting the first output that appears, seeing that it runs, and calling the job finished. That’s not what I’m describing. The difference lies in what happens between the first AI-generated result and the moment someone decides the work is ready to ship. Traditional engineering already relies on layers no individual engineer personally recreates – compilers, databases, operating systems, frameworks, cloud platforms, automated tests, static analysis, and countless dependencies. We learned long ago that correctness should not depend entirely on what one programmer happens to know and notice. AI extends that abstraction into implementation itself.
The industry hasn’t quite figured out what to make of that yet. We still tend to define technical credibility using the competencies of the people who historically had exclusive admission to the factory. Even supposedly AI-native conversations can quickly return to syntax, language internals, framework minutiae, and implementation details that made perfect sense when the human was the implementation engine. Some of that knowledge will remain valuable, and in some domains indispensable. But the more consequential question is no longer whether every builder can personally reproduce every implementation. It is whether the system they direct can reliably produce the intended product, expose its assumptions, survive meaningful testing, and provide enough evidence to deserve trust.
At the same time, implementation is becoming dramatically cheaper, and that changes the relative value of everything surrounding it. When code becomes cheaper, deciding what deserves to become code becomes more valuable. When technically functional interfaces can be generated in minutes, visual judgment matters more. When features become inexpensive to implement, product judgment matters more. When ten plausible solutions can be produced before lunch, knowing which one actually serves the customer matters more. AI can generate an interface astonishingly quickly; it is still far less reliable at looking at that interface and recognizing that the hierarchy feels wrong, the interaction is irritating, the language doesn’t sound human, the page feels cheap, or the requirement was satisfied while the person who has to use it was forgotten. Those are not secondary concerns to me. They are the product.
Perhaps this means we’re trying too hard to squeeze the emerging role into the word engineer at all. “AI-native product engineer” gets closer. “AI-native builder” may be closer still. I’m less interested than I used to be in defending the title. What interests me is the expanding class of people who can now move from conception to functioning software without first becoming specialists in every implementation layer between those two points.
For decades, implementation knowledge was admission to the software factory. AI is opening its doors to people who have always known what they wanted to build but didn’t necessarily possess every specialized skill required to build it themselves. I still read code, challenge technical decisions, test behavior, demand explanations, and take responsibility for what comes out of that factory. I simply don’t believe personally writing every line should remain the price of admission. What excites me is the ability to conceive something meaningful, shape the entire experience, and stay involved until the finished product becomes real.
As for Mom, I suspect we’ll continue our greeting-card disagreement for years to come. She’ll keep appreciating the warmth of a handwritten message, and I’ll keep designing cards filled with photographs, personal memories, and carefully chosen words. I rather like that neither of us is likely to change our mind.
But if you’re a software engineer who wants someone to appreciate every line of code you wrote by hand, I know exactly who would love to receive your Christmas card.
Just make sure you write it in cursive.