> So if copying a useful piece of code from Stack Overflow has always been acceptable
This has not "always been acceptable"; copy-pasta was a pejorative not that long ago, and people have been fired for simply copying code from SO and using it without understanding it.
distances
Yes, and often it was clear what was copied and what was written by your colleague. Everyone has a signature style of code. I would often in review catch odd looking code, find the origin of it, and require a rewrite.
kayo_20211030
> The developers who stand out will be the ones who understand the systems.
That has always been true. AI doesn't change it. It just rearranges some elements that come ahead of that understanding. The volume and velocity are challenges but the understanding and judgement is what separates the good and the great.
BTW: "systems" in my world include not just the technology components but also the humans who operate, adjust and manage all the pieces, and the processes that control it all.
cyanydeez
It is an interesting diametric inversion: before AI, you had people designing good code from the ground up for the love of the game and you had businesses cutting corner due to budgets.
Now you have AI infilitrating both sectors, and well.
Ok, so it's probably going to be the same problem. With AI, I can now explore more docs and more tests, and push out into the edge cases, all because I've got a local LLM and have no real worry about electricity costs.
Businesses on the other hand, will be addicted to LLMs and will have token budgets and will soon enough go back to just good enough software designs.
kayo_20211030
I think so. Two traditional and _almost_ disjoint sets, the technology realm and the business realm, will start to (be forced to?) have much greater overlap. There have always been political battles along the boundary, but this upcoming one will be bloody and long. The current structures and control mechanisms will have to change appreciably for any of the promises of AI to be realized.
zer00eyz
Im not sure thats why businesses are straying from more LLM use.
Finding where AI is moving the needle has been hard, if not impossible.
Because code, by it self has never moved the needle. It's the product, what the code does that moves the needle.
Building the wrong thing, faster, is just a speed run to a legacy code base. That isnt your development teams fault.
kayo_20211030
> It's the product, what the code does that moves the needle.
Never a truer word said. It's the only thing that moves the needle.
I'm not sure that businesses are straying from AI. I reckon everyone's on board. but AI is now accessible to the business folks - callow as they are to the requirements of the technology components - and it's bound to run up against the technology folks trying to wave them off when enthusiastic excesses threaten what the code does, now or in the future. There'll be adjustments on both sides.
zer00eyz
> I'm not sure that businesses are straying from AI.
Clamping down might be a better choice of words here.
I think what most of the HN set misses is that there is a ton of code being written that they just don't see. It's code that prior to AI never would have existed. That expensive programing resource (this is most of us) doesn't have time to go whip up those time saving scripts for the people in accounting and marketing who need them. And it's not like these people are gonna gab that they saved themselves 3 hours a week with some basic python. They are gonna take that time back and shut up about it.
cyanydeez
I'm fairly certain 90% of github downtime is that "corporate dark code written by ai"
mpalczewski
volume and velocity used to stand out, you could get very far with it, and if you had built a career on that(I had), your career is now over or you pivot. Volume and velocity also had it's own quality and over time you did so much that the reps just by themselves got you to the next level. None of that is true anymore. Some skills became important and some skills became useless. this industry has always moved fast and this is just another round of adapt or die.
WillEMac
I think there is some nuisance on the redundancy required for the software.
For example I've worked in clean tech where PLC programming controls turbines, complete understanding is required here. Every bug and LOC associated a human needs to be in the loop, it's worth the time.
Alternatively I do game development, and I don't think there is value in understanding the complete debugging process. For example I accidentally bound spacebar-release to two things in multiplayer causing a co-op glitch. I do not need to search for this needle in a haystack to debug, that is a bad use of time.
>If writing code becomes cheap and accessible to everyone, then writing code stops being much of a differentiator. The developers who stand out will be the ones who understand systems.
I agree especially for limits/boundary conditions. In the game I'm working on, fundamentally understanding 500 GPU vs. CPU controlled fish on screen and their limitations is required to be a good architect, or this game will run at 10fps.
FrustratedMonky
Scale of the impact.
If your game was being played by a million people paying a subscription. Then it would be worth debugging it.
pas
Still, even current AI/LLMs can do debugging.
For example after an hour of process of elimination it finds the bug, reproduces it, then it recommends a ~1 line fix. Then that's where one should spend their attention budget, and think through the consequences, weighing positives and negatives, and then either asking for a different fix, not merging, or accepting it. This is a lot more productive IMHO.
jebarker
I fall somewhere in the middle of the spectrum of developers the author describes. I use AI daily for limited code writing and lots of debugging. I agree with the author that things go off the rails when you stop truly reviewing its output and just click accept to get the thrill of productivity. I don’t think using AI for debugging means you have to do that though, it’s still a choice. As an AI-human team I have had the experience many times now of debugging an issue in a complex system that I simply don’t think I could have done alone or in a reasonable amount of time. I don’t think this is a reflection of my low abilities - it’s because the AI brings to the table skills that I’ll never have like reading through and correlating huge amounts of logs across many runs of the same system on different compute nodes in a cluster. Once it finds a needle in the haystack I can still take the time to understand and reason about what it found though.
ssivark
The author makes an important point about ownership but that got watered down to code understanding and debugging. What matter is not just ownership of the code that got written, but also ownership of the problem identification and the choice of solution. I wrote about this recently from the slightly different angle of conversational tempo [1], but the shared crux is that we want AI to act as a cognitive companion and help us understand the situation, identify the problem and make decisions -- instead of the AI running off to prematurely "solve" the problem and then put the burden on the user to figure out what the hell just happened and how it was only marginally correlated with intent.
> And the consequences become particularly serious when something happens that the machine can't solve
Sadly the bot-gulled will always say "But the next model will be good enough to do that!".
aetherspawn
Judging by the rate of things it probably will be
eviks
> Nobody has every detail of all of them memorized.
That was never the requirement, you've made it up to avoid addressing the real argument
> So if copying a useful piece of code from Stack Overflow has always been acceptable,
Not really, the thing you partially hide in "useful" is the quality assessment. Blindly copy&pasting code was "never" "acceptable"
> why would asking a machine to produce that code be fundamentally different?
Because the previous premise is wrong, but also this one - it will be different code with different tradeoffs, at least try to make any argument why the situations are identical
zingar
I think I do agree with the central point but a point of order is that if you tell AI to fix the bug and then tell it to fix the next error you might still be building an important skill: learning how to make the AI get good results.
chrisjj
That kinda presumes you get good results.
All you're sure to get is a bigger bill for tokens.
Terr_
It also assumes the people will somehow develop the skill to verify whether the LLM-result is "good".
That's not guaranteed to happen and it's not a new problem, since it happens when managers are unable to detect problems in the team's product or output.
_bobm
In your closing thoughts, you don't mention what is this staying firmly in control? how do you stay firmly in control while reaping the benefit of the model while being more productive?
because if you start a curriculum over what the model wrote then, one can argue, you are better off writing it yourself in the first place.
jobuildsstuff
One concrete answer from my own small tool: move the things you must stay in control of out of your head and into tests. Our privacy rules (drafts never stored or logged) are executable, so any patch that quietly violates them fails the suite whether or not I reviewed that diff carefully that day. I still read the code, but the invariants no longer depend on my attention holding.
pas
just FYI for anyone who doesn't know about this amazing tool yet:
>Let the AI write the code, not design the solutions.
I don't think design is necessarily out of reach for AI. As usual, the closer you get to the bleeding edge of what's been done vs. what's possible, the more thought needs to go into a design for it to be considered good. And TBH, even if you only make it to "it works", that's still laudable. There's plenty of profitable companies with terrible designs, technical debt, and broken systems built before AI, and that's why often these arguments fall flat for me.
I like the idea of mostly getting average designs out of AI. I am tired of running into overly complicated solutions to seemingly simple problems. Microservices vs. Monoliths for example. Maybe they thought they saw something that needed that complexity which was credible before, but they have gone and left someone else with their decisions, and left any credibility to the void. They're just playing the game though because there's is/was an incentive to get micro services on your resume for the next job.
dunlin
The hardest part is knowing what you forgot. You can't check for gaps you don't know exist.
jt2190
> AI can create the illusion that you understand a system because it can make the system work for you. You ask a question and get an answer. You encounter an error and get a patch. The patch doesn't work, so you provide the new error and get another patch. Eventually the machine finds something that works.
> From the outside, this looks like competence. But if you don't understand why the solution works, you're not actually becoming more capable. You're becoming dependent on the machine to maintain the illusion.
So many things in life operate exactly like this: We don’t need to understand the why, we just accept the solution as-is and move on. An experienced professional has another skill: keeping track of which things matter enough to dig in to and develop mastery, and which things can be “good enough”. This is also informed by the “intuition of how machines behave” that the author mentions.
0x445442
I realized recently the LLMs are calling bullshit on the moniker of engineer or programmer that I've bestowed on myself over the course of my career. The current LLMs are making it quite easy to seperate software design from implementation. I used to be firmly in the camp that one really needed to roll up their sleves, sit down with an editor and start banging away until the software evolved and coalesced around a solution.
I convinced myself that functional specs and detailed design documents were not needed because they wouldn't be kept in sync with the code. But the LLMs are essentially turning the synthesis of the code from those documents to a compilation step of sorts.
Now I must ponder the question, what portions of the acts of coding, designing and delivering a working product were the portions that bring me joy. I've been attempting to answer this question by making a concerted effort to delegate the coding to the LLMs and reviewing if the code conforms to the designs I've written down. This process is much closer to the historical engineering disciplines but I have to say, its not been easy.
My advice to the the more junior reading this. Experiment with different functional and design spec formats that best serve the LLMs and develop the skill of writing these and then managing the LLMs.
TLDR, the LLMs are giving the term Software Engineering actual meaning.
fluoridation
>The current LLMs are making it quite easy to seperate software design from implementation.
I don't really agree. This kind of division of labor has always been possible, with architects doing the design and engineers/programmers doing the implementation. Architects who design systems with lofty requirements with no regard for the cost of their decisions are kind of a meme in the industry. I don't believe it's really possible to separate design from implementation, unless the person specifying the design is really knowledgeable about the problem space.
0x445442
The Architects you're describing aren't reviewing the code and making suggestions for changes so your comparing apples and oranges. What I'm describing is more of a team lead to team members relationship.
fluoridation
I understand that. That review process is a bridge that imposes a maximum separation between design and implementation (that is to say, they can be separated so far, and no further). The two can't be fully decoupled.
This has not "always been acceptable"; copy-pasta was a pejorative not that long ago, and people have been fired for simply copying code from SO and using it without understanding it.
That has always been true. AI doesn't change it. It just rearranges some elements that come ahead of that understanding. The volume and velocity are challenges but the understanding and judgement is what separates the good and the great.
BTW: "systems" in my world include not just the technology components but also the humans who operate, adjust and manage all the pieces, and the processes that control it all.
Now you have AI infilitrating both sectors, and well.
Ok, so it's probably going to be the same problem. With AI, I can now explore more docs and more tests, and push out into the edge cases, all because I've got a local LLM and have no real worry about electricity costs.
Businesses on the other hand, will be addicted to LLMs and will have token budgets and will soon enough go back to just good enough software designs.
Finding where AI is moving the needle has been hard, if not impossible.
Because code, by it self has never moved the needle. It's the product, what the code does that moves the needle.
Building the wrong thing, faster, is just a speed run to a legacy code base. That isnt your development teams fault.
Never a truer word said. It's the only thing that moves the needle.
I'm not sure that businesses are straying from AI. I reckon everyone's on board. but AI is now accessible to the business folks - callow as they are to the requirements of the technology components - and it's bound to run up against the technology folks trying to wave them off when enthusiastic excesses threaten what the code does, now or in the future. There'll be adjustments on both sides.
https://olakai.ai/blog/uber-ai-budget-blowout/
https://www.404media.co/companies-are-throttling-employees-a...
Clamping down might be a better choice of words here.
I think what most of the HN set misses is that there is a ton of code being written that they just don't see. It's code that prior to AI never would have existed. That expensive programing resource (this is most of us) doesn't have time to go whip up those time saving scripts for the people in accounting and marketing who need them. And it's not like these people are gonna gab that they saved themselves 3 hours a week with some basic python. They are gonna take that time back and shut up about it.
For example I've worked in clean tech where PLC programming controls turbines, complete understanding is required here. Every bug and LOC associated a human needs to be in the loop, it's worth the time.
Alternatively I do game development, and I don't think there is value in understanding the complete debugging process. For example I accidentally bound spacebar-release to two things in multiplayer causing a co-op glitch. I do not need to search for this needle in a haystack to debug, that is a bad use of time.
>If writing code becomes cheap and accessible to everyone, then writing code stops being much of a differentiator. The developers who stand out will be the ones who understand systems.
I agree especially for limits/boundary conditions. In the game I'm working on, fundamentally understanding 500 GPU vs. CPU controlled fish on screen and their limitations is required to be a good architect, or this game will run at 10fps.
If your game was being played by a million people paying a subscription. Then it would be worth debugging it.
For example after an hour of process of elimination it finds the bug, reproduces it, then it recommends a ~1 line fix. Then that's where one should spend their attention budget, and think through the consequences, weighing positives and negatives, and then either asking for a different fix, not merging, or accepting it. This is a lot more productive IMHO.
[1] https://woventhought.substack.com/p/ai-assistants-need-adapt...
Sadly the bot-gulled will always say "But the next model will be good enough to do that!".
That was never the requirement, you've made it up to avoid addressing the real argument
> So if copying a useful piece of code from Stack Overflow has always been acceptable,
Not really, the thing you partially hide in "useful" is the quality assessment. Blindly copy&pasting code was "never" "acceptable"
> why would asking a machine to produce that code be fundamentally different?
Because the previous premise is wrong, but also this one - it will be different code with different tradeoffs, at least try to make any argument why the situations are identical
All you're sure to get is a bigger bill for tokens.
That's not guaranteed to happen and it's not a new problem, since it happens when managers are unable to detect problems in the team's product or output.
because if you start a curriculum over what the model wrote then, one can argue, you are better off writing it yourself in the first place.
https://github.com/semgrep/semgrep
I don't think design is necessarily out of reach for AI. As usual, the closer you get to the bleeding edge of what's been done vs. what's possible, the more thought needs to go into a design for it to be considered good. And TBH, even if you only make it to "it works", that's still laudable. There's plenty of profitable companies with terrible designs, technical debt, and broken systems built before AI, and that's why often these arguments fall flat for me.
I like the idea of mostly getting average designs out of AI. I am tired of running into overly complicated solutions to seemingly simple problems. Microservices vs. Monoliths for example. Maybe they thought they saw something that needed that complexity which was credible before, but they have gone and left someone else with their decisions, and left any credibility to the void. They're just playing the game though because there's is/was an incentive to get micro services on your resume for the next job.
> From the outside, this looks like competence. But if you don't understand why the solution works, you're not actually becoming more capable. You're becoming dependent on the machine to maintain the illusion.
So many things in life operate exactly like this: We don’t need to understand the why, we just accept the solution as-is and move on. An experienced professional has another skill: keeping track of which things matter enough to dig in to and develop mastery, and which things can be “good enough”. This is also informed by the “intuition of how machines behave” that the author mentions.
I convinced myself that functional specs and detailed design documents were not needed because they wouldn't be kept in sync with the code. But the LLMs are essentially turning the synthesis of the code from those documents to a compilation step of sorts.
Now I must ponder the question, what portions of the acts of coding, designing and delivering a working product were the portions that bring me joy. I've been attempting to answer this question by making a concerted effort to delegate the coding to the LLMs and reviewing if the code conforms to the designs I've written down. This process is much closer to the historical engineering disciplines but I have to say, its not been easy.
My advice to the the more junior reading this. Experiment with different functional and design spec formats that best serve the LLMs and develop the skill of writing these and then managing the LLMs.
TLDR, the LLMs are giving the term Software Engineering actual meaning.
I don't really agree. This kind of division of labor has always been possible, with architects doing the design and engineers/programmers doing the implementation. Architects who design systems with lofty requirements with no regard for the cost of their decisions are kind of a meme in the industry. I don't believe it's really possible to separate design from implementation, unless the person specifying the design is really knowledgeable about the problem space.