One Silver Bullet: Adaptability  🔗 **Source:** [One Silver Bullet: Adaptability](https://www.youtube.com/watch?v=2VzkT-7GTMM) > [!note]+ Document Notes > > [!info] Provenance > > **Analysis generated:** 2026-08-27 by Claude (Opus 5) via the `readwise-deep-read` pipeline. > > **Source:** YouTube — https://www.youtube.com/watch?v=2VzkT-7GTMM > > **Transcript:** ~10,900 chars · video (conference talk) > > **Speaker:** **Daniel**, self-introduced as heading the education mission at an organisation the captions render variously as *"Kodu Future," "Kodi Feature,"* and *"code your future"* — `[INFERENCE]` **CodeYourFuture**, a UK charity training people in poverty and displaced people for tech roles. `[STATED]` He describes himself as a former *"staff engineer and manager at places like Google and Apple and Twitter"* working on internal developer experience. **No surname is given on air and none is asserted here.** > > **Venue:** `[INFERENCE]` A **LeadDev** event — he thanks *"lead dev"* directly, references giving *"a talk at Lee Dev Berlin last November,"* and mentions a booth in the hall. > > **Register key:** `[STATED]` speaker-stated · `[EVIDENCE]` demonstrated · `[INFERENCE]` reviewer inference · `[RECOMMEND]` reviewer recommendation. > > **Coverage:** Full transcript read. Machine captions corrupt the organisation's name, the venue, a partner company, and a graduate's name repeatedly (see [Transcription artifacts](#transcription-artifacts)). > > **Disclosed interest:** `[STATED]` *"I'll be at the speaker hours afterwards and we have a booth out in the hall."* `[INFERENCE]` **This is a genuine argument and a recruiting pitch, and the speaker discloses the second** — noted for calibration, not as an accusation. > # 🏷️ Title: One silver bullet: Adaptability > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ### 🔗 References > - `[STATED]` His own earlier talk at **LeadDev Berlin, November 2025**, referenced via an on-screen QR code (not captured). > - Named partner: **Capgemini** (captioned *"Cap Gemini"*), which `[STATED]` *"hired more than a hundred of the people we've trained into software roles."* > - `[INFERENCE]` No external research, data, or third-party source is cited anywhere in the talk. > ## 📝 Summary > **The claim, and it is the contrarian position in this batch.** `[STATED]` *"AI is changing software. We can't deny that. But my claim is it's not changing things as much as we pretend it is."* > The reductions are specific: `[STATED]` *"LM APIs are new, but APIs aren't — same core skills, some modifications. LM ops is new. Honestly, it's pretty much ops with a little less determinism and a few more files we need to pass around."* And: `[STATED]` *"AI is definitely changing things, but change isn't new. We're in an industry that changes all the time."* > **The argument.** If the changes are smaller than claimed, then the skill that matters is not tool fluency but **learning to learn** — and the hiring implication is a shift from *what have you done* to *what can you do*. > **The evidence: three named graduates.** > - **Andre** — fled disrupted schooling in Russia, arrived in the UK without standard qualifications, trained with **no AI content whatsoever**, then was hired to build the organisation's LLM code reviewer. `[STATED]` *"We didn't teach him how to refine a prompt… We gave him a problem."* > - **Ley** — an English teacher from Iran with little prior computer experience, who discovered through the course that she preferred business-analysis work, and was placed when Capgemini asked for BAs. > - **Amina** — two computing degrees that `[STATED]` *"kind of let her down"*; hired by a VP who approached after the Berlin talk, and who later came back asking for another. > **The strongest structural insight, which he states and doesn't name.** `[STATED]` *"our course on average is about a year end to end… we could hand them the number of people they wanted to interview and we could guess which ones they were going to accept. Compare that to sifting through a thousand CVs."* > `[INFERENCE]` **A year of supervised observation is a higher-bandwidth signal than any CV, and that — not training — is what the organisation actually sells.** > **Bottom line.** `[INFERENCE]` A well-argued, humane talk with a real gap: it advocates hiring for potential and demonstrates only one method of assessing it — **a year of observation that a hiring manager cannot replicate.** And three named successes arrive with **no denominator**: no completion rate, no placement rate, nobody the programme didn't work for. > ## 📖 Main Content > ### The contradiction with the Meta talk, and how it resolves > `[STATED]` Daniel: *"LM APIs are new, but APIs aren't — same core skills, some modifications."* > `[EVIDENCE]` The Meta engineering manager in this same batch, on the same conference circuit, in the same year: *"My 20 years of experience were worthless. Even worse, those years hold me back."* > `[INFERENCE]` **These read as flatly opposed and they are not, and separating them is the most useful thing this pairing does.** The Meta talk is about **tool fluency** — a senior manager frozen on stage because he did not know what vibe coding was, unable to demonstrate current practice. Daniel is about **transferable fundamentals** — APIs, ops, review, problem decomposition. **Those depreciate at completely different rates.** > `[INFERENCE]` And the **DX data from this batch supplies the measurement that adjudicates it**: across 460 companies, staff engineers used *"significantly less tokens"* than juniors on the same use case. That is judgment surviving the tool change and showing up as efficiency — while the juniors caught up on raw time saved. **Experience in tools depreciates fast; experience in judgment does not.** Three sources, three methods, one consistent result once the two kinds of experience are held apart. > `[RECOMMEND]` The precise formulation the Meta talk needed and did not have: **your tool knowledge is worthless and your judgment is not, and the failure mode is mistaking the first for the second.** > ### Andre is a natural experiment and nobody calls it one > `[EVIDENCE]` `[STATED]` *"at the time he did our course, we didn't teach him anything about AI… But when he finished the course, we hired him to build us an LM code reviewer… We didn't teach him how to refine a prompt. We didn't teach him how to avoid blowing out a context window or how to avoid token limits. We gave him a problem."* > `[INFERENCE]` **This is exactly the right shape of evidence for the talk's thesis, and Daniel presents it as an anecdote.** The claim is that learning-to-learn transfers to tools not taught. The test is: take someone trained with zero AI content and hand them an AI problem. **The AI curriculum was absent by accident of timing, which makes it a cleaner test than one designed on purpose.** > `[INFERENCE]` It is n=1, unblinded, and reported by the party with an interest in the result. It is still the strongest single piece of evidence in the talk, and it deserves the framing it does not get. > `[EVIDENCE]` The tool itself is also described honestly: `[STATED]` *"humans still review every trainee piece of work… but they were wasting a lot of time on low-hanging fruit. People were spending a lot of time identifying duplicate code or badly named variables."* `[INFERENCE]` **Machine handles the mechanical layer, humans keep the judgment layer.** That is the same division this batch found in the Syntax automation caveat and in the WP Rocket post-mortem — *generation is cheap, judgment about what matters is not* — arrived at independently a third time. > ### The hiring critique is self-implicating, which makes it credible > `[STATED]` *"I think most of Hi, I'm Daniel and I head up the education mission at Kodu Future. We offer a free training program to people in poverty to try and get them good jobs in tech. My personal goal is to only produce people from our program that I myself would want to hire. And I like to think I have pretty high standards. I was a staff engineer and manager at places like Google and Apple and Twitter. And my focus was on internal developer experience. Taking some of the best engineers in the world, working out how can we get get you a little more productive, get you a little better at what you do. And it's been very clear from all the talks we've had today, from everything that's happening in our industry at the moment, a AI is changing software. We can't deny that. But my claim is it's not changing things as much as we pretend it is. We have people talking about how this is a brand new industry. We have to rethink how we do everything. And I'm not sure that's true. I want to review it. I may trust it more or less depending on what kind of problem they're solving and how much experience they have solving that kind of problem before. There are some things that are definitely different. The robot will be faster at producing me code and maybe don't have to be quite as polite in my feedback. I'm not as confident that the LM or the agent will learn from my feedback on this PR and apply it to the next one. There are definitely some things that are different, but there's a lot of stuff that's very similar to existing skills we already have and ways that we work. LM APIs are new, but APIs aren't same core skills, some modifications. LM ops is new. Honestly, it's pretty much ops with a little less determinism and a few more files we need to pass around. AI is definitely changing things, but change isn't new. We're in an industry that changes all the time, right? There's always a new language or a new framework or a new paradigm or a new way that we're approaching things. And I think we need to remember that we're we're making smaller changes than we think. We'll talk about how we how we teach a Kodi feature and how we think about new technology and new change. We're a very goal oriented organization. Our goal is to get people into jobs. Someone completing our course isn't success for us until they're in a job and thriving in a job. We keep working with them. We keep supporting them. We keep helping them learn and grow. Our core focus is on learning to learn. And I love everything Hal was just saying about mental models. It's about understanding the core. It's about working out not just to be taught some steps, some tips and tricks, but how to think and how to expand what you know. And so we've been adapting to AI and how we teach, but we haven't had to adapt that much because we were already teaching people how to learn new things, how to go beyond what we were teaching them. Let me give you an example. This is Andre. Andre was one of our our students. Um he grew up in Russia and he knew his whole life he wanted to be a software engineer. War broke out a few years ago and it disrupted his education. He was a teenager and he eventually found himself in the UK without the kind of standard qualifications you'd use to to get into our industry. He learned programming through code your future and part as part of that he got lots of code review from industry professionals. We're a volunteer organization and we give a lot of feedback on exercises people do. And because these are people in industry giving that feedback, the feedback they give naturally adapts as people's working style does as people get used to things like AI. Now, at the time he did our course, we didn't teach him anything about AI. We've since added some content. We're building up some of those mental models that are really important. But at the time he did the course, there was none of that. But when he finished the course, we hired him to build us an LM code reviewer. Now, humans still review every trainy piece of work at Code Your Future, but they were wasting a lot of time on lowhanging fruit. People were spending a lot of time identifying duplicate code or badly named variables, stuff are pretty good at spotting. And so, he could put together this saves our humans time so they can focus on what humans are really good at. And the theme I really want to pull out here is that importance of learning to learn. We didn't teach him how to refine a prompt. We didn't teach him how to avoid blowing out a context window or how to avoid token limits. We gave him a problem. And because he'd learned how to learn, because he'd learned how to go beyond what we taught him, he could work out how to solve that problem. I think for all of us as we're trying to grow our organizations, we need to think, how are we hiring? I think most of our hiring practices wouldn't have hired Andre to write us an AI tool. They should have though. He's been really good at it. There's a gap there somewhere. We'll talk to you about another of our graduates, Ley. Ley is fantastic. She grew up in Iran. She was an English teacher. When she grew up, she didn't really have much experience with computers. She found herself in the UK. and she joined Kodi Feature wanting to learn about computers, thinking about becoming a software engineer. She was surprised though. She actually found through the course she really loved the more business analyst style work. She really loved getting the people together, making sure we're all on the same page, making sure we're actually solving the right problem together. Now, she's good at writing code. Like, she did our course. She's great at that. But this was the thing she was really excited about. We've worked with Cap Gemini, one of our partners, for for a long time, and they've hired more than a hundred of the people we've trained into software roles. They're a great partner. We love working with them. They love working with our graduates. And conveniently, they reach out to us saying, "Hey, we've never done this before, but we actually need some BAS. Have you got anyone we should talk to?" We go, "Yeah, 100%." We have a broad community of people from a range of different backgrounds and roles in our volunteer group and we could put together a really short bespoke training course to take someone who already had this software knowledge and experience from our training and train those specific techniques needed to get into that role. Now she and three or four others are thriving as really technical having wonderful jobs doing fantastic things. And the thing I want to call out for us all here is the reason we could do that is we got to know Ley really well. We're a part-time course to fit around the fact that people have lives and jobs and things going on. And so our course on average is about a year end to end for someone to be with us. So we knew really well. When Cap and I came to us and said we want some BAS, we could hand them the number of people they wanted to interview and we could guess which ones they were going to accept. Compare that to sifting through a thousand CVs or apply through LinkedIn that you get. That personalized connection knowledge really helps to get the right person in the right role. The last story I want to tell you about is AA's fantastic. She's really smart and she really wanted to get into software and she normally did everything right. She did a bachelor's in computing. She's a masters in computing and I'll be honest with you, they kind of let her down. Courses didn't really challenge her. They didn't talk about multiple ways to approach a problem or trade-offs. They didn't really review much of her work. The courses that she did lacked a lot of depth. They were quite shallow. She wasn't really taught much by her practical skills across both those degrees. She didn't write a single test. She didn't do any teamwork. She didn't know what Git was. She didn't really know how to look for jobs or how to interview. She joined Kodi Future and we helped her grow her skills a little bit, but honestly, she she knew she knew her stuff. We helped her grow in her confidence. And the biggest thing that we did was we helped her grow in that adaptability, that confidence and knowledge and ability to go beyond the things that you've been taught and work out what you need to to solve a problem. Now I'm really pleased to be able to share with this community that we're really pleased to be a part of a success story out of LeDev. I gave a talk at Lee Dev Berlin last November. Uh if you follow the QR code, you can watch it. The the pitch was basically so many engineering managers are struggling to hire that perfect senior engineer right now. They think I need someone who has exactly this experience and exactly this experience and exactly this experience. They spend three or six or nine or 12 months searching and sifting through CVs and interviewing and interviewing and interviewing and not finding that perfect. My pitch was simple. I have a bunch of early career engineers who are really adaptable and will learn really quickly. Try hiring one of them instead. Straight after that talk, a VP of engineering came approached us and said that really specific CFKA role for a while. Who have you got? They interviewed Amina. They loved Arma. They hired Amina. No question. Now she's thriving in a great job delivering a bunch of new tech that she's never used before and I was really excited a couple of weeks ago that VP called us up and said hey we love Arma we actually need another one who have you got so thank you so much to lead dev for helping to make this happen lesson I think we can all take from this is we need to adapt our hiring strategies if I think back 15 20 years ago our industry was overly focused on pedigree Right? You wanted someone with the right degree from the right short list of universities. And I'm so grateful that we've mostly moved past what have you done? What's your experience? And that is much better. It's a much better predictor of success. But I'm sure we've all had someone on our team who's done a lot of really impressive stuff and struggles to adapt when the industry changes or when the team needs change. So, I think we all need to start thinking less about what have you done and more about what can you do? Where will you go? Now, I'll be at the speaker hours afterwards and we have a booth out in the hall. I'd love for people to come talk to me about who it is that you're struggling to hire. Maybe we can have a talk about how we can start helping you hire for what people can do rather than what they've done and help you find your arena too. Thank you so much., One Silver Bullet: Adaptability, Daniel (CodeYourFuture) — LeadDev, 01m0z355vr0ejr6ka0qzev415m.