Software Engineering Isn’t Dying. It’s Evolving: From Vibe Coding to Agentic Engineering

In 1878, Sir William Preece rejected the telephone. Today, the same story is repeating in software.

A Lesson from 1878

In 1878, Sir William Preece, Chief Engineer of the British Post Office, faced a question before a parliamentary committee:

“Will the telephone be widely adopted by the public in the future?”

His answer became one of history’s worst technological predictions:

“The Americans have need of the telephone, but we do not. We have plenty of messenger boys to deliver the post.”

Here’s the irony: Preece was the man who brought the telephone to Britain. He wasn’t unfamiliar with the technology. He simply refused to accept that the world was changing.

147 years later, I’m watching the exact same scene play out in software engineering.

“I Write My Own Code, I Don’t Need AI”

I’ve been hearing this more and more recently. There’s a growing group that labels engineers who use AI tools as “lazy” or “not real developers.” They reject every innovation without testing, trying, or attempting to understand it.

On the other end, there’s another extreme: people who believe writing a prompt will produce a flawless product. This is exactly what “vibe coding” means — coding by feel. No fundamentals, no questioning the output, just generating.

Recently on Lex Fridman’s podcast, Peter Steinberger (creator of OpenClaw) addressed both extremes head-on. His message was clear: using AI agents isn’t “vibe coding.” It’s an engineering discipline. He calls it Agentic Engineering.

Not blind rejection. Not blind trust. Managing agents with engineering rigor.

Why “Writing a Prompt” Isn’t Enough

An AI agent can give you a working endpoint in 30 seconds. But “working” and “production-ready” are worlds apart. Let me break this down with concrete examples.

Frontend: Generating Divs Is Not Designing Experiences

Ask AI for a login form. You’ll get a working one. But what do you find when you actually audit it?

Accessibility (a11y): Is aria-label present? Are role attributes correct? Does keyboard navigation work? Is the tab order logical? Can a screen reader parse this form correctly?

AI routinely skips WCAG standards. It’ll use a <div onClick> instead of a <button>. Visually identical -- but invisible to screen readers and unreachable via keyboard.

Design System Consistency: AI has no awareness of your existing design system. It doesn’t know whether your spacing scale is 4px-based or 8px-based. It doesn’t recognize your typography tokens. It can’t distinguish your semantic colors (success, warning, destructive). It gives you a working component that looks nothing like the rest of your product.

Performance: An AI-generated React component can create unnecessary re-renders. A list component written without useMemo or useCallback will re-render all children on every state change. Bundle size can balloon. Core Web Vitals (LCP, CLS, INP) are never AI's priority.

A real example: ask AI for an e-commerce product page. You’ll get one. But is that hero image lazy-loaded? Has LCP been optimized? Is there a font-loading strategy that prevents CLS shifts? Questioning these things requires knowing what Core Web Vitals are in the first place.

Backend: Working Code Is Not Secure Code

When AI writes a CRUD endpoint, it typically solves the “happy path.” But what about edge cases?

Security:

• SQL Injection: Did AI use parameterized queries or string concatenation?
• Rate limiting: What happens when 10,000 requests hit this endpoint per second?
• Authentication/Authorization: Is JWT validation correct? Is token expiry handled? Is role-based access control properly configured?

State Management Decisions: Ask AI for a state management solution. One time it suggests Redux, another time Zustand, another time React Context. The one who decides which fits your project isn’t AI — it’s you. Using Context in a 50-component app, or Redux in a 5-component form — both are wrong decisions. Making this call requires understanding the trade-offs.

Error Handling: AI typically wraps everything in a generic try/catch. In production, this makes debugging nearly impossible. Structured logging, error boundaries, graceful degradation -- these are never AI's priority.

Architecture: You Can’t Build Systems with Prompts

This is the most critical layer. And the one most people overlook.

Providing Context: AI agents are only as powerful as the context you provide. This isn’t just saying “read this file.” It means knowing your repo’s structure, understanding which services communicate with each other, recognizing where tech debt has accumulated — and feeding this to the AI. Because it can’t figure this out on its own.

MCP (Model Context Protocol) Integration: One of the most significant developments of 2025–2026. MCP enables AI agents to interact structurally with external sources — databases, APIs, file systems. But integrating this correctly into your project requires deep knowledge of your system. Which tools will you define? Which resources will you expose? What are the security boundaries?

Skill Files and Repo Truth: For AI agents to work effectively, they need well-structured SKILL.md files, proper .cursorrules, well-organized READMEs. Writing these files requires knowing your project intimately. The quality of AI-generated code is directly proportional to the quality of these files.

Choosing the Right Tool: Every week brings a new AI tool, a new framework, a new paradigm. Instead of cramming everything into your stack, filtering for what genuinely adds value — this is a matter of engineering maturity. Before asking “how can this be done,” you need to ask “should this be done at all?”

The Autopilot Analogy

Autopilot systems have existed in aircraft since the 1930s. In 90 years, the piloting profession hasn’t “died.” What happened was this: the pilot’s role evolved. They no longer hold the joystick manually. They manage complex systems. They detect anomalies. They intervene in crisis situations.

The same applies to calculators. Mathematicians didn’t become obsolete when calculators were invented. They stopped wasting time on arithmetic and gained the freedom to focus on more complex theoretical problems.

AI agents are exactly this: next-generation tools. But using a tool effectively requires knowing where you’re going. Autopilot is useless to a pilot who doesn’t know the route.

Three Groups

Today, the software world has three groups:

1. The Resisters: They reject every innovation. They cling to old workflows. “My way works,” they say. Yes, it works — for now. Sir William Preece’s messenger boys “worked” too.

2. The Believers: They believe AI solves everything. They see learning fundamentals as unnecessary. They write prompts and never question the output. They’ll face reality when they need to maintain that generated code six months later.

3. The Adaptors: They know the fundamentals. They adopt innovations selectively. They manage AI agents with engineering discipline. They don’t take every tool — they choose the right ones. They use tools to amplify human expertise, creating a multiplier effect.

Preece’s mistake wasn’t failing to understand the telephone. He was the man who brought it to Britain. His mistake was refusing to accept that the world had changed.

Conclusion: Time to Evolve

Agentic engineering isn’t the death of coding. It’s the evolution of coding.

The question isn’t whether to use AI. The question is how you use it. With engineering discipline, or with a “write a prompt, see what happens” mentality?

Master the fundamentals. Integrate innovations — but not all of them, only the right ones. Solve the problems you face faster and more effectively.

Adaptation always beats resistance.

Link to the full Lex Fridman — Peter Steinberger podcast episode is in the comments.