There’s a version of the AI coding conversation that goes like this: AI writes the code, humans review it, everyone ships faster. What that version skips is the uncomfortable question underneath: can you review code you’ve never written yourself?
Hywel Carver has been thinking about this longer than most. He’s the founder and CEO of Skiller Whale, a company built on the premise that engineers learn best by doing, not by watching. When he first talked publicly about what AI-generated code would mean for developer skill development, it was 2023, at a conference. The consensus at the time was still pretty comfortable. Things have gotten less comfortable since.
Rob sat down with Hywel to work through what it actually means to grow engineers in a world where most code is generated, not written.
1. Knowledge transfer is not the same thing as learning
The way most organizations approach skill development is to throw information at people and call it training. Watch this video. Read this documentation. Here’s a course with 47 modules.
“Very often the way that we expect people to learn is by just giving them a load of information. The actual practice of trying to do that thing, we leave you on your own to do in isolation. And that’s where the rubber hits the road. That’s when you find out whether you actually can do it or not.”
Hywel Carver, Founder and CEO, Skiller Whale
The problem is that information without practice doesn’t produce skill. Hywel’s framing: knowing and understanding are the first two rungs of a six-level learning hierarchy. Actually being able to apply something, evaluate someone else’s work, and eventually create something new comes later, and it only gets there through doing. If your development program stops at the second rung and calls it done, you haven’t built anything.
2. Bloom’s taxonomy explains exactly why AI code review is harder than it looks
Hywel referenced Bloom’s taxonomy of cognitive learning as a framework for understanding the current problem. The six levels build on each other: know, understand, apply, analyze, evaluate, create.
The way engineers have historically gotten good at reviewing code is by writing a lot of it themselves and having it reviewed in return. That cycle is how you build the mental model that lets you look at a loop and immediately think about off-by-one errors and variable state, rather than reading each line individually.
“We are used to a world where applying the skill of writing software is how we get good enough to evaluate it, to look at what someone else has done and say, yes, I am happy to put my name to that and for it to go into production.”
Hywel Carver, Founder and CEO, Skiller Whale
If 90% of code is now AI-generated, the training loop that used to happen organically through writing code no longer fires at the same rate. You can still develop those mental models. You just have to do it deliberately, through structured practice designed to build them, rather than picking them up as a byproduct of shipping.
3. AI and humans are bad at different things, and that’s precisely why both matter
Another interesting argument from the conversation: the error categories that AI is susceptible to are largely not the ones humans fall into, and the reverse is also true. AI is excellent at catching syntax errors, off-by-one issues, and assignment-vs-comparison bugs. Humans are not particularly good at those.
Humans are good at something different: reasoning about real-world consequences that weren’t in the scope of the ticket. The change that would give a specific category of users infinite free access. The knock-on effect that shows up in a workflow nobody thought to include in the spec.
“We are good at detecting things like: this is going to have a knock-on effect to that category of user that wasn’t in the scope of the change request. Humans are good at spotting that kind of thing.”
Hywel Carver, Founder and CEO, Skiller Whale
Hywel presented an example of an AI agent that found production credentials in a repo and wiped the database in nine seconds. It’s an argument for keeping human and AI review in parallel, because they’re checking for fundamentally different things.
4. Using AI well is a skill, and it’s learnable
There’s an assumption baked into a lot of AI tooling rollouts: give people access to the tool, maybe run a vendor demo, and let adoption happen. Skiller Whale ran a study that suggests this assumption is wrong.
They worked with part of an engineering organization while the rest of the org had access to the same tools but no structured training. Both groups had the vendor talk. Both had access to the AI coding assistant.
“The group we worked with had 90% weekly active users where the rest of the org had 50% weekly active users. When we looked at their main measure of productivity, which was PR throughput, the group we worked with saw a roughly doubling in their PR throughput. The rest of the org actually went down very slightly.”
Hywel Carver, Founder and CEO, Skiller Whale
A doubling versus a slight decline, same tools, same company. The difference was whether engineers had built mental models for how the tools actually work. People who understand what an LLM is doing underneath prompt differently, catch failures differently, and know what to try when the output is wrong.
5. Mental models don’t expire, even when implementations do
The pace of change in AI tooling feels genuinely overwhelming if you try to keep up at the surface level: new models, new frameworks, new prompting techniques, new papers every week. Hywel’s argument is that this is the wrong level to track.
“If you have a good sense of how an LLM works, and then someone says, one of the things an LLM can do is produce output that says do a function call, you see how tools work and you’re like, okay, that makes sense to me. You have a way better understanding of it than someone who’s just been a user of those systems.”
Hywel Carver, Founder and CEO, Skiller Whale
His analogy: if you had a solid mental model of HTML, CSS, JavaScript, and how a browser renders pages in the mid-1990s, that model has not meaningfully changed today. The implementations are faster, the APIs are cleaner, but the underlying structure is the same. The mental model carries you through decades of surface-level change. The same logic applies to LLMs. The tips-and-tricks content will be obsolete in six months. But the architecture of how they’re trained and how they produce output hasn’t changed that much.
6. The job title is changing faster than anyone expected
One thing Hywel raised that didn’t get a full chapter in the conversation but probably deserves one: after teams go through structured AI training, the next thing they come back asking for is communication skills. Engineers are having more contact with stakeholders. Product functions at some companies have gotten smaller. Individual engineers are doing more.
That sounds like good news for engineering influence. It also means engineers who were hired to write code are now expected to run conversations they weren’t trained for, translate technical decisions for non-technical audiences, and navigate organizational dynamics that used to be someone else’s job.
The skill set that made someone an excellent engineer in 2020 is still valuable, but it needs some expansion in order to meet the role’s new level of complexity.
Subscribe to Confident Commit for new episodes and the data behind how software actually ships: confidentcommit.com.
