Do not let AI tools empty the bottom rung

I believe software companies that cut early-career hiring because AI coding assistants have made experienced engineers faster are spending a reserve they will need back within five years. My position is not that the tools change nothing. They change a great deal about what a junior engineer does in their first year. The response should be to redesign that year around the work the tools make more important, such as writing tests and specifications, reviewing generated code and talking to customers, and to keep hiring juniors at a rate the senior bench of the future requires.

I hold this view with some caution, because the argument on the other side is strong and I have lost versions of it in other forms. I also hold it as a human resources leader rather than an engineer, and the colleagues who disagreed with me know the technical work better than I do. What I bring is a record of where Kestrelford's senior engineers came from, and a long memory of what happens to a company that stops growing its own people.

The arithmetic in the planning deck

In November 2024 our engineering leadership proposed reducing co-op work terms from 96 a year to 30 and graduate hires from 34 to 8. The case rested on a pilot in which experienced engineers using AI coding assistants completed routine changes about a quarter faster than before. Much of a junior engineer's first year had consisted of exactly those routine changes, under supervision. If the seniors could now do them faster, why pay juniors to do them slowly and then pay seniors again to review the work? The C$4.6 million saved would fund fourteen senior hires, who would produce more in their first year than a cohort of graduates.

On a one-year view, I could not fault the arithmetic. My objection was to the time horizon. Almost half our senior engineers in 2024 had first joined Kestrelford as co-op students or graduates. They knew our customers' pipe networks, our codebase's history and the reasons behind decisions nobody had written down. A company that stops hiring at the bottom does not notice for three or four years, because the cohorts already inside keep moving up. Then it discovers that its seniors must be hired from outside, at a premium, without that history, and that the co-op relationships it took a decade to build now belong to competitors.

I also doubted that the pilot measured the whole job. It counted completed changes. It did not count how many of those changes later produced a customer ticket, or how much of a senior's time went into checking generated code that looked right and was not. When we asked our support team in Halifax to trace defects back to their source, the answer was less flattering to the tools than the pilot had been.

What a first-year engineer does now

Our chief executive accepted a compromise for 2025: 72 co-op terms and 22 graduates, with a review after twelve months. The more important change was in what those people did. We stopped treating the first year as a queue of small changes to be completed and checked. A first-year engineer now writes the tests and specifications that AI-assisted changes are checked against, reviews generated code alongside a senior colleague and owns a small feature from specification to release. Each spends two weeks with our support team, answering tickets from municipal engineers and utility staff whose work depends on our software.

The reasoning is that AI tools move the scarce skill from producing code to judging it. Someone has to know what the code should do, how to show that it does, and how a customer will experience it when it does not. Those are not junior skills that seniors can safely skip teaching. They are the skills that make a senior engineer, and they are learnt fastest by doing them early with supervision.

After eighteen months, the time from a graduate's start to their first independent production change had fallen from eleven weeks to six. Co-op students accepting our return offers rose from 58% to 74%. Incidents traced to changes made by first-year engineers occurred no more often than the company average. I do not claim these results prove the model, because other things changed at the same time and the cohorts are small. They are enough to justify continuing it, and our chief technology officer, who opposed the original proposal in writing, now presents the programme to our committee himself.

Who pays for the mentoring

The honest weakness of my position is cost, and it falls on the senior engineers. Reviewing a junior's tests and teaching them to read generated code takes time that a senior could spend shipping work. If that time is unrecorded, it is the first thing to disappear when a release is late, and the juniors learn that the company did not mean it.

We now record 10% of each mentor's time in their objectives and count it in promotion decisions. We deferred six of the fourteen senior hires to pay for the programme, about C$2.9 million, and our engineering managers have had to plan around that gap. Some seniors resent the obligation. A few have told me plainly that they joined to build software, not to teach, and I take that seriously; not every senior engineer should mentor, and we no longer pretend otherwise.

There are also companies where my argument fails. A business that does not expect to exist in its present form in five years, or that can reliably hire experienced engineers who understand its domain, may be right to stop hiring juniors. Most software companies I know are neither. They are counting on a senior bench they have not yet grown.

My suggestion to another board is to ask one question at the next planning cycle. Of your senior engineers today, how many joined as students or graduates, and where will the equivalent people come from in 2031? If the answer depends on hiring them from companies that kept investing in juniors while you did not, the saving in this year's plan is a loan, and the interest will be paid in the market for experienced engineers.