DEV Community: RatioShift

What AI Can’t Fake: How junior engineers can stand out in the age of AI

RatioShift — Tue, 08 Sep 2026 18:45:54 +0000

There is a piece of advice that circulates endlessly through mentoring conversations, coding bootcamps, and LinkedIn posts aimed at people trying to break into the tech industry. Get certified. Build something for your GitHub. Put together a portfolio. Contribute to open source. Let’s call this “the checklist”.

It’s not bad advice, and it wasn’t bad advice when people started giving it. The problem is that enough people have followed it that it has stopped being advice and started being a floor. The rise of LLMs has only sharpened this, making it far easier to write a polished, tailored CV that hits every mark on a job description, or to spin up a portfolio project. The checklist looks less distinctive than ever. It’s the minimum, not the differentiator.

I see this clearly through my work with CodeYourFuture, a charity that provides free technical training and career support to people from underrepresented backgrounds. The people I mentor there have worked hard to get where they are; some are still learning and trying to land their first role, others are already in the industry and trying to figure out how to progress. What I notice, talking to them, is that the checklist items are rarely what’s holding them back. They have the certifications. They have the GitHub repos. They are doing everything they were told to do, and they are still finding it difficult to stand out. Standing out requires something else, and that thing is not to add another certification to their LinkedIn.

At London Tech Week this year, I listened to speakers from some of the biggest names in the industry. The same hiring wishlist kept coming up: curiosity, adaptability, and the ability to learn. They want evidence that someone can pick up an unfamiliar codebase, work in a different context, shift between problem domains without falling apart. These qualities matter more to them than any specific technical credential.

The difficulty — and every speaker acknowledged it — is that these qualities are genuinely hard to assess from a CV, cover letter, or even a technical interview. A list of certifications tells you what someone has been taught. It does not tell you how they think, how they respond when things are unfamiliar, whether they show any intellectual curiosity outside of their day-to-day work. That gap between what hiring managers want and what traditional methods can surface is the real problem. The checklist was never designed to solve it.

Work on code you didn’t write

Closing that gap starts with contributing to an open source project you did not build. Not a project you started yourself or one where you know all the context. Find something unfamiliar, read the code, understand how decisions were made without being there when they were made, and then do something useful. This matters because it puts you in a situation that is much closer to what actual employment looks like: navigating someone else’s architecture, working under review from people who do not know you, working in legacy codebases with contradictory coding styles and patterns. It is a concrete demonstration that you can learn a system you did not design, which is most of the job.

Write from confusion

The next thing is to develop a point of view and put it somewhere public. This does not mean writing tutorials. Tutorials are another form of the checklist; plenty of people write them and they tend to blur together. What is rarer, and more useful, is writing honestly about confusion. Not the resolved version of a problem, but the experience of being confused, the specific thing that did not make sense, and then exactly what clicked and why. That specificity is what gets remembered. There is also a practical reason to write while you are still close to the confusion: some senior engineers may have forgotten what it genuinely felt like not to understand something. That memory is an asset. Use it before it fades.

Speak so non-engineers can follow

The third thing is the hardest to fake and the easiest to neglect: learn how to translate technical decisions for people who didn’t make them and don’t share your frame of reference. Not dumbing things down; that framing is condescending and also inaccurate. Translation is a different skill, one that requires you to understand what you are trying to communicate well enough to find a different path to it. Many early-career engineers treat this as something to develop later, once they have more experience, once the technical foundations are solid. It is not a later skill. It is a foundational skill, and building it early, before you are comfortable, is considerably easier than retrofitting it later. Junior engineers naturally default to speaking in technical terms when they are around other technical people, and the longer that default goes unchallenged, the harder it becomes to break.

Find work with real stakes

There is one more route, and it is among the most underrated for early-career engineers: find technical work to do for free. Volunteering. In the UK there are platforms built precisely for this, such as reachvolunteering.org.uk, doit.life, and CodeYourFuture (codeyourfuture.io). I am sure similar platforms and organisations exist in other parts of the world, and many charities would be willing to accept help from people working remotely. What makes this different from a side project is not the technical challenge — it’s that the stakes belong to someone other than you. The constraints are real, the consequences of poor work land somewhere outside your GitHub profile, and the decision to do it at all is entirely yours. It does something good for society at the same time, which is reason enough on its own. Hiring managers tend to look favourably on volunteering work; choosing to take on work like this when nobody asked you to signals exactly the curiosity and initiative they are looking for, in a way the checklist cannot.

None of this replaces the checklist. The checklist gets you in the room, and it was never meant to do more than that. Everything else here is a behaviour, not a credential — something you demonstrate rather than something you claim. Credentials can be generated now. Behaviour has to be lived. That is the thing AI can’t fake, and it is the thing that makes someone worth keeping around.

The Productivity Trap: Why Using AI to Cut Jobs Is a Strategic Mistake

RatioShift — Wed, 17 Jun 2026 19:35:19 +0000

AI adoption was everywhere at London Tech Week 2026: in the keynotes, the breakout sessions, and the conversations between talks. So was the usual hiring agenda: curiosity, adaptability, T-shaped professionals, engineers with business sense. I took notes, nodded along, and heard plenty I’d expected. What I hadn’t expected was a recurring thread across multiple sessions: what the smartest companies had decided not to do with AI, and why.

The leaders who stood out weren’t the ones talking about which skills they were looking for. They were the ones asking a harder question: not which skills to hire for, but what happens to the people you already have.

The obvious move, when AI can demonstrably do the work of several people, is to reduce headcount. The logic is clean: same output, lower payroll, better margins. Plenty of companies are making exactly this calculation. But the leaders who gave me pause were the ones arguing the opposite: that committing to no AI-driven redundancies wasn’t just the ethical choice, it was the strategic one.

Their reasoning was straightforward. If your engineers suspect that every productivity gain they unlock is a step toward their own redundancy, they will stop unlocking productivity gains. Not consciously, perhaps, but the instinct for self-preservation is hard to override with a company memo about embracing change. Fear produces compliance, not curiosity. And curiosity, as every leader at the event was keen to stress, is the thing they most want and find hardest to hire for.

Psychological safety, in other words, isn’t a soft concept. It’s the precondition for everything else on the wishlist.

Which brings me to the continuous learning problem, because it’s more complicated than the conference circuit tends to admit.

Leaders say they want engineers who keep learning. What they mean (or what they should mean) is engineers who can genuinely rebuild their competence as the landscape shifts, not just engineers who have added a few lines to their LinkedIn.

Here’s what the honest version looks like from the inside. Most engineers I’ve known, myself included, have already rebuilt from scratch more than once. A language or framework you spent years mastering becomes legacy. You relearn. The tools change again. You relearn again. This isn’t continuous learning in the aspirational sense; it’s a recurring tax on expertise you’ve already paid for. At some point, the stamina runs out.

The university system offers no real solution. Curricula are designed to meet the needs of industry, but the industry now moves at the speed of model releases. By the time a graduate arrives in the job market, the core language they were taught may already be a second-best choice. The emergence of tools like Claude raises a harder question still: how much does syntax even matter any more? What exactly should a student be studying, and how would a course designer know? The gap between what education produces and what industry needs isn’t closing; it’s structural. It’s a problem nobody in education can solve quickly, which means the only environment where continuous learning can realistically happen is the one employers control.

AI does lower the friction here, and that matters. The paradigm shifts feel less brutal when you have something that can translate your existing knowledge into a new context. But there’s an obvious trade-off that doesn’t get named often enough: that engineers who lean heavily on AI assistance get shallower over time. The deep fluency that comes from wrestling with a problem yourself – from actually failing and debugging and understanding why – is quietly eroding. That might be an acceptable trade. But it should be a conscious one.

The companies that seem to understand all of this are doing something specific. They’re treating psychological safety not as a culture initiative but as an adoption strategy. If you want your engineers to experiment with AI, to find the places where it genuinely accelerates their work, and to be honest about where it doesn’t, you need them to feel that doing so won’t cost them their jobs. The commitment to no redundancies creates the conditions for the curiosity and adaptability that leaders claim to want. You can’t hire for those qualities and then manage them out of people once they’re through the door.

The ratio between technical depth and broader adaptability is shifting; that much is true, and London Tech Week confirmed it. But the shift isn’t simply a matter of engineers needing to broaden their horizons. It depends on whether the organisations employing them create the conditions for that broadening to happen at all.

The companies using AI to thin their headcount may hit their margin targets this year, although the evidence suggests many won’t even manage that. Forrester’s 2026 Future of Work report found that 55% of employers already regret AI-driven redundancies; cutting people for a technology that, in many cases, wasn’t ready to replace them. The ones who have made the opposite bet – keeping people, making them feel safe, and letting them experiment – are building something harder to replicate than a leaner payroll. They’re building teams that are actually capable of adapting. Whether that bet pays off at scale remains to be seen. But the alternative is looking shakier by the month.

Cutting for efficiency now might be exactly what prevents you from being efficient later.