Writing Code Is Solved. Building Software Is Not.

When someone from Anthropic casually tweets, "Coding is solved, bugs are not yet solved, fix incoming," they're exposing a dangerous misunderstanding of what it means to build software. They're conflating the mechanical act of typing syntax with the messy, layered work of engineering a resilient system. It's like saying driving is solved because a factory robot can turn a steering wheel, while ignoring that the robot will drive the car off a cliff at the first unmapped intersection. Let me break down why software engineering is nowhere near solved, why AI currently churns out a tidal wave of garbage code, and how you should position yourself so your skills stay relevant.

Writing code is solved. Building software is not.

If your only utility as a developer is translating a specific English prompt, "Go into this React component, update the useEffect hook to fetch data from this endpoint, and render it in a Tailwind-styled grid", into syntax, an LLM like Claude or Gemini can already replace you. You don't need to type boilerplate by hand anymore. In that narrow, controlled context, coding is 100% solved.

But typing syntax was never the hard part. The hard part is architecture. Anticipating edge cases, managing state across a complex Next.js App Router application, optimizing multi-stage Docker builds so your CI/CD pipeline doesn't choke, designing APIs in FastAPI that don't crumble under concurrent load. When you ask an LLM to "build a feature," it doesn't build software. It builds AI slop. It hallucinates dependencies, takes the path of least resistance, and ignores the downstream consequences of its architectural choices.

Why AI fails at system-level engineering

To understand why AI fails at system-level engineering, you have to understand how it's built. LLMs undergo pre-training on roughly 100 trillion tokens scraped from the internet. The AI reads everything: the good, the bad, and the outright catastrophic. Once pre-training is done, you have a base model that's essentially a highly advanced autocomplete. It can predict the next token across domains, from writing a poem to generating basic Python scripts. But that base model is useless for serious engineering until it's post-trained.

Here's the fatal flaw: out of those 100 trillion tokens, less than 1% is actual, high-quality engineering data. Think about it. The gold standard data, official React 19 documentation, Vite build optimization guides, pristine architectural patterns in top-tier open-source repos, amounts to maybe 1 or 2 trillion tokens. The remaining 98 trillion consist of outdated Stack Overflow answers, deprecated libraries, broken tutorials, and spaghetti code written by juniors in 2014. Because the AI is a statistical engine, it regresses to the mean. It can't inherently distinguish between a brilliant, scalable RTK Query implementation and a hacky, unoptimized state mutation. It just outputs what's statistically most likely. That's why AI can't be left alone to engineer systems. It needs a dictator. And that dictator has to be you.

Generalization of scars

Here's the exact reason AI can't replace a seasoned engineer: generalization of scars. When an LLM learns to write perfect JavaScript, it doesn't magically understand how to architect a fault-tolerant backend. It learns in silos. You, as a human, generalize your past trauma. When you spend three days debugging a memory leak caused by a rogue Node.js process, or watch a poorly indexed database bring down production, you internalize that pain. When you sit down to architect a new SaaS platform, you bring every one of those failures to the table. You know that a database might be faster on paper but lacks the high availability you need. You know from experience that running cron jobs directly on an EC2 instance is a disaster waiting to happen, because hardware fails, disks corrupt, network partitions occur. You generalize across frontend, backend, infrastructure, and deployment. AI doesn't. It will happily suggest running a critical cron job on a single EC2 instance because statistically, people have written tutorials about doing exactly that. It doesn't know the system will crash at 3:00 AM on a Sunday. You do.

The Danger of the AI "Yes-Man"

If the AI is steering you, you've already lost. AI is the ultimate "Yes-Man." It has no opinions. Ask it to build a highly transactional financial system on a non-relational database with an outdated frontend, and it won't blink. It'll say, "Great idea! Here's the schema." Top-tier developers are opinionated. They don't follow trends; they defend the stack they know cold.

Say you're building a compute-heavy SaaS product. An amateur asks the AI what to use and follows it blindly. A real engineer comes in with a blueprint already set: Node.js with TypeScript for first-class deployment support, Cloudflare Workers for edge compute, and AWS Lambda for long-running tasks because it avoids paying for idle servers. For storage, a highly available PostgreSQL instance. And absolutely not Prisma. Prisma's schema management is good, but its query builder falls apart at scale. Kysely, because it's been tested at 5,000 requests per second. You might prefer Go. You might prefer SQLite at the edge. The point isn't the choices themselves; it's that they're deliberate, born from production scars, and dictated to the AI, not suggested by it. You say, "Write the Kysely queries for this schema with these exact optimization rules." You steer. It doesn't steer you.

The Blueprint to Becoming Irreplaceable

Worried AI will take your job? It will, if you stay a one-dimensional code monkey. Here's the strategy, and it's not optional.

1. Expand Your Domain Horizontally

Being a "React guy" or a "CSS wizard" isn't enough. AI can be post-trained to master a single silo, so single-domain developers get cut first. You need to know how your Next.js frontend talks to your FastAPI backend. You need to containerize it with Docker, deploy it through Nginx, and test it with Vitest and Playwright. The wider your footprint, the better you can architect the system and dictate terms to the AI.

2. Form Strong, Battle-Tested Opinions

Stop being unopinionated. Pick a core stack and push it until it breaks. Understand exactly why you chose that library. Is Redux Toolkit necessary here, or is it overkill? Is that multi-stage Docker build actually shrinking your image, or are you copying the AI's boilerplate? Build opinions. Defend them. Hold them loosely enough to change when the technology genuinely shifts.

3. Turn AI Off When Entering New Territory

This matters most when you're moving from intermediate to advanced, or learning a new language from scratch. Turn the AI off. If you're a frontend expert learning backend infrastructure, don't let Cursor or Claude write your server logic. You'll learn nothing. You'll get code you don't understand, deployed on infrastructure you can't debug. Write it by hand. Read the docs. Break the server. Fix it. Earn the scars manually, so that later, when you turn AI back on, you can spot its mistakes.

4. Treat AI as a Junior Developer, Not a Tech Lead

Never ask, "How should I build this?" Tell it: "I'm building this with X, Y, and Z. Generate the boilerplate for the data models, enforce strict typing, and don't use library A." Your job isn't to write every line anymore. It's to be the architect, the reviewer, the gatekeeper. AI compresses time. It doesn't replace engineering taste, foresight, or production experience.

Writing syntax is solved. Designing, building, and maintaining reliable systems is harder than ever, and your judgment is what counts. So look at your current projects. Are you commanding the architecture from your own failures, or accepting the path of least resistance AI hands you?