I gave a guest lecture on AI in Michael Hilton’s Foundations of Software Engineering course (CMU 17-313) today. One of my favorite things about lecturing is the conversations that happen afterward, the ones that go in directions nobody planned.

This one hasn’t left my head: software engineering is going through the same transition that building went through in the 18th century, when structural design separated from craft construction and became its own discipline. What we now call civil engineering.

The welders who join steel beams on a bridge are skilled tradespeople. They’re not involved in the structural design. They don’t decide where the load-bearing members go. They don’t reason about wind shear or seismic tolerance. But the bridge is designed so that a welder doing their job correctly can’t bring the whole thing down. The structural engineer’s job isn’t to weld. It’s to create a system where welding happens safely within well-defined constraints.

I think this is what’s happening to software engineering right now. Not in five years. This year.

The Split

Product managers are writing code. This is how I operate with Zabriskie, the app I’m building. I act as a product manager more than a programmer. I have non-technical collaborators who file bugs and feature requests, and Claude Code implements them directly. People who’ve never written a line of code are describing what they want, the AI writes it, they verify, it ships. The feedback loop is tight and the results are surprisingly good.

But someone has to design the bridge. Someone has to decide how the database schema handles multi-tenancy. Someone has to design the deployment pipeline so a bad change rolls back automatically. Someone has to build the abstraction layer that lets a product manager add a new notification type without accidentally breaking the payment flow. That’s the platform engineer. The structural engineer of software.

The PMs writing features? That’s the welding. And there’s nothing wrong with it. But it only works if the bridge is designed right.

The profession is splitting. The mistake would be pretending it isn’t happening.

What the Platform Has to Guarantee

Here’s where civil engineering has something important to teach us.

A civil engineer doesn’t just design a bridge. They decide where the bridge goes based on geology, water flow, soil load. They specify the materials. They calculate the forces. They design the inspection regime. They assess the environmental impact. They ensure compliance with building codes. Then, and only then, does construction begin.

Every one of these has a software analog, and together they paint a picture of what platform engineering actually is:

What Actually Changes About the Job

This isn’t about coding becoming less important. It’s about what you spend your time on.

Today, most software engineers spend the majority of their day writing features. Tomorrow, I think the best ones will spend their day designing the systems that make it safe for anyone to ship features. This is what I’ve been spending most of my time on with Zabriskie. I’m not writing much code anymore. I spend my time with the AI directing the platform direction. What are the domain boundaries? What needs isolation? Where do we need observability? How does the system heal itself when something goes wrong? That’s the job now.

The day-to-day shifts. Instead of “implement the notification preference screen,” it’s “design the notification system so that a PM can add a new notification type and the worst thing that happens if they get it wrong is that one notification doesn’t send.” Instead of writing the migration, it’s designing the migration system so that conflicting migrations are detected and blocked automatically. Instead of fixing the bug, it’s building the observability that surfaces the bug before a user reports it.

It’s not a demotion. It’s a different kind of engineering. And honestly, it’s harder. Writing a feature is a bounded problem. Designing a platform that stays safe as dozens of people and agents ship changes to it every day, that’s an open-ended one. With AI agents doing more of the feature work, the assumption has to be that individual changes will sometimes be imperfect. Agents hallucinate. They introduce subtle bugs. They make confident changes based on incomplete context. The platform has to absorb this. Not by making agents perfect, but by making the system tolerant of imperfection.

The Hard Questions

I keep hearing the same anxiety from different directions. Engineers wondering what their job looks like in two years. Students wondering if they’re learning the right things. At CMU, two questions came up that crystallized it for me.

The first: students early in their software engineering careers don’t know how to tell when the AI is doing something wrong. They don’t have the spidey-sense yet. The AI generates code that looks plausible, passes a surface-level review, and the student ships it. They can’t smell the bad decision because they’ve never seen what a bad decision leads to. How do you develop judgment about something you’ve never experienced failing?

The second is even harder: where do our senior engineers come from? The ability to design good platforms, to make the right architectural calls, that comes from experience. You learn what breaks by building things that broke. You learn where to put the domain boundaries by having drawn them in the wrong place. You learn what to monitor by having been the person staring at useless dashboards during an incident at 2am. If AI is writing most of the code, and junior engineers aren’t getting the reps of building and breaking things themselves, how do they develop the judgment to become the platform engineers we need?

These are connected, and they form a kind of paradox. You can’t design a migration system that handles conflicts if you’ve never written a migration. You can’t design isolation boundaries if you don’t understand how a database connection pool works. You can’t build semantic observability if you’ve never been the person debugging a production incident from raw logs. The understanding comes from doing the work. But we’re taking the coding away from students at the exact moment they need it most. We need them to code to build intuition, but the industry is moving toward a world where they don’t code.

CS Is Not SE

Here’s the thing: most universities don’t even have a software engineering program. They have computer science programs. And computer science is a discipline designed to produce researchers. Algorithms, data structures, theory of computation, concurrent programming. It’s a rigorous education in how to write correct programs. But it was co-opted decades ago as the default training path for people who are going to spend their careers doing software engineering, which is a fundamentally different discipline.

Computer science teaches you to write correct programs. Software engineering teaches you to build software that is changeable, resilient, and reliable. CS is the welding. SE is the structural engineering. How do you design systems that are safe to operate? How do you release reliably? How do you reason about failure? How do you evolve a codebase over years without it collapsing under its own weight? Courses like 17-313 teach these things, and they teach them well. But very few universities have a dedicated SE program. Most students get one or two SE courses inside a CS degree and call it done.

That distinction used to matter less when every engineer was also the person writing the code. Now that AI is handling more and more of the “write correct programs” part, the software engineering part is all that’s left. And we don’t have enough curriculum around it. Platform engineering can’t be an afterthought or a single lecture in a survey course. It needs to be a first-class part of how we teach students to think about building software.

Civil engineering solved the experience problem with structured apprenticeship. You don’t go from coursework to designing bridges. There are years of supervised practice, increasing responsibility, professional licensing exams. The judgment develops through guided experience, not just classroom instruction.

I don’t think software engineering needs PE exams. But we need to take this seriously.

Here’s a concrete example. For years, I gave one guest lecture per semester in a software engineering course at CMU on reliably releasing software. Feature flags, metrics, observability, safe deployments, self-healing, rollback strategies. One lecture. A nice-to-know topic in a course full of other things. That content is now the whole game. It’s not a single lecture anymore. It’s the core of what platform engineers need to understand, and it deserves its own course, its own projects, its own curriculum.

The profession is changing. The question of how we train the people who make it safe for everyone else to build is one we can’t afford to put off.

Thanks to Michael Hilton and Rohan Padhye for giving me the opportunity to lecture as adjunct faculty at CMU. Without it, I wouldn’t have the space to think about and explore these problems. And thanks to CMU for teaching me how to think in the first place.