Talk transcript

Lora: Yes, I manage the early engineering programs at Culture Amp. And the way I look at that work is probably a little unusual. I'm not thinking about someone's first 90 days. I'm not thinking about how quickly they can become productive. And I'm definitely not just thinking about how to help them survive their first year. I'm thinking about the version of them that doesn't exist yet-- the senior engineer, the systems thinker, the person who will one day resolve your toughest production incident or shape your next core system. That's what I care about. How do we make them better at being senior engineers? And to answer that question, I keep running into the same obstacle-- not the juniors, but us.

Have you ever noticed how easy it is to believe that the way we learned is the way everyone else should learn? I think a lot of us carry that around without even realising it. We think, well, I had to grind through the small repetitive tasks. I had to earn my way into meaningful work. I had to prove myself on the edges before anyone trusted me with the core. And because that was our path, we started treating it as a law of nature, not just one version of learning that happened to shape us. Sometimes we say it out loud. Back when I started, we had to. More often, it shows up quietly in how we design roles, in how we allocate work, and in how we decide who is ready. That's the bit I want to challenge today.

And here is a provocation I want to offer. Yes, junior tasks are disappearing, but junior engineers are not. And that means that the training model we grew up with, the one that we absorbed, the one that we are still probably running, it has to change.

My own path into tech was nonlinear. I had several careers before tech. I worked across the stack, and eventually I found my home in Engineering enablement. And what my journey taught me was that learning is messy, nonlinear and deeply human. And the science of learning kept confirming that. Yes, learning doesn't care about our tidy org charts or our tidy curriculum plans. So today, I really want to offer something practical, a way of thinking about what we are actually training our juniors for and what gets in the way. By the end, I want you to live with a framework you can use and maybe one assumption you're willing to question.

We cannot have a serious conversation about engineering skills in 2026 without speaking about AI. Yes, we are living in the middle of a huge change with AI. And I know you, the people in this room, probably sit across a massive spectrum of opinions. For some of you, this is the most exciting time to be building. For others, it feels like the soul is getting stripped out of the craft. Some people think AI is mostly hype, and some think it's a total game changer. And if that sounds conflicted and contradictory, it's because it is. Many of us are holding two truths at once. This is scary, and this is so exciting. So if you're feeling a bit uneasy or even a bit defensive, you are not alone. What I want to offer is a way through that tension, not will there be jobs, but what do we actually need to grow now? That feels like the better question. The more useful question, the question that gets us out of the abstract anxiety and into the things that we can control.

Historically, we've treated our new engineers as if they were fragile by default. We gave them the safest, smallest, most isolated work, fixed the tiny bug, add the field to the form, make this tiny change in the corner of the code base where nothing important can break. And then we expected them to spend years orbiting the real system before being trusted with the core. A lot of us probably know this feeling, where you're technically on the team, but not really in the room where the meaningful decisions are happening yet. And I get why we did that. For many of us, that was the normal apprenticeship model. That was how you earned it. But I think we need to be honest. Sometimes this wasn't great teaching. It was just habit. That was the way things were. And sometimes it was just lack of imagination.

And I know what some of you might be thinking now. The bar is higher than it's ever been. Juniors are expected to know more on day one. It's genuinely harder to start. And you're not wrong. The expectations have changed. But I want to gently challenge the conclusion people draw from that, because I hear a lot of it is harder now. And what I think people actually mean is it is different now. And those are not the same thing. Harder implies that the junior is not quite up to it yet. Different asks us to look at what we believe about their potential. Because here is the reframe I want to offer. Expecting early career engineers to engage with meaningful complexity earlier is not a risk. It can be a sign of respect. It can mean we believe they are capable, that they can be trusted with critical work, that they can take ownership, that their brains are wired to learn to meaningful challenges, not busy work. Because that's where learning gets real. Our brains learn fast when the work matters, when the stakes are real, but the environment is safe enough to fail, fix, and try again.

And I also want to be clear. I'm not arguing for throwing people in the deep end without any support and just wish them luck. I'm arguing for something much more deliberate. Meaningful challenge paired with support is a better teacher than years of carefully rationed irrelevance.

Learning happens when engineers wrestle with problems just beyond their current ability. And AI raises the ceiling on what someone at that level can do. Long gone are the days where junior engineers' only option was to sit alone, get stuck for three days, and hope eventually someone explains the system to you. Now they can ask an AI to explain a legacy module, generate a first pass at a feature, and when AI automates the writing of the code, the writing of the obvious boilerplate, the value of the engineer shifts upward. The job becomes less about producing syntax and writing code from scratch, and more about framing problems, reading critically, evaluating trade-offs, and orchestrating towards something useful.

So AI native juniors, well-mentored, can skip years of boilerplate and engage with real engineering much earlier. Today, the work a junior engineer does can be more exciting, more impactful, and more meaningful than it has ever been if we let it be.

But to unlock that, we have to be willing to question our "How I learned" bias. We have to separate what was genuinely essential in our own journey and what was just the way things were. Our training model has to change. And when I think about what that model looks like, I keep coming back to three layers of skills, skills that don't compete with each other but reinforce each other.

The first layer is the one people are most tempted to deprioritise right now, "The Fundamentals". Yes, foundational skills still matter, maybe more than ever. In AI conversations, sometimes people talk as if fundamentals are certainly optional, as if the AI tools are so great, so powerful, that you don't need to understand what's underneath. Just prompt well, just review the output. But when an engineer works with AI, their job is no longer to write the code. It is to own it. And those are two very different things. Because AI doesn't know if it solved the right problem, it doesn't know what your system already does, it doesn't know what will happen in cases nobody taught to test. It predicts the most plausible answer confidently, fluently, and without a warning label when it's wrong.

So the question is, really, what does a junior engineer need in order to interrogate this output? Not just review it, but interrogate it. The answer is not years of writing syntax. It's the ability to ask four questions: Does this actually solve the right problem? Before reaching for an AI tool, can you break down what's actually being asked? AI is very good at solving the problem you described. It's not good at noticing you described the wrong one.

So problem decomposition, the habit of thinking before prompting, very important. Do I understand what this code is doing? Not broadly, but really line by line. Can you read it and explain it to someone else? Because you should never ship code you cannot explain. Because if you can't explain it, you can't maintain it, and you can't debug it. What could go wrong that isn't in this output? AI keeps edge cases consistently. It solves the happy part beautifully and quietly ignores what happens at the boundary. Can you look at a solution and ask, what did it miss? What input would break this? What assumption is baked in here that might not hold? And can I fix it when it breaks? Not just regenerate it, but fix it.

Debugging is the skill that proves understanding. And it's one of the most at risk skills right now, because the part of the least resistance is always to prompt again. I hope the next version is better.

So the foundational skill is not writing code. It is critiquing it. Can you read what's in front of you? Can you explain why it works? Can you spot what feels off? Can you see when something is technically correct, but structurally terrible? Can you debug it when it fails? And these aren't advanced skills. They are the foundation of engineering judgment. And they can be built early on real work with the right support. And in fact, AI accelerates this if you use it right.

A junior who asked the tool why it made a choice, who pushes back, who uses it as a thinking partner, not just an answer machine, can build in months the intuition that used to take years of repetitive work to develop. And a recent Anthropic study found exactly that. The strongest learners were not the ones who used AI to generate code faster. They were the ones who used it to ask deeper questions. So yes, fundamentals can grow when you let people do work that matters.

And then we have the explicitly AI skills. Things like becoming genuinely comfortable with tools like GitHub Copilot, or Cursor, or Claude Code, knowing how to configure them, how to use their features well, and when to put them away. Prompting and spec-writing, context engineering. Prompting is just communication really. It's being able to explain the system, the constraints that go, and what good looks like. Being able to say what matters, what can't change, what trade-offs you are willing to make. This is the skill of explaining reality well enough to another collaborator so that they can help you. And then you have critical evaluation, reading the output, pushing back, asking for alternatives, tightening the brief until the result is good enough to build on.

And this is where a new risk emerges, and it's not just bad output. The risk is feeling confident while being completely wrong. Because the tool doesn't just hallucinate, it hallucinates fluently. It can sound coherent, plausible, and confident. And for someone without the experience yet to spot what's off, this creates a really dangerous kind of certainty. We have to frame AI as a hypothesis generator. Its job is not to hand over truth. Its job is to give the junior something to interrogate, something to test, something to verify with a more experienced human when needed.

And yes, AI accelerates exploration, but it does not remove the responsibility to think. Which means never accepting output at face value, testing it properly, asking does it actually solve the problem, the right problem, what edge cases are missing, what unstable library just got smuggled in because it sounded plausible.

And third, we have the higher level contributions we used to save for later. Architectural taste, which isn't the same as writing perfect code. It's recognising patterns in how systems are put together. Cross-functional communication and collaboration, so that you can work across design, product, engineering, so the team is really genuinely solving the same problem. Security awareness, knowing what that is okay to share with which tools. And business impact, understanding why the work matters, not just how to ship it. Taken together, these three layers are not nice to have. They are what makes someone valuable in a world where an AI tool can write a half decent feature before you finish your coffee.

So the skills we used to think of as advanced and are now the entry ticket. That doesn't mean people arrive with them fully formed. It means we can't afford to postpone them. We can't say we'll let you think about architecture in five years. We can't say business context is for seniors. We can't say security is someone else's problem. Because if AI is handling more of the boilerplate then the differentiator becomes judgment, context, communication. The ability to recognise when a solution is technically possible but strategically wrong.

And I think there is a hopeful side to this too. I don't think you need 10 years before you can start building taste. I think taste develops through exposure, through comparison, through feedback, through seeing multiple approaches and learning to articulate the trade-offs between them. And that's one of the most exciting things AI can actually enable. A junior engineer can now generate four different approaches to the same problem in just an hour. Not because they are all good, but because the act of comparing them with a senior accelerates the development of judgment. It creates more chances to notice what good feels like.

So if that's the change, how do we actually help people grow into it? How do we build senior level instinct in a junior level timeframe without burning people out, without throwing them in the deep end alone and without just replacing one bad training model with another? For me, the answer is not more content or a prettier tutorial or another training. It's not one more recorded talk that nobody has the time to watch. It is human connection. That's the answer that I keep coming back to. 'Cause yes, the content is already there, the tools are there. The missing piece most of the time is not access to information. It's access to interpretation, to feedback, to someone that can help you make sense of what actually matters. And now share three patterns that I've seen work really well.

The first pattern is pairing, but pairing with a junior while they work with an AI agent. The junior is framing the problem, choosing what context to include, deciding what to trust and what to question. The AI is suggesting options, sometimes useful, sometimes not so useful. And the senior job is not to micromanage the code. It's to coach the judgment. Is the prompt to vague? Is the context polluted? Are we solving the wrong problem? Should we be using AI for this at all? What constraints have we forgotten? The specific code the agent generates doesn't matter as much as the instinct the junior is building. And I think one hour of that kind of pairing can do more for someone's growth than a week of solo grind. Because you're not helping them to ship code, you're helping them to build instincts. You're rewiring how they think about working with AI tools. So if you're a senior engineer in this room and you're wondering what is the highest leverage thing I can do for juniors right now, I would put this really high on my list.

The second pattern is the art of articulation. I'm sure that many of you run demos and those are great, but I want to challenge you to raise the bar on what you ask your juniors to talk about. Don't just ask them to show the code. Ask them why this approach, what trade-offs they considered, what they rejected, where AI helped, where it didn't. What changed for the user? What changed for the business because of their work? Because the habits we are building is not just technical output, it's ownership, it's judgment, it's telling the story of their work. And at first, they'll probably not know the answers to those questions and that's okay. The point is not that they already have all the answers. The point is that they start training the muscle early. The habit of asking why and for whom and what if, not just how. Because engineers who can articulate their reasoning are better collaborators, they're better reviewers, they're better at supporting when a solution is solving the wrong problem. In our early career programs, we've seen massive success when juniors regularly practice explaining the intent behind their decisions and the impact of their work. And this is not about turning everyone into a product manager, it's about growing engineers who naturally think like stakeholders, not just syntax writers.

The last pattern is the curated knowledge exchange. While we all know the vague version of mentorship, where you ask, "if anyone wants to mentor, let me know", "If anyone wants to learn something, just ask". But most juniors don't know what's okay to ask for and most seniors don't know what would be most useful to offer. So what works better is a list of specific learning needs, specific topics. Work with your teams to list the specific one-hour topics. They actually need to learn things like debugging strategies, the why behind our architecture, techniques for navigating incomplete information, or maybe things like how to evaluate third-party dependencies suggested by AI. Make this list visible, specific, and then you can go to someone with a bounded ask. Not would you mentor me forever, but could you run a one-hour session on the back end for front-ends? This is much easier to say yes, too. And I know some of these advice can sound too corporate. If you imagine it only working inside a big organisation, if you're in a small team or a startup, or you don't have an internal enablement function, this room, this conference can be your learning ecosystem. I'm sure that there are people here right now who could probably give your team one genuinely useful hour on topics that matter. You don't need to have a giant budget. You need a giant budget or a giant team. You need the clarity on what your people need, and you need the courage to ask. You need to connect people to the learning that they actually need.

So let me bring this together. We are living through a fundamental change in the engineering craft. The old story said that you earn your place through years of repetitive syntax, through manual grunt work, and slowly increasing trust. This story is already changing. You can now spin up a project, scaffold and up-generate the first pass at the feature in a single afternoon. But that does make the junior role different, because the things that matter most now are the things we used to delay, things like architectural judgment and taste, critical evaluation, cross-functional collaboration.

So let me leave you with three specific takeaways that you can carry back to your teams:

Overcome the how I learn bias. We need to prepare early career engineers for the world they are entering now. And in that world, the people who thrive will not be the ones who simply learn how to grind through the boilerplate faster. They'll be the ones who can frame the problem, question the output, connect the dots, work with other humans, and direct AI tools with judgment. So look at your juniors differently.

Trust them with more meaningful work. Teach senior thinking earlier. Focus on the why over the what. In a world where AI can generate a code in seconds, an engineer's value lies in the why. Why this architecture and not that one? Why this solution for these users at this moment in the product's life? Coach them in how to evaluate, not just how to produce, ask them for reasoning, not just output. You'll be amazed how quickly they rise to that level when you signal that this is what's important.

And lastly, build a kind of learning environment where AI accelerates growth instead of faking it. If you're a senior engineer, maybe the highest-leveraged thing you can do is not try the code faster for someone. Maybe it's just sitting beside them while they learn how to orchestrate the tools. If you remember nothing else from this talk, remember this, the future belongs to the orchestrators. Engineers who can frame problems, harness tools, and work brilliantly with other humans. Every junior engineer you're working with right now is a future orchestrator, but only if you choose to train them for it. Yes, junior tasks are disappearing, but junior engineers are not. They are still our greatest source of future senior talent. So please, please, please train them for the world that's here, not the one we came from. Thank you!

Audience Q&A

MC: Hello! We have time for... two questions. Your name, please.

Audience member: Hi, I'm Illan from Xero. I loved your talk. I think it's fantastic, just rings... true all along. And I think that the one thing that we could say is that we need those juniors to be the engineers. They're actually cheaper and going to learn faster to be the engineers we need in this age. So we need more of them, not just to keep going for the sake of being nice. But I want to ask you those fundamental skills and the ability to read code. How do you see those developing? 'Cause from my experience, I only know how I learned and that was by writing code. Is reading code even a skill you can learn without writing code? And how are we going to make sure that they don't skip that?

Lora: Yeah, I love this question. So the way to get better at reading code is by reading code. And I think that there are a lot of theories and a lot of educators who actually say that the way that we've been teaching coding has been wrong all along because in no other kind of human language you learn by writing. We first copy what we see. And even as adults when we learn human languages, a lot of us start by reading. And we are naturally much better at reading than talking and writing. And so there's the argument that we've all along we've been teaching coding wrong. And I think there's a lot of great talks on that as well. That our brains, the way they process information is by just like we need to be able to see a lot of good examples in order for our brains subconsciously to make connections. And so reading code has never been so important but today it's even more important.

And I think a lot of juniors struggle with it because they say, okay, how am I supposed to do code reviews when I don't know more than my senior? How am I supposed to be reviewing their code? I'm like, no, at this stage code reviewing is about getting into the habit of like reading a lot of code and noticing patterns and trying to understand things and asking questions. So like you can do that even if you don't understand and you're not ready to approve a pull request. But yeah, you get better at reading code by reading code, reading a lot of it, asking questions when you don't understand things. You can do code reviews with another senior engineer and see how they read the code. And so yeah, we just need to read really a lot of code. We still need to be able to ask questions and to make sure that, okay, I don't understand this thing. I think that's what it means, but am I correct? And if you are really lost, just ask a senior engineer to sit next to you and read the code together with them. But make sure that you do this really every day and you read a lot of code. Great question! MC: One more question. Your name?

Audience member: Do companies need to create any checklist so that it will be helpful for the juniors because they don't know the code standard for the company, what they want. And for example, I was working when in Apple, there was like our senior was reviewing the code. First, I was working as a tester and before I was pushing code on to git, there was a senior who were reviewing the code. Like that, they should follow this process or they should also need to create some checklist so that everybody can check whatever these standards they need to follow like that thing.

Lora: Yes, so your question is if we have a checklist for code reviews? Yes, yes! And Yen, who is also on the speakers table, correct me if I'm wrong, but we don't have a checklist for code reviews, but I know that some teams might have their own kind of checklist of things that you have to check or a lot of these things will also be automated. If there was a checklist, we will probably try to automate those. So I would say that, yeah, that's my answer. There's no strict checklist. Maybe we will have it by different teams might have something like that. But what I tell, one of the things that I don't like with, oh, sorry, with handling checklist to junior engineers is that I want them to talk to people and to learn what works for them. And so that's the reason I would probably advise against having a checklist to hand to juniors and say, "Hey, that's the process that you follow. "That's what you have to do every time you read code." No, I actually want them to have the conversation with another human and learn from that other human and maybe like create your own checklist. But great, great question!

Thank you! Thanks, thanks everyone!

References:

• Culture Amp