Alright, real talk moment. Last week I watched someone with zero coding background build a fully functional app in an afternoon. Working auth, a database, a halfway decent UI. Prompt in, app out. They were thrilled. I was thrilled for them. And also, if I'm honest, quietly having a small existential crisis in the corner of the room.
Not because I felt threatened exactly. More like — I spent actual years learning why guard let exists, why force-unwrapping an optional is basically playing production Russian roulette, why you don't just slap @State on everything and hope. And now that entire chunk of hard-won suffering can apparently be skipped with a well-worded prompt and a bit of patience. Cool. Cool cool cool. Love that for me.
The New Skill Isn't Coding. It's Knowing What You Don't Know.
Here's the thing that's been sitting weird with me: the app that person built works. It runs. It does the thing. But if it breaks in a weird edge case at 2am, they have no idea why, because they never had to build the mental model that would let them find out. They have the output without the map.
It's giving major "I summoned a shadow clone but I don't actually know ninjutsu" vibes. The clone can absolutely fight for you. It looks exactly like you. It even talks like you. But the second something goes wrong that the clone wasn't built to handle, you're standing there with zero chakra and zero idea what just happened, because you never did the training that would let you improvise.
That's the real shift, I think. It's not "can you build the thing." It's "when the thing inevitably breaks in a way nobody predicted, do you have literally any framework for figuring out why." AI is extremely good at producing working code. It is much less good at producing a person who understands why it's working, which is a completely different skill that doesn't transfer just because you were in the room when it happened.
The Uncomfortable Part Nobody Wants to Say Out Loud
Here's where it gets messier though, and I want to be fair about this instead of just being smug about my years of suffering like it was some kind of noble sacrifice.
A huge amount of what "understanding code" used to gatekeep wasn't actually that valuable in itself. Knowing the exact syntax for a for loop in three different languages was never the point — it was a costly proxy for the thing that actually mattered, which was being able to reason about logic and structure. If AI genuinely lets more people skip the costly proxy and get straight to building useful things, that's not automatically bad. Loads of us gatekept a skill that was mostly just "memorized enough incantations to get the compiler to stop yelling," and dressed it up as deep expertise.
So I don't think the honest question is "is it bad that people can build without understanding." I think it's "what happens to the people who only ever build without understanding, the moment something needs actual understanding to fix." Those are very different problems, and I think a lot of the online discourse conveniently blurs them together because "everyone's fine, don't worry about it" and "everyone's cooked, we're all doomed" are both easier takes than the actually annoying, nuanced middle one.
My Honest, Slightly Nervous Take
I think we're heading toward two very different kinds of app-builders, and the split isn't going to be "used AI" vs "didn't use AI," because basically everyone's going to use it. The split is going to be between people who used AI as a shortcut through understanding, versus people who used it as a scaffold toward understanding — same tool, completely different relationship to it.
The scaffold group asks why, even when the thing already works. They read the generated code like it's a stranger's PR, not a magic box. They break things on purpose in a sandbox just to see what the error actually looks like, so next time it happens for real they're not starting from zero. The shortcut group ships the working thing and moves on, and I get it, deadlines are real, but eventually the bill comes due, usually at the worst possible time, usually in production, usually on a Friday.
I want to be in the scaffold group. Some days I actually am. Other days I catch myself accepting a suggestion because it compiled and I had somewhere to be, and I have to go back later and actually sit with what it did, like eating my vegetables after I already had the dessert.
Okay, Your Turn, Don't Leave Me Hanging Here
So genuinely — where do you land on this? Do you think "understanding the code" is going to matter less over time, the same way most of us don't understand assembly anymore and it's completely fine? Or is this different, because the failure modes of AI-generated logic are weirder and less predictable than the failure modes of a compiler?
And be honest: when's the last time you accepted a suggestion, watched it work, and never actually went back to ask why?
Asking for a friend. The friend is, once again, me. I contain multitudes and also several unexamined, accepted suggestions.
This article was written based on my own experiences and opinions. AI tools were used to help with grammar and structure, but the story, ideas, and voice are entirely my own.
Top comments (30)
The danger is not that more people can build. That part is good. The danger is that ownership gets separated from understanding. If nobody knows the data model, failure modes, permissions, and deployment path, the app is not really built yet. It is only assembled.
"Built vs assembled" is the distinction I've been trying to articulate for a while and you just did it in one sentence. Assembled means the pieces fit together and the thing runs. Built means someone understands why the pieces fit together, what breaks if they don't, and what to do when something unexpected happens. The output looks identical until the moment it doesn't, and at that point the difference between built and assembled is the difference between a fifteen-minute fix and a very bad afternoon.
The ownership point is the one that gets underweighted in most conversations about this — because ownership isn't just about who wrote the code, it's about who can be responsible for it when something goes wrong. If nobody understands the data model or the failure modes, there's no one to be responsible in any meaningful sense, just people trying things and hoping. That's not a team that built something, that's a team that's managing something they don't fully control.
Exactly. Ownership is the test that separates built from assembled.
The dangerous part is that the two can look identical on launch day. The difference appears when the system breaks, the business rule changes, or a dependency behaves oddly. Then the team either has a mental model, or it has a pile of working parts it is afraid to touch.
"A pile of working parts it is afraid to touch" is such an accurate description of what assembled-without-understanding produces over time—and the fear itself becomes load-bearing in a weird way, because the system keeps running partly because nobody dares change anything. Which works until something external forces a change, a dependency update, a business rule shift, or a breaking API, and then the fear stops being protective and becomes the problem. The mental model isn't just about understanding; it's about being able to move without being afraid. That's what built actually means.
Fear becoming load-bearing is a great way to describe it. The system keeps working because everyone has learned the forbidden zones by rumor. That is not ownership; it is avoidance with a deployment history. The real test is whether a new person can make a necessary change without turning the whole app into archaeology.
"Avoidance with a deployment history" is such a precise description of what that state actually is — it's not stability, it's just the absence of anyone having been brave enough or desperate enough to touch the thing recently. And the new person test is the right one because a new person doesn't know the forbidden zones yet, so they'll walk into exactly the places everyone else has been carefully steering around, and what happens next tells you everything about whether the system is actually understood or just successfully avoided. If onboarding someone new regularly produces incidents, that's not a people problem, it's a knowledge problem that the deployment history has been disguising.
Yes. The new-person test is brutal because it removes the private map everyone else has built in their head. If the system only stays stable because insiders know what not to touch, the deployment history is hiding the real cost. Onboarding then becomes the audit that the architecture has been postponing.
"Onboarding becomes the audit that the architecture has been postponing" — that's the line. Because the insider map gets built so gradually and so implicitly that nobody notices it's there until someone arrives without it and starts touching the things everyone else learned not to touch. At that point the onboarding incident isn't bad luck or a knowledge gap, it's the architecture finally getting tested by someone who doesn't know the rules, which is the only honest test it was ever going to get. The deployment history was never evidence the system was sound, it was just evidence that the right people hadn't left yet.
That is a great way to put it. The architecture only seems stable because the people carrying the private map are still around. Onboarding removes that hidden dependency. When the new person breaks something by doing the reasonable thing, the system is not unlucky; it is finally being tested without folklore.
"Tested without folklore" is the cleanest version of this I've seen — because the folklore is what makes the system seem more robust than it is. The people carrying the private map aren't just holding knowledge, they're actively compensating for architectural gaps every time they make a decision, and that compensation is invisible until it stops. The new person doing the reasonable thing and breaking something isn't a knowledge failure, it's the system finally encountering someone who wasn't trained to work around its weaknesses. That's not bad luck, that's information the codebase has been withholding. 🌸
Exactly. Folklore is comfortable because everyone can repeat it, but it does not survive contact with a failing system. A test with provenance is less glamorous, but it gives the next person something real to inspect.
Yes, and that is why onboarding is such a useful architecture test. A new person is not just learning the system; they are revealing which assumptions were never encoded anywhere. If the reasonable path breaks things, the design depended on folklore.
"Everyone can repeat it but it doesn't survive contact with a failing system" is exactly the problem with folklore — it feels like shared knowledge but it's really just shared habit, and those two things look identical until something actually breaks and you need the knowledge to hold up under pressure. A test with provenance is less satisfying to explain in a meeting but it's the one you can actually trust when it matters.
"Revealing which assumptions were never encoded anywhere" is such a precise description of what onboarding actually does — it's not just knowledge transfer, it's an audit of what the system assumed everyone already knew. Every time a new person does the reasonable thing and breaks something, that's a specific assumption surfacing that lived in someone's head rather than in the code. The design didn't fail the new person; it finally got tested by someone who wasn't carrying the hidden prerequisites.
That onboarding point is strong. New people are often the first real test of whether the system explains itself. When they break something reasonable, the system just revealed undocumented design.
"The system just revealed undocumented design" is such a clean way to reframe what a new person breaking something actually means — it's not a failure of the person, it's a failure of the system to communicate its own constraints. Every time that happens it's the architecture surfacing a requirement it never wrote down, and the new person just happened to be the first one who didn't know to avoid it. The reveal is useful information if you treat it that way rather than attributing it to a knowledge gap that needs patching with more onboarding documentation.
Exactly. A new person breaking the path is often the first honest integration test of the architecture. The system was relying on folklore, and the newcomer simply did not have the folklore installed yet.
That is why I like treating those moments as requirements discovery. The fix is not always more onboarding. Sometimes it is making the constraint visible in the code, the workflow, or the product itself.
The reframe that actually matters is "debuggable mental model," not "knows the language." A builder who's never heard of
guard letis fine until the app does something they can't explain. At that point they can't even form a hypothesis, because they have no map of the system's behavior to reason from.The fix isn't "learn syntax first." It's giving builders a way to observe what the thing is actually doing, traces, diffs, state, so the map gets reconstructed from behavior instead of from source knowledge. The open question is whether the apps you've watched get built this way tend to fail loudly (crash, obvious error) or silently (wrong output that looks fine), because that's what decides whether the missing mental model is survivable or a ticking clock.
"Debuggable mental model" is a much better frame than "knows the syntax" — it shifts the question from what you memorized to whether you have enough of a map to form a hypothesis when something goes wrong. The person who's never heard of guard let but understands that optionals exist and that unwrapping can fail is in a completely different position than someone who knows the syntax but has no model of why the crash happened.
The loud vs silent failure distinction is the one that actually keeps me up about this. From what I've seen, the failures tend to start loud — crash, obvious error, something that stops the demo — and get fixed by prompting the AI to fix the symptom. The model is very good at making the obvious error go away. What it's less good at is distinguishing between "fixed the cause" and "handled the output of the cause in a way that makes the error stop appearing." So the app progresses to a state where the loud failures have been patched and the silent ones are accumulating underneath, and at that point the missing mental model isn't survivable anymore, it's just not visible yet.
The traces and diffs approach you're describing is interesting because it's essentially building the map from the outside in — observable behavior first, source understanding second. I'm curious whether that produces a mental model that's actually equivalent to one built from source knowledge, or whether there are categories of failure it structurally can't surface. 🌸
This is a very good perception of AI involvement in software development.
As a beginner into the tech I often find myself thinking that trying to understand while slow my learning process, that I will be behind in the industry. Because the hours I would use just to understand an AI generated code someone who doesn't care about understanding the code will use it to generate additional 2 functional applications. But also at the end of the day there's the confidence I always have in me anytime I understand an AI generated code on any projects I'm working, because it makes me play God over the project, I can destroy a part of the code either by mistake or intentional and still fix it back. So to answer your question I'm among the set of that support understanding the code you're been given by AI than just copying and past. I know as beginner like me I may not move fast like other vibe coders but I'm also grooming the one habit that most of them do not have PROBLEM SOLVING
Thank you
"I can destroy a part of the code either by mistake or intentional and still fix it back" — that's such a vivid way to describe what real ownership of a codebase feels like, and honestly that's exactly the confidence gap between understanding and copy-pasting. 😊
The speed trade-off you're describing is real, but I think you're right that it's temporary. The vibe coder who ships two apps this week and the developer who understood one deeply are not in the same position six months from now. Problem solving is the one thing that doesn't get outsourced. Keep going!
That's the thing I have been stressing over for motnhs and have also brought up in many of the tech discords. I joined CS cuz I loved math and creating stuff. But lately it feels that the joy of creation os being stripped from the field. I especially liked your part about the 2 types of AI builders. ANd that often leads me to wonder how did the earlier people actually learn. I try to avoid using AI when I am learning something new but it's become so hard lately. I made a chrome extension for personal use a few days back and I read gthe documentation and I made t myself but I had to use claud to generate a roadmap for me . And everytime I do that it feels like I am cheating myself.
Which genuinely makes me question how did people before try and learn completely new stuff like just for fun how were people so sure if their chosen library is most efficient and how did they decide the niches of tech they were interested in
The "feels like cheating myself" line really resonated — I think that feeling is actually a healthy signal, not a reason to feel bad. It means you care about genuinely understanding the thing, which is exactly the instinct worth protecting.
On your question about how people learned before — honestly, slower and with a lot more dead ends. Stack Overflow rabbit holes, reading documentation three times before it clicked, building something broken and having no idea why, asking a friend who also wasn't sure. It was messier and more frustrating, but the frustration was also where a lot of the learning lived. The struggle wasn't a bug, it was kind of the point.
What you did with the Chrome extension — reading the docs, building it yourself, only using AI for the roadmap — that's actually the scaffold approach. You kept the understanding work for yourself and used AI for the part that doesn't build instinct. Using Claude to generate a roadmap isn't cheating, it's using the tool for orientation rather than outsourcing the actual learning. That's a meaningful difference.
Assalamualaikum,
This is actually a very interesting point.
I feel like many beginners (including me) can build things but don’t fully understand them yet.
Do you think this will become a bigger problem in future?
Wa alaikum assalam! 😊 I think it depends on the habit more than the tool — AI getting better at explaining why code works could actually help beginners build understanding faster than ever before. But if the default stays "here's working code, move on," then yes, the gap between people who understand and people who just ship is probably going to widen over time. The tool is neutral — it's the habit around it that decides which side of that gap you end up on. The fact that you're already asking this question suggests you're on the right track!
Wa alaikum assalam! Thank you so much for your thoughtful reply. I really liked your point about habits over tools that actually made me think differently. I’m trying to focus more on understanding instead of just using tools blindly. Appreciate your encouragement!
That's really great to hear! And honestly just being aware of the difference between understanding and tool-use is already most of the battle — a lot of people never stop to ask that question at all. Keep going, you're clearly thinking about this the right way.
ok )
I've watched many clips about how to get an edge in the tech industry and let me tell you what I learned. The more niche and specialized you are, the more valuable you become to solving specific problems in a company. That requires huge understanding and there is no greater time than today to study whatever you want with AI.
Before, you have to pay for a mentor. But now, the internet and AI models are free for us to use and educate ourselves. It all boils down to discipline. Control yourself into showing something you didn't fully create or understood yet. That would be the line that will determine which software engineers would last and which would be weeded out as soon as a real-world problem occurs.
"The more niche and specialized you are, the more valuable you become" — that's such a good reframe, and I think you're right that the timing couldn't be better for it. Having an always-available, infinitely patient AI to explain concepts, give examples, and answer follow-up questions is something no previous generation of learners had access to. The barrier used to be finding the right mentor or affording the right course. Now the barrier is almost entirely discipline, which is harder to outsource than money.