Kelzodi blog: AI in Practice

CAD + Plotter vs. AI + LLMs: What the Architecture Revolution Can Teach Software Engineering

Every technological revolution has its winners, its losers, and its lessons.

One of the best historical examples happened in architecture during the 1980s and 1990s, when Computer-Aided Design (CAD) and plotters transformed the way buildings were designed and documented.

The biggest impact was not on architects. It was on draftsmen.

Entire teams whose role was to transform architects' sketches into technical drawings suddenly found that software could produce cleaner, faster and more consistent drawings than manual drafting ever could.

The skills that had defined the profession for decades (perfect line work, lettering, manual precision) lost much of their commercial value almost overnight. Many professionals successfully adapted and became CAD specialists. Others unfortunately did not.

Architecture did not disappear. Quite the opposite. Projects became larger, more ambitious and more complex because producing technical documentation became dramatically faster and cheaper.

Looking back, CAD didn't destroy architecture. It transformed the skills that created value.

Today, software engineering appears to be entering a remarkably similar transition.

Large Language Models are rapidly automating many of the activities traditionally assigned to junior developers:

• boilerplate code
• CRUD implementations
• unit tests
• documentation
• API integrations
• refactoring
• code explanations

Once again, the repetitive execution layer is becoming increasingly automated.

And once again, the profession itself is unlikely to disappear.

Software demand continues to grow, and AI will almost certainly accelerate it by making many applications economically viable that previously weren't. However, history also suggests that productivity gains alone do not guarantee a healthy transition.

There is one important difference between the CAD revolution and today's AI revolution.

CAD was deterministic. It only drew what the architect explicitly instructed.

Modern AI is probabilistic. It proposes solutions, writes code, reasons over documentation, identifies bugs, suggests improvements and increasingly behaves like an autonomous collaborator rather than a sophisticated tool.

That makes today's transformation considerably deeper.

But my biggest concern is not whether AI will replace programmers. It is how we train the next generation of software engineers.

For decades, junior architects learned by drafting drawings. The work was repetitive, but it forced them to understand construction details, standards, dimensions and how buildings actually came together.

Similarly, junior software engineers have traditionally learned by implementing small features, fixing bugs, writing tests and gradually understanding increasingly complex systems.

If AI performs most of those implementation tasks, we must ask ourselves an uncomfortable question:

How will tomorrow's senior engineers be developed?

At this point, a paradox emerges. Many organizations are already asking a perfectly rational business question:

If a senior engineer, assisted by AI, can deliver the work that previously required several junior developers, why continue hiring as many junior developers?

From a short-term productivity perspective, the argument is compelling. But it also raises a much more fundamental question.

Traditionally, junior developers were not simply an additional pair of hands, they were the talent pipeline from which future senior engineers, technical leads and software architects emerged.

If AI increasingly becomes every senior engineer's "junior developer", who becomes tomorrow's senior engineer?

Perhaps the most important challenge of the AI era is not replacing junior developers. It is ensuring that we do not unintentionally replace the learning journey that has produced generations of experienced engineers.

In my opinion, AI is an extraordinary productivity multiplier. But it also amplifies knowledge or the lack of it. An experienced engineer uses AI to accelerate work because they can evaluate the generated solution.

A junior engineer without strong foundations may accept AI-generated code simply because it compiles and appears correct. That is a dangerous illusion. Writing code has never been the hardest part of software engineering.

Understanding why the code works, how it interacts with the rest of the system, and whether it satisfies the business problem has always been the real challenge.

AI dramatically reduces the cost of writing software. It does not reduce the cost of understanding software. This makes another discipline even more critical than before: Requirements engineering.

AI will always generate an answer. Even if the requirements are incomplete. Even if they are ambiguous. Even if they are contradictory.

If we fail to define business requirements precisely and simply ask AI to "build the feature", we risk producing incorrect software faster than ever before.

The old principle still applies: Garbage in, garbage out. The difference is that today's garbage may become thousands of perfectly compiling lines of code in seconds.

There is another aspect that deserves more attention. Many junior developers begin their careers in consulting companies, often working on customer projects with limited day-to-day mentoring.

Traditionally, they learned by writing code themselves, making mistakes, receiving reviews and gradually building intuition under the guidance of more experienced colleagues.

If AI starts replacing not only implementation but also that learning process and organizations fail to strengthen mentoring and technical supervision we may unintentionally create a generation of developers who deliver software faster than ever while developing a much weaker understanding of software engineering fundamentals.

That is not an AI problem. It is a leadership and training problem.

The lesson from CAD is not that technology eliminates professions. It is that professions evolve.

Draftsmen who embraced CAD remained valuable.Those who refused to adapt struggled.

Software engineering will likely follow the same path. The most valuable developers won't necessarily be those who write the most code manually.

They will be those who understand systems, architecture, business needs, security, maintainability, and who know when AI is right and when it is confidently wrong.

Perhaps the biggest lesson is this: AI should accelerate learning, not replace it.

If we allow junior developers to rely on AI before they understand software engineering fundamentals, we risk weakening the very pipeline that produces tomorrow's senior engineers.

History may not repeat itself exactly. But if the CAD revolution taught us anything, it is that adopting a new tool is only half the challenge. The other half is redesigning how we develop the professionals who use it.