The Industrialization of Software Engineering

Before industrialization, most products were made by hand. If you wanted a table, someone had to know the materials, the tools, and the process to build it.

Industrialization changed that. It made products cheaper, faster to produce, and easier to access. It also reduced how much craftsmanship went into the average product.

I think software is entering the same phase now. AI agents can already produce a large amount of application code with very little human input. That increases output, but it also changes where the real engineering work happens.

The Shift From Craft to Throughput

Mass production does not eliminate craftsmanship. It changes where craftsmanship is applied.

Most people do not need a handcrafted table. They need a table that is good enough, available now, and affordable. A lot of software will follow the same pattern.

I do not believe every application deserves hand written code from top to bottom. Many internal tools, CRUD applications, and client specific business apps can be generated, reviewed, and shipped much faster with AI in the loop.

That is a real benefit. More companies will be able to build software, and teams will be able to deliver routine features faster.

It also has a cost. When code is produced at industrial scale, the average quality flattens. The output may be acceptable, but not especially thoughtful, durable, or well designed.

What AI Is Good At

AI agents are good at repetitive implementation work. Give them an established stack, a clear pattern, and a narrow requirement, and they can produce a lot of code quickly.

That makes them a strong fit for the part of the industry that builds similar systems over and over. Agencies and internal teams that mostly produce line of business software will adopt AI heavily, whether as a replacement for part of the work or as a force multiplier for the same team.

But many people are overextending this lesson. Not every product can be treated this way. The more differentiated the product is, the more the value moves away from raw code production and toward architecture, taste, product judgment, design, and long term maintenance.

Why Senior Engineers Matter More

If AI handles more implementation, senior engineers become more important, not less.

I can imagine a small product team made up mostly of senior engineers who design systems, define constraints, and guide agents through implementation. In that model, the senior engineer is less of a ticket executor and more of an architect, editor, and reviewer.

A senior frontend engineer might focus on the design system, accessibility rules, and interaction patterns. A senior backend engineer might focus on data models, API boundaries, and security constraints. Once those foundations are in place, AI can generate much of the surrounding code.

This is where a lot of companies still misunderstand seniority. Senior engineers should not just be faster coders. They should be the people with the taste to decide what deserves precision, what can be automated, and what trade-offs are acceptable.

To me, taste is the ability to tell the difference between code that merely works and software that actually feels well designed. It is knowing what to simplify, what to leave alone, and what looks correct at first glance but will become a problem later.

What Happens to Junior Engineers

I do not think the junior role disappears. I think it changes.

If teams generate more code, they also need more review, more testing, and more validation against requirements. That work has to be done by someone, and it is a reasonable entry point for a junior engineer.

A junior can work closely with a senior engineer, learn the design decisions behind a feature, review AI generated code, test the system, and catch mismatches between the requirements and the implementation. That is still engineering work. In many cases, it is better engineering training than spending two years just moving tickets around.

Over time, that junior can take on more design responsibility. The path to seniority becomes less about producing volume and more about learning judgment.

The Squeeze on Mid-Level Work

The role I think is most exposed is the mid-level engineer whose main responsibility is turning tickets into code.

In many companies, that is the most common shape of day to day engineering work. A task comes in through a ticket system, the engineer implements it, submits it for review, and moves to the next one. That workflow is structured, repetitive, and easy to describe. It is also the kind of work AI can automate well.

I do not mean every mid-level engineer disappears. I mean the market may stop rewarding engineers who stay only at that layer of responsibility.

This is why I think the old idea of spending years comfortably in implementation-only work is fading. Mid-level engineers will need to get better at system design, requirements analysis, code review, and mentoring earlier than previous generations did.

QA as a Career Stage

I have never been fully convinced that QA should be a completely separate track from software engineering.

QA work is valuable. Catching regressions, validating behavior, and finding gaps in requirements are all critical skills. But I think those skills fit naturally inside the growth path of a software engineer, especially at the junior level.

That is one reason I expect more junior engineers to start in review and testing heavy roles. In practice, they would be doing work that overlaps with traditional QA, but with a clearer path toward design and implementation ownership later.

Honestly, I think that path makes more sense than treating QA as a dead end specialization for people who are already doing valuable engineering work.

Why Education May Matter More

Formal education may become more valuable in this world, not less.

If AI can produce code for straightforward applications, then the human advantage shifts toward understanding systems, trade-offs, algorithms, data structures, software design, and developing taste. Those are the areas where a strong academic foundation can help.

Self taught engineers will still exist, and many will still be excellent. I am not arguing otherwise. But if a company is hiring someone to review AI generated systems, reason about architecture, and grow into a senior engineering role, it may care more about foundational knowledge than it does today.

A degree can help build those foundations, but it does not create taste on its own. Formal education can give someone a head start on architecture and systems thinking, while taste is usually acquired over time by working on real products.

That is similar to other industries. You might hire a self taught electrician for simple work at home. For a power plant, you usually want an engineer with deeper formal training.

Why Craftsmanship Still Matters

Industrialization does not eliminate artisans. It just makes them rarer and, in some cases, more valuable.

Some software will still be written mostly by hand, the same way some tables are still built by a craftsperson instead of a factory. That kind of work is slower and usually more expensive, but it can also be more coherent, more durable, and more thoughtful in the details. Not because handwritten code is magically better, but because every part of it received more care.

Some products will explicitly position themselves this way. Just like some goods are marketed as handmade, locally made, or crafted by a small team, some software may signal that it was designed and implemented mostly by humans. That may become a quality signal for a certain kind of user.

In practice, this may look like a choice between an industrialized product and a handmade one. The industrialized product may ship more features faster. The handmade one may have fewer features, but the features it does have may work better, feel more polished, and hold up longer.

These code artisans will often be senior engineers, because taste usually takes time to develop. But I do not think this is only a role for people with long resumes or formal credentials. It can also describe the self taught engineer behind an avatar who became obsessed with one problem and ended up building an absurdly good library, or the student who has been building small things since childhood and already developed strong instincts for quality.

What makes someone an artisan is not whether they use AI or whether they went to university. It is taste, care, and the ability to know what should exist, what should be simplified, and what is not good enough yet.

Conclusion

I think AI is pushing software engineering toward industrialization. That will make routine software cheaper and faster to produce, but it will also move engineering value away from raw implementation and toward design, review, oversight, and taste.

I also think industrialization will not eliminate craftsmanship. Some software will still be built more like a handmade product, with fewer features, more care, and a stronger point of view behind every decision.

The teams that adapt well will be the ones that know which model they are using. If they are building at scale, they will need strong systems and strong judgment. If they are building by hand, they will need taste and the discipline to make that extra care worth the time.