AI Handles the Code. Can You Handle the Rest?

Every few years, a technology conference produces a talk that lands differently than the speakers around it — not because it's louder, but because it's asking a harder question. Will King, a design engineer at Snowflake, gave one of those talks at Laracon US this week, and the title tells you exactly why the room paid attention: AI Can Do Your Job.

King's argument runs like this: if you can describe what done looks like before the work starts, AI can do it. Full stop. The part of your job that involves writing code to a known specification — the rote execution layer — is already being swallowed. What remains, what has always been the actual job, is deciding what's worth building in the first place. That's creative work. And here's where King makes his sharpest move: he refuses to let developers wave creativity off as someone else's department.

"Creativity has a branding problem," he told the audience. "Design does not own creativity." What he means is that before a single line of code gets written, someone has to answer the question of which lines are worth writing. That question doesn't answer itself. It requires judgment, context, the ability to look at a user complaint and recognize it as a symptom of something structurally wrong with your product rather than a feature request to be checked off a list.

That observation is correct, and it's been correct for a long time. King is not the first person to point out that software development was never really about typing. He is, however, making the point at a moment when the typing is being automated at speed, which gives the observation a sharper edge than it usually carries.

The Framework Is Sound. The Framing Has a Catch.

King lays out a process for cultivating creativity that is, frankly, more rigorous than most conference talks on the subject. Catalysts come from two places: the work itself (feedback, bugs, product misuse patterns) and the world outside it (anything you've ever experienced that has nothing to do with software). He argues that novel ideas emerge when what you notice collides with what you know — and that the depth of what you know determines whether a catalyst becomes an idea or just fades as a vague frustration.

His point about domain expertise is one worth sitting with. King suggests that the developers who get the most out of AI tools will be the ones with genuine mastery of their field, because domain fluency is what lets you tell a model what you actually want rather than accepting whatever it produces. This tracks with what we're seeing across the industry — the 17% skill decline Anthropic's research has documented in developers who lean on AI without building fundamentals suggests that the shortcut is also a trap. Expertise, in King's framework, isn't just good for creativity. It's good for using AI well.

So the framework holds. But there's a distributional problem buried inside it — meaning it benefits some people far more than others, and King doesn't address that gap. His prescription for developing creatively involves building a personal library of inspiration, pursuing wide-ranging outside interests, deliberately seeking diverse inputs, and investing time in mastering your medium. These are genuinely useful practices. They are also practices that require time, stability, and the kind of cognitive bandwidth that comes from not being stretched thin by financial pressure or job insecurity.

The room at Laracon was full of working developers — people with the seniority, the income, and the conference budget to be there. King's framework speaks fluently to that room. It speaks less clearly to the developer who is already wondering whether their contract gets renewed, or the junior engineer whose "creativity" budget is approximately zero hours per week because the backlog never shrinks.

The GPS Problem

Here's the analogy that keeps nagging at me. GPS navigation made it dramatically easier to drive somewhere you've never been. It did not make you a better driver. It made you a more dependent one — there's a documented body of research showing that heavy GPS use degrades the spatial reasoning you'd otherwise develop naturally. Nobody argues that GPS was a bad invention. But the people who understand roads, who have an internalized map of a city, who know what the traffic pattern looks like at 5pm on a Thursday — they use GPS differently than someone who just follows the blue line and parks wherever it says.

King's framework essentially argues: be the person who understands roads. Master the underlying domain so thoroughly that AI becomes a tool you direct rather than an oracle you follow. That's the right answer. But it requires you to have done the work before the tool arrived, or to be disciplined enough to do it despite the tool being present. That's a harder lift than King's talk suggests, and right now there's reasonably strong evidence that AI coding tools make the undisciplined path — just follow the blue line — extremely easy to take.

What King Gets Genuinely Right

The most useful thing in the talk is the argument against treating feedback as a solution. King is pointed about this: "Catalyst should always be treated as a signal, not the source of truth." A customer complaint tells you where to look. It does not tell you what to build. The developer who reads a support ticket and immediately translates it into a feature is skipping the creative work — the zoom-out, zoom-in process of figuring out whether the request is a symptom of a deeper structural mismatch between the product and how people actually use it. That discipline, applied rigorously, is probably worth more than any individual technical skill in a world where AI can execute technical tasks on demand.

His point about fidelity is similarly practical. "The goal isn't perfection. The goal is clarity." The right prototype is the smallest thing that answers your current question, built from the cheapest materials that give you a usable signal. Industrial designers have known this for decades — you don't injection-mold a part before you've confirmed the form in foam. The cost of building throwaway tools to answer specific questions has dropped to near-zero with AI assistance, which means the excuse for building at the wrong fidelity — "it would take too long to make a quick version" — has largely evaporated.

And the talk's core loop — catalyst, idea, contact with reality, clarity, new catalyst — is a clean description of how creative work actually functions when it's functioning well. "The output of creativity is not the artifacts that you make along the way," King says. "The output is the clarity that you get while making them." That's worth underlining. The Figma mockup, the throwaway prototype, the rough draft — these are instruments of learning, not deliverables. The confusion between the two is responsible for an enormous amount of wasted effort and misplaced attachment to early work.

My Read

King is right that creativity is learnable. The binary view — you either have the gift or you don't — is a convenient fiction that lets people off the hook. Creativity has a process, that process can be practiced, and there's nothing mystical about developing taste through accumulated exposure to what works and what doesn't. The counterfeit-bill examiner who recognizes a fake through touch alone got there through volume, not talent.

But I think King is also, without quite meaning to, delivering a talk that is easier to act on if you already have slack in your life. The developers who will thrive in the framework he describes — the ones who build broad input libraries, who invest in mastering multiple domains, who have the time and stability to pursue interests with no obvious connection to their work — are disproportionately the ones who were already in a strong position. That's not an argument against his framework. It's an argument for being clear-eyed about who it's written for.

The uncomfortable question underneath this whole conversation — one that King gestures toward without quite landing on — is not whether creativity is learnable. It's whether the creative layer of software development will remain as valuable as he suggests, or whether AI will continue creeping up the stack, handling more of what we currently call judgment. The pace of change in AI coding tools in the last two years makes that question harder to dismiss than it was when the conference-talk version of this argument first started circulating.

King's answer is that figuring out what's worth building is a job AI can't do. He may be right. I'd be more confident in that claim if AI weren't getting demonstrably better at the things we said the same thing about twelve months ago.

---

Bob Reynolds is Senior Technology Correspondent at Buzzrag.