Ask a room full of computer science students what they want to build and almost nobody says a Perl script an insurer wrote in 2003. Ask where the actual junior demand sits in Germany, though, and a lot of it is exactly that: old, load-bearing code that a shrinking number of people still understand, running inside companies that cannot simply switch it off.
Where the old code actually lives
Germany's economy is unusually dependent on systems built years, sometimes decades, ago. Industrial control and manufacturing execution systems run factory floors that have not been rebuilt from scratch since they were installed. Insurers and banks run policy and ledger systems that predate most of their current staff. The Mittelstand, the backbone of German industry, runs a huge amount of custom or heavily customised ERP (enterprise resource planning, the software that runs a company's core operations: inventory, orders, finance) that nobody wants to touch because nobody fully remembers why it was built that way.
None of this is going away soon. Rewriting a working, load-bearing system from scratch is expensive, risky and slow, and most companies that depend on one would rather modernise it carefully than gamble on replacing it outright.
Why the junior demand actually sits here
Modernising an old system is not glamorous work, and that is exactly why it is a reliable place for a junior to get hired. Somebody has to read the existing code, understand what it actually does (as opposed to what the documentation, if it exists at all, claims it does), and work out what is safe to change. That reading and understanding work does not require ten years of experience nearly as much as it requires patience, care and a willingness to actually test what you touch before you ship it.
An AI coding agent changes the arithmetic here rather than removing the need for a person. An agent can move fast through unfamiliar code, but it cannot tell you which behaviour in a decade old system is an intentional business rule and which is an accident nobody ever fixed, and it should not be trusted to decide that alone. Someone still has to read the output, check it against what the system is actually supposed to do, and catch the change that looks correct but breaks something three steps downstream. That is precisely the kind of judgement a careful junior, working with an AI agent rather than being replaced by one, can build fast.
Why this favours you, not against you
Legacy work rewards a different set of habits than the ones most students spend their degree optimising for. Chasing the newest framework or the newest model teaches you very little about reading someone else's decisions and working out what is safe to change. Careful reading, methodical testing and a willingness to slow down before you touch something you do not fully understand yet: those are the habits legacy work actually rewards, and they are exactly the habits an AI agent cannot substitute for.
That also means one junior, paired with a good agent, can now cover more ground on this kind of work than a junior working alone could a few years ago. Companies that need this work done are not chasing candidates with five years of experience in one specific old system. They are looking for someone who can demonstrate the underlying skill: read unfamiliar code carefully, use an AI tool well without trusting it blindly, and ship a change that does not break anything.
The Legacy Fix is this job in miniature
This is exactly the shape of the IBM Bobathon, an exciting challenge built with IBM Bob (an agentic AI software development tool: it plans, writes, tests and modernises code across a whole repository, rather than answering one question at a time). The scenario is a constructed one: your first week as a junior engineer at a German car-parts company, inheriting a legacy Python repository nobody has fully documented. You read the code, work with Bob to understand and fix what is broken, and are marked on your judgement, not your typing speed.
Pass, and IBM issues you an IBM SkillsBuild certificate of completion. It is free to attempt and free to hold if you pass, though it is worth knowing going in that about 3 in 10 participants do not pass, based on ProoV's own grading data across projects, so it is not a rubber stamp.
Where to start
If reading someone else's code carefully and working out what is actually safe to change sounds more interesting than intimidating, that instinct is worth trusting. Legacy modernisation is one of several fields with steady demand right now: go and see what the work actually feels like before you decide whether it is for you.
