I agree with the title, but perhaps for different reasons.
Somewhere (maybe the 1960s?) the idea crept in that programming is some kind of production process, and the "engineering" happens upstream. Elsewhere, the line between engineering design and manufacturing is the transition of a set of documents to those with the skills to turn what those documents specify into real products in a reliable, repeatable manner. That repeatability is one of the hallmarks of manufacturing. For software, all the processes reliable enough to qualify are downstream of typing `make` and striking return, ending in the binaries and the computational processes that those paying the bills desire. It's our build and deployment tools that do the construction, which means that our source code is the final, detailed design.
Weirdly, I thought the terms would be reversed… I think of a craftsman as someone who values quality over quantity, and makes everything beautiful and long lasting, while an engineer is more about productivity and tolerances and efficiency. A craftsman makes better quality but doesn’t scale the way an engineer and the factory process does, although mass produced goods sacrifice quality for quantity.
It's interesting how the words can be ambiguous like that. If I think of the distinction in the context of e.g. clothes, there's likely more engineering in fast fashion and more crafting in bespoke clothing. With food, more engineering in the food items you'd find at a gas station and more crafting at a restaurant.
>> “artisanal” coders who value the experience of coding over the final product
I don't see "artisanal" as that. It may be more that they value the details rather than the experience of coding. They value the details of the final product. Details that most people will not care about. The details that are present in bespoke clothing but missing in fast fashion, the details that are present in a good restaurant's food but missing from a gas station food item.
I think this dissonance is because people currently equate the engineering with profit optimization, as were already pretty deep into the capitalism "endgame".
But in the first phase of industrialization, the quality went up - exactly because we suddenly had specific measurements and tolerances.
The markets however did what they do best: optimize for profit. And the public markets preferred cheap over quality... At least in the consumer space. Objectively quality has significantly improved across the board with every decade. Just not in consumer goods, because of their consistent spending habits
So in my mind a craftsman is something akin to an artist.
Whereas an engineer provides solutions.
id consider that a craftsman tends to build without constraints. an enginner meets the constraints with a defined safety factor.
an engineer uses tools that represent the current state of the science, while a craftsman uses tools passed down as archaic art that require meticulous skill to use rather than repeatable math
Very little of it lasts for long. And if it does, it's legacy banking or some ossified terrible thing people are afraid to touch - not something revered.
Every piece of software today will be rewritten. By 2100 much of it will be dead and gone. Like punch cards that have rotted away.
In food contexts when I see "artisinal" I usually just think of rich white people buying the same stuff in nicer packaging and typography for twice the price.
The actual artisans don't need to advertise themselves as artisans, they just sell shit.
Actual artisans largely make "shit" and mostly leave the selling to others.
There are always exceptions, of course, and people that seek out crafted goods often want to climb over counters and into workshops .. but the crafting time tends to outweigh the selling time by a magnitude or two.
Engineering is about creating something that serves a purpose, while operating within a set of constraints. Part of that is realizing that "100% correct/reliable in all circumstances" is an unrealistic goal, since implementation time and cost is one of those constraints.
A good engineer will acknowledge this tradeoff between robustness and cost and behave accordingly. For example, if you're working on safety critical or very foundational systems like OSes, medical tech, etc you should bias very heavily in favor of robustness. If you're not, this can easily be an act of overengineering. The engineer's job is to find the right spot along the cost-correctness curve for the thing they are building.
This has always been true, and LLMs just change certain parts of the equation. For example, code writing is far less of a bottleneck than before, so "we can just try with a throwaway impl and see if this works" is suddenly economically viable. It also turns out that many things, in practice, don't need to be as correct as some of us may have believed.
We can still enjoy making quality things, but doing so is often an act of artisanship rather than engineering.
> LLMs just change certain parts of the equation. For example, code writing is far less of a bottleneck than before, so "we can just try with a throwaway impl and see if this works" is suddenly economically viable.
The economic costs of LLM use have been abstracted away, but they're still very much there. The ecological cost of building and running data centres will be a pretty heavy economic cost somewhere in the future. It's not obvious, but it still exists.
(I'm not dumping on LLMs — otherwise I wouldn't even be here. I'm not a glutton for punishment. I know well that HN users excited about LLM use now vocally outweigh, and are pretty intolerant of people who are more on the cautious/negative end of the spectrum. I don't want that trouble in my life).
> Engineering is about creating something that serves a purpose, while operating within a set of constraints.
A builder fits that description. Even a cook fits that description.
Engineering is something else. It's hard to describe what it is, probably why it has its own word. Dictionaries probably offer a definition.
> A good engineer will acknowledge this tradeoff between robustness and cost and behave accordingly.
An engineer will never intentionally produce something shoddy for cost reasons. They will simply refuse to do it. What you are getting at it some tasks don't require an engineer at all. You want to build a bridge to span a kilometer of water? You need an engineer. You need to occasionally cross a ditch? Anyone could lay plank across. No engineer required. The author makes this point too, with software craftsmen.
But when nobody will die from your decision (and to be clear I think security is extremely important, but moreso for banking/healthcare than a private wow server), then “shoddy” becomes a matter of reputation/taste vs value/marketability.
The demand curve is different because it’s low stakes, like throwing a bad party or oversalting food. And part of the problem in software to begin with is too much LARPing about scale/engineering for things that don’t need it, as well as lack of accountability or care for things that do.
You can still be an “engineer” working on a game, it’s just more about making the game fun than making it safe. Or, you create a process for making and test hundreds of experimental bridges, and refine/invest additional time in understanding and verifying the safety of the best one.
Isn't there a difference between making things that code does and the code itself? Ive seen truly beautiful software with terrible to follow but effective code and I've seen beautiful code that while technically amazing didn't do anything of substance. Software is like woodworking, it includes all levels of care and product outcomes.
A good chunk of engineering is putting together reliable systems from unreliable parts.
You build in safeguards, redundancy, defense in depth, recovery systems. You build models of the system and prove characteristics about it.
Software is fundamentally automation. LLMs enable automating the construction of software itself. They're much faster and cheaper than people, and they're more unreliable. (People are unreliable too!)
The immediate challenge of these times is figuring out how to reliably construct reliable software in the large, over the longer term, reliably. This is an engineering challenge, and the only way we'll get to the other side of it is by trying to do it. Things will be rough, there will be a Cambrian explosion of techniques, most approaches will fail, and many more won't survive as models improve on quality and capability. But we'll figure it out.
Making things by hand, as in the time before agentic coding, can be engineering too, but it is not the core challenge of these times, and it will soon be a hobby, or possibly a kind of luxury good. You will no more want hand-written software than you'll want a hand-made car. It will not have the precision, performance or reliability of machine-made software.
Strong agree. I think the fundamental challenge of working in fields that increasingly become AI-enabled will be the ability to understand and direct large or intricate systems without prior knowledge/the advantage of having built the model as implemented. That’s already how it works in complex domains or large businesses.
It does require a different kind of ego/abilities than before. My (negative) framing of the whiplash effect is that it’s a reckoning of “process fetishism”/a bad kind of careerism in the tech hiring market (because for the labor market to work, candidates need to be evaluable and sortable by businesses, and many people build an identity/optimize for legibility around “best practices” or very particular “technologies” which might get them a job).
Ultimately, you need to know and learn/be responsible for stuff, and be able to help people with your labor, not be “a type of person” that isn’t effective at the task of helping. But at the same time knowing things and being able to take accountability/help people remains critical, especially because that’s what people will want to pay for even as “time spent typing it in” decreases.
Personally, I think it will be a good thing because software and “tech” will become a more strongly domain-driven/enabling medium for real-world or specialized things. IE it is the end to “software for its own sake” or “willingness to type it in and play with Jira/jenkins/frameworks” and the beginning of something that is more applicable or knowledge-building rather than “being the X for Y at Z”. Harder but more fun :)
Cars use AI for steering control (et al) and technology very similar to RLVR (hold the RL), eg property-based testing and formal verification, to prove the soundness of their embedded systems. Most of us in San Francisco trust Waymo with our lives more than human uber/Lyft drivers
As long as you can verify/test and take accountability for the thing you put your name on there’s no reason not to treat it as a process or search problem rather than one you assemble yourself by hand. The only problem is that it’s ironically much harder and more engineering than most “software engineers” are willing or able to do.
I spent several years working on permutation testing/experimentation and creating e2e verification of infrastructure because at scale, or when reliability/correctness are critical, you cannot rely on a single person’s mental model, or for the world to not drift around a system as it works now. That kind of system is what allows you to use LLMs or engineers who don’t know everything about it to improve or change it. It’s more science than art, which is often (but not always) what you want
The vocabulary point matters: calling careful work artisanal turns reliability into a personal taste when it is often the core engineering requirement.
I find more pleasure and satisfaction by programming at a higher altitude, at the system level. This zooming out gives you a better feel for building an effective scaffold and you can iterate on ideas faster.
Thank you for sharing this. This is a concern many of us had — I sure did — but I always felt like an unfortunate bystander with little control over the situation. This posts shows how we can at least start talking about this in a constructive manner.
But can they compete with my shade grown software? It does result in a 40% markup, but there's no putting a price on being raised in a loving environment, is there.
I've gone back over most of my contributions to open source using LLMs and honestly, even though it was my best work at the time, there are big gaps that they find right away.
The myth that we've been shipping perfect code for years, but you can't trust LLMs, is just subjective blindness. People can't see the issues that they can't see, definitionally.
You can absolutely use the exact techniques we used to use in "the old days" to produce reliable code with LLMs generating most of it. The issue is, it's really not a lot less conceptual and intellectual effort than in "the old days", at root. You speed up the programming part, but the rest is still a hard slog, so nobody is out here doing really thorough testing in ways we used to dream of.
I think the issue people run into is that the types of errors the LLM makes are ones humans wouldn’t make, like having a basic misunderstanding of the goal of the software and making silly logic errors that technically work, but don’t serve the correct purpose.
This can be seen more clearly with self-driving cars as an example. A self-driving car may be safer than a human driver, but when the self-driving car plows into the side of a semi truck in broad daylight… that’s generally not a mistake a human would make. Humans and AI have different failure modes, so when AI fails where we generally wouldn’t, it really stands out and gets judged harshly.
Likewise, I've found many bugs using LLMs in the small software libraries I hand wrote and considered complete and correct - even though it was my sole focus at the time and I thought I had perfected it
This seems to be changing, in the year of heavy LLM use that I’ve done.
When I started, I had to review every line, and frequently found bugs, but lately, I’ve been impressed with the quality of the code. I don’t think that I’ve had to make any code-level adjustments, in a while.
Do you have any analytic basis to make that assertion? I haven't found that to be true, it'd be more accurate in my experience to say that LLM code has different issues than the code humans write.
I won't lie, of course my code has bugs. The difference, as I see it, is the kinds of bugs that manifest, and how well they can be avoided.
There are two steps to writing the program: building a model in your head to map understanding to algorithms, and then implementing the algorithm in code (and of course this can get recursive if the algorithm relies on other high-level mechanisms, like data structures).
I have found that most of the time, the kind of bugs that unit tests find are typos, i.e. mistakes in the second step; but the errors that actually cost time to resolve are errors in understanding, i.e. the first step.
They can't be found with testing or verification because what it means for code to be correct depends on the specification, and the error is that the specification itself is incorrect. Asking an LLM to check this one specific part of the software is thus useless, and whole-program analysis is not cheap enough to employ at this point.
So what about avoidance? When I say hand-written code is 100% correct (or at least approaches that number), I mean that with experience, I learn more about which models tend to be correct, and thus avoid bugs of the latter kind by construction. Of course typos still exist, which is why I write unit tests, and I expect LLMs to be able to find them as well; but I believe the only way to avoid incorrect models is to learn stuff by doing, failing and failing again, figuring out nitty-gritty low-level details, until at some point you become an expert in that area and know what to use.
I would call myself an artisanal programmer. Software Engineers are some of the least likable people I've ever met and being associated with them is cringe. Questions like, "Why are you using Notepad++ instead of using VSCode with 100+ plugins?" in a very condescending manner gets old very quickly. They need the title of Engineer because deep down they are very insecure.
On the plus side, they're usually promoted very quickly to management and never code again.
I think you might be interested in reading the post Are We Really Engineers (https://www.hillelwayne.com/post/are-we-really-engineers/), which in part covers the point about whether "engineer" is closer to a profession designator or a respectable title. It really surprised me when I read it first time!
> I would call myself an artisanal programmer. Software Engineers are (...) very condescending (...) They need the title of Engineer because deep down they are very insecure.
Yes, these are the only two options. That is definitely true.
It's of course impossible to have any nuance or middle ground here where you use LLMs to assist while you still focus on the engineering design decisions and the quality.
I'm reasonably sure/hopeful all of these discussions will be as important as people's discussions about whether using vim makes you a real programmer or not.
"Does it work" is what matters. We already know that "do this make no mistakes" works on some things. And then some things that are very "wide" e g "integrations for lots of different things" you basically write a new layer of software on top of the software in specs and .md and that yields a software project that you can mostly just add features by asking for them. But there's still deep narrow projects where creating that context is way more work than just implementing it. And then you have some projects where you can mix approaches and use the "metasoftware" for all the cicd and boring bits but not the core. I'd argue all of the above it's kind of meaningless to try to distinguish it as even if it's fully handrolled an llms still there as a search engine and task runner.
I agree with the title, but perhaps for different reasons.
Somewhere (maybe the 1960s?) the idea crept in that programming is some kind of production process, and the "engineering" happens upstream. Elsewhere, the line between engineering design and manufacturing is the transition of a set of documents to those with the skills to turn what those documents specify into real products in a reliable, repeatable manner. That repeatability is one of the hallmarks of manufacturing. For software, all the processes reliable enough to qualify are downstream of typing `make` and striking return, ending in the binaries and the computational processes that those paying the bills desire. It's our build and deployment tools that do the construction, which means that our source code is the final, detailed design.
Weirdly, I thought the terms would be reversed… I think of a craftsman as someone who values quality over quantity, and makes everything beautiful and long lasting, while an engineer is more about productivity and tolerances and efficiency. A craftsman makes better quality but doesn’t scale the way an engineer and the factory process does, although mass produced goods sacrifice quality for quantity.
It's interesting how the words can be ambiguous like that. If I think of the distinction in the context of e.g. clothes, there's likely more engineering in fast fashion and more crafting in bespoke clothing. With food, more engineering in the food items you'd find at a gas station and more crafting at a restaurant.
>> “artisanal” coders who value the experience of coding over the final product
I don't see "artisanal" as that. It may be more that they value the details rather than the experience of coding. They value the details of the final product. Details that most people will not care about. The details that are present in bespoke clothing but missing in fast fashion, the details that are present in a good restaurant's food but missing from a gas station food item.
I think this dissonance is because people currently equate the engineering with profit optimization, as were already pretty deep into the capitalism "endgame".
But in the first phase of industrialization, the quality went up - exactly because we suddenly had specific measurements and tolerances.
The markets however did what they do best: optimize for profit. And the public markets preferred cheap over quality... At least in the consumer space. Objectively quality has significantly improved across the board with every decade. Just not in consumer goods, because of their consistent spending habits
So in my mind a craftsman is something akin to an artist. Whereas an engineer provides solutions.
id consider that a craftsman tends to build without constraints. an enginner meets the constraints with a defined safety factor.
an engineer uses tools that represent the current state of the science, while a craftsman uses tools passed down as archaic art that require meticulous skill to use rather than repeatable math
Software is ephemeral.
Very little of it lasts for long. And if it does, it's legacy banking or some ossified terrible thing people are afraid to touch - not something revered.
Every piece of software today will be rewritten. By 2100 much of it will be dead and gone. Like punch cards that have rotted away.
Your bank's mainframe would like to know your location.
survivorship bias. while something like 20% of code in production today runs on mainframes, that probably represents <0.1% of all code ever written
Games
I share the sentiment as a gamer but according to preservationists the majority of games have already been lost to history.
Good software runs for decades without maintenance. And by 2100, most of us will be gone.
[dead]
In food contexts when I see "artisinal" I usually just think of rich white people buying the same stuff in nicer packaging and typography for twice the price.
The actual artisans don't need to advertise themselves as artisans, they just sell shit.
Actual artisans largely make "shit" and mostly leave the selling to others.
There are always exceptions, of course, and people that seek out crafted goods often want to climb over counters and into workshops .. but the crafting time tends to outweigh the selling time by a magnitude or two.
The true crossovers are the artisans that make crafting a performance and sell by making, eg: Lino Tagliapietra - https://www.youtube.com/watch?v=luU1mlCZc8U
How constructive to make this... racial.
Engineering is about creating something that serves a purpose, while operating within a set of constraints. Part of that is realizing that "100% correct/reliable in all circumstances" is an unrealistic goal, since implementation time and cost is one of those constraints.
A good engineer will acknowledge this tradeoff between robustness and cost and behave accordingly. For example, if you're working on safety critical or very foundational systems like OSes, medical tech, etc you should bias very heavily in favor of robustness. If you're not, this can easily be an act of overengineering. The engineer's job is to find the right spot along the cost-correctness curve for the thing they are building.
This has always been true, and LLMs just change certain parts of the equation. For example, code writing is far less of a bottleneck than before, so "we can just try with a throwaway impl and see if this works" is suddenly economically viable. It also turns out that many things, in practice, don't need to be as correct as some of us may have believed.
We can still enjoy making quality things, but doing so is often an act of artisanship rather than engineering.
> LLMs just change certain parts of the equation. For example, code writing is far less of a bottleneck than before, so "we can just try with a throwaway impl and see if this works" is suddenly economically viable.
The economic costs of LLM use have been abstracted away, but they're still very much there. The ecological cost of building and running data centres will be a pretty heavy economic cost somewhere in the future. It's not obvious, but it still exists.
(I'm not dumping on LLMs — otherwise I wouldn't even be here. I'm not a glutton for punishment. I know well that HN users excited about LLM use now vocally outweigh, and are pretty intolerant of people who are more on the cautious/negative end of the spectrum. I don't want that trouble in my life).
> Engineering is about creating something that serves a purpose, while operating within a set of constraints.
A builder fits that description. Even a cook fits that description.
Engineering is something else. It's hard to describe what it is, probably why it has its own word. Dictionaries probably offer a definition.
> A good engineer will acknowledge this tradeoff between robustness and cost and behave accordingly.
An engineer will never intentionally produce something shoddy for cost reasons. They will simply refuse to do it. What you are getting at it some tasks don't require an engineer at all. You want to build a bridge to span a kilometer of water? You need an engineer. You need to occasionally cross a ditch? Anyone could lay plank across. No engineer required. The author makes this point too, with software craftsmen.
But when nobody will die from your decision (and to be clear I think security is extremely important, but moreso for banking/healthcare than a private wow server), then “shoddy” becomes a matter of reputation/taste vs value/marketability.
The demand curve is different because it’s low stakes, like throwing a bad party or oversalting food. And part of the problem in software to begin with is too much LARPing about scale/engineering for things that don’t need it, as well as lack of accountability or care for things that do.
You can still be an “engineer” working on a game, it’s just more about making the game fun than making it safe. Or, you create a process for making and test hundreds of experimental bridges, and refine/invest additional time in understanding and verifying the safety of the best one.
Highly recommend this if anyone wants to think more about what engineering is: https://mitpressbookstore.mit.edu/book/9781728280455
we built cathedrals without a detailed understanding of load calculations and material properties
I prefer the term "classically trained programmer." :-)
Isn't there a difference between making things that code does and the code itself? Ive seen truly beautiful software with terrible to follow but effective code and I've seen beautiful code that while technically amazing didn't do anything of substance. Software is like woodworking, it includes all levels of care and product outcomes.
A good chunk of engineering is putting together reliable systems from unreliable parts.
You build in safeguards, redundancy, defense in depth, recovery systems. You build models of the system and prove characteristics about it.
Software is fundamentally automation. LLMs enable automating the construction of software itself. They're much faster and cheaper than people, and they're more unreliable. (People are unreliable too!)
The immediate challenge of these times is figuring out how to reliably construct reliable software in the large, over the longer term, reliably. This is an engineering challenge, and the only way we'll get to the other side of it is by trying to do it. Things will be rough, there will be a Cambrian explosion of techniques, most approaches will fail, and many more won't survive as models improve on quality and capability. But we'll figure it out.
Making things by hand, as in the time before agentic coding, can be engineering too, but it is not the core challenge of these times, and it will soon be a hobby, or possibly a kind of luxury good. You will no more want hand-written software than you'll want a hand-made car. It will not have the precision, performance or reliability of machine-made software.
Strong agree. I think the fundamental challenge of working in fields that increasingly become AI-enabled will be the ability to understand and direct large or intricate systems without prior knowledge/the advantage of having built the model as implemented. That’s already how it works in complex domains or large businesses.
It does require a different kind of ego/abilities than before. My (negative) framing of the whiplash effect is that it’s a reckoning of “process fetishism”/a bad kind of careerism in the tech hiring market (because for the labor market to work, candidates need to be evaluable and sortable by businesses, and many people build an identity/optimize for legibility around “best practices” or very particular “technologies” which might get them a job).
Ultimately, you need to know and learn/be responsible for stuff, and be able to help people with your labor, not be “a type of person” that isn’t effective at the task of helping. But at the same time knowing things and being able to take accountability/help people remains critical, especially because that’s what people will want to pay for even as “time spent typing it in” decreases.
Personally, I think it will be a good thing because software and “tech” will become a more strongly domain-driven/enabling medium for real-world or specialized things. IE it is the end to “software for its own sake” or “willingness to type it in and play with Jira/jenkins/frameworks” and the beginning of something that is more applicable or knowledge-building rather than “being the X for Y at Z”. Harder but more fun :)
A whole bunch of assumptions and beliefs passed off for truths.
LLMs have very little to do with engineering, unless you let a pair of dice decide how you build a house.
Cars are not built by AIs, they're built by extremely precise robots, over precise instructions.
I'd VERY much want a hand-made car over an LLM-made car, thank you.
Because I do want the precision, reliability and performance that an LLM-made car won't ever be able to guarantee.
Cars use AI for steering control (et al) and technology very similar to RLVR (hold the RL), eg property-based testing and formal verification, to prove the soundness of their embedded systems. Most of us in San Francisco trust Waymo with our lives more than human uber/Lyft drivers
As long as you can verify/test and take accountability for the thing you put your name on there’s no reason not to treat it as a process or search problem rather than one you assemble yourself by hand. The only problem is that it’s ironically much harder and more engineering than most “software engineers” are willing or able to do.
I spent several years working on permutation testing/experimentation and creating e2e verification of infrastructure because at scale, or when reliability/correctness are critical, you cannot rely on a single person’s mental model, or for the world to not drift around a system as it works now. That kind of system is what allows you to use LLMs or engineers who don’t know everything about it to improve or change it. It’s more science than art, which is often (but not always) what you want
The vocabulary point matters: calling careful work artisanal turns reliability into a personal taste when it is often the core engineering requirement.
I find more pleasure and satisfaction by programming at a higher altitude, at the system level. This zooming out gives you a better feel for building an effective scaffold and you can iterate on ideas faster.
You mean by vibecoding? Don't call that programming, for God's sake
Thank you for sharing this. This is a concern many of us had — I sure did — but I always felt like an unfortunate bystander with little control over the situation. This posts shows how we can at least start talking about this in a constructive manner.
But can they compete with my shade grown software? It does result in a 40% markup, but there's no putting a price on being raised in a loving environment, is there.
I carefully bottle feed every function by hand, and let it out to pasture at least twice a day.
it's organic right?
What are the examples of artfully crafted software? What software can never be made with LLMs?
Not a loaded question but a genuine one.
Couldn't take an article seriously that started with the author claiming that code he writes by hand is "100% correct"
Bruh
I've gone back over most of my contributions to open source using LLMs and honestly, even though it was my best work at the time, there are big gaps that they find right away.
The myth that we've been shipping perfect code for years, but you can't trust LLMs, is just subjective blindness. People can't see the issues that they can't see, definitionally.
You can absolutely use the exact techniques we used to use in "the old days" to produce reliable code with LLMs generating most of it. The issue is, it's really not a lot less conceptual and intellectual effort than in "the old days", at root. You speed up the programming part, but the rest is still a hard slog, so nobody is out here doing really thorough testing in ways we used to dream of.
I think the issue people run into is that the types of errors the LLM makes are ones humans wouldn’t make, like having a basic misunderstanding of the goal of the software and making silly logic errors that technically work, but don’t serve the correct purpose.
This can be seen more clearly with self-driving cars as an example. A self-driving car may be safer than a human driver, but when the self-driving car plows into the side of a semi truck in broad daylight… that’s generally not a mistake a human would make. Humans and AI have different failure modes, so when AI fails where we generally wouldn’t, it really stands out and gets judged harshly.
Likewise, I've found many bugs using LLMs in the small software libraries I hand wrote and considered complete and correct - even though it was my sole focus at the time and I thought I had perfected it
Same. Frontier LLM code review proved to be a very humbling experience for me.
I have had the same experience.
I’m still in the process of revisiting and refining the many hand-coded dependencies that I’ve created, over the years.
Most of the issues found, were corner cases, that would likely never be encountered, but they are issues, nonetheless.
We definitely haven't been writing completely correct code in the past. But even so, the code LLMs write has more issues than the code humans write.
This seems to be changing, in the year of heavy LLM use that I’ve done.
When I started, I had to review every line, and frequently found bugs, but lately, I’ve been impressed with the quality of the code. I don’t think that I’ve had to make any code-level adjustments, in a while.
Do you have any analytic basis to make that assertion? I haven't found that to be true, it'd be more accurate in my experience to say that LLM code has different issues than the code humans write.
Six months ago this ceased to be the case for some (if not most), and the quality of LLM generated code has increased over time.
I'm sorry to be the bearer of bad news: human coding has not improved a lick since then.
I won't lie, of course my code has bugs. The difference, as I see it, is the kinds of bugs that manifest, and how well they can be avoided.
There are two steps to writing the program: building a model in your head to map understanding to algorithms, and then implementing the algorithm in code (and of course this can get recursive if the algorithm relies on other high-level mechanisms, like data structures).
I have found that most of the time, the kind of bugs that unit tests find are typos, i.e. mistakes in the second step; but the errors that actually cost time to resolve are errors in understanding, i.e. the first step.
They can't be found with testing or verification because what it means for code to be correct depends on the specification, and the error is that the specification itself is incorrect. Asking an LLM to check this one specific part of the software is thus useless, and whole-program analysis is not cheap enough to employ at this point.
So what about avoidance? When I say hand-written code is 100% correct (or at least approaches that number), I mean that with experience, I learn more about which models tend to be correct, and thus avoid bugs of the latter kind by construction. Of course typos still exist, which is why I write unit tests, and I expect LLMs to be able to find them as well; but I believe the only way to avoid incorrect models is to learn stuff by doing, failing and failing again, figuring out nitty-gritty low-level details, until at some point you become an expert in that area and know what to use.
I also write 100% correct code, it does exactly what I wrote it to do (not compile).
It may not be 100%, but human code is objectively more reliable and higher quality than any LLM generated slop code.
she*
Or, call yourself whatever you like.
I would call myself an artisanal programmer. Software Engineers are some of the least likable people I've ever met and being associated with them is cringe. Questions like, "Why are you using Notepad++ instead of using VSCode with 100+ plugins?" in a very condescending manner gets old very quickly. They need the title of Engineer because deep down they are very insecure.
On the plus side, they're usually promoted very quickly to management and never code again.
I think you might be interested in reading the post Are We Really Engineers (https://www.hillelwayne.com/post/are-we-really-engineers/), which in part covers the point about whether "engineer" is closer to a profession designator or a respectable title. It really surprised me when I read it first time!
Exactly, when the real question is "why are you using notepad++ instead of emacs, you philistine?"
Because nobody showed him vi?
> I would call myself an artisanal programmer. Software Engineers are (...) very condescending (...) They need the title of Engineer because deep down they are very insecure.
Jokes really do write themselves sometimes...
Sounds similar to Rust programmers
"I’ve seen it before, though: it’s very much part of the fascist playbook."
Holy reach
Way ahead of ya.
Fully agree with this, careful work is foundationally engineering. Slopping and not reviewing work is not.
Yes, these are the only two options. That is definitely true.
It's of course impossible to have any nuance or middle ground here where you use LLMs to assist while you still focus on the engineering design decisions and the quality.
That would fall under "careful engineering"
I'm reasonably sure/hopeful all of these discussions will be as important as people's discussions about whether using vim makes you a real programmer or not.
"Does it work" is what matters. We already know that "do this make no mistakes" works on some things. And then some things that are very "wide" e g "integrations for lots of different things" you basically write a new layer of software on top of the software in specs and .md and that yields a software project that you can mostly just add features by asking for them. But there's still deep narrow projects where creating that context is way more work than just implementing it. And then you have some projects where you can mix approaches and use the "metasoftware" for all the cicd and boring bits but not the core. I'd argue all of the above it's kind of meaningless to try to distinguish it as even if it's fully handrolled an llms still there as a search engine and task runner.
[flagged]
[flagged]