Code has always been the easy part(laughingmeme.org)
laughingmeme.org
Code has always been the easy part
https://laughingmeme.org/2026/02/09/code-has-always-been-the-easy-part.html
147 comments
The literal writing of the code was hard. This revisionism about how we were all secretly shakespeare typing monkey scammers pulling the wool over the eyes of the economy drives me nuts. Choosing which words to put in the editor, how to express all these ideas in a limited syntax. That was the big skill.
Sure, writing a program that makes a machine kind of do something was easy. Lots of people can do that. But then you ship a mobile app to a billion users and discover that people are genuinely wired differently.
different cultures, different mental models, different expectations
Now you have to accommodate and express all of that complexity in a language whose only reader is a machine that tolerates zero ambiguity. And you have to do it in a way that other engineers can read, reason about, and build on top of without the whole thing exploding. That's not requirements gathering. Its literally writing it down
You're doing the thing where you read code like a fish breathes water and conclude it was easy to write. You can read a Nobel Prize novel in a weekend too. The readability is the achievement, not evidence it was trivial.
Edit: I got pretty heated about this and wrote up a proper rebuttal: https://promptless.ai/blog/technical/writing-code-was-hard-a...
Sure, writing a program that makes a machine kind of do something was easy. Lots of people can do that. But then you ship a mobile app to a billion users and discover that people are genuinely wired differently.
different cultures, different mental models, different expectations
Now you have to accommodate and express all of that complexity in a language whose only reader is a machine that tolerates zero ambiguity. And you have to do it in a way that other engineers can read, reason about, and build on top of without the whole thing exploding. That's not requirements gathering. Its literally writing it down
You're doing the thing where you read code like a fish breathes water and conclude it was easy to write. You can read a Nobel Prize novel in a weekend too. The readability is the achievement, not evidence it was trivial.
Edit: I got pretty heated about this and wrote up a proper rebuttal: https://promptless.ai/blog/technical/writing-code-was-hard-a...
I program for 20 years. More than half of my life. Some people forget how they felt as beginners, I did not. Which I know, since I teach programming as well.
As a beginner syntax is the hard thing, remembering how to write a thing. As a beginner you don't even think about structure, how to write maintainable or testable code — you're just happy it eventually works for you. Depending on the beginners character they might fall into the trap of thinking more complicated code using more advanced language features is a sign of a genius programmer.
When you're getting better you realize that writing the code is indeed the easy part and that you should avoid writing code that is too clever unless it is well localized and neatly tucked away. Writing clever code is something that does not impress you at all — quite the opposite as it is usually just unnecessary bragging. The hard part after all isn't writing clever code, it is finding good abstractions, staying consistent, writing maintainable and testable code without being too smart. It is understanding and then solving the real world problem in an elegant way. It isn't writing what the customer think they want, it is writing whst they truly need.
That does not mean actually writing the code isn't specialized work that requires skill. But it just isn't the hardest part of the job. Just like knowing how to use the tools isn't the hardest part for a car mechanic. Making sure that the car drives reliably, you chose the right parts, you did it fast and efficiently is.
As a beginner syntax is the hard thing, remembering how to write a thing. As a beginner you don't even think about structure, how to write maintainable or testable code — you're just happy it eventually works for you. Depending on the beginners character they might fall into the trap of thinking more complicated code using more advanced language features is a sign of a genius programmer.
When you're getting better you realize that writing the code is indeed the easy part and that you should avoid writing code that is too clever unless it is well localized and neatly tucked away. Writing clever code is something that does not impress you at all — quite the opposite as it is usually just unnecessary bragging. The hard part after all isn't writing clever code, it is finding good abstractions, staying consistent, writing maintainable and testable code without being too smart. It is understanding and then solving the real world problem in an elegant way. It isn't writing what the customer think they want, it is writing whst they truly need.
That does not mean actually writing the code isn't specialized work that requires skill. But it just isn't the hardest part of the job. Just like knowing how to use the tools isn't the hardest part for a car mechanic. Making sure that the car drives reliably, you chose the right parts, you did it fast and efficiently is.
I think we’re agreeing and likely have different understandings of what’s meant by “code wasn’t the hard part”. What you’re describing is what I’m calling the hardest part: building a system. To me that’s different from “coding”. This isn’t engaging in revisionist history. It’s why I’m referencing a book written 51 years ago, almost two decades before I was born,[0] and referring to a joke about systems design from ‘99[1].
0: https://en.wikipedia.org/wiki/The_Mythical_Man-Month?wprov=s...
1: https://www.laputan.org/mud/
Edit: This also isn’t to say that _millions_ around the world aren’t employed just to write code. This isn’t to say LLMs aren’t hugely disruptive. This isn’t even to say they aren’t also good at the hard parts. It’s just to say there’s a difference between coding and systems design and one is harder than the other in most cases in most jobs.
0: https://en.wikipedia.org/wiki/The_Mythical_Man-Month?wprov=s...
1: https://www.laputan.org/mud/
Edit: This also isn’t to say that _millions_ around the world aren’t employed just to write code. This isn’t to say LLMs aren’t hugely disruptive. This isn’t even to say they aren’t also good at the hard parts. It’s just to say there’s a difference between coding and systems design and one is harder than the other in most cases in most jobs.
Great writeup, that is all
>That’s not evidence the task was easy. That’s evidence it was so hard...
Are humans starting to adopt LLM patterns or was this was ironically written with an LLM?
That said, I'm surprised you didn't bring up Marx in your essay in the later sections. I vaguely remember he had some thoughts about derivation of value from labor vs "ideas/capital". Whether or not you agree, this debate is reminiscent of that just moved up one level to white-collar workers.
Are humans starting to adopt LLM patterns or was this was ironically written with an LLM?
That said, I'm surprised you didn't bring up Marx in your essay in the later sections. I vaguely remember he had some thoughts about derivation of value from labor vs "ideas/capital". Whether or not you agree, this debate is reminiscent of that just moved up one level to white-collar workers.
LLMs adopted human writing patterns, not the other way around.
This article is a coping mechanism. What it's really saying is this:
"The thing that LLMs are taking over is easy, we humans still have agency over the hard part."
That's what he's trying to say, and I can tell you, this is not true. Programming was the hard part. That's why we got paid so much. It's the easy jobs that are immune to AI: Gardening, construction work, blue collar jobs,... etc.
Mind you not easy in the sense that the work isn't hard, but easy in the sense that anyone can do it. Those are the jobs that are ironically safe.
"The thing that LLMs are taking over is easy, we humans still have agency over the hard part."
That's what he's trying to say, and I can tell you, this is not true. Programming was the hard part. That's why we got paid so much. It's the easy jobs that are immune to AI: Gardening, construction work, blue collar jobs,... etc.
Mind you not easy in the sense that the work isn't hard, but easy in the sense that anyone can do it. Those are the jobs that are ironically safe.
Programming is -relatively- the easy part.
Getting it right is much harder.
Knowing what to build is way harder.
Debugging is hard.
Dotting all the i's and crossing all the t's to get your product to ship can be hard.
Maintenance and support is hard, especially if the product is riddled with problems, but also just due to the passage of time.
Dealing with tech debt is hard.
Communicating is hard.
Getting it right is much harder.
Knowing what to build is way harder.
Debugging is hard.
Dotting all the i's and crossing all the t's to get your product to ship can be hard.
Maintenance and support is hard, especially if the product is riddled with problems, but also just due to the passage of time.
Dealing with tech debt is hard.
Communicating is hard.
Pedantics. all of that is programming.
And all of that AI can do it now.
And all of that AI can do it now.
Anyone can do construction, blue collar jobs? That hasn't been my experience with contractors.
I don't know about blue collar jobs but I sure know not everyone can do construction or gardening right. And it's hard to it right. I known, I tried.
Anyways, "programming" is a broad concept. It can be very easy or very hard, generalization makes no sense.
Anyways, "programming" is a broad concept. It can be very easy or very hard, generalization makes no sense.
Do you think someone un fammilar with coding can sit down with one of these agents that write software and end up with a running phone app?
> Do you think someone un fammilar with coding can sit down with one of these agents that write software and end up with a running phone app?
The people claiming that the coding was the easy part certainly believe it.
The people claiming that the coding was the easy part certainly believe it.
Yes. I don’t think this. I have seen this.
I'm definitely cheap when it comes to software costs, and I'm guilty of paying for big bills of mud.
This is completely different though. In the past I'd always go back to paid SaaS when the mud broke apart.
Not true for the past 18 months for me, I am developing features, maintaining code, all via natural language to a much higher standard than I've ever had in my business before.
A low bar, perhaps, but it's definitely not the same.
This is completely different though. In the past I'd always go back to paid SaaS when the mud broke apart.
Not true for the past 18 months for me, I am developing features, maintaining code, all via natural language to a much higher standard than I've ever had in my business before.
A low bar, perhaps, but it's definitely not the same.
It's so laughable that people now all claim programming has always been easy.
I give you a bunch of high school students with average grades and no programming experiences. How long do you need to educate them so they can implement a JPEG decoder from JPEG spec, without a reference library?
It's a 100% unambiguous task. One doesn't need to understand the math behind discrete Fourier transform to implement JPEG. It's just a 1 to 1 translation from the spec to code. Must be not so hard!
I give you a bunch of high school students with average grades and no programming experiences. How long do you need to educate them so they can implement a JPEG decoder from JPEG spec, without a reference library?
It's a 100% unambiguous task. One doesn't need to understand the math behind discrete Fourier transform to implement JPEG. It's just a 1 to 1 translation from the spec to code. Must be not so hard!
It's very obviously not "the easy part", it's definitely hard. It's just not the only hard part. And there may be other parts that are harder in some sense.
Something can be hard and also be the easy part. Imagine you got to see into the future and use a popular app before it was released, and you decided to make it yourself and reap the profits. Would be an absolute cinch to copy it compared to trying to make a successful app from a blank page.
Some code is hard. Most business logic (in the sense of pushing data around databases) isn't. The value is in analysis and action, which the system enablrs, not the machine itself.
Creating a high performance general purpose database is hard, but once it exists and is properly configured, the SQL queries are much easier. They'd better be or we wasted a lot of time building that database.
Creating a high performance general purpose database is hard, but once it exists and is properly configured, the SQL queries are much easier. They'd better be or we wasted a lot of time building that database.
Also totally depends on what kind of coding you are doing.
Yeah building a web app can become somewhat easy, but is distributed machine learning? What about low level kernel code?
Yeah building a web app can become somewhat easy, but is distributed machine learning? What about low level kernel code?
Still easy. You just have to learned different concepts. Someone in web needs to be familiar with databases, some protocols like HTTP, DNS, some basic Unix admin,.. Someone in low level kernel code will need to know about hardware architecture, operating system concepts, assembly,... But the coding skill stays the same mostly. You're still typing code, organizing files, and fiddling with build systems.
Different type of "coding skills" and different type of complexities make these two impossible to put into the same bucket of "still easy". You've probably never done the latter so you're under impression that it is easy. I assure you it is not. Grasping the concept of a new framework vs doing algorithmic and state of the art improvements are two totally different and incomparable things. In 30M population of software engineers around the globe there is only handful of those doing the latter, and there's a reason for it - it's much much more complicated.
You are conflating problem solving and the ability to write code. Web Dev has its own challenge, especially at scale. There’s not a lot of people writing web servers, designing distributed protocols and resolving sandboxing issues either.
I'm not conflating one with each other, I am saying that "coding skill" when dealing with difficult topics at hand is not just a "coding skill" anymore. It's part of the problem.
Not knowing C after a course on operating systems will block you from working on FreeBSD. Knowing C without a grasp on operating systems will prevent you from understanding the problem the code is solving.
Both are needed to do practical work, but they are orthogonal.
Both are needed to do practical work, but they are orthogonal.
Exactly but they are not orthogonal as you try to make them to be. That's just trivializing things too much, ignoring all the nuance. You sound like my uncle who has spent a career in the IT but never really touched the programming but he nevertheless has a strong opinion how easy and trivial the programming really is, and how this was not super interesting to him because this is work done by some other unimportant folks. In reality you know, he just cannot admit that he was not committed enough, or shall I say likely not capable enough, to end up in that domain, and instead he ended up writing test specifications or whatnot. A classic example of Dunning-Kruger effect.
There is a nuance in what you say. You say it is "still easy" but it is not. It is not enough to take a course on operating systems and learn C to start contributing to the operating system kernel in impactful way. Apart from other software "courses" that you need to take such as algorithms, advanced data structures, concurrency, lock-free algorithms, probably compilers etc. the one which is really significant and is not purely software domain is the understanding of the hardware. And this is a big one.
You cannot write efficient algorithms if you don't know the intricacies of the hardware, and if you don't know how to make the best out of your compiler. This cannot be taught out of the context as you suggest so in reality all of these skills are actually interwhined and not quite orthogonal to each other.
There is a nuance in what you say. You say it is "still easy" but it is not. It is not enough to take a course on operating systems and learn C to start contributing to the operating system kernel in impactful way. Apart from other software "courses" that you need to take such as algorithms, advanced data structures, concurrency, lock-free algorithms, probably compilers etc. the one which is really significant and is not purely software domain is the understanding of the hardware. And this is a big one.
You cannot write efficient algorithms if you don't know the intricacies of the hardware, and if you don't know how to make the best out of your compiler. This cannot be taught out of the context as you suggest so in reality all of these skills are actually interwhined and not quite orthogonal to each other.
I do agree with you that there's a skill tree for any practical work to be done. And nodes can be simple or hard. But even if there are dependencies between them, the nodes are clearly separated from each other and some are shared between some skill sets.
If you take the skill tree you need to be a kernel contributor, it does not take much to jump over to database systems development, or writing GUI. You may argue that the barrier entry for web dev is lower, but that's because of all the foundational work that has been done to add guardrails. In kernel work, they are too expensive so there's no hand holding there. But in webdev, often enough, you'll have to go past the secure boundary of those guardrails and the same skill node like advanced data structures and concurrency will be helpful there.
Kernel dev is not some mythical land full of dragons. A lot of the required knowledge can be learned while working in another domain (or if you're curious enough).
If you take the skill tree you need to be a kernel contributor, it does not take much to jump over to database systems development, or writing GUI. You may argue that the barrier entry for web dev is lower, but that's because of all the foundational work that has been done to add guardrails. In kernel work, they are too expensive so there's no hand holding there. But in webdev, often enough, you'll have to go past the secure boundary of those guardrails and the same skill node like advanced data structures and concurrency will be helpful there.
Kernel dev is not some mythical land full of dragons. A lot of the required knowledge can be learned while working in another domain (or if you're curious enough).
No, it's not mythical but it is vastly more difficult and more complex than the majority of other software engineering roles. Entry barrier being lower elsewhere is not something I would argue at all. It's a common sense. Unless you're completely delusional. While there's a lot of skills you can translate from system programming domain elsewhere there are not a lot of skills you can translate vice-versa.
The easy part and hard are not mutually exclusive.
Honestly, it really is the easy part of the job. Really truly.
It's difficult when you're first learning but there are definitely much harder skills to learn.
It's difficult when you're first learning but there are definitely much harder skills to learn.
[deleted]
99.9% of the code i write is easy, but that's just because of the sort of work i do. Its not far from basic CRUD. Maybe with pubsubs and caching thrown in for fun.
But that doesn't mean there isn't some tricksy stuff. All the linear algebra in graphics programming takes awhile to wrap your head around. Actually, game programming in general i find a bit hard. Physics, state management, multi threading, networking...
But that doesn't mean there isn't some tricksy stuff. All the linear algebra in graphics programming takes awhile to wrap your head around. Actually, game programming in general i find a bit hard. Physics, state management, multi threading, networking...
For most of the tricky stuff the hard part is thinking clearly. Deciding how to approach the problem, what to prioritize, etc
Translating that into whatever language you chose is not that hard.
Translating that into whatever language you chose is not that hard.
Right, the actual engineering part is hard. Typing out the code without botching syntax usually isn't very hard. Unless it's a C++ type with a dozen modifiers.
What's easy for some might be truly hard for others.
Sure; but I'm not humblebragging at how talented at coding I am. I'm good at it because I have a lot of practice and experience, but I'm hardly the best.
It's the easiest part because the hard parts of the job are everything else -- you're a knowledge worker so people look to you to make decisions and figure it out. You figure it out and make it work for whatever "it" happens to be.
It's the easiest part because the hard parts of the job are everything else -- you're a knowledge worker so people look to you to make decisions and figure it out. You figure it out and make it work for whatever "it" happens to be.
> It's the easiest part because the hard parts of the job are everything else -- you're a knowledge worker so people look to you to make decisions and figure it out. You figure it out and make it work for whatever "it" happens to be.
If you thought coding was easy, wait till you see the competition for knowledge workers. You're in a spot now where the part that made you valuable (implementing business rules in software) can now be done by virtually anyone.
Doing all the non-coding parts (or, as you put it, "the hard parts") can now be done by almost any white collar worker.
If you thought coding was easy, wait till you see the competition for knowledge workers. You're in a spot now where the part that made you valuable (implementing business rules in software) can now be done by virtually anyone.
Doing all the non-coding parts (or, as you put it, "the hard parts") can now be done by almost any white collar worker.
Sure, anyone with the knowledge and experience lol
"Knowledge worker" isn't a cutesy phrase, it means I don't get paid for my time, I get paid for what I know. Contrast that to, say, working retail where you are paid to staff the store from 8-6. It's not a value judgement (retail is hard work) it's a description.
We've already had years and years of predicting the death of software engineering to offshoring and that didn't happen for the same reason. India turns out plenty of fantastic engineers who can do my job. Those people also have better options than staffing some cut rate code factory, and you can't substitute the latter if you need the former. But nice try lol
"Knowledge worker" isn't a cutesy phrase, it means I don't get paid for my time, I get paid for what I know. Contrast that to, say, working retail where you are paid to staff the store from 8-6. It's not a value judgement (retail is hard work) it's a description.
We've already had years and years of predicting the death of software engineering to offshoring and that didn't happen for the same reason. India turns out plenty of fantastic engineers who can do my job. Those people also have better options than staffing some cut rate code factory, and you can't substitute the latter if you need the former. But nice try lol
> "Knowledge worker" isn't a cutesy phrase, it means I don't get paid for my time, I get paid for what I know.
What you appear to be missing is that (if AI coding is as good as we are told) there will considerably more people with the business knowledge to drive an AI to create their solutions.
The bit that made developers valuable was the ability to actually implement those business rules in software. You will be competing with all those laid off devs as well as those non-developers who have all that business knowledge.
In simple terms, there are two groups of people:
1. Developers, who have some business knowledge, and
2. White collar workers who have no development knowledge.
Previously (or currently, say) the supply of solutions providers came only from group 1. Now they come from both group 1 and group 2.
The supply of solutions providers just exploded, you can expect the same sort of salary that the people in group 2 get, which is nowhere close to what the people in group 1 used to get.
What you appear to be missing is that (if AI coding is as good as we are told) there will considerably more people with the business knowledge to drive an AI to create their solutions.
The bit that made developers valuable was the ability to actually implement those business rules in software. You will be competing with all those laid off devs as well as those non-developers who have all that business knowledge.
In simple terms, there are two groups of people:
1. Developers, who have some business knowledge, and
2. White collar workers who have no development knowledge.
Previously (or currently, say) the supply of solutions providers came only from group 1. Now they come from both group 1 and group 2.
The supply of solutions providers just exploded, you can expect the same sort of salary that the people in group 2 get, which is nowhere close to what the people in group 1 used to get.
Yeah, nah, that's just a complete misunderstanding of what SWEs actually do lol
I'm not a code factory who occasionally talks to the suits. That isn't the job lol
I'm not a code factory who occasionally talks to the suits. That isn't the job lol
> I'm not a code factory who occasionally talks to the suits. That isn't the job lol
The problem you are facing is that "person who talks to business" is a huge pool of talent, and now you have to compete with them. Previously your only competition was "person who talks to business and can code".
The problem you are facing is that "person who talks to business" is a huge pool of talent, and now you have to compete with them. Previously your only competition was "person who talks to business and can code".
Nope, those people are not competition lol. I get that you want that to be true for some reason, but it's not.
I do not get paid to write code. No software engineer does. The more senior the engineer, the less code they write.
I don't even really talk to the business folks, that's what a PM is for.
I already told you what I actually do, you're free to read it and learn. Or not, I ain't the boss of you
I do not get paid to write code. No software engineer does. The more senior the engineer, the less code they write.
I don't even really talk to the business folks, that's what a PM is for.
I already told you what I actually do, you're free to read it and learn. Or not, I ain't the boss of you
"I already told you what I actually do, you're free to read it and learn. Or not, I ain't the boss of you"
Nobody listens to someone who talks like this. Nobody learns from someone who talks like this. You're not a leader and you're not a very good software engineer and likely if you boss anyone around, they think you're a clown.
Nobody listens to someone who talks like this. Nobody learns from someone who talks like this. You're not a leader and you're not a very good software engineer and likely if you boss anyone around, they think you're a clown.
The people for whom I've seen "coding is the hard part" are typically promoted out of the way or fired. They never entered a flow like those who considered it easy and addictive. The latter are the pillars of the eng team.
I'm curious which skills you think are much harder than programming.
It depends on whether you mean programming (typing your solution into your text editor) or programming (formalizing your solution to a problem in a way that can be programmed).
Honestly? Anything that requires a lot of manual dexterity because that takes a long time to master, like a trade or art.
People love to lionize it, but honestly I can teach the basics of coding to anyone in a weekend. I love teaching people to code. It can be frustrating to learn but it's just not that difficult. I've mostly written Python and Ruby and Node for my career. They're not super hardcore languages lol.
What is hard is learning the engineering side. I don't get paid for the code I write, I get paid because I get handed a business wishlist and it's my job to figure out how to make that business reality and execute it, from start to finish.
I tell my boss what I'm going to be working on, not the other way around, and that's true pretty early in your career. At my current level of seniority, I can personally cost the company millions of dollars. That's not even a flex, most software engineers can do that. Learning to make good decisions like that takes a long time and a lot of experience, and that's just not something you can hand off.
People love to lionize it, but honestly I can teach the basics of coding to anyone in a weekend. I love teaching people to code. It can be frustrating to learn but it's just not that difficult. I've mostly written Python and Ruby and Node for my career. They're not super hardcore languages lol.
What is hard is learning the engineering side. I don't get paid for the code I write, I get paid because I get handed a business wishlist and it's my job to figure out how to make that business reality and execute it, from start to finish.
I tell my boss what I'm going to be working on, not the other way around, and that's true pretty early in your career. At my current level of seniority, I can personally cost the company millions of dollars. That's not even a flex, most software engineers can do that. Learning to make good decisions like that takes a long time and a lot of experience, and that's just not something you can hand off.
Totally. I would add that code that "works" it's easy to do. Code that it's efficient, easy to maintain and safe... That it's another story.
But the sad truth is that most software can be or it's done with shitty code that "kinda works" as long as the CPU it's fast enough.
But the sad truth is that most software can be or it's done with shitty code that "kinda works" as long as the CPU it's fast enough.
And if you're in one of those jobs, you don't get paid the big bucks.
[deleted]
If it was the easy part, then why did they pay us hundreds of thousands, sometimes millions, sometimes more - to do it? The fact of the matter is that it wasn't easy, not for a brain that's architected the way a human's is. The fact that computers can now do it much more quickly and arguably - in many cases - better doesn't diminish the act itself - it just shows how far AI has come, and how easily human intelligence will be dwarfed as it continues to make progress.
This has always seemed like a paradox to me. Once I got past the initial learning curve, coding seemed easy and fun. But most people can't or won't get past that learning curve, for reasons that I don't think we understand.
But if coding were hard, then writing small pieces of code would be as hard as writing big pieces. To make an analogy, playing the violin in tune doesn't get any easier, the shorter the piece that you have to play.
Developing software is hard. Some sort of "phase transition" occurs when a project gets big and complex, where coding is no longer what makes it hard. And writing software in a way that is not a net burden to a project or organization is hard, involving not just complexity but humanity. Most smart people in an organization have subtly arranged their affairs so that their career progress doesn't hinge on the success of a software project.
I admit that I only say these things as an observer, since I can code all day, but didn't pursue a software development career.
I also admit that I'm waiting for AI to handle the second two levels of software development. I'll concede that AI can develop software when The Mythical Man Month no longer reads like it was written yesterday.
But if coding were hard, then writing small pieces of code would be as hard as writing big pieces. To make an analogy, playing the violin in tune doesn't get any easier, the shorter the piece that you have to play.
Developing software is hard. Some sort of "phase transition" occurs when a project gets big and complex, where coding is no longer what makes it hard. And writing software in a way that is not a net burden to a project or organization is hard, involving not just complexity but humanity. Most smart people in an organization have subtly arranged their affairs so that their career progress doesn't hinge on the success of a software project.
I admit that I only say these things as an observer, since I can code all day, but didn't pursue a software development career.
I also admit that I'm waiting for AI to handle the second two levels of software development. I'll concede that AI can develop software when The Mythical Man Month no longer reads like it was written yesterday.
> Some sort of "phase transition" occurs when a project gets big and complex, where coding is no longer what makes it hard.
It's in the name. Coding is taking an algorithm specified in some manner (pseudocode, diagrams, natural languages, thoughts,...) and transforming it into a sequence of instructions, statements, and expressions, that can be executed by a machine (either directly or through an automated process).
We have solved the coding difficulties on several front with things like programming languages (no need to type opcodes), syntax highlighting, linters, snippets, editors, IDEs,...
But someone still have to come up with the "Algorithm", and that's where it's hard. Usually because it's a combination of two sources: The business domain and the technical constraint. That's where people are failing.
But we did manage to create a lot of building blocks, like the standard algorithms and their data structures, libraries that provides an abstraction over a subdomain, frameworks that provides a scaffold to the thinking process,... But the developer still have to solve the system. And that system can get complex real quick if he's careless.
I do believe if you fail at the coding part, that's easy to fix with a few courses (or books) and some practice time. But the system thinking and the solving part is not easily taught. It's not even related to technology other than the latter being the domain it's exercised.
It's in the name. Coding is taking an algorithm specified in some manner (pseudocode, diagrams, natural languages, thoughts,...) and transforming it into a sequence of instructions, statements, and expressions, that can be executed by a machine (either directly or through an automated process).
We have solved the coding difficulties on several front with things like programming languages (no need to type opcodes), syntax highlighting, linters, snippets, editors, IDEs,...
But someone still have to come up with the "Algorithm", and that's where it's hard. Usually because it's a combination of two sources: The business domain and the technical constraint. That's where people are failing.
But we did manage to create a lot of building blocks, like the standard algorithms and their data structures, libraries that provides an abstraction over a subdomain, frameworks that provides a scaffold to the thinking process,... But the developer still have to solve the system. And that system can get complex real quick if he's careless.
I do believe if you fail at the coding part, that's easy to fix with a few courses (or books) and some practice time. But the system thinking and the solving part is not easily taught. It's not even related to technology other than the latter being the domain it's exercised.
Or, abbreviated?:
Coding is easy; design is hard(er).
Coding is easy; design is hard(er).
Part of it is learning, but it's just as much coming into the right mental models for it.
Programs are just virtual machines assembled from numerous smaller parts, not so different from a bicycle, car, or mechanized assembly line, but that's not at all how I thought of them when I was first getting into writing code. I'm not sure I even had a mental model at that point, or if I did it was too simplistic to build anything useful with. It was after my mind picked up the machine model when I started to become capable of writing code and eventually designing and build software from scratch.
Programs are just virtual machines assembled from numerous smaller parts, not so different from a bicycle, car, or mechanized assembly line, but that's not at all how I thought of them when I was first getting into writing code. I'm not sure I even had a mental model at that point, or if I did it was too simplistic to build anything useful with. It was after my mind picked up the machine model when I started to become capable of writing code and eventually designing and build software from scratch.
Honestly, it's not even the learning curve. It's easy. Most people can think precisely enough to program.
The difference is that we enjoy sitting in a chair for ~8 hours a day laying dominoes. A lot of folks do not like that.
The difference is that we enjoy sitting in a chair for ~8 hours a day laying dominoes. A lot of folks do not like that.
You aren't paid to write lines of code, you are paid to build, ship and maintain products and services, usually in a complex corporate setting with ambiguous and ever-changing requirements. Code is a very small part of the overall picture.
Why do you think in most technical organizations the higest ranking and highest paid engineers generally write the least amount of code (often none)?
Why do you think in most technical organizations the higest ranking and highest paid engineers generally write the least amount of code (often none)?
On one such engineer there's hundreds or thousands of others executing the idea into work so your premise about "Code is a very small part of the overall picture" is obviously very wrong. You wouldn't need to hire that many people if that was remotely true.
My experience is that the higher paid someone is generally the less they actually code. I'm sure some places have very difficult code but in my experience there's a reason that engineers fresh out of college mostly code and the highest paid engineers do things like design, planning, and coordination.
Folks have little appreciation for how soon we're all about to transition to something new.
I don't know what that entails, but something is going to happen.
I got into a discussion with some Rust compiler folks yesterday. I called Rust the "final human language we'll serialize our thoughts to": it's easy to write for LLMs, is super type safe, ergonomic, easy for humans to read and reason about, and has really nice deploy characteristics - single binary, no GC, bare metal, etc. If Python and Rust are equivalently easy to emit, you'll probably choose Rust if you're not bound to other choices.
People quipped back that this was absurd and that Rust is built for decades of future human use, that this kind of talk would put people off of Rust, and that they need to think of the future.
As if anything will be human in the coming decades.
Programming languages were punch cards.
I don't know what that entails, but something is going to happen.
I got into a discussion with some Rust compiler folks yesterday. I called Rust the "final human language we'll serialize our thoughts to": it's easy to write for LLMs, is super type safe, ergonomic, easy for humans to read and reason about, and has really nice deploy characteristics - single binary, no GC, bare metal, etc. If Python and Rust are equivalently easy to emit, you'll probably choose Rust if you're not bound to other choices.
People quipped back that this was absurd and that Rust is built for decades of future human use, that this kind of talk would put people off of Rust, and that they need to think of the future.
As if anything will be human in the coming decades.
Programming languages were punch cards.
> I called Rust the "final human language we'll serialize our thoughts to": it's easy to write for LLMs, is super type safe, ergonomic, easy for humans to read and reason about, and has really nice deploy characteristics - single binary, no GC, bare metal, etc.
I think it will go the other way - what use is a language with the poor ergonomics of Rust if humans aren't in the loop?
I think it will go the other way - what use is a language with the poor ergonomics of Rust if humans aren't in the loop?
> super type safe
Maybe if you're willing to write insanity like this:
If it is just as easy to emit a language that is type safe, why Rust?
Maybe if you're willing to write insanity like this:
struct Zero;
struct Succ<N>(N);
trait Add<Rhs> {
type Output;
}
impl<M> Add<M> for Zero {
type Output = M;
}
impl<N, M> Add<M> for Succ<N>
where
N: Add<M>
{
type Output = Succ<<N as Add<M>>::Output>;
}
fn add(a: u32, b: u32) -> u32 {
a + b
}
If it is just as easy to emit a language that is type safe, why Rust?
We skipped over sum types here and the syntactic sugar that makes them a cut above other languages.
Other languages meaning Javascript? Rust doesn't even have proper sum types. Try expressing this Coq sum type in Rust: { x : A & B x } I'll wait.
If it is just as easy to emit a language that is type safe, why Rust?
If it is just as easy to emit a language that is type safe, why Rust?
Because they could.
Try running a business that doesn't have the revenues to support high wages and you'll quickly figure out why you will pay as much as possible every single time: It means you can buy your way out of hiring the riffraff. Why do you think these high paying jobs were premised on weird trivia tests and other things that had absolutely nothing to do with the job? Hint: It was a social test to see if you'd fit in to the culture.
There have always been legions of people in India ready and able to write code for practically nothing. It was never hard or expensive. But they didn't fit in socially.
Try running a business that doesn't have the revenues to support high wages and you'll quickly figure out why you will pay as much as possible every single time: It means you can buy your way out of hiring the riffraff. Why do you think these high paying jobs were premised on weird trivia tests and other things that had absolutely nothing to do with the job? Hint: It was a social test to see if you'd fit in to the culture.
There have always been legions of people in India ready and able to write code for practically nothing. It was never hard or expensive. But they didn't fit in socially.
Because SWEs don't get paid for code. The code is just one byproduct of making business wants into business reality. We get paid to go figure out how to turn a management wishlist into a reliable money machine.
Most developers in the US are “enterprise” developers working in 2nd tier cities working in banks, government, airlines and unknown startups (including most YC companies) that will never make over $175K inflation adjusted their entire career. Hell the way enterprise developer comp has stagnated over the last decade, they may not see that in nominal terms.
If they paid us for coding they would pay by LOC but that's not the case.
They didn’t. No one getting paid that much was getting paid for their code.
coding is getting your foot in the door to software engineering, which is really like, computer systems engineering. We do so much more than code...
Software engineering is more information processing engineering. Code is just the shovel with which we build the trench. Everything is about data, and we build the things that control and process the data based on various events according to some wants and needs.
LLMs are more like a trench digger with a cat's personality. It can helps in some cases, but are more likely to destroy a field. And good luck if you have some difficult terrain to pass through.
LLMs are more like a trench digger with a cat's personality. It can helps in some cases, but are more likely to destroy a field. And good luck if you have some difficult terrain to pass through.
I really recommend you try LLMs again if you haven’t, the last part is really becoming less and less true every day. But I 100% agree that this does not pose a risk to the software developer for all the other points you mentioned. It will just make that trench digger more useful to the developer that needs it. And they’ll still need someone to drive the digger.
LLM is useful just like StackOverflow, Wikipedia, Web Search Engine, Manuals,… are. But automated (which is a pro) and with an hallucination problem (which is a core problem).
The others also may contain wrong information, but the risks are lower and not being automated means the risks are not compounded.
I personally believe we need more trustable source of information rather than automated way to transform it. Especially for the low hanging fruit of coding, which still require to presolve the problem and put us back at the real reason to have a developer.
And one thing that people seems to forget is the wealth of pre-LLM tools to speed up coding. No one uses notepad (from Windows 7) to write code, which is what they keep brandishing as the alternative to their agents and what not.
The others also may contain wrong information, but the risks are lower and not being automated means the risks are not compounded.
I personally believe we need more trustable source of information rather than automated way to transform it. Especially for the low hanging fruit of coding, which still require to presolve the problem and put us back at the real reason to have a developer.
And one thing that people seems to forget is the wealth of pre-LLM tools to speed up coding. No one uses notepad (from Windows 7) to write code, which is what they keep brandishing as the alternative to their agents and what not.
The hallucination problem has dropped exponentially in recent times in code generation. I can’t even recall a time any of the modern models I’ve used have done it in my recent usage. It’ll still do it in cheap/fast models and in places outside of code generation, but the good models write frankly incredible code, especially if you set them up with feedback loops.
Code was the easy part for people who wrote code day in day out with very strictly defined requirements. But even for someone like me that's been doing it for 30 years...new frameworks, languages, architectures, wiring up 3rd party apis, banging my head because I fat fingered something, greping debug logs, late nights, early mornings and lots of coffee. There were few times where I would call it "easy". I just ideated and built an app optimized for mobile and laptop, and deployed it globally in two hours and built a Roku companion app in a couple nights after the kids went to bed. I had never built a Roku app before and am pleased with the polish for something that went from an idea to launch in two hours.
Yes I have 30 years of experience and there were still areas that were not easy but man it was fun. Writing the code, building and deploying product is easier than it was before by a huge margin.
Skicamslive.con if you're wondering what I built. Feedback welcome
Yes I have 30 years of experience and there were still areas that were not easy but man it was fun. Writing the code, building and deploying product is easier than it was before by a huge margin.
Skicamslive.con if you're wondering what I built. Feedback welcome
Small personal projects are really not comparable to professional software development in a corporate setting.
In fact your example demonstrates what the article says. Yeah the LLM made coding easier, and probably reduced your shipping time from a few days to a few hours.
Now - since you have solved the hardest problem and have all this valuable code - how long will it take you to turn your product into a business and generate enough money to support yourself?
That's the hard part.
In fact your example demonstrates what the article says. Yeah the LLM made coding easier, and probably reduced your shipping time from a few days to a few hours.
Now - since you have solved the hardest problem and have all this valuable code - how long will it take you to turn your product into a business and generate enough money to support yourself?
That's the hard part.
> Now - since you have solved the hardest problem and have all this valuable code - how long will it take you to turn your product into a business and generate enough money to support yourself?
> That's the hard part.
It's now even harder because SNR fell off a cliff. As the effort to produce a product approaches zero, the financial viability of that product goes to zero as well.
> That's the hard part.
It's now even harder because SNR fell off a cliff. As the effort to produce a product approaches zero, the financial viability of that product goes to zero as well.
Happy for you, but GitHub has plenty of webcam feed URLs, webcam viewers, Roku code etc. You "built" it for some value of 'building' but it certainly doesn't seem the same kind of 'building' as described in the first three sentences of your post.
It's nice you got something out of it in just two hours. If the LLM companies are doing their caching right, the next person to ask for this set of apps with prompts close enough to yours can get it in five minutes.
Also there's a typo in the URL.
It's nice you got something out of it in just two hours. If the LLM companies are doing their caching right, the next person to ask for this set of apps with prompts close enough to yours can get it in five minutes.
Also there's a typo in the URL.
Well said. But, I understand what they meant, they meant from an organisation’s perspective. Either way, I’ve seen far too many people in HN who fear AI won’t write perfect code, forgetting half the code we wrote before was probably worse.
I’ve also found joy again in building things, but I never fetishised the code myself anyway, I suppose I just wasn’t built that way, which might mean I was always biased to be like this.
I’ve also found joy again in building things, but I never fetishised the code myself anyway, I suppose I just wasn’t built that way, which might mean I was always biased to be like this.
[deleted]
It's a bit like saying "Writing English was always the easy part" vs. writing a book that becomes a best-seller or classic.
I think thats a great analogy. There are a lot more people who can dictate a story page by page to a "writing machine" and create a 300 page book than there are who can write a 300 page book of a the same quality without a writing machine.
Same with coding. Most programmers, and writers, are average. They are not doing amazing work. They get paid 80-120k, same as the HR professional, or the account manager.
Creating average work was always relatively easy for writing and coding and is now relatively easy for everyone.
Same with coding. Most programmers, and writers, are average. They are not doing amazing work. They get paid 80-120k, same as the HR professional, or the account manager.
Creating average work was always relatively easy for writing and coding and is now relatively easy for everyone.
Correct! I’d go further and say typing is the easy part of writing a book, and I absolutely agree with that
I strongly believe that this is a false and outdated take.
Code being the easy part was predicated on how long it took to build a product, and the impact that had on product management, sales, and marketing.
When the time to build collapses, all product/sales/design/martketing mistakes are forgiven. You can pivot so fast, that mistakes in other domains dont matter as much and are reversible
All of the axioms we previously held true need to be rethought
Code being the easy part was predicated on how long it took to build a product, and the impact that had on product management, sales, and marketing.
When the time to build collapses, all product/sales/design/martketing mistakes are forgiven. You can pivot so fast, that mistakes in other domains dont matter as much and are reversible
All of the axioms we previously held true need to be rethought
don't worry that we got the wrong requirements from the customer, chose an impossible deadline, priced it wrong, and there's no market, we can just vibe code our way out of it??
The point is that even in case of total product management failure, the cost of failing is much lower both in time and money.
I don't see it. In my experience with AI/Claude so far, building something with AI then changing direction half way through is a great way to generate garbage structure and garbage code. It takes time to dig yourself out of that hole, possibly more than if you had just slowly built by hand from the beginning all. Maybe I'm holding it wrong.
If you switch directions with hand crafted code you have a mess too and a large amount of tedious refactoring work to do.
Which should be perfect work for Ai.
Which should be perfect work for Ai.
It might make failure faster, but that doesn't mean it's cheaper.
Users will churn quick if you aren't reliable or useful and a security incident can be company-ending for a startup.
Users will churn quick if you aren't reliable or useful and a security incident can be company-ending for a startup.
Company-ending is a form of failure. The quicker you do that, the quicker you can start your next company.
In an odd way you’re absolutely proving the article’s point. The requirements, deadline, pricing, idea, implementation, customer story, these are the things that matter and are hard. Compared to that, code is easy.
>When the time to build collapses, all product/sales/design/marketing mistakes are forgiven
I must be living in topsy turvey land because this is literally the opposite of what is true. When the time to build collapses, those things become the criticality of the entire product. From a customer perspective, those were always the things that mattered, the customer story. No customer cares how a thing was coded, they’ve ALWAYS cared about all those other things.
I must be living in topsy turvey land because this is literally the opposite of what is true. When the time to build collapses, those things become the criticality of the entire product. From a customer perspective, those were always the things that mattered, the customer story. No customer cares how a thing was coded, they’ve ALWAYS cared about all those other things.
nah youre missing it, if time to build takes 9 months, you better get the product right.
if time to build takes 2 months, just build it and iterate.
or just rebuild the product to the customers liking...
if time to build takes 2 months, just build it and iterate.
or just rebuild the product to the customers liking...
I’m not missing anything. Customers getting what they want earlier is a good thing. If the product is flawed, it will be outcompeted by a product that is better designed for customers. You’re sidestepping like crazy my dude
Because we don't need to worry about uptime, customer satisfaction, or data integrity.
> and nobody got into it because programming in Perl was somehow aesthetically delightful. (The language is referred to as write only line noise for a reason)
Today we call it "vibe coding" when people use an AI to write software without reading the code, or even learning how coding works. But people have been doing that for ages. Most "Perl programmers" back in the day never even attempted to learn the language, and often weren't software developers. But despite their horrible coding skills, the Perl worked anyway. And thus the language got a reputation for being hard to read, despite it being amazing that it worked at all.
Perl is still far and away my favorite language. I get things done so much faster in it, and programs I wrote 25 years ago work perfectly today on the latest systems. (Maybe that's the problem? If it were a real language, it would've broken 5 different times by now! And then I get paid to fix it... I think I understand software engineering now...)
Today we call it "vibe coding" when people use an AI to write software without reading the code, or even learning how coding works. But people have been doing that for ages. Most "Perl programmers" back in the day never even attempted to learn the language, and often weren't software developers. But despite their horrible coding skills, the Perl worked anyway. And thus the language got a reputation for being hard to read, despite it being amazing that it worked at all.
Perl is still far and away my favorite language. I get things done so much faster in it, and programs I wrote 25 years ago work perfectly today on the latest systems. (Maybe that's the problem? If it were a real language, it would've broken 5 different times by now! And then I get paid to fix it... I think I understand software engineering now...)
The thing that makes me crazy about this article, others like it (and so many of the comments in response to them ) is the naive assumption that whatever the author is used to is always the case.
It's just not. I've been a developer for 25+ years, and in technical diligence looking at companies getting investments for seven, and have done diligence on 100+ companies. It's ALL OVER THE PLACE. It depends on the product, the company, the team, the way the company is managed, the business domain, etc.
For some companies, products, and teams.. the code absolutely is the hard part, and building that insanely sophisticated software is worth millions. I've seen scientific software that sold for millions of dollars per copy.
For others, the code is essentially commodity plumbing around some operational knowledge of a domain that makes nice dough with minimal code complexity. I've also seen founders who were going to spend the rest of their days floating around the bahamas because they wrote the right PHP-ball-of-mud in the right domain at the right time, sigh.
The world of software is vastly broader than the vast majority of programmers think. And there are a lot of very, very different ways to make money in it.
It's just not. I've been a developer for 25+ years, and in technical diligence looking at companies getting investments for seven, and have done diligence on 100+ companies. It's ALL OVER THE PLACE. It depends on the product, the company, the team, the way the company is managed, the business domain, etc.
For some companies, products, and teams.. the code absolutely is the hard part, and building that insanely sophisticated software is worth millions. I've seen scientific software that sold for millions of dollars per copy.
For others, the code is essentially commodity plumbing around some operational knowledge of a domain that makes nice dough with minimal code complexity. I've also seen founders who were going to spend the rest of their days floating around the bahamas because they wrote the right PHP-ball-of-mud in the right domain at the right time, sigh.
The world of software is vastly broader than the vast majority of programmers think. And there are a lot of very, very different ways to make money in it.
Thank you !
Some code has always been the easy part, similar to the way a lot of systems abstract the more complicated pieces of a software project away from you. I am not talking about the relationship between higher and lower level languages but rather the way in which certain large enterprise systems already made the code 'very' easy.
For example, I have worked with SAP a lot...the largest ERP system in the world by some margin and I have used it's internally built tools that extend a small amount of developer functionality to the 'IT department developer' that gives a user with knowledge or .NET and SQL the chance to make little validations or do some bespoke data visualisations pretty quickly. This was trivially easy and pretty sure AI tools will make a developer redundant in this context because the documentation is good and there's a lot of it.
Contrast eg hooking up a system like SAP to an unusual non-standard Ecommerce offering and you have a far more complex problem (that interestingly doesn't require huge amounts of code but does in fact take a long time because of lack of documentation and a certain amount of understanding required). I would also point to programming games, which I enjoy...compare using Unity with some C# scripts for making games, to building your own engine (which will pretty much become redundant soon anyway if it already isn't). AI is very good on the Unity stuff but I suspect would struggle with it's own engine for a specific game.
For example, I have worked with SAP a lot...the largest ERP system in the world by some margin and I have used it's internally built tools that extend a small amount of developer functionality to the 'IT department developer' that gives a user with knowledge or .NET and SQL the chance to make little validations or do some bespoke data visualisations pretty quickly. This was trivially easy and pretty sure AI tools will make a developer redundant in this context because the documentation is good and there's a lot of it.
Contrast eg hooking up a system like SAP to an unusual non-standard Ecommerce offering and you have a far more complex problem (that interestingly doesn't require huge amounts of code but does in fact take a long time because of lack of documentation and a certain amount of understanding required). I would also point to programming games, which I enjoy...compare using Unity with some C# scripts for making games, to building your own engine (which will pretty much become redundant soon anyway if it already isn't). AI is very good on the Unity stuff but I suspect would struggle with it's own engine for a specific game.
This discussion feels analogous to me to the age-old "we can do it fast now, and do it right later" tradeoff discussion, except now it's about knowledge, maintainability etc.. There are stages of companies and types of products where solution quality has a bigger buffer, some are more critical. We also know that in many places, once you shipped a crappy solution in a week, you've now set an expectation, and management will expect you do repeat that forever, not getting the time to actually fix/rearchitect when needed.
We used to brush that off with the "we'll fix all of that once we've shipped", now we brush it off with "doesn't matter, AI can fix it later easily". This applies to knowledge about the code, domains and quality itself, too.
To me, this is a reasonable tradeoff to discuss, and sticking to either extreme ("AI is cancer" and "AI is the silver bullet") feels silly.
There's real risk here, and I do see a lot of seniors act like kids in the candy store. That speaks volumes to what AI really unlocks (cheap experimentation, for one!), but also warrants caution.
Based on the data (not great quality tbh...) we have, the net speedup is more realistically around 5-10% of the total time of software engineers, and we're yet to see the cost of that speedup.
We used to brush that off with the "we'll fix all of that once we've shipped", now we brush it off with "doesn't matter, AI can fix it later easily". This applies to knowledge about the code, domains and quality itself, too.
To me, this is a reasonable tradeoff to discuss, and sticking to either extreme ("AI is cancer" and "AI is the silver bullet") feels silly.
There's real risk here, and I do see a lot of seniors act like kids in the candy store. That speaks volumes to what AI really unlocks (cheap experimentation, for one!), but also warrants caution.
Based on the data (not great quality tbh...) we have, the net speedup is more realistically around 5-10% of the total time of software engineers, and we're yet to see the cost of that speedup.
Of course, this is still considering the current model of working. Which in itself is a question.
Yes, code has always been the easy part. LLMs produce it even more copiously, so it is ever easier now, and yes, that makes the bottlenecks worse:
But even with that one constraint about human-to-human communications, LLMs are improving throughput: by writing better docs faster, by helping us get the gist faster (though using LLMs to read docs that could have prompts embedded is scary), and so on.
Personally, where the communication burden is intense I don't think we'll see 10x, 5x, not even 25% efficiency improvements. But now consider projects where the communication burden is minimal as there is only one human -- personal projects, open source projects, that sort of thing. In those cases a 5x, even 10x efficiency improvement is not out of the question. Many projects have communications burdens that are not so intense that they can't experience 2x efficiency improvements.
The challenge will lie in safely maximizing those improvements and doing it better than the competition.
- communication between humans
"what are we to build?"
"what is the architecture?"
"how shall we design this?"
etc
- architecture review
- design review
- code review
- docs review
- ...
- understand what is possible
- and how to achieve it
- architect
- design
- review
But even with that one constraint about human-to-human communications, LLMs are improving throughput: by writing better docs faster, by helping us get the gist faster (though using LLMs to read docs that could have prompts embedded is scary), and so on.
Personally, where the communication burden is intense I don't think we'll see 10x, 5x, not even 25% efficiency improvements. But now consider projects where the communication burden is minimal as there is only one human -- personal projects, open source projects, that sort of thing. In those cases a 5x, even 10x efficiency improvement is not out of the question. Many projects have communications burdens that are not so intense that they can't experience 2x efficiency improvements.
The challenge will lie in safely maximizing those improvements and doing it better than the competition.
Like saying putting paint on a brush and wiping it on paper is the easy part of painting.
Even with coding agents, there is still a need to understand what it’s doing, how it will interact with other systems, where bugs or edge cases will show up and many other aspects that become security risks when ignored by someone that YOLO’s their vibe coded app into production
Even with coding agents, there is still a need to understand what it’s doing, how it will interact with other systems, where bugs or edge cases will show up and many other aspects that become security risks when ignored by someone that YOLO’s their vibe coded app into production
There’s a need for something to understand those things, but from a user perspective it doesn’t matter if that’s a human or an LLM.
Besides, loads of software that’s human written has people maintaining it that don’t understand what it’s doing or how it interacts with other systems or where bugs or edge cases will show up etc etc too. In fact I’d say most software is like this.
LLM’s probably make less security holes than humans at this point.
Besides, loads of software that’s human written has people maintaining it that don’t understand what it’s doing or how it interacts with other systems or where bugs or edge cases will show up etc etc too. In fact I’d say most software is like this.
LLM’s probably make less security holes than humans at this point.
I've written these words multiple times here on HN, and have a draft blog by virtually the same title. I can't agree more with the sentiment, though I think theres some nuance the author is missing out on. Regardless, thank you for sharing.
I think what the author is saying is akin to that old joke about a broken machine that nobody at the company can fix.
They bring in a high priced consultant who spends a few minutes looking at the machine, reaches in and pushes a switch and suddenly the machine starts working.
When the manager gets the invoice, he calls the consultant demanding an explanation for why it cost so much. After all, the consultant only spent a few minutes looking and then flipped one switch.
The consultant offered to send a more detailed invoice and the manager received one that said:
- Flipping a switch: $1 - Knowing which switch to flip: $999
In other words, the writing of the code is like flipping the switch. It’s the rest of “coding” that’s difficult.
They bring in a high priced consultant who spends a few minutes looking at the machine, reaches in and pushes a switch and suddenly the machine starts working.
When the manager gets the invoice, he calls the consultant demanding an explanation for why it cost so much. After all, the consultant only spent a few minutes looking and then flipped one switch.
The consultant offered to send a more detailed invoice and the manager received one that said:
- Flipping a switch: $1 - Knowing which switch to flip: $999
In other words, the writing of the code is like flipping the switch. It’s the rest of “coding” that’s difficult.
I think it's better to say 'the artifact is not the product'. Code is actually very hard, because it is the act of formalizing vague problems. That's thinking. It can be separated from literally typing the code in, and some problems are solvable in so many isomorphic ways you might as well describe them to an LLM and let it pick one out of a hat (embarrassingly solved problems), but it's like saying "prose is the easy part".
I think what it means is that coding is difficult but predictable — in the sense that, you can solve it by throwing enough money at it.
Figuring out what to build in a way that actually leads to product-market fit, on the other hand, is something you cannot solve just by throwing money at it.
So in this frame, coding becomes 'the easy part' — not because it's truly easy, but because it can be solved relatively straightforwardly with resources
I do and always will belive this phrase to be wage suppression propaganda. I think the proof is self evident. ie salaries.
I guess we just hallucinated leet code too.
I guess we just hallucinated leet code too.
Easy or not, code is obviously a time-consuming part. Anything that can dramatically reduce the time surely have significant impact.
Trivializing code has reached an insufferable nadir. It is like saying math or medicine is the easy part, or cooking or carpentry. Often those who say it cannot code or read code, and are good at marketing, so they simply keep on promoting it and be dismissive of other work. Disillusioned to see it at the top of HN, and hand waving away methodical and substantial activities can only bode badly.
It's akin to saying "swinging a hammer is the easy part of creating a building". Or "inserting a needle into a vein is the easy part of medicine".
Both are somewhat true, and yet, I'll still be quite happy if we have AI that can do them.
I'm certainly not trying to trivialize the progress that LLMs are making. I'm trying to be realistic, noting both the strengths and weaknesses of LLMs, and what that means for the fields they touch.
Both are somewhat true, and yet, I'll still be quite happy if we have AI that can do them.
I'm certainly not trying to trivialize the progress that LLMs are making. I'm trying to be realistic, noting both the strengths and weaknesses of LLMs, and what that means for the fields they touch.
I as a "developer", I have probably used less than 10% of my time coding the last 15 or so years... I switched jobs to being a contractor in 2011, and after that it has been a downward slope towards less and less coding, and more of other things. Mostly validation and testing in various forms.
Every time computers master a skill that was previously thought to require a lot of intelligence/knowledge/ingenuity, people suddenly claim that it wasn't that hard after all.
- Non-trivial arithmetic
- Puzzles involving combinatorics
- Chess
etc. etc.
- Non-trivial arithmetic
- Puzzles involving combinatorics
- Chess
etc. etc.
When was chess ever not hard?
Afaik the best AIs can win now but even they aren't playing 'perfect' unloseable games.
Afaik the best AIs can win now but even they aren't playing 'perfect' unloseable games.
Previous discussion from 2 weeks ago: https://news.ycombinator.com/item?id=46966753
As a junior dev, it wasn't so easy for me :/
I’m out of my element here. At least I’m speaking as an observer and not a participant of the programming language debates that I feel are less prevalent in communities like here than they are in the past. Ostensibly due to the raise of LLMs and debates about them taking up most of the programming discourse now.
I wonder if someone with real experience/insight thinks that this claim is revisionist.
I wonder if someone with real experience/insight thinks that this claim is revisionist.
AI reduces the thinking time, too. And most of my time is spent either thinking or coding.
Brilliant. You can already see the HN users in here with emotional attachment issues who are sad because of the issues you talk about, and it’s causing them to bury their heads in the sand.
It’s going to be a hard transition, but we can’t pretend it’s not happening, that won’t get us anywhere.
It’s going to be a hard transition, but we can’t pretend it’s not happening, that won’t get us anywhere.
This meme is just cope at this point, and it’s frustrating to watch engineers pretend that it was actually the architecture that was hard or whatever.
No author, this isn’t the same as SPAs and CI/CD.
This isn’t just happy tools helping us focus on the business side.
We’re devaluing all white collar work. The thing that keeps the US economy afloat. Even if this tech requires human oversight, why would companies keep you when they can hire someone overseas at 1/10th the cost and get to 80% of the productivity with AI.
Anthropic just dropped their safety pledge. Do you think they’ll hesitate as they transfer wealth from workers to their shareholders?
Please people. Stop being avoidant. Stop pretending it’s a meritocracy and you’re at the top. Stop pretending the one thing about the job AI can’t do is the job.
No author, this isn’t the same as SPAs and CI/CD.
This isn’t just happy tools helping us focus on the business side.
We’re devaluing all white collar work. The thing that keeps the US economy afloat. Even if this tech requires human oversight, why would companies keep you when they can hire someone overseas at 1/10th the cost and get to 80% of the productivity with AI.
Anthropic just dropped their safety pledge. Do you think they’ll hesitate as they transfer wealth from workers to their shareholders?
Please people. Stop being avoidant. Stop pretending it’s a meritocracy and you’re at the top. Stop pretending the one thing about the job AI can’t do is the job.
[deleted]
They’ve been able to hire someone from overseas for ages for 1/10th the cost, turns out there are other variables in play.
It's the combination of factors. AI augmentation makes offshoring much more viable.
I… don’t agree with this at all.The bottleneck of offshoring was always in the other parts of the job, not code generation. It was in communication and feedback, and product and customer needs.
LLMs are literally communication and comprehension tools. An offshore team with AI assistance can produce clearer English documentation, parse ambiguous product requirements more effectively, and ultimately close the feedback loop faster.
This is the exact cope I’m talking about, as if these tools are just good at code generation and the actual work was always communication or architecture or something.
This is the exact cope I’m talking about, as if these tools are just good at code generation and the actual work was always communication or architecture or something.
Ehh, maybe a little. I don’t think the bottle neck has been prised open all that much yet in those areas
This is a pretty defeatist take. Stop doing that, and start doing what instead?
What a strange thing to say.
Code was never the easy part.
If it was, then AI and LLMs would have been of no interest for coding.
Self evidently wrong.
Code was never the easy part.
If it was, then AI and LLMs would have been of no interest for coding.
Self evidently wrong.
Lol. Lmao, even.
Software developers have spent the last twenty years blabbing about how product management is useless and coding is the one true skill.
Software developers have spent the last twenty years blabbing about how product management is useless and coding is the one true skill.
Eh, in my experience, design has always been harder than coding. If I get my design right, the coding follows naturally and easily.
Coding is hard when you're learning it. "How do I use templates in C++? How do I handle error checking in Python?" etc. But it's the most basic piece of software development.
Coding is hard when you're learning it. "How do I use templates in C++? How do I handle error checking in Python?" etc. But it's the most basic piece of software development.
...to the person who knows how to code.
Yeah, exactly. Most employed programmers I ever met in the past decades actually cannot code and really really struggled (not anymore with AI) to do anything. And yet, usually because of a degree of some crap college, they have a job as something they cannot actually do.
Err, what do you mean they cannot do anything? Where are you meeting these programmers??
Large (non software) enterprises. Mostly. Government departments. That type of thing. Like I said in another thread; have a wander with me over to Shell, Barclays and stuff like that; entire bags of (many outsourcing/external) 'programmers' who don't know how variables or loops work.
I can only assume so many people are repeating this as "cope".
Or perhaps you are the one who is “coping”?
Ask yourself honestly, is this genie ever going back in the bottle? If not, you’re gonna have to find a way to come to terms with it my dude.
Ask yourself honestly, is this genie ever going back in the bottle? If not, you’re gonna have to find a way to come to terms with it my dude.
>> I can only assume so many people are repeating this as "cope".
> Or perhaps you are the one who is “coping”?
> Ask yourself honestly, is this genie ever going back in the bottle? If not, you’re gonna have to find a way to come to terms with it my dude.
I think you misunderstand the GP: The developers writing this, or similar things, are seemingly unable to understand that they'll be un/under-employed along with everyone who is anti-AI, and this is their coping mechanism.
After all, if you don't need coding knowledge to produce an application, and only need domain knowledge, you are now competing with 10x more people for the same job.
> Or perhaps you are the one who is “coping”?
> Ask yourself honestly, is this genie ever going back in the bottle? If not, you’re gonna have to find a way to come to terms with it my dude.
I think you misunderstand the GP: The developers writing this, or similar things, are seemingly unable to understand that they'll be un/under-employed along with everyone who is anti-AI, and this is their coping mechanism.
After all, if you don't need coding knowledge to produce an application, and only need domain knowledge, you are now competing with 10x more people for the same job.
And I say good. Coding and application development being more accessible is a good thing. Technological advancement usually takes the form of taking something that used to be hard and socialised and making it easy and accessible. In the long run, this is a good thing.
> And I say good. Coding and application development being more accessible is a good thing. Technological advancement usually takes the form of taking something that used to be hard and socialised and making it easy and accessible. In the long run, this is a good thing.
Maybe it is a good thing, but I don't think that that fact, regardless of veracity, is relevant to the coping argument, though.
All the developers prattling on about how they are moving to a higher level of abstraction, or how they are moving to the more difficult parts of the process are ignoring that those parts traditionally paid less and that they are now competing with a larger pool of people who can provide that skill.
Maybe it is a good thing, but I don't think that that fact, regardless of veracity, is relevant to the coping argument, though.
All the developers prattling on about how they are moving to a higher level of abstraction, or how they are moving to the more difficult parts of the process are ignoring that those parts traditionally paid less and that they are now competing with a larger pool of people who can provide that skill.
All the developers you’re talking to are in more senior positions which are the safest of all. High paid engineers barely write any code anyway, their job was _already_ abstracted beyond the grunt work. So, when they talk about moving on to a higher level of abstraction, I genuinely believe they are right that those job losses largely won’t affect them.
The difficulty of course will be recent graduates. I genuinely feel for the difficulty they’ll have.
The difficulty of course will be recent graduates. I genuinely feel for the difficulty they’ll have.
The hard part is long term maintenance. The hard part is retrofitting new features. The hardest part of all is not building a big ball of mud.
Mythical Man Month is still an amazing read. 9 agents still cannot have a baby in 1 month because the problem has never been the speed at which we type.