This seems to be a fairly common opinion, as does the opinion that this sits as a counterpoint to.
There has been a divergence that is quite stark. I have seen it argued that this is a reflection of ability, and that as a skill multiplier those lacking in skill are feeling left behind. I'm not certain that this is accurate. I definitely see people who have made things that impressed me in the past have been more likely to embrace AI. It may just be a measure of a type of personality.
I have noticed that people who have a strong sense of possessiveness over what they create are more resistant, but those who create in order to have the world contain the thing they are making are happy to have anything that will enable them to contribute to the world.
I think the biggest differentiator is simply that there are people for whom the act of typing the code into the editor was the part they enjoyed, and LLMs have basically killed that, by making it woefully inefficient by comparison.
I think this is exactly it. And IMO - there's nothing wrong with enjoying that part of it. But it may not be a high paying career like it was previously.
Some people though society was paying them lots of money to type code into an editor. But that was never true - people and businesses were paying them to solve problems.
I think the scary bit is down the road. We can all use AI well because we have the gist of how things work and a well-honed set of technical empathy for "how they probably wrote it."
I'm not sure how you build that sense as well if you're starting out today, though.
I think the biggest differentiator is simply that there are people for whom the act of typing the code into the editor was the part they enjoyed, and LLMs have basically killed that, by making it woefully inefficient by comparison.
This is a very uncharitable take; I see it mostly from devs who are all-in on AI (not saying you are one), not from devs who just use AI while programming. Basically, I see it from devs who want to never touch a keyboard again.
Maybe they never liked programming in the first place, but liked managing instead, so now they can manage instead of programming.
Maybe they never liked programming, but they did like delivering; now they can work as a product manager, delivering only.
Whatever the reason, they never really liked programming[1]. My experience in programming, since the mid-90s, is that my design is refined as I type out the programs. I gain insight into the problem as I create the program. My thoughts are refined as I read what I type (and not just with programs, with prose as well).
Possibly the all-in devs never read what they typed anyway, so the act of programming never caused them to refine their ideas. Maybe they never read what they typed as they typed it in. Maybe they did, but it never triggered introspection.
Whatever the case is, it's a very uncharitable take to trivialise those engaging in more thought, due to actually writing, as simply enjoying the act of typing.
They are not. They are enjoying the iterative process of deep thinking.
TBH, maybe this is why so many of the all-in AI vibers are trying to trivialise the typing part - if they can convince themselves that typing is so trivial and bereft of thought, then they don't have to admit to themselves that they are thinking less, and the thinking they do do, is not as deep.
----------------------------------
[1] All advances in programming, such as in data structures, algorithms, languages, theory, etc came mostly from people who liked programming. As these people can not hone their skills by working at it for money in the future, who knows if we ever get any more advances.
I definitely agree with you about this for certain problems but I think for a large number of people, they are just using an ORM to bind to a form to later save back with some validation. There is not much deep thinking they need to do other than which columns to index.
I definitely agree with you about this for certain problems but I think for a large number of people, they are just using an ORM to bind to a form to later save back with some validation. There is not much deep thinking they need to do other than which columns to index.
I dunno; unless it's an extremely trivial case (single table, no joins), they are still thinking about this: does this new form make sense as a standalone form? Does the functionality overlap with a current form (and if so, should we rather refactor the workflow than add a new step), etc.
There's also nitty-gritty stuff: should I make this a common function callable by other form-generating code, or keep it as a single-caller function?
More often, when writing code you often get a good sense of what is currently broken in the design. In greenfield, you can just go ahead and modify the design. In brownfield you are going to try to minimise the modifications in design as much as possible. This is still thought.
Whatever the reason, they never really liked programming
I agree with this, at least. Because for me the act of typing the code into the editor was never the enjoyable part. It was always just the thing you had to do before you could enjoy the creation. I wanted to build a website, not type HTML into an editor. I wanted to mod Ultima Online, not type C# into an editor. I wanted to make a PWA, not type ruby into an editor. I wanted to interface some bespoke hardware with GPIO pins, not type python into an editor. I wanted to build an ETL pipeline to make better operational decisions at work, not type code into a fucking editor.
I’m an engineer, not a typist. I get paid for my judgment and for adding value, not lines of code typed.
Actually typing the code was always just a means to an end. Can you honestly say different?
My experience in programming, since the mid-90s, is that my design is refined as I type out the programs. I gain insight into the problem as I create the program.
[...]
Whatever the case is, it's a very uncharitable take to trivialise those engaging in more thought, due to actually writing, as simply enjoying the act of typing.
I don't understand the vitriol here. Are you saying you just sit down and start writing the code, without planning or designing the application you're writing beforehand? Surely not.
Nowadays before any code gets written, by me or by an agent, there ends up being several rounds of back-and-forth on the overall architecture and design of whatever is under consideration. I put thought into data structures, ownership and lifetimes, design patterns, overall project context, etc.
That is, IMHO, the hard part of software engineering. If you're a professional, that's the part that pays the bills. Once that part is done, is there any actual value to implementing a ring buffer by hand vs having the model do it? Is there materially more thought? I argue there is not.
I write the code that the models don't write well. I let the models write the code they're good at writing because I've got a thousand better uses for my time than implementing a ring buffer, or an API endpoint handler, or whatever, by hand.
All advances in programming, such as in data structures, algorithms, languages, theory, etc came mostly from people who liked programming.
Pretty sure most of these advancements came from people who were computer scientists first and foremost. They programmed by hand because no other method existed at the time. But there's a famous quote about computer science having very little to do with writing code.
edit: lol HN's bone-headed rate limits strike again. Oh well, conversation ends here I guess. By the time the rate limit has elapsed this conversation will be ancient history.
That is, IMHO, the hard part of software engineering. That's the part that pays the bills. Once that part is done, is there any actual value to implementing a ring buffer by hand vs having the model do it? Is there materially more thought? I argue there is not.
Nope. The hard part of software engineering is recognizing all the subtle ways in which no existing abstraction ever perfectly fits your non-trivial problem and its subproblems.
This work is never "done". I do find it amusing how every time your line of reasoning comes up, the examples are always textbook trivial problems and solutions. It's even sometimes an insistence that LLMs are "compilers" for this kind of thinking.
It's the stuff of middle manager fantasy that things are "just so" and that implementation work has less depth instead of far more. If implementation is so trivial, the world is only inching closer to demanding an explanation from your lot why you think most implementations are so bad.
To address the parent of all these replies, I agree it's a difference of personality. The "hands off" people are going extinct, and they're terrified. The future has always been about getting our hands even dirtier.
> My experience in programming, since the mid-90s, is that my design is refined as I type out the programs. I gain insight into the problem as I create the program.
> [...]
> Whatever the case is, it's a very uncharitable take to trivialise those engaging in more thought, due to actually writing, as simply enjoying the act of typing.
I don't understand the vitriol here. Are you saying you just sit down and start writing the code, without planning or designing the application you're writing beforehand?
I gotta ask?: why do you think "my design is refined" means that I start without a design? The wording is fairly clear: for a design to be refined, it means it has to exist.
(I'm also not sure that vitriol is the correct word to use here; it seems, again, like needless disparagement).
Once that part is done, is there any actual value to implementing a ring buffer by hand vs having the model do it?
Do you have an example that isn't "I use a library to do this when writing code"? This strawman comes up again and again in these types of discussion: no, I don't write a ringbuffer, I use an existing library.
You are also glossing over which group I am describing, specifically, those who are all-in on AI development and do not read nor write code.
I think the style essay akin to a punchy, TED-talk style persuasive essay is dead.
Whether or not this author wrote it themselves (I strongly suspect at least an AI editor), the specific style that was, for a time, very attractive has become the hallmark of AI-written prose; and, while the content doesn’t seem wrong from a particular view, it also leaves a taste of waste to me - waste that I spent that time reading something they didn’t write, full of -isms that aren’t theirs, when the thesis could have padded out far less paper.
The word count feels unearned, even if the content is fine.
It's one thing to have AI-written software, where the code isn't the consumable; and quite another to have AI-written essays that are intended to engage a human's critical thinking.
The part I find most exciting is not that the same ticket takes fewer hours. It is that entirely different projects now fit inside a human life.
This is my favorite part too. With my own project for example, I had the agent integrate libgit into it so I could add source control to my IDE. Yes, I could have done it myself, but it would have taken me months of trying to understand the API, testing various things, and finally implementing it all. Instead, the agent did almost all the work (I still designed the architecture and how it plugged in). It took about two weeks calendar time and most of that time I was doing something else while the agent worked.
The thing is, before AI agents, I wouldn't have even attempted the work. I wouldn't have been able to afford the time.
The thing is, before AI agents, I wouldn't have even attempted the work. I wouldn't have been able to afford the time.
Before AI agents, what we would have is maybe a line in the changelog, like “git support has been added” and maybe some post if there’s a substantial Ui/Ux improvement or novelty.
Now it’s just: I did something with AI (with no description of why it has been done, just what) and it was pretty fast (compared to an exaggerated estimation).
Even if it's AI generated (or AI "improved"), I'll comment on the content:
The learning loop got tighter. Ask a question. Inspect the answer. Run the code. Break it. Read the implementation. Correct the assumption. Try again.
This assumes that you have the resources (time and money/AI usage budget) and the interest/motivation to do that. If you do programming as a job rather than as a hobby, the time you can spend on things like this and the budget you can spare for it will be severely limited. Also, after you have finally coaxed the LLM into generating something that fits all the requirements without breaking in new and surprising ways, has code that's not ridiculously overengineered (that's probably the real reason behind vibe coding: as long as you don't look at the horror beneath the hood, you can tell yourself everything's fine), doesn't break some convention of the codebase and has the required test coverage and other metrics, you're not only out of time for the task at hand, but also more than ready to move on to something else.
This guy can't even be bothered to type his own thoughts out, but expects us to read what claude dumped out? Typing your own thoughts is just not hard at all, I don't get it.
What I understood from TFA is that the author is complaining about formalism and bad abstractions. The latter is a real complaint, but I can’t understood viewing formalism as a burden.
At it’s core computing is about taking some information, encode it, transform it, and then decode the result. The latter can be interpreted by humans or used to drive some machinery. The value of computers is that they can do encoding/transform/decoding part reliably and really quickly. But it’s up to use to specify how.
One common trait I found with people that dislike formalism is that they have great reluctance to admit they’re wrong, or at least consider the possibility. And a formal system cleanly mark what is correct according to its axioms.
The issue with most AI practice is that they eschew reliability and guarantees of correctness (not there hasn’t been bugs previously). The proponents can talk about their goals, but they can’t explain the projects they’re working on and reason how it should be correct.
For them, it’s like seeing a chess game and deciding it’s ok if a pawn move like a knight to capture the king, because that’s the intended goal. Like “just move the piece with your hands”. Because it’s hard to devise a strategy that respect the rules. The bad play is obvious when it’s a real chess board, but imagine it’s a generic board where all pieces are little puck with a led fave for colors and types. They wouldn’t mind the pawn to change its type to knight for the illegal move and then revert to pawn once that’s done.
So something like Python and Go is pretty generic. You can code various domains with it (servers, games, apps,…), but it’s up to you to really follow the rules of that domain. Using AI code, there’s a non zero chance for a bit of cheating to happens. While it “works”, it’s not correct, and there’s some use cases that are totally wrong.
It's all relative to what your goals are and what you're most experienced with. Your "hard parts" are someone else's "easy parts".
The machine doesn't give a shit what you think is hard. You still can't throw away any of the code that you don't understand. The machine needs it all and you choose to stay ignorant.
Experience of the topic at hand absolutely still matters, and even moreso with LLMs. The unhealthy approach is to delegate your work and bury your head in the sand. The healthy approach is to use LLMs to learn and do faster.
The future is exciting and breathtaking, not lamentable.
Fond feelings for punch cards and hanging chads are the result of thick rose-tinted glasses.
If reading this smells like it’s been ai generated, that’s because it is.
https://web.archive.org/web/20260606173815/https://jakegolds...
Yeah but it’s a good point even if not personally made.
meh. so many words to say engineering was never about the toil.
This seems to be a fairly common opinion, as does the opinion that this sits as a counterpoint to.
There has been a divergence that is quite stark. I have seen it argued that this is a reflection of ability, and that as a skill multiplier those lacking in skill are feeling left behind. I'm not certain that this is accurate. I definitely see people who have made things that impressed me in the past have been more likely to embrace AI. It may just be a measure of a type of personality.
I have noticed that people who have a strong sense of possessiveness over what they create are more resistant, but those who create in order to have the world contain the thing they are making are happy to have anything that will enable them to contribute to the world.
I think the biggest differentiator is simply that there are people for whom the act of typing the code into the editor was the part they enjoyed, and LLMs have basically killed that, by making it woefully inefficient by comparison.
I think this is exactly it. And IMO - there's nothing wrong with enjoying that part of it. But it may not be a high paying career like it was previously.
Some people though society was paying them lots of money to type code into an editor. But that was never true - people and businesses were paying them to solve problems.
I think the scary bit is down the road. We can all use AI well because we have the gist of how things work and a well-honed set of technical empathy for "how they probably wrote it."
I'm not sure how you build that sense as well if you're starting out today, though.
This is a very uncharitable take; I see it mostly from devs who are all-in on AI (not saying you are one), not from devs who just use AI while programming. Basically, I see it from devs who want to never touch a keyboard again.
Maybe they never liked programming in the first place, but liked managing instead, so now they can manage instead of programming.
Maybe they never liked programming, but they did like delivering; now they can work as a product manager, delivering only.
Whatever the reason, they never really liked programming[1]. My experience in programming, since the mid-90s, is that my design is refined as I type out the programs. I gain insight into the problem as I create the program. My thoughts are refined as I read what I type (and not just with programs, with prose as well).
Possibly the all-in devs never read what they typed anyway, so the act of programming never caused them to refine their ideas. Maybe they never read what they typed as they typed it in. Maybe they did, but it never triggered introspection.
Whatever the case is, it's a very uncharitable take to trivialise those engaging in more thought, due to actually writing, as simply enjoying the act of typing.
They are not. They are enjoying the iterative process of deep thinking.
TBH, maybe this is why so many of the all-in AI vibers are trying to trivialise the typing part - if they can convince themselves that typing is so trivial and bereft of thought, then they don't have to admit to themselves that they are thinking less, and the thinking they do do, is not as deep.
----------------------------------
[1] All advances in programming, such as in data structures, algorithms, languages, theory, etc came mostly from people who liked programming. As these people can not hone their skills by working at it for money in the future, who knows if we ever get any more advances.
I definitely agree with you about this for certain problems but I think for a large number of people, they are just using an ORM to bind to a form to later save back with some validation. There is not much deep thinking they need to do other than which columns to index.
I dunno; unless it's an extremely trivial case (single table, no joins), they are still thinking about this: does this new form make sense as a standalone form? Does the functionality overlap with a current form (and if so, should we rather refactor the workflow than add a new step), etc.
There's also nitty-gritty stuff: should I make this a common function callable by other form-generating code, or keep it as a single-caller function?
More often, when writing code you often get a good sense of what is currently broken in the design. In greenfield, you can just go ahead and modify the design. In brownfield you are going to try to minimise the modifications in design as much as possible. This is still thought.
Fair points, good boundaries and abstractions will always offer easier, more stable extensibility.
I agree with this, at least. Because for me the act of typing the code into the editor was never the enjoyable part. It was always just the thing you had to do before you could enjoy the creation. I wanted to build a website, not type HTML into an editor. I wanted to mod Ultima Online, not type C# into an editor. I wanted to make a PWA, not type ruby into an editor. I wanted to interface some bespoke hardware with GPIO pins, not type python into an editor. I wanted to build an ETL pipeline to make better operational decisions at work, not type code into a fucking editor.
I’m an engineer, not a typist. I get paid for my judgment and for adding value, not lines of code typed.
Actually typing the code was always just a means to an end. Can you honestly say different?
I don't understand the vitriol here. Are you saying you just sit down and start writing the code, without planning or designing the application you're writing beforehand? Surely not.
Nowadays before any code gets written, by me or by an agent, there ends up being several rounds of back-and-forth on the overall architecture and design of whatever is under consideration. I put thought into data structures, ownership and lifetimes, design patterns, overall project context, etc.
That is, IMHO, the hard part of software engineering. If you're a professional, that's the part that pays the bills. Once that part is done, is there any actual value to implementing a ring buffer by hand vs having the model do it? Is there materially more thought? I argue there is not.
I write the code that the models don't write well. I let the models write the code they're good at writing because I've got a thousand better uses for my time than implementing a ring buffer, or an API endpoint handler, or whatever, by hand.
Pretty sure most of these advancements came from people who were computer scientists first and foremost. They programmed by hand because no other method existed at the time. But there's a famous quote about computer science having very little to do with writing code.
edit: lol HN's bone-headed rate limits strike again. Oh well, conversation ends here I guess. By the time the rate limit has elapsed this conversation will be ancient history.
Nope. The hard part of software engineering is recognizing all the subtle ways in which no existing abstraction ever perfectly fits your non-trivial problem and its subproblems.
This work is never "done". I do find it amusing how every time your line of reasoning comes up, the examples are always textbook trivial problems and solutions. It's even sometimes an insistence that LLMs are "compilers" for this kind of thinking.
It's the stuff of middle manager fantasy that things are "just so" and that implementation work has less depth instead of far more. If implementation is so trivial, the world is only inching closer to demanding an explanation from your lot why you think most implementations are so bad.
To address the parent of all these replies, I agree it's a difference of personality. The "hands off" people are going extinct, and they're terrified. The future has always been about getting our hands even dirtier.
I gotta ask?: why do you think "my design is refined" means that I start without a design? The wording is fairly clear: for a design to be refined, it means it has to exist.
(I'm also not sure that vitriol is the correct word to use here; it seems, again, like needless disparagement).
Do you have an example that isn't "I use a library to do this when writing code"? This strawman comes up again and again in these types of discussion: no, I don't write a ringbuffer, I use an existing library.
You are also glossing over which group I am describing, specifically, those who are all-in on AI development and do not read nor write code.
Slop detected
I think the style essay akin to a punchy, TED-talk style persuasive essay is dead.
Whether or not this author wrote it themselves (I strongly suspect at least an AI editor), the specific style that was, for a time, very attractive has become the hallmark of AI-written prose; and, while the content doesn’t seem wrong from a particular view, it also leaves a taste of waste to me - waste that I spent that time reading something they didn’t write, full of -isms that aren’t theirs, when the thesis could have padded out far less paper.
The word count feels unearned, even if the content is fine.
Yes, it stinks.
It's one thing to have AI-written software, where the code isn't the consumable; and quite another to have AI-written essays that are intended to engage a human's critical thinking.
I am very tired of it all.
This is my favorite part too. With my own project for example, I had the agent integrate libgit into it so I could add source control to my IDE. Yes, I could have done it myself, but it would have taken me months of trying to understand the API, testing various things, and finally implementing it all. Instead, the agent did almost all the work (I still designed the architecture and how it plugged in). It took about two weeks calendar time and most of that time I was doing something else while the agent worked.
The thing is, before AI agents, I wouldn't have even attempted the work. I wouldn't have been able to afford the time.
Before AI agents, what we would have is maybe a line in the changelog, like “git support has been added” and maybe some post if there’s a substantial Ui/Ux improvement or novelty.
Now it’s just: I did something with AI (with no description of why it has been done, just what) and it was pretty fast (compared to an exaggerated estimation).
Even if it's AI generated (or AI "improved"), I'll comment on the content:
This assumes that you have the resources (time and money/AI usage budget) and the interest/motivation to do that. If you do programming as a job rather than as a hobby, the time you can spend on things like this and the budget you can spare for it will be severely limited. Also, after you have finally coaxed the LLM into generating something that fits all the requirements without breaking in new and surprising ways, has code that's not ridiculously overengineered (that's probably the real reason behind vibe coding: as long as you don't look at the horror beneath the hood, you can tell yourself everything's fine), doesn't break some convention of the codebase and has the required test coverage and other metrics, you're not only out of time for the task at hand, but also more than ready to move on to something else.
This guy can't even be bothered to type his own thoughts out, but expects us to read what claude dumped out? Typing your own thoughts is just not hard at all, I don't get it.
What I understood from TFA is that the author is complaining about formalism and bad abstractions. The latter is a real complaint, but I can’t understood viewing formalism as a burden.
At it’s core computing is about taking some information, encode it, transform it, and then decode the result. The latter can be interpreted by humans or used to drive some machinery. The value of computers is that they can do encoding/transform/decoding part reliably and really quickly. But it’s up to use to specify how.
One common trait I found with people that dislike formalism is that they have great reluctance to admit they’re wrong, or at least consider the possibility. And a formal system cleanly mark what is correct according to its axioms.
The issue with most AI practice is that they eschew reliability and guarantees of correctness (not there hasn’t been bugs previously). The proponents can talk about their goals, but they can’t explain the projects they’re working on and reason how it should be correct.
For them, it’s like seeing a chess game and deciding it’s ok if a pawn move like a knight to capture the king, because that’s the intended goal. Like “just move the piece with your hands”. Because it’s hard to devise a strategy that respect the rules. The bad play is obvious when it’s a real chess board, but imagine it’s a generic board where all pieces are little puck with a led fave for colors and types. They wouldn’t mind the pawn to change its type to knight for the illegal move and then revert to pawn once that’s done.
So something like Python and Go is pretty generic. You can code various domains with it (servers, games, apps,…), but it’s up to you to really follow the rules of that domain. Using AI code, there’s a non zero chance for a bit of cheating to happens. While it “works”, it’s not correct, and there’s some use cases that are totally wrong.
It's all relative to what your goals are and what you're most experienced with. Your "hard parts" are someone else's "easy parts".
The machine doesn't give a shit what you think is hard. You still can't throw away any of the code that you don't understand. The machine needs it all and you choose to stay ignorant.
Experience of the topic at hand absolutely still matters, and even moreso with LLMs. The unhealthy approach is to delegate your work and bury your head in the sand. The healthy approach is to use LLMs to learn and do faster.