AI could finally let us teach software engineering properly

If you studied a foreign language, you are familiar with a situation where you are more capable to understand language than properly speaking it. This is not limited to the language studies – when you study through a book you often fall in classic trap of re-reading notes or highlighting and feeling like you've learned. That illusion of competence is shattered once you try retelling it, or someone asks you a question.

The remedy for that is known. You try to speak, you close the tutorial and try recreating the code from scratch, you try explaining what you've read like I'm five – an infamous Feynman's technique.

I think that the education system should prepare students for junior roles and give them enough foundational knowledge to gradually apply more and more of it, as they progress towards senior roles. Therefore the educational struggle is only justified if we are targeting the right skills. Which skills?

Junior developer used to be a role often focused on doing grunt work and some form of apprenticeship. In the companies I knew junior devs were getting well scoped, clearly formulated tasks, focused on implementation, not design or decision-making in a complex, sometimes convoluted context.

These times are gone now, AI usually does it all better than a junior developer, as long as the tasks are well-scoped and clearly specified. Also, much, much faster. Of course, it requires a proper supervision, which requires experience and a more mature engineering mindset. You have to tell bad code from good code, and there is no universal rule to it – most non-trivial aspects are a tradeoff, therefore contextual, therefore choosing the right option or design requires an elaborated understanding of engineering practice and context. The role of junior developers is up for reinvention.

What should we expect from juniors now and how do we tutor them? I had a short discussion with a dear friend Filipp Guzeev from Veeam and came up with some propositions.

In system engineering we usually work in a loop:

Stakeholder analysis

who has any interest in the system?

• stakeholders induce evolving requirements, which demand
  • metrics
  • risk assessment (what if we fail to satisfy them)

Functional architecture

some requirements get attached to functional components.

Resource allocation

for example, where will we deploy the code, what computation resources do we have, what do we lack etc.

Verification and validation

verification checks whether the code satisfies requirements, validation checks whether the code solves the business problems. We use metrics elaborated on the first step.

I think we can try to build the mentoring process around it. Instead of writing the code, the junior will have to go through these stages, as a semi-research project. Of course, they will limit only to the essential stakeholders. They will discuss intermediate results with his mentor. Requirements and metrics will have to make their way into the AI prompt. There should be a clear trace from requirements to the acceptance tests to the code, property-based tests for invariants, actually running the thing, adversarial review ("what input breaks this?") and so on.

The junior developer will have to think through the questions like "I am writing a protocol, how will it evolve? How should I version it? Do we need backwards compatibility? How will it react if the other party diverges from expected behavior?"

Junior developers usually do not have an expertise to know the answers to such questions, and they do not know the right questions to ask. But this is where they can grow the most – partly they may converse with LLM itself asking it to elucidate more such questions, try to figure the answer by themselves and then discuss the results with their mentor. The outcome of the junior's work should be not just the code in a pull request, but a report of his research, showing what questions did he ask and what were the answers. The report will keep trace of rejected alternatives too.

That research is one part of the learning experience. The second part is, unsurprisingly, reading the generated code and checking that the requirements are really satisfied in the code. LLM agents are quite good in gaming your requirements, for example, they may overfit to your tests without providing a correct general solution. This is where the capability of writing roughly the same things by hand is essential – it builds the degree of understanding required to then analyse and critique other people's, or agents', product.

One of the caveats might be a single point of failure – the mentee researching the questions by asking LLM, while LLM also writes the code, and will likely write the tests. That's the same supplier performing design and verification, with correlated blind spots. Systems engineering has a strong norm against this and requires an independence rule: requirements and acceptance criteria written before and without the model, or verified against a different source, or checked by a human. Otherwise the whole loop can be closed by the AI and the defense becomes another generated artifact. So, we might need to freeze the acceptance criteria mid-journey.

Finally, a major part of the engineering is complexity management. There are many kinds of complexity: essential vs accidental, coupling vs cognitive load, local vs global, complexity of description vs complexity of operation, and so on. The concept of complexity is complex and not reducible to a single face or metric.

An example is in order. Many systems are stitched together from parts we don't own. Each of those parts forces a choice. You can bind your code directly to a library and pin its version. The system stops moving, which is the point: nothing breaks. But nothing improves either – no bug fixes, no security patches, and the longer you wait, the more painful the eventual upgrade. Or you can put an adapter between your code and the library. Now a change to the library's interface stops at the adapter instead of spreading through your codebase, and swapping in a competitor becomes a day's work rather than a month's.

The adapter is more code, and more code is more complexity. Whether you get anything for it depends on facts you have to go out and check: how often this library breaks its interface, how deeply it has already spread through your system, whether a serious alternative exists. There is no general answer. That is what makes it a tradeoff and not a rule.

In good engineering, we do not just "keep things simple" – every action on the codebase does something to its complexity, and does not always decrease the overall complexity. The goal of management is to prevent any single part of the system from blowing up in complexity, according to contextually reasonable definition of complexity. This allows us to grow the system, maintain it, adjust it, interface with it. Human is the measure of all things complexity – if I can't handle it anymore, the system degraded into unmaintainability. Agents too have a limit to the complexity they can handle.

So juniors of today, in my opinion, are middle developers of yesterday. In order to control AI agents you need more engineering maturity, not less. And that's where LLMs, in my opinion, become an an exciting addition to software engineering education.

We were always struggling to teach the real important stuff – not the quirks of this or that language¹ (like signed vs unsigned overflow in C), but system architecture, proper decomposition, code style. Not "this is how you code a hashmap in C++" but "if you have a functional component in a system that stores data, it has latency regardless of its implementation". The nature of a thing is more important than the form of a thing. But pragmatically we were limited to really small projects. First, because of time constraints. Second, because of fault tolerance – if a huge project fails midway, and its architecture is bad (expected from a student) you have to redo everything, which takes time. But on a small scale you can always write bad, smelly code, and mostly get away with it. It's on large projects where you see the cost of bad complexity management the hard way, when you need to implement a feature, or fix a bug, but there is nothing you can do with the code without breaking something, and no one understands it anymore.

LLMs enable us to finally pump the scale of assignments and expose the problems of mismanaged complexity and poor architecture. Bad interface – simulate an evolution and see how it becomes uglier with time, loses backwards compatibility and becomes a nightmare to support. See how it makes impossible to write a decent test suite. Bad decomposition – watch as god objects emerge, functionality gets split in unnatural ways, and logic gets scattered and duplicated everywhere. And so on. This is, perhaps, the greatest thing I could have hoped for in teaching software system engineering, as opposed to coding, mastering tools, platforms, or technologies that fade into obsolescence faster than you get your bachelors degree.

One thing to be cautious is the cost of bad design. In some cases LLMs mitigate it because refactorings become cheaper. One common observation is that in AI-heavy development bad design accumulates to a point when a complete rewrite is necessary. Fixing it intelligently requires a degree of understanding which is only, I think, achievable through a deep expertise and a capability of working with a complex, sometimes convoluted context. Perhaps we can catch the catastrophe by feeding the codebase to a fresh LLM with no context, and if it fails to implement some new feature coherently, this may signify that a human would fail too.