This is a really good post. I'm a naturally controlling person, and I care about my craft a lot, so even in my recent dabbling (on a ~3000 LOC project) with agentic coding, one of the things I naturally did from the start was not just skim the diffs that the AI generated, but decide for myself what technologies should be used, describe the logic and architecture of the code I wanted in detail — to keep my mental model fresh and accurate — and read every single line of code as if it was someone else's, explicitly asking the AI to restructure anything that I didn't feel was the way I'd implemented it — thus ensuring that everything fit my mental model, and going in and manually adding features, and always doing all debugging myself as a natural way to get more familiar with the code.

One of the things I noticed is that I'm pretty sure I was still more productive with AI, but I still had full control over the codebase, precisely because I didn't let AI take over any part of the mental modelling part of the role, only treating it as, essentially, really really good refactoring, autocompletion, and keyboard macro tools that I interact with through an InterLISP-style REPL instead of a GUI. It feels like a lever to actually enable me to add more error handling, make more significant refactors for clarity to fit my mental model, and so on. So I still have a full mental model of where everything is, how it works, how it passes data back and forth, and the only technologies I'm not familiar with the use of in the codebase are things I've made the explicit choice not to learn because I don't want to (TKinter, lol).

Meanwhile, when I introduced my girlfriend (a data scientist) to the same agentic coding tool, her first instinct was to essentially vibe code — let it architect things however it wanted, not describe logic, not build the mental model and list of features explicitly herself, and skim the code (if that) and we quickly ended up in a cul de sac where the code was unfixable without a ton of work that would've eliminated all the productivity benefits.

So basically, it's like that study: if you use AI to replace thinking, you end up with cognitive debt and have to struggle to catch up which eventually washes out all the benefits and leaves you confused and adrift

I've been seeing teammates go from promising juniors to people who won't think, and I've tried hard here to say what I think they're going wrong.

Like the great engineers who came before us and told us what they had learned, Rob Pike, Jez Humble, Martin Fowler or Bob Martin, it's up to those of us with a bit more experience to help the junior generation to get through this modern problem space and grow healthily. First, we need to name the problem we see, and for me that's what I wrote about here.

In recent weeks, I have made huge changes to my main codebase. Pretty sweeping stuff, things that would have taken me months to get right. Both big, architecturally important things, as well as minor housekeeping tasks.

None of it could have been done without AI, yet I am somehow inclined to agree with the sentiment in this article.

Most of what I've done lately is, in some strange sense, just typing quickly. I already knew what changes I wanted, in fact I had it documented in Trello. I already understood what the code did and where I wanted it to go. What was stopping me, then?

Actually, it was the dread loop of "aw gawd, gotta move this to here, change this, import that, see if it builds, goto [aw gawd]". To be fair, it isn't just typing, there ARE actual decisions to be made as well, but all with a certain structure in mind. So the dread loop would take a long long time.

To the extent that I'm able to explain the steps, Claude has been wonderful. I can tell it to do something, it will make a suggestion, and I will correct it. Very little toil, and being able to make changes quickly actually opens up a lot of exploration.

But I wonder if AI had not been invented at this point in my career, where I would be. I wonder what I will teach my teenager about coding.

I've been using a computer to write trading systems for a long time now. I've slogged through some very detailed little things over the years. Everything from how networks function to how c++ compiles things, how various exchanges work on the protocol level, how the strats make money.

I consider it all a very long apprenticeship.

But the timing of AI, for me, is very special. I've worked through a lot of minutiae in order to understand stuff, and just as it's coming together in a greater whole, I get this tool that lets me zip through the tedium.

I wonder, is there a danger to giving the tool to a new apprentice? If I send my kid off to learn coding using the AI, will it be a mess? Or does he get to mastery in half the time of his father? I'm not sure the answer is so obvious.

> Claude wrote me Go tests that passed. They were beautiful, and they were worthless. They all collapsed to true == true.

My favorite one of these is when I was having Claude write a nix derivation to package kustomize at 4.5.5 and instead of getting the correct source version and building it, it just set some build args on the latest version to override the output of the --version CLI flag.

AI will hopefully humble so of the people I work with.

The people who understand nothing about business, yet you can't talk to because they think gifted for being able to write instructions to a computer.

The people spin out new frameworks every day and make a clusterf*ck of hyped and over-engineered frameworks.

The people who took a few courses and went into programming for money..

I went into software because I enjoyed creating (coding was a means to an end), and I always thought coding was the easiest part of software development. But when I get into corporate work, I find people who preach code like religion and don't even care about what is being produced, spend thousands of hours debating syntax. What a waste of life, I knew they were stupid, and AI made sure they knew as well.

I'm a 20+ years programmer working with my colleagues who are 2-5 years of experience. I could see they had accepted AI generated tests which are testing solely the mocks. This is quite annoying, because for me, when I want to finish a task properly, I have to write tests from scratch. I'm also using the same AI tool, but I want to use it differently, as a "copilot" and not the "main pilot"

For better or worse I’ve been finding it difficult to stay motivated at times for sharpening my craft. I’m currently reading Learning Go 2nd and it’s cool learning the idiomatic ways to write code in a language. However part of me feels like even if I strive to write “clean code”, now the bottleneck seems to be shifting to reviewers time and expertise.

So I fear I’m fighting a losing battle. I can’t and don’t want to review everything my coworkers put out, and code has always been a means to an end for leadership anyways so it seems difficult to justify carving out time for the team as a whole to learn, especially in the age of genAi.

I find that AI is really good at the easy stuff like writing tests for simple class without too many dependencies that we have all written hundreds of times.

Things go wrong as soon as I ask the AI to write something that I don't fully grasp, like some canvas code that involves choosing control points and clipping curves.

I currently use AI as a tool that writes code I could write myself. AI does it faster.

If I need to solve a problem in a domain that I haven't mastered, I never let the AI drive. I might ask some questions, but only if I can be sure that I'll be able to spot an incorrect hallucinated answer.

I've had pretty good luck asking AI to write code to exacting specifications, though at some point it's faster to just do it yourself

There used to be a time when you needed to be very skilled woodworker in order to make nice cabinets. There still are, but the number of machine / CNC made cabinets outnumber artisanal 100% hand-made cabinets by some incredible number. For every masterpiece made by a Japanese cabinet maker, imagine how many Ikea cabinets there are out there...

And that's how I believe software engineering will end up. Hand crafted code will still be a thing, written by very skilled developers...but it will be a small niche market, where there's little (to no) economic incentives to keep doing it the craftmanship way.

It is a brave new world. We really don't know if future talent will learn the craft like old talent did.

At some level it is true that AI is a bit like adding electric engines everywhere.

Including gym equipment.

To me it seems it happened the other way around: a reduction in the valuation of mastery preceded, and facilitated, the acceptance of LLM output as "good enough".

What was called "move fast and break things", is one example. This development model leaves behind a trail of shit, that is poorly integrated and often, fully understood by no one.

Like vibe coding, this is all great until something doesn't work (not IF something doesn't work, but UNTIL).

This failure to appreciate mastery is illustrated in even earlier "business model" strategies, such as elimination of large corporate R&D laboratories, and the LBO raiders.

It's widely understood that every product and service in the current era is going to shit (certainly for the users, even if not for the ownership). Toasters built in the early '50s still work, toasters built today are designed for the dump. This isn't a problem with toasters, it's a problem with the business model of unrestrained capitalism.

I wrote a blog post looking at a similar vein: https://www.dcaulfield.com/mastery-4-ai

If everyone uses AI, then the standard of mastery hasn't lowered - it's increased!

We're now caught in a dilemma: Do we play the short term game and use AI at the expense of our skills, or do we play the long term game and avoid AI where possible to build up expertise while risking being out-competed by everyone else who is using AI?

Not even mastery. The other day I was trying to figure out how to pass an external label to Prometheus alert rules when unit testing the rules with "promtool test rules". Man, all the models gave all kinds of hallucinated answers, and I had to resort to reading the promtool code. In the end, mastery means we get apply our skills to solve new problems, yet in the current state AI can only interpolate already solved problems.

> Claude wrote me Go tests that passed. They were beautiful, and they were worthless

Their ability to look correct exceeds their ability to be correct. Optimized for form more than function. Like politicians and management at large companies. Like the rote student who can be correct, but wont know why. Being fair though, it is a useful tool among many others in our toolbox.

Yup, I agree with the author 100%. By far the worst part of AI code generation is the inability to discern old and deprecated APIs/syntax/workflows of tech stacks that are constantly changing.

In complete irony, I got back to reading actual docs for Python, React, Scala (my stacks) because I do NOT like being spoon-fed slightly-off answers.

I have a feeling that the skills for fixing up AI slop will be in-demand quite soon.

But, more to the point - AI code is legacy code.

I mean, yes. And also; it's the age old problem that arises every time a new technology arrives in full: it requires a steadier-than-priorly hand in order to not have ballistic effects on society. This goes for books over what-my-betters-told-me, swords over flint-blades, automotive cars over horse-carts and indeed; ALL technology. New tech of any real substance invariably carry the need for cultural shift towards a more advanced stance that allows for the gainful use of said technology at scale.

What actually happened is that AI shifted / moved the valuable points to master

I might half agree with the premise. I've heard some version of the phrase "make it work, then make it right" and sure, if you only vibe code, you will be left with ... vibes.

I find that when I'm reaching for AI it's because I'm actually trying to decide if I want to implement the idea I have, and need a PoC vs. expecting production ready things. For example, I was working on a UI and wanted to be able to "swap" two ul lists in JS. Not too hard of a thing to do, but I didn't remember the syntax, etc, and instead of hand writing, I asked the AI to do it.

It worked. The code was insanely overwrought and iterating over each list item 1 by 1 etc etc etc. But that's fine, I'm still not sure the "swap button" in the UI is the right UX, so I put a todo and am working on the "right problem" instead of banging out a clean list swap function. The mastery I'm seeking is not "most elegant usable list swap function, with maintainable code" but instead "Is this the best UX?" AI slop helped me stay in flow state towards that mastery.

Music to my ears, can't wait this slop generator to flop.

There’s always been this draw in software engineering to find the silver bullet that will allow you to turn off your brain and just vibe your way to a solution. It might be OOP or TDD or pair programming or BDD or any number of other “best practices”. This is just an unusual situation where someone really can turn off their brain and get a solution that compiles and solves the problem, and so for the type of person that doesn’t want to think, it feels like they found what they’re looking for. But there’s still no silver bullet for complexity. I guess there’s nothing to do but reject the PR and say “Explain this code to me, then I’ll review it.”

"People who won't think" resonates with me for the draw I've felt being pulled towards by chatbots, and I've got plenty of experience in software and electrical engineering. They're pretty damn helpful to aid discovery and rubber ducking, but even trying to evaluate different products/approaches versus one another they will hallucinate wild facts and tie them together with a nice polished narrative. It's easy enough to believe them as it is, never mind if I had less expertise. I've found that I have to consciously pull the ripcord at a certain point, telling myself that if I really want the answer to some question I've got to spend the time digging into it myself.

I have to disagree. The same people who won't think existed in previous generations as well. The only difference was, they blindly regurgitated what Bob Martin et. al were saying.

No one knows for sure, the truth is we’ll have to burn one generation as the experimental test subjects before we can get an idea of what works and what doesn’t when it comes to AI assisted education. There is a lot we will probably get wrong and some kids will be screwed, but for the generations after hopefully we can do better.

very good articulation on the problem. My bet is that it is probably fine in the sense that the mastery itself is not going to be relevant.

I want to view AI coding as invention of new coding tools, at least in the way you described. I (hope) it will be more like punch-card->assembly-> BASIC/C -> scripting language -> some sort of well-structured natural language.

I think it depends on the effort put into reading and understanding the code being generated. The article makes the assumption that extended use of LLMs leads to a shift of _not reviewing and validating the code_. It is pointed out as the wrong thing to do but goes on assuming that that's what you do. I think it's like reading books.. there are various degrees of reading comprehension from skimming for content/tone, to reading for enjoyment, to studying for applications, to active analysis like preparing for a book club. There isn't a prescribed depth of reading for any document but context and audience has an effect on what depth is appropriate. With code, if it's for a one-off utility that can be verified for a specific application, yeah why not just look at its output and skip the code, full vibing, especially if it doesn't have any authority on its own. But if it is business critical it better still have at least two individuals read over it, and other CONTRIBUTING-related policies.

And it's not just complacence.. this illusion of mastery cuts even harder for those who haven't really developed the skills to do a review of the code. And, some code is just easier to write than it is to read, or easier to generate with confidence using an automata or some macro-level code, which often the LLMs will not produce, in preference to repeated-in-various-styles inlining of sub-solutions, unless you have enough mastery to know how to ask for the appropriate abstraction and would still rather not just write the deterministic version.

   > I wonder, is there a danger to giving the tool to a new apprentice? If I send my kid off to learn coding using the AI, will it be a mess

As long as your kid develops the level of mastery needed to review the code, and takes the time to review it, I don't think it'll be a mess (or not too large to debug). A lot of this depends on how role models use the tool, I think. If it's always nonchalant "oh we'll just re-roll or change the prompt and see" then I doubt there will be mastery. If the response is "hmm, *opens debugger*" then it's much more likely.

I don't think there's anything wrong with holding back on access to LLM code generators but that's like saying no access to any modern LLMs at this point, so maybe that's too restrictive; tbh I'm glad that's not a decision I'm having to make for any young person these days. But separate from that you can still encourage a status quo of due diligence for any code that gets generated.

I'm probably one of the people you're talking about.

I'm feeling basically mostly fulfilled in life, and don't feel my life is being wasted.

I didn't understand the thing about "AI made sure they knew as well", or maybe I'm not actually who you're describing.

But I definitely get into language, syntax, frameworks, parsing, and blah blah blah.

Plenty of people still play chess. Plenty of people still run. Machine performance has surpassed humans long ago in both disciplines. Are those people stupid also?

Interestingly, a lot of the engineers I know are hoping for the exact opposite. They're hoping that AI will humble the business, management, product types.

The way they see it, AI can easily shit out a hundred product concepts, market research, slide decks, sales emails, reports, etc. No need to bring on MBAs or self-proclaimed visionaries or LinkedIn gurus.

I think both camps will be disappointed. The engineers will be disappointed that they'll still need vapid business/product people to keep them pointed at projects that will actually put food on the table. The business/product people will be disappointed that they'll still need sanctimonious engineers to make anything actually work.

I wouldn't put too much hope into this because now, AI can help these people go from really vague thoughts to something that sounds even more fluent.

My sense is we really have to raise everyone's critical thinking abilities in order to spot bullshit.

Counterpoint: a cabinet has always been a cabinet and nobody expects it to be anything but a cabinet. Rarely are software projects as repeatable and alike to each other as cabinets are.

Software is codified rules and complexity, which is entirely aribtrary, and builds off of itself in an infinite number of ways. That makes it much more difficult to turn into factory output cabinetry.

I think more people should read "No Silver Bullet" because I hear this argument a lot and I'm not sure it holds. There _are_ niches in software that are artisanal craft, that have been majorly replaced (like custom website designers and stock WordPress templates), but the vast majority of the industry relies on cases where turning software into templates isn't possible, or isn't as efficient, or conflicts with business logic.

I understand the analogy, but code is so much more fungible. It is the stuff of thought. Rather than a physical thing with hard limits.

I think software will remain much more artisan because, in some sense, software is a more crystallized form of thinking, yet still incredibly fungible and nebulous.

Anything adversarial is going to be the best people using the best assist: military drones, trading, anything performance hot pathed (AI inference itself), thats all too competitive to be anything but hybrid.

But by a similar argument, most anything with healthy competition and a discerning market can only lag that standard by some amount.

It's easy to conflate a once-in-a-generation orgy of monopolistic consolidation with the emergence of useful coding LLMs, but monopolies always get flabby and slack, and eventually the host organism evicts the parasite. It's when, not if.

And we'll still have the neat tools.

> For every masterpiece made by a Japanese cabinet maker, imagine how many Ikea cabinets there are out there

Minimalist design isn’t the result of minimal effort. It actually takes quite a lot of time and skill to design a cabinet that can flat pack AND be assembled easily AND fit cost constraints AND fit manufacturing and shipping and storage constraints AND have mass market appeal.

IKEA stuff exists because of hundreds or thousands of people with expertise in their roles, not in spite of them.

Those CNC-made cabinets are driven by software written by a human being. And I'm not talking about the CNC software itself: CNC machine operators _code_, even if it's not obvious to those who don't know somebody who works with CNC machines. They provide descriptions to the machine in the form of M-Code and G-Code.

Your analogy doesn't work at all.

(I know this because my previous landlady's husband was a CNC machine operator.)

i used to make 'leaflet websites' in the 90s, then shopping carts. it was an era where everybody wanted an online presence to make themselves seem legitimiate. i expect this is the normal progression of anybody born in the 80s who could do software dev.

it got to a point where people would say they needed a website and i'd say to them that a facebook page would meet their needs better or eventually that a shopify site met their needs better. my business obviously folded.

People do love Ikea, Wal-Mart, McDonalds, and The Gap.

It is an analogy that only passes the initial glance. Especially since the CNC made cabinets are not full of design flaws. Your analogy would only make sense if these CNC cabinets were generated by CNC AI that may or may not follow the sensibilities of a human designer. Or if the inexperienced carpenters using CNC machines just described the design verbally to the CNC machine instead of carefully encoding their design into gcode.

Clearly you don't value the process of coding if you think it is analogous to a carpenter manually carving the details of a design that's above the process of building it. It is not a good analogy, at all.