I spent a long time honing my trade and I did learn a lot in the process, so I want to believe this argument, I really do. But then I imagine it applied to a lot of pre-industrial era jobs and I am not so sure.
"Master, should I still learn to weave our beautiful Persian rugs by hand?"
"Yes, and... Have you seen one of these mass-produced rugs? They all look the same and their quality is terrible! And how would you ever operate one of those new machines if you don't know a good rug from a bad one? By learning to weave manually, you are also learning about choosing the right yarn, negotiating the right prices with the merchant down at the market, selecting a good apprentice to pass down the trade. All these things will always be useful!"
Yes, there are still artisans making and selling beautiful rugs at premium prices. But most people now are content with resting their feet on a cheap Ikea thing that they can replace every few years, so that market has shrunk to almost nothing.
Is it possible the size of the market for hand woven rugs has actually stayed the same, and the mass produced variety has simply filled the void for the large segment who were never able to afford them?
Yeah, the small, useful bits of code I've made this year at work could have been contracted out in years past (we're a tiny non-tech co). But in addition to expense, there's the hassle of coordinating it, QA, etc. Really dont need all that for a project that connects a couple APIs with a minimal UI to help automate something previously done by hand.
With software I'm seeing a lot of people who would never have been able to build something, and wouldn't have hired a developer now try their hand at selling it
Some of those will go on to be successful and need technical people to support it
I don’t write the same program over and over again so I am always confused by how exactly this industrialization metaphor is supposed to map on to software development
Think of it this way, the Persian rug isn't the same pattern every time either. The base job is the same, but the implementation requires planning and the like. A rug making machine is good at creating the same thing over and over again, but not very good in being flexible.
Software... a lot of software is basically the same thing (database, api, frontend), the only difference is what data and business rules. But the act of writing code isn't very different. It's the what code to write where software engineers come in.
But we are kind of in a inverse situation, a huge amount of software is a one size fits all solution. Probably every small SaaS starts out with a number of extremely happy customers, but scaling means you can't satisfy everyone, so happiness turns into frustration. Big tech also supplies a lot of software that is one size fits all and not everyone is perfectly happy with.
If creation of customized software solutions is consistently getting cheaper and good enough in quality, the near future is about creating much more custom solutions for considerable smaller customer or consumer groups.
Mind that we still need people who understand tech and verify that a system does what it claims to do, in a safe and efficient way. Every non-technical vibe coder will at some point realize, that he maybe can prompt away every problem he has, but that is still considerable effort and also includes all the mistakes a professional already eradicated from his habits. Many vibe coded projects will also collapse under their own weight, rethinking a strategy - with tech in mind - is also professional effort.
Even if LLMs would produce perfect, high quality code all the time, instructing the "perfect" prompt is still a human problem. LLMs cannot mind read and fully understand the environmental and social circumstances. Understanding these things and model them into solutions, are also human problems.
All this still requires profound technical knowledge, even more now considering security is under fire.
I crave more reliable software more than I do software that is infinitely customizable.
Spinning jennys were neat but if theyd been invented in a world where use of star trek replicators was routine I think theyd be more curiosity than revolutionary.
Artisinal code would definitely die off if the cp command didnt exist though.
> Yes, there are still artisans making and selling beautiful rugs at premium prices. But most people now are content with resting their feet on a cheap Ikea thing that they can replace every few years, so that market has shrunk to almost nothing.
Yes, and it’s worth pointing out the class of people buying ikeas rugs were NOT buying Persian wool/silk rugs before…they had bare floors or make coverings out of cloth or woven grass.
Also worth pointing out that since 1979, regardless of whether it is secondhand or not and which country you are procuring it from, rugs made in Iran (Persian rugs) have been totally banned for import to the U.S. Tribal rugs now come more from places like Turkey and India. So the market is being extremely artificially suppressed, boosting ikea rugs even more.
Hello all, I wrote this article to help students considering CS as a major.
My own son has just started university studying CS, so I have skin in this game.
I continue to believe in what I've said in this article despite being startled (like most people) by the advances in AI recently.
One thing that I have noticed since writing this article is that the most effective vibe coders are already excellent developers, which I think is in keeping with the themes I discuss here. While I do expect the amount of hand-written code to decline, I think that knowing how code (and technical systems) work is going to continue to be valuable and perhaps even more valuable. I have no crystal ball, but that's what I'm seeing right now.
1. my ignorance is massive so don't bet on my predictions. There's so much FUD. This is like the industrial revolution but on steroids.
2. I see the moat around software decreasing quickly. Therefore, I'm going to project that there will be fewer coders in software only companies (such as Adobe, SAS, or Intuit)
3. It will be easier to support software so I see the need for more technical entrepreneurs. Software is going to be an amenity with services, hardware, or support. The code itself isn't going to be valuable like its current form.
4. I would project there will be more programmers in the future, but not pure programmers. More like the 1970s programmers who had other professions but would create their own programs.
I'm not sure this is more significant than the industrial revolution, but it is certainly faster. I am withholding judgement until we start to see real world changes beyond symbol manipulation.
I agree there is little moat around code qua code now. I'm not sure that means there will be fewer coders, because the people in the best position to take advantage of this new technology are... coders.
I again agree that code qua code is becoming less valuable, but I think that ironically _understanding_ code (and systems) is going up in value. Complexity still grows super-linearly and so judicious technical decisions will need to be made.
I strongly agree with your last point and I am advocating for a "+CS" track here at Montana State, where non-CS majors can learn enough practical CS to be productive and then excel in their own major. I'm speculating a 3-4 class track with AI/vibe coding as part of it.
As someone who just started university studying CS as well, I really appreciate you writing this blog. I recently went into a bit of a p(doom) spiral worrying about CS, uni and maybe sort of an existential crisis and I had an discussion on HN with a more experienced person about it which went into similar topics[0]
Also, I wish for your son to have a good university experience and hope he makes great friendships and connections which help him throughout his life and I wish the best for his future and to enjoy the present as it happens :-D
Thanks for these insights. They made me think of AI as what a mechanic is for your car. He knows more and is more capable than you, and he can save you a lot of time vs if you had to do the dirty work yourself.
However, the more you know yourself about car maintenance, the more you will trust his diagnosis, solutions and the fairness of the money he asks for it. More generally, the more you will trust him to act in your interest instead of only his (or someone else's).
> I think that knowing how code (and technical systems) work is going to continue to be valuable and perhaps even more valuable.
I think the art of refactoring will be more valuable than ever.
I'm having an LLM free day today, going through a lot of generated code, de-duplicating and making the abstractions more usable. It's quite enjoyable and improves my understanding of the code significantly.
Out of school for awhile, but covering low-level topics, down to logic gates, assembly, and doing floating point math manually, is not something I _use_ every day, but was crucial both when programming in higher level languages, and now using AI tools to write code in higher level languages.
It feels like there will be a beefy "middle" where people can probably drop some of that context, and get a lot of productive things done with AI. But there will still be a need for people more deeply knowledgeable and educated. It's probably just not in the proportions we have today.
_Kind of_ like the boom of coding bootcamps. A lot of people got good work done going through a coding bootcamp, but didn't get the deep background that a CS major would.
Coding bootcamps didn't mean we don't need CS education, and neither will AI, I expect. But the numbers and jobs are definitely going to change.
Thanks for your thoughts! Can you explain why in your model being able to read code will stay any more important for tomorrow's coders than it is for today's managers? Is it resting on the assumption that tomorrows models will be worse at that than tomorrows coders?
It’s good but I kinda disagree with them stuck issue. Getting stuck is frustrating and having an easy way to get unstuck seems good.
However, the skill of having to try many different things and have patience and deal with an unproductive day and sleep in stuff, being able to pull yourself out of a hole, bootstrap deeper understanding in times when you feel helpless…it’s character building and incredibly valuable.
I feel like AI will allow people to have less resolve and determination, like looking at the crossword answers.
Yeah. I have worked with people who have a very low threshold for struggling and reach out the moment something isn't obvious. They never learn anything. They can go for years and years never growing or improving in any way.
The problem is AI lowers all barriers to reaching out. Previously you'd have to ask a real person, which might be embarrassing. I do wonder if I would have struggled as much if I didn't have to. I look at what's happened to people's bodies when they no longer have to do physical labour and I wonder if the same thing will happen to their minds.
The struggle is necessary to grow, sure. But we're free to choose and upgrade our struggles. After calculators and then computers, struggle in math levelled up.
Yes, but they're still going to encounter those moments, just at different points.
The same way we never stopped encountering "Wait, what the hell?" moments when we had the internet and could search for problems instead of digging through textbooks or --help, they'll just run into those blocking moments at a higher level of abstraction, then have to backtrace the problem down to the level they need to understand to resolve the issue. Curious people continue to be rewarded with a higher ceiling, but the floor to get something functional is brought down.
The alternative is that AI just deletes software engineering as a discipline and everything gets vibecoded, which still seems unlikely even if the improvements continue to accelerate.
So even if the improvements continue to accelerate, even when you get to a point when an agent not just codes but also designs, optimizes for complexity and maintainability, you don't think software engineering as a human discipline gets deleted?
I am in a similar position. My son is a talented high school programmer considering colleges. He has expressed Anti AI sentiment to me. This article gives us a useful lens and I appreciated it a lot.
Thank you for the article but what about students who truly have no connections? It seems like a bleak time for us, none in my family work in even a corporation that would need tech people and my friends are in similar boat.
Luckily I was able to complete an internship lately (implemented EEVDF scheduler for Redox OS) but even then, the amount of Rust Junior jobs are so rare that it is proving to not be of much help.
"friends" is not limited to people that you grew up with, or studied with, or people that your parents knew. They can also be contacts that you made by reaching out, in social circles or through shared interests or tecnhical workshops, etc.
I think you’re underestimating how bad the job market is right now, everything else I kind of agree with. You should spend a few months applying to jobs (even if you don’t need one), just to see how dire it is out there. I’ve been working almost 20 years and the last 6-7 have been brutal job market but the last year has been extra-brutal. Another thing you may be discounting: your network connections don't go very far if most of them have retired or left the industry.
> Is Coding → Prompting like Assembly → High Level Coding? […] I do not agree with this simile. Compilers are, for the most part, deterministic in a way that current AI tools are not.
It’s not quite about the determinism. It’s about being able to reason about the relationship between source code and compiled program with formal precision. You can predict which changes in the source code will lead to which exact changes in the behavior of the compiled program. The same isn’t the case about changes to an LLM prompt and the LLM’s output.
You could make an AI deterministic by fixing its source of randomness. That still wouldn’t allow you to reason about how its output will change when (for example) you add or remove a word in the prompt. The only way to find out is to run the LLM (= have the prompt run through the model and observe what comes out).
That is the fundamental difference. Changes to source code have predictable and reason-able outcomes. You generally don’t have to compile the code and test it to know how precisely the change will affect the behavior of the compiled program according to the semantics of the programming language. That’s the case even if the compiler uses some probabilistic heuristics for trade-offs in code generation, and hence isn’t deterministic on the machine code level.
To repeat, the difference is how you can reason about a compiler’s behavior versus an LLM’s behavior. Programming languages are designed such that you can reason about it. With LLMs it’s always an experiment.
But you're comparing vibe coding to using a compiler. This is an important comparison but you don't need to use LLMs this way; that's why, I think, senior engineers are more effective with LLMs than juniors.
When coding, a few things are happening. You build a representation of what you want to achieve in your head and translate that to code, aka "typing the code", which is actually a pretty complicated process but certainly not all of the entirety of the software engineering process. Then you review what you wrote and commit.
With LLMs you still maintain steps 1 and 3. you reason about the solution, translate it to English and then let the LLM do the "typing the code". Finally you review the output.
The output review is completely deterministic and you have the opportunity to even tweak the LLM's output to match your mental model. The nondeterministic nature of the LLM isn't super relevant because it just changes how much work you do in this step. At this point it's just like standard coding minus the typing. Ultimately it's still an objective relationship with the compiler. It's very much like how tech leads engineer a system through their teams.
Assuming that you truly understand and own every line of the LLM's output, the model is almost working like a macro.
You can vibe code without knowing what a function or a variable is. What is an int vs a bool vs a string. You can absolutely build something useful with today's technology without knowing how any of it works underneath. If you know how it works underneath you'll have a leg up on someone who doesn't, but what's the opportunity cost of knowing how that all works underneath. What are you missing out on and not learning while you're learning and reasoning about the aforementioned 1 & 3?
You can build lots of interesting things now without understanding the code, but the maximum complexity of what you build will always be defined by what the latest model and harnesses are capable of without architectural guidance.
If whatever you built is good enough for you, then the model was ipso facto sufficient. This has been true for many small projects since the first coding agents came out over a year ago.
It comes up a lot, it's almost not worth arguing as it detracts.
I might take on to saying that compilers are more deterministic than vibe coding, that should stop the vibecoders from arguing about how technically 1+1 is not deterministic because of UB in C or whatever.
That said, they'll probably start debating that something is either deterministic or it isn't, and we can answer that they couldn't be more wrong, and they'll answer that wrong is an absolute state and not subject to gradation, , and we can answer that of course it's relative, it's wrong to say a tomato is a vegetable, but it's more wrong to say it's a suspension bridge, and then we can finally go to bed because the online arguments have all been solved, the end, it's done.
only a Sith deals in absolutes. There's a big difference in the strength of the connection from input to output between LLM edits and writing the code.
Not in full generality, of course, because you can formulate an LLM as a program, so LLM behavior is a subset of program behavior. But we generally strive for writing programs such that we can reliably reason about their behavior. We don’t always succeed (it’s the topic of software engineering how we can succeed), but it’s close enough, and enabling that is what programming languages with precise semantics are designed for. With LLMs, on the other hand, there is no path to such reliable reasoning on their behavior.
I think this narrow view on determinism comes up a lot. Essentially any program can be made deterministic over single inputs by fixing all side-inputs. But there is determinism over classes of inputs too, eg. an algorithm given input X deterministically outputs X+1.
I think the wider view is usually what people mean when they talk about nondeterminism in LLMs. Maybe because computers are traditionally so deterministic the wide view is almost taken for granted by programmers.
It's not the narrow view, it's the only actual definition of determinism. Words have meaning. Determinism means "same cause = same effect". If the cause is underspecified and requires interpretation that varies depending on the interpreter, the whole concept is meaningless. Intelligence (human or machine) operates in an underspecified domain, it makes sense to talk about undefined behavior, misinterpretation, alignment, anything really, but not determinism.
Random number generators are deterministic. If you give it the same seed, you get the same result. But that does not mean that a human can predict, for a new seed, what the result will be.
Another thing about compiler, if your input(source code) is stupid and not follow the expected format, it will outright refuse to generate output for you, no matter how much you ask or whatever trick you pull.
With LLM, if your input is stupid, the llm may/may not nudge you and happy to continue with that input and gives it 100% effort.
I think the correct word to use is "chaotic", in the mathematical sense (e.g. double pendulum).
A tiny change in the inputs can result in a large (and hard to predict) change in the output. Non-determinism is a different axis completely, and some compilers are (semi-accidentally) NOT deterministic either (two runs are not byte identical)
Thank you for this; I think you've hit on a problem I have explaining this point. I tend to lean on the determinism aspect, but it never felt right.
As a sibling commenter said, I agree that the concept here is "chaotic". A small change in the input (the prompt) can create large (or not!), unpredictable changes in the output. And variations on that small input change can have wildly different effects on the output.
But a change (large or small) to C code will create predictable (large or small) changes to the assembly output.
I think you're wrong, the compilers are already unpredictable (or chaotic, better to say than nondeterministic, as someone pointed out). However the classical compilers limit the effect of unpredictability to resource use (such as CPU, memory and binary size), and not the "result" of the program.
Although even program results are not guaranteed, famously C standard leaves some things undefined and up to implementation.
So the analogy works as long as you understand that natural language itself (aka the prompt) doesn't give complete specification, and it's the LLM itself which selects a particular formalization. But in principle it's not much different from compiler electing to use an optimization and making program faster. Or using a particular flavor of stdlib.
In fact today even the execution itself is unpredictable. For example, a different input can cause cache eviction or branch misprediction, making a loop much slower. Or a different thread might execute on hyperthreading core, affecting the performance.
I think with LLMs, we will be in a long tail of finding those scenarios (where natural language leads to big misunderstanding) and fixing them.
Either we'll still need humans with an understanding of the code to oversee the agents and guide the overall architecture
or
Agents will be able to do the oversight as well, and humans truly need to do almost nothing. But if LLMs are capable of that, they will also be capable of virtually any other job, and the entire way we think about the ecnomy and work is going to fundamentally change.
I don't really see a middle ground where AIs can take over every aspect of software development but not other fields. Maybe blue collar work will remain, assuming the ability to create virtually infinite amounts of software doesn't lead to major advances in robotics. Either way, there is no reason for software engineers to be uniquely worried, at least over the long term.
How many people will we need in those positions of oversight, though? If the demand doesn't expand we might see 95% of developers out of work regardless
I agree with basically everything said here, BUT i wish people would stop (mis)using the word "deterministic" in this way:
> Compilers are, for the most part, deterministic in a way that current AI tools are not. Given a high-level programming language construct such as a for loop or if statement, you can, with reasonable certainty, say what the generated assembly will look like for a given computer architecture (at least pre-optimization).
> The same cannot be said for an LLM-based solution to a particular prompt.
This is the correct and meaningful difference to point out here, but it has nothing to do with determinism. LLMs could be perfectly deterministic and still suffer from the same problem. The problem isn't that LLMs themselves are nondeterministic, it's that language is imprecise, and language models themselves are (for the most part) black box text processors. An imagined piece of functionality ("feature") has to pass through both of these somewhat opaque steps before it ends up as code, unlike code that is processed by a compiler, where both the constraints and the structured /formal understanding of the input are much stronger which allows us to reason about and trace the relationship between inputs and outputs in ways that we can't for LLMs and natural language.
> I do think AI is going to change computer programming. Not as dramatically...
Well, academia is the last industry that is going to change.
People pay for education regardless of how employable they're in the end. So the whole field is pretty much detached from the rest of the world. They're not interested in change, it would undermine their job security.
My employment has been terminated multiple times in the past. I _had to_ change. There is no other way to be marketable.
Academia is not that. Their business is to fill you up with obsolete tech and take your money. Don't trust them.
I read this when it first came out (Feb 2026) - I agreed with it then, and I still agree with it now. But I also just think that knowing the fundamentals is important, some people really believe we're "skipping a step" and that won't be important. Either way, people who already have good fundamentals are probably going to be using them WITH LLMs, and it doesn't take a ton of practice to "keep up" with fundamentals (see an expert jazz guitarist play a C scale, rudiments come back quickly when they're engaged).
Are people still writing any code by hand? My VP doesn't even READ code anymore. I rarely write code, but I've found a great spot between "full offloading" and staying really in tune with the "actions" I'm taking as together they form the "whole" deliverable at the end of a project / task. I still try to understand what the problem is, I draft a solution to solve it, then sometimes I'll give that solution to AI, and other times I'll compare my solution with the AI solution.
But, for the most part, I believe I'm somewhere in the middle? (Yes it's faster to use AI to generate code, but I still want to see that code when it's done and make sure it matches the broader system)
I'm mostly curious what other devs experience is...
I write everything by hand still. I don’t believe speed vs quality trade offs are worth it. Somehow I’m still shipping as fast as my peers. Where LLMs have saved me time is in research and finding the right documentation.
You should be careful. It’s not just about being faster. LLMs can write more tests, more reliably, and find things that must be changed following a change that you might overlook, and find contradicting requirements so much better than humans. You can probably keep up in terms of speed , though I doubt it for nearly every programmer I’ve ever met including myself… but almost certainly not with the same level of quality and thoroughness, despite what people on HN seem to think.
I’ll be ok, I produce higher quality work than any LLM ever will. And if that time ever comes, which I seriously doubt, it’s not like it’s that hard to prompt.
LLMs will hallucinate edge cases or worry about things that just aren’t possible within context. It results in more tests than are needed. I personally dont think LLMs are any good at all.
A month ago I was still talking like you. Then I said to an insisting colleague, “watch I’ll try to vibe code a game engine and show you the crap it produces.”
Granted, this wasn’t my first game engine so I knew exactly what to say, but I was completely floored. GPT Sol & Astra at max effort was flawless at nearly everything I threw at it. I’m talking fully ground up, zero dependencies, just the primitives and SIMD. Fully featured engine done in two weeks with deferred 2-stage render pipeline, shadow maps, mesh shaders, MSAA, post processing, collision, physics, the works.
I even intentionally skipped a few important optimizations and went back to refactor them in, thinking there’s no way it can do a wholesale rewrite of major systems, but it did it. I got dry mouth from all the jaw dropping. My prompts got shorter and more ambiguous, so it would ask me clarify. I audited every line of code, and it was good (after adding two skills.md). I gave up. I’m a reluctant believer.
It sucks, but sadly these things are really good. Don’t be last contrarian, there’s nothing to gain. You’re just lying to yourself
This is exactly the approach I’m limiting myself to: LLMs as a very smart rubber duck to assist in research and understanding complex systems. I have no interest in it writing the code for me, just like I have no interest in another person doing the same.
I am the engineer, I am the one that has the vision, and I am the one that needs to understand the thing down to the minute details.
That said, most systems I still write are not so complex I need a very smart assistant, so I rarely use LLMs at all; it is still a valuable skill being able to research and think hard for yourself. An LLM cannot think out of the box (of its training dataset), and there lie the discoveries and paradigm shifts that move tech forward.
I really and unironically applaud you, when the code you're writing has higher quality than the average AI produces AND it means something.
In the domains I get paid to work in, it simply doesn't matter.
The code was shit to begin with, because of hundreds of hacks due to underspecified or simply wrong requirements, bad code practices, architecture that couldn't keep up but was never fixed due to stubbornness...
Not saying we humans would do better or worse in general, just sharing my experiences.
I have customers where AI usage is absolutely forbidden and others where it's totally fine and colleagues vibecoded mess will come to bite them/us all.
I enjoy programming and producing high quality work. Why would I want to give up the thing I find fun and produce something subpar?
> The code was shit to begin with, because of hundreds of hacks due to underspecified or simply wrong requirements, bad code practices, architecture that couldn't keep up but was never fixed due to stubbornness...
My coworkers have always produced slop, even before LLMs. Unfortunately, as the lead on the project it’s still my responsibility to get that up to a certain quality level or at least make it isolated and malleable enough that it can be changed and we all won’t have a bad time doing it.
I guess what I’m saying is.. I get it. It’s hard to work with other people who are just pushing whatever is given by the LLM. But I still have fun doing it myself.
I could keep pace until about half a year ago. But it meant hands-on typing code for the full work day. Now with claude I can produce similar output in 1-2 hours, most of the time is spent on iterating and having the LLM review the code and fix it by itself and then me testing everything. There is more risk of letting the LLM make judgements and building the wrong thing and me having a smaller chance of discovering holes in the requirements because claude is happy to confidently make the wrong decisions.
> I explain that, if they don’t write the code, they will not be able to effectively read the code. The ability to read code is certainly going to be valuable, maybe more valuable, in an AI-based coding future.
I'm not certain of this. Thinking back to when I first started in my career after graduation- I remember feeling like my ability to write code had improved greatly during my time in school. Meanwhile, my ability to read code felt like it had barely improved at all. Even now, after over a decade in the industry, while both skills have improved tremendously, I still feel like my ability to read and internalize code is not at the level I would like or assume it to be simply as a result of my experience.
It could very well be that reading and writing are two separate (though related) skills that require intentional practice and honing on their own. I can't speak for everyone, but reading code as a skill, for me, only really began to develop once I had a job where it was expected of me.
Maybe it's possible to learn to read code without learning to write it. It certainly feels like its possible to learn to write it without learning to read it.
Not GP, but the main thing is that there is always some conceptual model being a good codebase. Meaning there’s the problem, then a given set of data structures and algorithms that forms a solution for that model.
It’s often hidden behind the syntax and implementation because of the layers of abstraction. A single operation (semantic wise) may be scattered over many statements, and some definition may be important in several subconcepts. It helps to be familiar with various technical concepts as possible. basic data structures like lists and trees, more advanced concepts like scheduling and concurrency, as well as platform concepts like files, process, networking,…
Why? Because they are implementation details that distract from the main conceptual model. It’s like how OpenBSD handle device discovery and configuration. Once you know that it’s a tree, you just need to remember how you build a tree and then most of the code are obvious. You can then discern the traversal stuff from the actual device configuration easily and know how to focus your reading.
I don’t think so. I strongly believe that writing and reading is pretty much the same, because they are strongly related to thinking. They are even secondary to the latter. I often interacted with juniors and other colleagues and those that do have issue with writing and reading often struggle with formalized thinking.
Taking a problem or a wanted behavior and dissecting it down to logical manipulation is hard for those people. They can go down one or two layers but then they got lost while building the necessary abstraction. You can observe it pretty much in real time as they’re losing track of assumptions for the current context. Thinking that way is a skill and once you can do it, reading and writing code is pretty much effortless.
Both learning to write and learning to read is merely a proxy of learning to think. Doing one while not doing the other is handicapping yourself for no reason.
Strong agree. School had me writing stuff myself on the order of a few KLOC at most, and maybe collaborating with a "group" in which at most 2 people actually did anything. What little exposure I got to reading a large codebase I didn't write, was all in personal projects trying to mod open source video games. I'm sure some people had more extensive experiences but that was my bachelor's.
First job had me using a programming language I wasn't super familiar with and trying to add a feature to a codebase 100s of KLOC, all written by other people. Definitely a sink-or-swim moment. My skills of reading and navigating the dreaded Other People's Code were all honed over the next dozen years.
That being said AI is a lot better at reading code than I am, as demonstrated by its ability to find incredibly subtle bugs in huge codebases. So I'm not even sure those code reading skills are all that useful now. When I have to review somebody else's code I get more mileage from pointing an AI at it and asking targeted questions like "how does this handle when a Foo's approval is revoked" than reading it myself line-by-line. I'm not saying I never use those reading skills but the ability to get the big picture, chase down deep callback chains, know where to look... those skills are likely to atrophy.
It's like using GPS vs. knowing the roads as well as a cabbie. GPS gets you pretty damn far for zero effort.
Reading code is very hard because you have to build a mental model from code that others wrote. You’re trying to understand what they wrote, the intent behind that, and what’s wrong or missing - that’s just a fundamentally hard thing.
But building mental models based on data and communications from others is one of the most valuable problem solving and communication skills there is in business, precisely what Carson is getting at in his essay.
Reading code was always much harder than writing it and it's certainly the root of many NIH syndrome disasters. Writing helps, but you're right that these are two seperate and related skills.
Don't think you can be a mature developer unless you can fluently read code. I tell everyone learning to code that reading code is equally important. In our world of AI tools reading code is turning out to be a key skill.
Yeah I agree that reading is a different skill from writing, especially reading someone else's code - I think doing code reviews is a great and valuable skill that should be taught alongside but separately from writing code. Can you reason about someone else's code without immediately rewriting it or jumping to "Well I would have written it differently"?
It's an important skill to learn, as a lot of software developers enter the market as "selfish", thinking they should understand and / or own all code, and if there's too much code or too many other people, they will advocate for microservices so they can once again own their slice of code.
But that's coding; software engineering is coding at scale, over time, and for the last two you need a different (albeit complementary) skillset of both hard and soft skills (hard skills being reading / understanding / reasoning about code, soft skills being letting go of your own ego and giving constructive feedback)
The one thing that we should look at given recent advance in maths using lean is, computer science will ( and should be ) used to create appropriate language for other fields ( biology, process, chemistry, games, movies etc ). ( hammer / nail analogy ). Science <-> Engineering used to be about representing anything in math so as to define and solve it, now onwards it will be about representing it in a language.
> Some people say that the move from high level languages to AI-generated code is like the move from assembly to high level programming languages.
> I do not agree with this simile.
I spent a while believing that the transition to AI-based development was similar to the shift to lower → higher level programming languages. However, like the author I now believe that this is an apples to oranges comparison, albeit with a slightly different take.
Chiefly it's because working with an LLM is working with output that is stochastic by nature and involves a different kind of broader, systems kind of thinking. The LLM ultimately outputs a deterministic product: code. You can decide (as a junior or newcomer) if you want to understand the code, or not.
I don't think it will matter that much in the end -- in the general sense -- whether software developers take it upon themselves to understand code though. I think if you want to become a well-rounded craftsperson or a "true engineer", you are always doing yourself a service to understand inner workings and "how the sausage is made".
Plenty of roles today which are instrumental to software products do not rely on code understanding. Product managers, Product designers, Designers (in general).
Somebody who designs an object or appliance made by injection-moulding plastic doesn't need to understand how to create moulds or make a model using wood -- but it sure helps them, as a thinking person, understand their products and the world better.
212 comments
"Master, should I still learn to weave our beautiful Persian rugs by hand?"
"Yes, and... Have you seen one of these mass-produced rugs? They all look the same and their quality is terrible! And how would you ever operate one of those new machines if you don't know a good rug from a bad one? By learning to weave manually, you are also learning about choosing the right yarn, negotiating the right prices with the merchant down at the market, selecting a good apprentice to pass down the trade. All these things will always be useful!"
Yes, there are still artisans making and selling beautiful rugs at premium prices. But most people now are content with resting their feet on a cheap Ikea thing that they can replace every few years, so that market has shrunk to almost nothing.
If handmade one appears it is as some centerpiece, and remaining ones are machine-made.
Some of those will go on to be successful and need technical people to support it
... and I'm reminded of all the folks that have Accounting degrees. Their degrees ended up being proof that they could track a lot of rules.
That proof meant they got hired and their job was not to ... "account", but to "fit into our business".
Perhaps that's the majority of CS folks going forward?
"Your CS degree proves you can help me not get stuck in technical problems so I can go solve [business/engineering/scientific/...] problems"...?
Software... a lot of software is basically the same thing (database, api, frontend), the only difference is what data and business rules. But the act of writing code isn't very different. It's the what code to write where software engineers come in.
The "only" difference? Wow.
What's left is a lot of very different software which have very few things in common.
If creation of customized software solutions is consistently getting cheaper and good enough in quality, the near future is about creating much more custom solutions for considerable smaller customer or consumer groups.
Mind that we still need people who understand tech and verify that a system does what it claims to do, in a safe and efficient way. Every non-technical vibe coder will at some point realize, that he maybe can prompt away every problem he has, but that is still considerable effort and also includes all the mistakes a professional already eradicated from his habits. Many vibe coded projects will also collapse under their own weight, rethinking a strategy - with tech in mind - is also professional effort.
Even if LLMs would produce perfect, high quality code all the time, instructing the "perfect" prompt is still a human problem. LLMs cannot mind read and fully understand the environmental and social circumstances. Understanding these things and model them into solutions, are also human problems.
All this still requires profound technical knowledge, even more now considering security is under fire.
Microsoft just introduced MXC:
"...for running untrusted code (model output ..."
https://github.com/microsoft/mxc
Spinning jennys were neat but if theyd been invented in a world where use of star trek replicators was routine I think theyd be more curiosity than revolutionary.
Artisinal code would definitely die off if the cp command didnt exist though.
Yes, and it’s worth pointing out the class of people buying ikeas rugs were NOT buying Persian wool/silk rugs before…they had bare floors or make coverings out of cloth or woven grass.
Also worth pointing out that since 1979, regardless of whether it is secondhand or not and which country you are procuring it from, rugs made in Iran (Persian rugs) have been totally banned for import to the U.S. Tribal rugs now come more from places like Turkey and India. So the market is being extremely artificially suppressed, boosting ikea rugs even more.
My own son has just started university studying CS, so I have skin in this game.
I continue to believe in what I've said in this article despite being startled (like most people) by the advances in AI recently.
One thing that I have noticed since writing this article is that the most effective vibe coders are already excellent developers, which I think is in keeping with the themes I discuss here. While I do expect the amount of hand-written code to decline, I think that knowing how code (and technical systems) work is going to continue to be valuable and perhaps even more valuable. I have no crystal ball, but that's what I'm seeing right now.
I agree there is little moat around code qua code now. I'm not sure that means there will be fewer coders, because the people in the best position to take advantage of this new technology are... coders.
I again agree that code qua code is becoming less valuable, but I think that ironically _understanding_ code (and systems) is going up in value. Complexity still grows super-linearly and so judicious technical decisions will need to be made.
I strongly agree with your last point and I am advocating for a "+CS" track here at Montana State, where non-CS majors can learn enough practical CS to be productive and then excel in their own major. I'm speculating a 3-4 class track with AI/vibe coding as part of it.
Also, I wish for your son to have a good university experience and hope he makes great friendships and connections which help him throughout his life and I wish the best for his future and to enjoy the present as it happens :-D
[0]: https://news.ycombinator.com/item?id=49981023
TA meaning...
However, the more you know yourself about car maintenance, the more you will trust his diagnosis, solutions and the fairness of the money he asks for it. More generally, the more you will trust him to act in your interest instead of only his (or someone else's).
The edge in the AI future will be ownership.
I think the art of refactoring will be more valuable than ever.
I'm having an LLM free day today, going through a lot of generated code, de-duplicating and making the abstractions more usable. It's quite enjoyable and improves my understanding of the code significantly.
It feels like there will be a beefy "middle" where people can probably drop some of that context, and get a lot of productive things done with AI. But there will still be a need for people more deeply knowledgeable and educated. It's probably just not in the proportions we have today.
_Kind of_ like the boom of coding bootcamps. A lot of people got good work done going through a coding bootcamp, but didn't get the deep background that a CS major would.
Coding bootcamps didn't mean we don't need CS education, and neither will AI, I expect. But the numbers and jobs are definitely going to change.
However, the skill of having to try many different things and have patience and deal with an unproductive day and sleep in stuff, being able to pull yourself out of a hole, bootstrap deeper understanding in times when you feel helpless…it’s character building and incredibly valuable.
I feel like AI will allow people to have less resolve and determination, like looking at the crossword answers.
The problem is AI lowers all barriers to reaching out. Previously you'd have to ask a real person, which might be embarrassing. I do wonder if I would have struggled as much if I didn't have to. I look at what's happened to people's bodies when they no longer have to do physical labour and I wonder if the same thing will happen to their minds.
The same way we never stopped encountering "Wait, what the hell?" moments when we had the internet and could search for problems instead of digging through textbooks or --help, they'll just run into those blocking moments at a higher level of abstraction, then have to backtrace the problem down to the level they need to understand to resolve the issue. Curious people continue to be rewarded with a higher ceiling, but the floor to get something functional is brought down.
The alternative is that AI just deletes software engineering as a discipline and everything gets vibecoded, which still seems unlikely even if the improvements continue to accelerate.
Luckily I was able to complete an internship lately (implemented EEVDF scheduler for Redox OS) but even then, the amount of Rust Junior jobs are so rare that it is proving to not be of much help.
In all seriousness though, thanks for writing this, I found it helpful.
It’s not quite about the determinism. It’s about being able to reason about the relationship between source code and compiled program with formal precision. You can predict which changes in the source code will lead to which exact changes in the behavior of the compiled program. The same isn’t the case about changes to an LLM prompt and the LLM’s output.
You could make an AI deterministic by fixing its source of randomness. That still wouldn’t allow you to reason about how its output will change when (for example) you add or remove a word in the prompt. The only way to find out is to run the LLM (= have the prompt run through the model and observe what comes out).
That is the fundamental difference. Changes to source code have predictable and reason-able outcomes. You generally don’t have to compile the code and test it to know how precisely the change will affect the behavior of the compiled program according to the semantics of the programming language. That’s the case even if the compiler uses some probabilistic heuristics for trade-offs in code generation, and hence isn’t deterministic on the machine code level.
To repeat, the difference is how you can reason about a compiler’s behavior versus an LLM’s behavior. Programming languages are designed such that you can reason about it. With LLMs it’s always an experiment.
When coding, a few things are happening. You build a representation of what you want to achieve in your head and translate that to code, aka "typing the code", which is actually a pretty complicated process but certainly not all of the entirety of the software engineering process. Then you review what you wrote and commit.
With LLMs you still maintain steps 1 and 3. you reason about the solution, translate it to English and then let the LLM do the "typing the code". Finally you review the output.
The output review is completely deterministic and you have the opportunity to even tweak the LLM's output to match your mental model. The nondeterministic nature of the LLM isn't super relevant because it just changes how much work you do in this step. At this point it's just like standard coding minus the typing. Ultimately it's still an objective relationship with the compiler. It's very much like how tech leads engineer a system through their teams.
Assuming that you truly understand and own every line of the LLM's output, the model is almost working like a macro.
I might take on to saying that compilers are more deterministic than vibe coding, that should stop the vibecoders from arguing about how technically 1+1 is not deterministic because of UB in C or whatever.
That said, they'll probably start debating that something is either deterministic or it isn't, and we can answer that they couldn't be more wrong, and they'll answer that wrong is an absolute state and not subject to gradation, , and we can answer that of course it's relative, it's wrong to say a tomato is a vegetable, but it's more wrong to say it's a suspension bridge, and then we can finally go to bed because the online arguments have all been solved, the end, it's done.
Can you really ?
I think the wider view is usually what people mean when they talk about nondeterminism in LLMs. Maybe because computers are traditionally so deterministic the wide view is almost taken for granted by programmers.
yells at cloud
a human can predict that the number that is generated will be suitably random.
a human can predict the result from a pseudo-random generator with enough knowledge of seed/program state/etc.
now I can't say this holds for a TRUE random number generator. nor do I know where we were going with this.
With LLM, if your input is stupid, the llm may/may not nudge you and happy to continue with that input and gives it 100% effort.
A tiny change in the inputs can result in a large (and hard to predict) change in the output. Non-determinism is a different axis completely, and some compilers are (semi-accidentally) NOT deterministic either (two runs are not byte identical)
As a sibling commenter said, I agree that the concept here is "chaotic". A small change in the input (the prompt) can create large (or not!), unpredictable changes in the output. And variations on that small input change can have wildly different effects on the output.
But a change (large or small) to C code will create predictable (large or small) changes to the assembly output.
Although even program results are not guaranteed, famously C standard leaves some things undefined and up to implementation.
So the analogy works as long as you understand that natural language itself (aka the prompt) doesn't give complete specification, and it's the LLM itself which selects a particular formalization. But in principle it's not much different from compiler electing to use an optimization and making program faster. Or using a particular flavor of stdlib.
In fact today even the execution itself is unpredictable. For example, a different input can cause cache eviction or branch misprediction, making a loop much slower. Or a different thread might execute on hyperthreading core, affecting the performance.
I think with LLMs, we will be in a long tail of finding those scenarios (where natural language leads to big misunderstanding) and fixing them.
Either we'll still need humans with an understanding of the code to oversee the agents and guide the overall architecture
or
Agents will be able to do the oversight as well, and humans truly need to do almost nothing. But if LLMs are capable of that, they will also be capable of virtually any other job, and the entire way we think about the ecnomy and work is going to fundamentally change.
I don't really see a middle ground where AIs can take over every aspect of software development but not other fields. Maybe blue collar work will remain, assuming the ability to create virtually infinite amounts of software doesn't lead to major advances in robotics. Either way, there is no reason for software engineers to be uniquely worried, at least over the long term.
> Compilers are, for the most part, deterministic in a way that current AI tools are not. Given a high-level programming language construct such as a for loop or if statement, you can, with reasonable certainty, say what the generated assembly will look like for a given computer architecture (at least pre-optimization).
> The same cannot be said for an LLM-based solution to a particular prompt.
This is the correct and meaningful difference to point out here, but it has nothing to do with determinism. LLMs could be perfectly deterministic and still suffer from the same problem. The problem isn't that LLMs themselves are nondeterministic, it's that language is imprecise, and language models themselves are (for the most part) black box text processors. An imagined piece of functionality ("feature") has to pass through both of these somewhat opaque steps before it ends up as code, unlike code that is processed by a compiler, where both the constraints and the structured /formal understanding of the input are much stronger which allows us to reason about and trace the relationship between inputs and outputs in ways that we can't for LLMs and natural language.
Well, academia is the last industry that is going to change.
People pay for education regardless of how employable they're in the end. So the whole field is pretty much detached from the rest of the world. They're not interested in change, it would undermine their job security.
My employment has been terminated multiple times in the past. I _had to_ change. There is no other way to be marketable.
Academia is not that. Their business is to fill you up with obsolete tech and take your money. Don't trust them.
Are people still writing any code by hand? My VP doesn't even READ code anymore. I rarely write code, but I've found a great spot between "full offloading" and staying really in tune with the "actions" I'm taking as together they form the "whole" deliverable at the end of a project / task. I still try to understand what the problem is, I draft a solution to solve it, then sometimes I'll give that solution to AI, and other times I'll compare my solution with the AI solution.
But, for the most part, I believe I'm somewhere in the middle? (Yes it's faster to use AI to generate code, but I still want to see that code when it's done and make sure it matches the broader system)
I'm mostly curious what other devs experience is...
In fact, sometimes LLMs write too many tests to the point it significantly slows down your test runs and CI!
LLMs will hallucinate edge cases or worry about things that just aren’t possible within context. It results in more tests than are needed. I personally dont think LLMs are any good at all.
A month ago I was still talking like you. Then I said to an insisting colleague, “watch I’ll try to vibe code a game engine and show you the crap it produces.”
Granted, this wasn’t my first game engine so I knew exactly what to say, but I was completely floored. GPT Sol & Astra at max effort was flawless at nearly everything I threw at it. I’m talking fully ground up, zero dependencies, just the primitives and SIMD. Fully featured engine done in two weeks with deferred 2-stage render pipeline, shadow maps, mesh shaders, MSAA, post processing, collision, physics, the works.
I even intentionally skipped a few important optimizations and went back to refactor them in, thinking there’s no way it can do a wholesale rewrite of major systems, but it did it. I got dry mouth from all the jaw dropping. My prompts got shorter and more ambiguous, so it would ask me clarify. I audited every line of code, and it was good (after adding two skills.md). I gave up. I’m a reluctant believer.
It sucks, but sadly these things are really good. Don’t be last contrarian, there’s nothing to gain. You’re just lying to yourself
I am the engineer, I am the one that has the vision, and I am the one that needs to understand the thing down to the minute details.
That said, most systems I still write are not so complex I need a very smart assistant, so I rarely use LLMs at all; it is still a valuable skill being able to research and think hard for yourself. An LLM cannot think out of the box (of its training dataset), and there lie the discoveries and paradigm shifts that move tech forward.
In the domains I get paid to work in, it simply doesn't matter.
The code was shit to begin with, because of hundreds of hacks due to underspecified or simply wrong requirements, bad code practices, architecture that couldn't keep up but was never fixed due to stubbornness...
Not saying we humans would do better or worse in general, just sharing my experiences.
I have customers where AI usage is absolutely forbidden and others where it's totally fine and colleagues vibecoded mess will come to bite them/us all.
> The code was shit to begin with, because of hundreds of hacks due to underspecified or simply wrong requirements, bad code practices, architecture that couldn't keep up but was never fixed due to stubbornness...
My coworkers have always produced slop, even before LLMs. Unfortunately, as the lead on the project it’s still my responsibility to get that up to a certain quality level or at least make it isolated and malleable enough that it can be changed and we all won’t have a bad time doing it.
I guess what I’m saying is.. I get it. It’s hard to work with other people who are just pushing whatever is given by the LLM. But I still have fun doing it myself.
I've always enjoyed it. In my spare time.
Also I wouldn't go as far to say that I myself produce higher quality code than my peers.
I am between a 5/10 and a 7/10 programmer at best.
I bring other valuable skills though.
No one who cares wants to. That's not the question.
The question is whether you can continue to get paid doing so.
I'm not certain of this. Thinking back to when I first started in my career after graduation- I remember feeling like my ability to write code had improved greatly during my time in school. Meanwhile, my ability to read code felt like it had barely improved at all. Even now, after over a decade in the industry, while both skills have improved tremendously, I still feel like my ability to read and internalize code is not at the level I would like or assume it to be simply as a result of my experience.
It could very well be that reading and writing are two separate (though related) skills that require intentional practice and honing on their own. I can't speak for everyone, but reading code as a skill, for me, only really began to develop once I had a job where it was expected of me.
Maybe it's possible to learn to read code without learning to write it. It certainly feels like its possible to learn to write it without learning to read it.
It’s often hidden behind the syntax and implementation because of the layers of abstraction. A single operation (semantic wise) may be scattered over many statements, and some definition may be important in several subconcepts. It helps to be familiar with various technical concepts as possible. basic data structures like lists and trees, more advanced concepts like scheduling and concurrency, as well as platform concepts like files, process, networking,…
Why? Because they are implementation details that distract from the main conceptual model. It’s like how OpenBSD handle device discovery and configuration. Once you know that it’s a tree, you just need to remember how you build a tree and then most of the code are obvious. You can then discern the traversal stuff from the actual device configuration easily and know how to focus your reading.
There's a perhaps subtle difference between possible and viable.
Taking a problem or a wanted behavior and dissecting it down to logical manipulation is hard for those people. They can go down one or two layers but then they got lost while building the necessary abstraction. You can observe it pretty much in real time as they’re losing track of assumptions for the current context. Thinking that way is a skill and once you can do it, reading and writing code is pretty much effortless.
Both learning to write and learning to read is merely a proxy of learning to think. Doing one while not doing the other is handicapping yourself for no reason.
First job had me using a programming language I wasn't super familiar with and trying to add a feature to a codebase 100s of KLOC, all written by other people. Definitely a sink-or-swim moment. My skills of reading and navigating the dreaded Other People's Code were all honed over the next dozen years.
That being said AI is a lot better at reading code than I am, as demonstrated by its ability to find incredibly subtle bugs in huge codebases. So I'm not even sure those code reading skills are all that useful now. When I have to review somebody else's code I get more mileage from pointing an AI at it and asking targeted questions like "how does this handle when a Foo's approval is revoked" than reading it myself line-by-line. I'm not saying I never use those reading skills but the ability to get the big picture, chase down deep callback chains, know where to look... those skills are likely to atrophy.
It's like using GPS vs. knowing the roads as well as a cabbie. GPS gets you pretty damn far for zero effort.
But building mental models based on data and communications from others is one of the most valuable problem solving and communication skills there is in business, precisely what Carson is getting at in his essay.
It's an important skill to learn, as a lot of software developers enter the market as "selfish", thinking they should understand and / or own all code, and if there's too much code or too many other people, they will advocate for microservices so they can once again own their slice of code.
But that's coding; software engineering is coding at scale, over time, and for the last two you need a different (albeit complementary) skillset of both hard and soft skills (hard skills being reading / understanding / reasoning about code, soft skills being letting go of your own ego and giving constructive feedback)
> I do not agree with this simile.
I spent a while believing that the transition to AI-based development was similar to the shift to lower → higher level programming languages. However, like the author I now believe that this is an apples to oranges comparison, albeit with a slightly different take.
Chiefly it's because working with an LLM is working with output that is stochastic by nature and involves a different kind of broader, systems kind of thinking. The LLM ultimately outputs a deterministic product: code. You can decide (as a junior or newcomer) if you want to understand the code, or not.
I don't think it will matter that much in the end -- in the general sense -- whether software developers take it upon themselves to understand code though. I think if you want to become a well-rounded craftsperson or a "true engineer", you are always doing yourself a service to understand inner workings and "how the sausage is made".
Plenty of roles today which are instrumental to software products do not rely on code understanding. Product managers, Product designers, Designers (in general).
Somebody who designs an object or appliance made by injection-moulding plastic doesn't need to understand how to create moulds or make a model using wood -- but it sure helps them, as a thinking person, understand their products and the world better.