The disconnect for AI is that it is a jagged frontier and it only really shines when one of its jagged frontiers extends counter to one of your valleys.
If you've been writing Perl for 30 years, you might not want to learn JavaScript just to make a little fun idea in your head to show your wife. Vibe code that shit man. Who cares? Your wife does not care about LOC or those internal design decisions you made.
If you're trying to learn something new like an algorithm, protocol, or API write that shit by hand. You learn by doing, and when you know how the thing works and have that mental context, you will always be faster than an AI. Also, when did we stop liking to learn? Why is it a bad thing to know all the ins and outs of a programming language? To write and make all the decisions yourself? That shit is fun. I don't care if you disagree.
If you're at work and they really care about getting something out of the door, do whatever you think is best. If you just wanna ship vibed code and review PRs all day, all the power to you. If you wanna write it by hand, and use AI like a scalpel to write up boiler plate, review code, do PR audits, etc... go for it!
A hammer is a really great tool that has thousands of purpose-designed uses. I still prefer my key to get into my car. It's all tools, you are a person.
A lot of this stuff if coming top-down from people who do not have the experience you do. Wouldn't a smart employee use their expertise to advise the organization? If you work at a company where that would not be okay, maybe it's time to start looking for another firm.
I suspect it happened when we achieved a level of such constant stimulation (there is a pocket computer always on us with infinite effortless distraction) that we’re never bored and never engage the default mode network.
When you’re bored, your mind goes to places it wouldn’t otherwise go. Curiosity kicks in. Curiosity is a precursor to learning. Learning engages the brain and is fun. But it’s not fun all the time, some of it is challenging and frustrating (which is good, that’s the process that teaches you).
When you have the digital equivalent to infinite candy and the brain equivalent to a sweet tooth, it’s hard to resist the siren’s call. The consequence is the brain equivalent to a stomachache—depression and loss of meaning—but unfortunately it doesn’t hit you the same way so you don’t make the immediate connection to make yourself stop. When you think about it, it’s ridiculous from several angles: the candy is infinite, it’s never going to run out, so you don’t need to gorge! But then we justify ourselves as only a true addict would, that while the candy is infinite, the flavours are limited editions and always rotating, and what if I miss that really good one everyone is on?! Then you miss it, is the answer. No one will be talking about it in fifteen minutes anyway.
> it happened when we achieved a level of such constant stimulation (...) that we’re never bored and never engage the default mode network.
I don't know... I don't disagree, but I think this has been repeated so much that I believe everyone, at least everyone that is actively participating in HN discussions is aware of this.
So if we are aware of this and we consciously choose to keep engaging in dopaminergic activities, without having some time to be bored, I think it starts to become a choice. We can blame tech for starting this trend of stealing our attention, but once we become aware of this, we can only blame ourselves for perpetuating it.
Or at least, aware that this argument continues to be made with tenuous evidence and anecdotes. And yet, people are being more productive (actually productive) with AI. Release schedules are increasing, bugs are getting fixed faster, security issues identified and patched sooner, so on and so forth.
I’m not denying (at all) that unused skills languish. I take issue with AI being characterized as a magic eraser that mystically makes people forget what they have already learned. I’ve just done a study and concluded that dogs gets dumber when I throw a ball. What’s my evidence? They stop staring at me to chase it. The ball definitely made them forget who I was, so we shouldn’t allow dogs to have balls anymore.
Can AI make developers lazy in new ways? Of course! Why wouldn’t it? I don’t write things in ASM because I can be “lazy” and write 50x more useful instructions with a few lines of a modern language. I doubt I’d be able to write working ASM anymore without a serious refresher. Did newer languages erase my memory of ASM and make me “lazy”, or did my efforts evolve to make use of the newest technology regardless of “lost” skills?
Can AI make developers lazy in new ways? Of course! Why wouldn’t it? I don’t write things in ASM because I can be “lazy” and write 50x more useful instructions with a few lines of a modern language. I doubt I’d be able to write working ASM anymore without a serious refresher. Did newer languages erase my memory of ASM and make me “lazy”, or did my efforts evolve to make use of the newest technology regardless of “lost” skills?
I would argue that's a misuse of AI. If the point of an engineer is to know how things work behind a piece of software, then shipping code without an understanding how it all works is a failure.
You wouldn't trust an engineer a bridge that an engineer vibe-engineered would you?
So instead of focusing on AI as a productivity tool, focus on AI as a means of adding rigor and understanding to your workflow.
> If the point of an engineer is to know how things work behind a piece of software
That might be the point of an engineer in some orgs, but mostly the point of an engineer is to ship a product or release that matches someone's vision of what should come next, and doesn't cause additional noticeable problems in the next quarter or three.
> You wouldn't trust an engineer a bridge that an engineer vibe-engineered would you?
If it was as easy to stress test/battery test/materials test/etc a bridge as it is to test code - then yes. I'd trust an engineer who vibe-engineered a bridge.
---
The problem with mapping digital problems into meat-space is that there is inherently a few orders of magnitude of cost automatically added to anything that happens in meat-space.
I can spin up an arbitrary number (10, 10k, 500k) docker instances, X with fuzzed inputs, Y with explicit edge cases, Z with tolerance testing, etc etc. And if that doesn't work - I can fix and push a button and it just happens again.
If a bridge engineer could do that with bridges - yes I'd expect them to be vibing just as hard as we are now.
Absolutely. These days engineers use AI and simulation to design new types of engines, jet nozzles, etc. Treating it not like a tool is the mistake, and the assumption many make is that “other people must be making that mistake too”.
No, but I’d certainly trust an engineer to use software with in-built algorithms to design a bridge instead of using a typewriter, calculator, and a pencil. What you argue is your perception that this means everything is vibe coded and an engineer doesn’t understand any of it. My thought would be that this sentiment seems more telling of your views or how you use it than someone else. I’m not saying it isn’t possible for you to be right in circumstances, but rather you seem to assume your view fits all circumstances.
That the point of the engineer is to know how all of it works? So one must know the specific details of how every hard disk driver is implemented, with the algorithms being used, and have checked all the math and inspected all that code, just to be able to “read file”? Do you also argue that million+ line codebases should be inspected through every dependency and every file, line by line, and run through a debugger, before making a single line change anywhere?
Seems more like an extensive exercise in self-flagellation on the company’s dime than would be appropriate, but that’s just my opinion.
We all have our domains. A person can absolutely use AI within their domain and understand its output perfectly as much as having written it themselves.
The need for knowledge in those domains also changes over time. The need to understand a domain at a depth is directly proportional to the depth of the changes you are making to a stack. I don’t need to know how the hard drive spins to write a program. I don’t even need to understand that hard drives exist to write most programs these days, because it is not an area of concern. All of the implementation and efficiencies happen at a level below, or another below that, or within a trusted dependency. The people working on all those things understand those domains better than I ever could have the time to.
Maybe you could better explain where vibe-coding significantly differs from the above as another “layer” of separation?
Look, I’m not arguing vibe coding is “good” in and of itself by any means, but just basically that it’s not all vibe coding, and those of us that understand that don’t really have as much need to argue about the inevitable or that things change.
> this argument continues to be made with tenuous evidence and anecdotes.
The linked Wikipedia page has plenty of evidence and studies and you can find plenty more with a basic web search. This is not something someone just made up; if you don’t know there are a multitude of studies on the harms of social media, you haven’t looked at all. Which is fine, it’s our prerogative to not search for information, but don’t turn around and say it doesn’t exist or is anecdotal.
> And yet, people are being more productive (actually productive) with AI.
You said, ironically without providing evidence, in the same paragraph that you complained about evidence not being provided for something else which has plenty of it. Furthermore, there are several studies suggesting AI may in fact decrease productivity, but I’m not going to link to those because the more important point is AI has nothing to do with the conversation. The original poster mentioned AI, but this branched thread is exclusively about the “liking to learn” part.
> And yet, people are being more productive (actually productive) with AI. Release schedules are increasing, bugs are getting fixed faster, security issues identified and patched sooner, so on and so forth.
I didn't see anything in parent chain that implied this. Nor did I see it "characterized as a magic eraser"; I saw it framed as something that impedes learning, and that was tied back to constant simulation.
> Or at least, aware that this argument continues to be made with tenuous evidence and anecdotes
The arguments I read and the argument you seem to be replying to seem to be different things.
If they don't want to, go for it. I'm all up for the freedom to choose your poison, as long as it doesn't restrict someone else's freedom of choice (like jumping off a building and landing on someone, killing you both). What I'm saying is that if you recognize booze is bad for you, but you don't do anything about it because heck there is a billion dollar industry behind it, everyone drinks and you'll die anyway, IDK it seems to me like it's mostly your fault, because you'd know where yo get help if you really wanted to. That is, of course, assuming where you live has good policies for treating people with such diseases.
>there is a billion dollar industry behind it, everyone drinks and you'll die anyway, IDK it seems to me like it's mostly your fault
This is an absurd statement. What good is the willpower of a single human in the face of a billion dollars of capital aimed at a society with a penchant for drinking?
People are not isolated systems. We live in a society.
> because you'd know where yo get help if you really wanted to. That is, of course, assuming where you live has good policies for treating people with such diseases.
You are probably not the kind of person that would read "Antichrist" and think that Nietzche was a satanist. Or that just because it's called National Socialist party, that the nazis where left-leaning, I'd wager. So why read statements in isolation?
You are pitting your randomly acquired will power and your in large part unintentional stumbling through life against all of human kind's psychology knowledge, against billions of dollars spent on advertising and advertising research. That is at this point tens maybe hundreds of millions of years of acquired human knowledge how to manipulate you versus your very randomly acquired 'will power'.
Have you seen the quotes coming out of the richest/most powerful companies on the planet? These are very intentional impacts by companies more powerful than entire nations.
I don't think 'but your willpower' stands a chance if you want to be connected to the modern world.
So if you are helpless in a world dominated by the billionaires and the clerics of psychological research, what's the hope for the average person? Should we just accept our fate and waste away in endless Instagram feeds, alcohol, drugs, gambling and all forms of addiction? These need to be managed at society level, banning or taxing goods. But no amount of regulation can compensate for someone determined to destroy himself. So yeah, it's your fault. But it's also society's fault. And at the end of the day the most effective thing you have is your choice.
This framing is doing so much PR work for the alcohol/tobacco/social media companies of the world. Effectively removes any blame from the corporations making billions of dollars off harming our societies.
It doesn't, or it shouldn't, but you are right, they subvert any responsibility the individual has so they can offload their responsibility into them. But my mistake here is not realising that people under abstinence doesn't behave as if they had any choice. In any case, my original comment was about social media only, which I think has a lot of psychological pressure over the individual, but doesn't have the pharmacological component.
> So if we are aware of this and we consciously choose to keep engaging in dopaminergic activities, [..] I think it starts to become a choice.
...or a subtle addiction that also creates the impression of productivity/progress/social interaction...
If so, then all applicable studies on addiction should be taken into consideration as well, but their context probably doesn't even begin to cover the size of the issue here.
> I think this has been repeated so much that I believe everyone, at least everyone that is actively participating in HN discussions is aware of this.
I promise you that is incorrect. People who actively participate on HN are a group more diverse than is often given credit, and I strongly believe there is nothing “everyone knows” here.
Just nine days ago, someone on HN was vaguely aware of the idea but did not know it’s called the default mode network. How many more aren’t even aware of the idea?
Not knowing the name means you’re not aware of all the details, intricacies, studies and ideas pertaining to it.
Finally, even if everyone knew about it that would still not be reason to not talk about it. Talking and doing something repeatedly is how you create habits and change behaviour. Same way you should still call out when someone does something bad even if “everyone knows they do it”.
> I think it starts to become a choice. (…) we can only blame ourselves for perpetuating it.
That is called blaming the victim. There are multiple billion dollar corporations and industries actively working to get you addicted, bombarding you from every side. It’s not a simple choice of “I’m not going to engage”, rather you have to actively disengage from what’s thrown in your face all the time. It’s exhausting. You’re falling into their trap and repeating the words they want you to. It’s like a supermarket which offers 99% junk and only a tiny section of always the same selection for healthy eating (not a hypothetical, I have several like that nearby) then blaming buyers for not eating more healthily. It’s not a fair choice if you’re constantly pushing and finding ways to trick people to in one specific direction.
And again, not everyone is aware of what is happening. Most people aren’t. And even those who are (which, again, is not even everyone on HN) aren’t immune.
Fair enough. It's always tricky to generalize like this, so I wont defend that position.
However, for those who know, I don't think this is blaming the victim. I think victim blaming is a form of debate simplification in this case, just like "this is life" or "shit happens".
Sure there are billions of dollars invested in attention stealing mechanisms, just as there are billions of dollars invested in gambling sites, in alcohol, tobacco and highly processed foods, or in the scamming industry. However, while we need as a society need to discuss mechanisms to control and maybe prohibit these practices, a functional adult human beings should be expected to create safeguards to protect themselves against this. Maybe the phrasing wasn't the best, but my point stands. Once you are aware of things that aren't good for you, you can really only count on yourself to do something about it.
we can also apply regulations but they are also not enough, otherwise people wouldn't OD on controlled substances. At one point the individual needs to start taking responsibility for their actions.
> gambling sites, in alcohol, tobacco and highly processed foods, or in the scamming industry
Those are great examples because they show that leaving it all up to the individual is not enough. All of those are regulated by the state because we as a society recognised they were doing their damnest to screw everyone else for their own gain. Social media is going the same route, with several countries already introducing bills to prohibit them to minors.
There is another discussion to be had if we’re going about it the right way (I certainly do not support privacy invasion in the form of age checks), but it does show we’re recognising its harm.
Exactly, but I still think those are two slightly different conversations. If we are talking about harmful habits at a more general level, I'll defend that we need to be very restrictive in those examples. Online gambling, alcohol use and such shouldn't be allowed to advertise, it should pay almost prohibitively expensive taxes etc...
But if we are talking about the individual, the one inserted in the society, which is temporally bound, the conversation changes. We have to admit that it isn't enough to wait for laws and culture to change in order for the individual to be able to protect him/herself. To be a functional adult is to recognize what's around us that is harmful and do our best to protect ourselves. This is why if people recognize the harm social media is doing to their attention and to their ability to be bored they only have themselves to blame if you don't take action, because only blaming the multi-billion dollar industry for the habits they exploit won't do much for the individual.
You've clearly never been addicted to anything. You seem to have little understanding of, or empathy for, those who have become addicted.
I quit smoking cigarettes. It took years. It was incredibly difficult on an emotional level, and took a lot of failure and disappointment to finally make it through. And I almost lost all my progress when I relapsed after my Dad died unexpectedly.
Every pair of eyes that you see walking down the street has an entire universe behind them that we cannot see. It is not simple like you assume.
I suggest you recognize your exceptional self-discipline and relatively unaddicted lifestyle as the stroke of good fortune that it is; you are genetically predisposed or developmentally more well-prepared than most. Recognize that others are less fortunate than you in that regard, but no less deserving of aid, comfort, and a legal avenue to seek recompense from unscrupulous actors.
You might disagree with my point, but you don't know me and you can't really lecture me on empathy. You just glossed over the parts of the argument where I am for discussing public policies that we can implement to care for those that suffer from addiction. But at the individual level, after recognizing the hardships of being addicted to anything, the ultimate choice and responsibility to do something is yours.
Your cigarette addiction might have started because of social pressure or because of advertisement, but every choice to light another one or not was entirely yours. Just like it's your merit to quit it, it would have been just as well your fault if you kept on smoking after recognizing you needed to quit.
> Your cigarette addiction might have started because of social pressure or because of advertisement, but every choice to light another one or not was entirely yours.
This is contradictory. Once you are addicted, the choice is no longer “entirely yours”. That’s what being an addict means, your physiology and your wants are in conflict and require constant active vigilance to contradict. Your head begins to rationalise and you’ll even forget you wanted to stop. If it were simply “entirely your choice”, addiction wouldn’t be an issue.
The advertising and other factors which caused you to become addicted don’t stop after you are addicted. So if you’re willing to admit that external factors may trigger the problem, you must be able to comprehend those factors also contribute to stopping you from solving it. But now you have your own biology as another obstacle.
I agree with you that the previous commenter made unreasonable assumptions about you, but I agree with them that at least in this particular conversation you’re not demonstrating empathy for the addict. What you’re essentially saying, repeatedly, is that they’re choosing to be addicts because they don’t simply choose to stop. This is not true, and you’ll quickly realise that if you engage with addicts, especially if they’re someone you knew from before. There is a transformation, addiction turns you into a different person you don’t always recognise.
I am rereading my comments and you guys are right. What I meant to say and got sidetracked by doubling down on the "your fault" argument is that you can't help someone that doesn't want help. In this sense it's the responsibility of the person that got some kind of addiction to first recognize that they need to want to get help, only then help is effective. But yeah, you are right saying that you are like a different person on a abstinence episode.
Wish I could rephrase my comments, but at least I know next time I will treat this topic with more care.
> When you’re bored, your mind goes to places it wouldn’t otherwise go. Curiosity kicks in. Curiosity is a precursor to learning. Learning engages the brain and is fun. But it’s not fun all the time, some of it is challenging and frustrating (which is good, that’s the process that teaches you).
And I love how I can go from a curious brainfart "hmm, could I do a movie catalogue app that uses a web page + phone camera + OpenAI API to identify physical DVDs by front/back cover instead of trying to find a reliable barcode database" to it actually working in maybe two hours of real time. Just paused the movie I was watching, typed the idea to Claude Code on mobile and kept watching.
After the movie went back to my computer, merged the changes and tested whether it worked. It mostly did. The UI/UX was horrible etc, but the basic idea was functional. It even got some of the movie extras correctly.
I didn't try to turn it into a product, didn't buy a domain for it or advertise it on Reddit or Show HN. But now I know it CAN be done. Curiosity sated.
I don’t see what that has to do with “when did we stop liking to learn”, which is the only point I’m addressing. My point has nothing to do with AI and it doesn’t seem like you actually learned anything from that experiment.
I read it more as response to your argument that it was a lack of curiosity due to over stimulation, which they responded to by citing an example of a time when they were curious while stimulated and chucked something at a vibe-coding agent to satisfy that curiosity.
Yep, now I have the time to satisfy my curiosity in weird things because it doesn't take active time from me that much.
Before all those curiosity brain farts would've just slipped away with "oh well, I'll never have the time to find out".
Wikipedia has scratched the same itch multiple times, but from a different angle. Doing deep dives in weird stuff is so much easier with Wikipedia than it used to be when you had to go to the library and pull books from the shelves for an hour or two.
I still love learning, especially outside of tech. Been working in the ML field for over 8 years, and while I went into it because I liked the field, I did lose some interest in learning things, but mostly because of the sheer volume of publication and the rate of change. Learning stopped being something I enjoyed doing and went to something I had to do to keep up. And it just stopped having the same flavor.
We also stopped learning when someone had the idea to put unrealistic deadlines in projects and tackling tech debt has been denied and the most hated activity from management.
I agree with you on everything you said here except:
> when you know how the thing works and have that mental context, you will always be faster than an AI
That's just plain false, honestly. No one can type at the speed AI can code, even factoring in the time you need to spend to properly write out the spec & design rules the AI needs to follow when implementing your app/feature/whatever. And that gap will only increase as LLMs get more intelligent.
Some of us do actually have intimate knowledge in certain areas where guidance of an AI takes longer than doing it yourself. It's not about typing speed, it's that when you know something really really well the solution/code is already known to you or the very act of thinking about the problem makes the solution known to you in full. When that happens it's less text to write that solution than it is to write a sufficient description of the solution to AI (not even counting the back and forth required of reviewing the AI output and correcting it).
This is actually my biggest gripe with vibecoding. The single best feature of any programming language is that it is precise. And that is what we throw out?! I favor of natural language, of all things?! We're insane!
It turns out an awful lot of precision (plenty for many things) lives in library and web APIs, documentation, header files and dependency manifests. Language can literally just point at it without repeating it all. Avoidance of mistake through elimination of manual copying in things like actuarial and ballistics tables was what the original computers were built for.
API Glue is the easy and boring part in programming. Nobody really enjoys wiring API A to API B, combining the results and using API C to push it forwards.
Any semi-competent AI Agent can do that with a plan you've written in 5 minutes.
I would love to see an AI try to make sense of GTK API.
I may be wrong, but it seems when people are talking about easy glue code, they’re talking about web services API, not OS API, not graphics or sound API, not file formats libraries,…
I used Sonnet 3.5 over a year ago to decrypt a notoriously shitty local government API to get data out of meetings, votes and discussions.
I know it's a piece of shit API done in the worst possible way on purpose (they don't want openness, but had to fulfill a law that mandates "openness") because I had previously tried to do it manually - twice. I ran out of whisky before I got anything done.
Sonnet _3.5_ almost one-shotted it with just the API "documentation" they had and access to Python and curl.
People have also hooked stuff into proprietary APIs on "smart" devices with zero documentation, just by having an Agent tirelessly run through thousands of permutations to figure it out.
Historically we almost entirely moved from ASM to C, a language with lots of undefined behavior, because precision is not the most valued feature of languages.
It's the existence of UB that is the reduction in precision. A language without UB is more precise, in my view, than one that has UB. I don't know if this a conventional view. But being able to write parsable, compiler-receivable code that does 'uh, whatever', feels like a reduction in precision to me compared to a language that does not have that property.
Otherwise, we're just saying that the precise parts of the language are precise, which isn't much of a differentiator since it's similarly true for all languages.
UB is about edge cases that a compiler should not be enforced to check against and an occurrence is always a bug. You don't necessarily need a precise description of the actual faulty behavior.
Right. The language has well-formed expressions with no defined meaning in terms of machine instructions. My claim is that this is a reduction in precision compared to assembly language.
Grandparent said:
> The single best feature of any programming language is that it is precise.
C overtook a more precise language family because it has features other than precision that people cared about. Perhaps a better tradeoff of expressiveness and readability with precision.
Grandparent could be correct, and precision is the best feature of C, despite being less precise than ASM. And its better expressiveness nets out to a better overall programmer experience. I just wanted to point out that precision is something we do trade away for other things we want.
I don't completely follow the analogy, but I do follow the argument. High precision regarding the requirements often is not needed and that's exactly where LLMs shine.
That's also where engineers come into play. They (and often only they) can judge how much precision is needed depending on the part of the system they are working on.
Could you please explain why you feel that having UB makes C less precise than asm?
To me, the notion of precision isn't in any way related to whether any given statement is sound. It's about the behavior of the language for sound programs.
There are syntactically well-formed C programs that are not sound programs because their behavior is undefined. Or, rephrasing: a subset of all parseable C programs contain 'do whatever, I dunno'. I interpret this as a lack of precision.
One could take the position that specifying precisely 'do whatever, I dunno' counts as perfectly precise. But then a language that was entirely UB would count as precise, which would be an odd position to hold, since you can't specify any behavior at all with it.
Nobody seriously interprets "the C programming language" as "parseable C". Of course there's parseable, undefined C, and of course it's very imprecise. It's not relevant.
Now consider sound, in-spec C. Versus natural language.
Ok I’ll do the same move and show why it doesn’t persuade me.
Consider the subset of natural language that has strictly defined semantics. This would include, for example, talking in about the arithmetic of real numbers. The rest is not relevant to evaluating the precision of natural language.
Does that exclusion feel different in the natural language case? Why?
Perhaps it’s a matter of degree, not a categorical difference.
> Consider the subset of natural language that has strictly defined semantics. This would include, for example, talking in about the arithmetic of real numbers. Does that exclusion feel different in the natural language case? Why?
Not really, no. I just think we have better ways of expressing well-defined mathematical concepts like that than natural language when the recipient is a machine.
The exceptions that prove the rule. When your programming language is built up of singular Unicode characters with specific meanings, of course that's faster than typing out in English what you want.
What do you use them for? For most AI users it's usually CRUD and I've never seen a web server or frontend in APL like languages.
The reason why programming is hard is because most languages force you to use a hammer when you need a screw driver. LLMs are very good at misusing hammers and most people find them useful for that reason.
If you use a sane dsl instead the natural language description of a problem is always more complex and much longer than the equivalent description in a dsl. It's also usually wrong to boot.
I don't think you will find anyone who can do better than an LLM at one shotting the prose version of the problem. Both will of course be wrong.
But I also don't think you will find an LLM that can solve the problem faster than a human with Prolog when you have to use the prose description of the problem.
Using esoteric programming languages doesn’t suddenly make it true for the majority of development, which is web apps, CRUD stuff, some data science, etc.
Who is using APL and J these days? I guarantee 90+% of Claude users are developing CRUD web apps, or something similar. Your point about algebra is a non sequitur to what people are actually developing for these days.
The volume of people successfully adopting agentic engineering practices suggests this stuff isn't rocket science, but it is a learned skill and takes setup.
A year later into heavy AI coding, my experience is what you're describing should aid in being able to run 5+ agents simultaneously on a project because you know what you're doing, you set it up right, and you know how to tell agents to leverage that properly.
More LOC committed per day is probably the only one that's guaranteed when you let spicy autocomplete take the wheel.
I don't think it's at all possible to reason about the other more meaningful metrics in software development, because we simply don't have the context of what each human is working on, and as with the WYSIWYG fad of 3 decades ago, "success" is generally self-reported, by people who don't know what they don't know, and thus they don't know what spicy autocomplete is getting woefully wrong.
"But it {compiles,runs,etc}" isn't a meaningful metric when a large portion of the code in question is dynamic/loosely typed in a non-compiled language (JavaScript, Python, Ruby, PHP, etc).
If you are on the right team with the right professionals you can measure. when we first started using LLMs we decided to run the same process as if they did not exist, same sprint planning meetings, same estimation. we did this for 6 months and saw roughly 55% increase in output compared to pre-LLM usage. there are biases in what were tried to achieve, it is not easy to estimate something will take XX hours when you know some portion (for example writing documentation or portions of the test coverage) you won’t have to write but we did our best. after we convinced ourselves of productivity gains we stopped doing this. saying you can’t measure something is typical SWE BS like “we can’t estimate” and the other lies we were able to convince everyone off successfully
Maybe you're the exception and are actually doing it right and actually getting good results, but every time I have heard this, it has been an ignorance-is-bliss scenario where the person saying it is generating massive amounts of code that they don't understand, not because they're incapable but because they don't care to, and immediately wiping their hands of it afterward.
To give an example of where I hear this, it is indistinguishable from the things I hear from my coworkers: "You just need the right setup!" (IMO the actual difference is I need to turn off the part of my brain that cares about what the code actually does or considers edge cases at all)
What I actually see, in practice, are constant bugs where nobody ever actually addresses the root cause, and instead just paves over it with a new Claude mass-edit that inevitably introduces another bug where we'll have to repeat the same process when we run into another production issue.
We end up making no actual progress, but boy do we close tickets, push PRs, and move fast and oh man do we break things. We're just doing it all in-place. But at least we're sucking ourselves off for how fast we're moving and how cutting edge we are, I guess.
I dunno, maybe I'm doing it wrong, maybe my team is all doing it wrong. But like I said the things they say are indistinguishable from the common HN comment that insists how this stuff is jet fuel for them, and I see the actual results, not just the volume of output, and there's no way we're occupying the same reality.
I've seen productivity surveys of senior programmers that share the reverse, and that matches our experience. A common finding is that gardening projects are a lot cheaper now when they're just a few extra terminal tabs running in parallel - security, refactoring, more testing, etc. Non-feature backlog items that senior developers value around tech debt are less of a discussion now. They're often essential now: to make AI coding work well, there is an effective automation poverty line around verification, testing, and specification that needs to be reached.
The understanding code thing is tough. Eg, when a non-senior fullstack developer manually edits frontend css code and didn't start from pixel-perfect designs across all form-factors, do they really understand what they did? I wrote the first formal mechanized specification of the CSS standard, and would claim 95%+ of web developers do not understand core CSS layout rules to beginwith: it was a struggle to semantically formalize even a tiny core of the box model as soon as you have floats. If the AI generates live storybooks and in-tool screenshots of all these things as part of the review process, and doing code review "looks good", what's the difference?
I don't truly think this way - my point is to challenge basic claims of manual coding to be good to begin with and whether AI coding is being held to an artificial standard. What I see in commercial and defense software is a joke compared to what we do in the verification world. AI coding automating review iteration fixes in areas like security engineering and test coverage+amplification has been a blessing for quality improvement.
More fundamentally, we require developers by default to be responsible for knowing what the code does and having tested it. Every case of relaxing that rule has to be explicit, eg, clear that something is a prototype, or an area is vibed with what alternate review/test flow, and we are learning as a team what that means in different situations. In practice, our senior ai coders are doing more quality engineering work than the manual coders, both per-pr and in broader gardening contributions.
I know you said you don't truly think that way, but to counter anyway since some people seem to legitimately hold this viewpoint:
I take issue with the implication that not necessarily having a full understanding of what the code/library/driver/compiler/abstraction is doing is somehow justification/permission to embrace and celebrate having basically no understanding of what any of the code is doing. The in-between space there is the vast majority of the surface area where nuance can and should exist.
>my point is to challenge basic claims of manual coding to be good to begin with and whether AI coding is being held to an artificial standard
That's fair, and I can only speak for myself here; I don't have any inherent philosophical issue with manual vs AI, but my personal experience is that AI coding is just straight-up a frustrating nightmare to deal with, IMO orders of magnitude worse than manual. It's faster, sure, but I end my rage-filled LLM debugging session walking away knowing I learned pretty much nothing and that there's no compounding knowledge or outcome that will keep me from experiencing the same thing tomorrow, and I hate that. I am Sisyphus rolling prompts into a terminal.
But I'm not gonna sit here and act like manual coding makes you morally virtuous or pure or whatever. IMO it's a great forcing function to better (even if not completely) understand what is going on in your system(s) and I think most everyone would agree with that. What's up for debate is probably whether that's worth the time tradeoff now that we have a magic time compressor machine available to us.
Maybe I only find that knowledge tradeoff valuable because I'm a lowly IC and not some super turbo chad 10x principal who built a distributed database in brainfuck 10 years ago for fun and has nothing left to learn, or a technical founder of 5 concurrent startups who is optimizing for business value. It's possible that a heavy bias for learning/skill acquisition blinds me here.
>we require developers by default to be responsible for knowing what the code does and having tested it. Every case of relaxing that rule has to be explicit
1. If what you're replying to was a thing, wouldn't there be a open source project where I could see this in action? or Some sort of example I could watch on youtube somewhere. 2. The people that talk like this in my company, spin up new projects all the time and then just get to hand them off for other teams to clean up the mess and decode what the heck is going on.
1. Probably most of https://github.com/simonw , but take care to seperate adopted / semi-professional from exploratory personal work
2. That sounds like your company has a weak engineering culture and is early on its upskilling journey. We explicitly seperate projects into prototypes vs production, where vibes are fine for the former, eg, demos by designers / data scientists / sales engineers but traditional code review standards for whatever is going into production. That mirrors my qualifier in #1.
I find that success here is a combination of engineering seniority, prompting experience, and domain experience . Anything lacking breaks the automation loop, like not knowing how and what to automate. Ex: All of our team finds value in ai coding, but junior engineers struggle on these dimensions, so are not running the 3+ agents that senior ones are.
You seem to have missed OP's point: some things are only encoded in our brains when you are sufficiently experienced.
Translating that into code can happen directly by you, or into prompt iterations that need to result in the same/similar coded representation.
In other words, when it matters how something works and it is full of intricate details, you do not need to specify it, you just do it (eg. as an example which is probably not the best is you knowing how to avoid N+1 query performance issue — you do not need a ticket or spec to be explicit, you can just do it at no extra effort — models are probably OK at this as it is such a pervasive gotcha, but there are so many more).
That's the failure to automate. The AI isn't telepathic, so agentic engineers not automating this stuff is skipping out on the engineering part.
You setup the environment and then you do the work. Unless you are switching employers every week, you invest in writing that stuff down so the generation is right-ish and generate validation tooling so it auto-detects the mistakes and self-repairs.
sometimes you write the feature and write it well so it's reusable.
imagine you have to implement a specific algorithm for a quantum computer.
There's no value setting up AI to do the writing for you. That might be orders of magnitude harder then writing the algorithm directly.
For highly specialized one-off features, it doesn't always pay off.
On the other hand, if all you do are some generic items that AI can do well... then I'm not sure you're going to have a job long term, your prompts and automation will be useful for the new junior hires that will be specialized in using these and cost effective.
That feels like true in theory, but in practice, we see the reverse for advanced projects where AI is helping us a lot. A decent chunk of our core IP falls into the bucket you're describing:
We have been building a GPU-accelerated graph investigation platform that has grown over 10+ years with fancy stuff all over the place - think accelerated query languages, layout kernels, distribution, etc. R&D-grade high performance engineering projects and kernels end up needing a lot of iterations to make a prototype and initial release. Likewise, they're more devilish to maintain when they need a small tweak later because of the sophistication and bus factor. Both phases benefit.
AI coding helps automate investigation, testing, measurement, patching, etc. The immediate effect is we can squeeze in many more experimental iterations with more fidelity and reach. Having an AI help automatically explore the design space and the details helps a LOT. And later, maintaining a wide surface area of code here that is delicate to touch and infrequently edited is traditionally stressful for teammates, and AI editing + AI-generated automation is helping destress that a LOT. We very much invest in upgrading our team, processes, and tooling here.
I think there's a level above that where the words to describe such structure are familiar and readily available and hey guess what? The model understands those too. Just about every pattern has a name. Or a shape. Or an analog or metaphor in other languages or codebases. All work as descriptors.
This presumes that most of this stays encoded as words in our brains: the effort to translate some of these into words might be similar to translating it into code (still words, just very precise).
It's like talking legalese vs plain English; or formal logic vs English. Some people have the formal stuff come more naturally, and then spitting code out is not a burden.
No, it really doesn't presume anything about brains or information encoding. Just points out that there is a level of mastery in which all the techniques and all the forms have names or adequate descriptions. Teachers often attempt to achieve this, to facilitate education.
It's no accident there is an adage from Aristotle in the vein of: "Those who can, do. Those who understand, teach."
So yes, there is a level of mastery that is beyond being able to do a good job of designing and evolving complex systems which enables people to teach others the same skill set.
However, this is a smaller number of practitioners, and most have learned through practice and looking over how more experienced engineers apply their knowledge.
Where I disagree is that this means everybody is equally capable of teaching with words, or that there are no experts who are bad at teaching (humans or directing AI) — this clearly indicates it is not encoded as words for said experts.
It's been pretty clear in my experience that experts tend to be capable of working with the same ideas in many different forms. That's what I would call mastery. It implies "complete" knowledge, which probably means several interrelated encodings with loci in different parts of the brain. Those interrelated encodings will be highly associated, and discerning in an expert. Which implies a high degree of usefulness and specificity in communication. This matches my experience.
Yes, there are still many areas where skilled humans are faster than AI (meaning faster coding yourself, than providing so much context and guidance that the AI can do it on its "own").
But in general the statement is really not true anymore, generic projects/problems have a pretty good chance that the AI can one shot a working solution from a lazily typed vague prompt.
Yeah it’s when you go off the happy path that it gets difficult. Like there’s a weird behaviour in your vibe-coded app that you don’t quite know how to describe succinctly and you end up in some back-and-forth.
But man AI is phenomenal for getting stuff out of your head and working quick.
That doesn't matter. The statement wasn't "faster than AI right now", it was "will always be faster than AI". And that's just nonsense.
Current AI systems are extremely serial, in that very little of the inherent parallelism of the problem is utilized. Current-gen AI systems run at most a few hundreds of thousands of operations in parallel, while for frontier models, billions of operations could be run in parallel. Or in other words, what currently takes AI 8 hours will take it barely long enough for you to perceive the delay after you release the enter key.
For a demo, play around with https://chatjimmy.ai/ , the AI chatbot of Taalas, where they etched the model into silicon in a distributed way, instead of saving it in RAM and sucking it to execution units by a straw. It's a 8B parameter model, so it's unsuitable for complex problems, but the techniques used for it will work for larger models too, and they are working to get there.
And even Taalas is very far from the limits. Modern better quality LLM chatbots operate at ~40 tokens per second. The Taalas chatbot operates at 17000 tokens/s. If you took full advantage of parallelism, you should be able to have a latency of low hundreds of clock cycles per token, or single request throughput of tens of millions of tokens per second. (With a fully pipelined model able to serve one token per clock cycle, from low hundreds of requests.) Why doesn't everyone do it like that right now? Because to do this, you need to etch your model into silicon, which on modern leading edge manufacturing is a very involved process that costs hundreds of millions+ in development and mask costs (we are not talking about single chips here, you can barely fit that 8B model into one), and will take around a year. So long as the models keep improving so much that a year-old model is considered too old to pay back the capital costs, the investment is not justified. But when it will be done, it will not just make AI faster, it will also make it much more energy-efficient per token. Most of the energy costs are caused by moving data around and loading/storing it in memory.
And I want to stress that none of the above is dependent on any kind of new developments or inventions. We know how to do it, it's held back only by the pace of model improvement and economics. When models reach a state of truly "good enough", it will happen. It feels perverse to me that people are treating this situation as "there was a per-AI period that worked like X, now we are in a post-AI period and we have figured out that it will work like Y". No. We are at the very bottom of a very steep curve, and everything will be very different when it's over.
Huh, I have to say that I am impressed with Chat Jimmy. No doubt that the hardware running this model operates faster than any human. If this was possible to scale, (and I'm not saying it isn't, I just don't think it's likely right now) LLM's have a real shot of replacing real-time graphics, frontend UIs, and all sorts of interactive media if the market allows it.
I still think regardless of how fast a model outputs tokens, it still benefits the person responsible for that output to be well informed and knowledgeable about the abstractions they're piling on top of. If you have deep knowledge, you can operate faster than other people, and make those important decisions in a more intelligent manner than any model.
Maybe in the model we do get super intelligence and my point will finally break, but at that time I don't think I'll be worried about being wrong on the internet.
Ok sorry about that. I seriously don't believe him. The Agent is so fast there's literally no way you can be faster.
Telling the agent your high level plan that you are extremely familiar with and then having the agent execute on 2000 lines of code is FASTER then having you execute on that 2000 lines of code. There is no reality where that can be physically beaten by even someone who's typing really quickly with zero pause. Physically impossible.
Less boring or not? Another way to put it... although my answer is boring, I think I'm right. He is either a liar or like many other people lacks skill in using AI... because the transition to AI is happening so fast... not many people are fully utilizing AI to it's maximum potential. Many still use IDEs, many still interact with terminal. Many people still don't use it to configure infrastructure, do database administration, deploy code... etc.
Why are you starting the clock at the time when you already have a "high level plan that you are extremely familiar with"? I think it's fairer to start from "I received a bug report/feature request" or similar.
Also, haven't you ever had a situation where the prompt you started with ends up being longer than the final code diff? Perhaps a subtle bug that's hard to describe/trigger, but ended up having a simple root cause like an off-by-one error?
Also also, coding agents are infamous for generating way more code than is strictly necessary. The 2000 lines of code that the agent generated may well have been only 200 lines had you written it yourself.
>Why are you starting the clock at the time when you already have a "high level plan that you are extremely familiar with"? I think it's fairer to start from "I received a bug report/feature request" or similar.
Done both. We tag the LLM on slack in a reply and the ticket gets created and forwarded to an agent that automatically works on it. The only time a human is in the loop is review or or queries for changes.
>Also, haven't you ever had a situation where the prompt you started with ends up being longer than the final code diff? Perhaps a subtle bug that's hard to describe/trigger, but ended up having a simple root cause like an off-by-one error?
Sometimes. Getting rarer and rarer.
>Also also, coding agents are infamous for generating way more code than is strictly necessary. The 2000 lines of code that the agent generated may well have been only 200 lines had you written it yourself.
Depends on the agent and it's random. This was mostly true probably 5 months ago. It's much less true now.
AI can write 2000 lines faster than you, but you can write the 2000 lines correctly first shot faster than having AI do 10 iterations on these 2000 lines with your guidance to finally get it right
I know that a better plan could mean fewer iterations, but again that extends the time you need to spend on that plan => the total time of the AI solution
Right but those 10 iterations only take up prompt writing time. When the agent is executing I move onto other tasks in parallel. AI is faster when you parallelize your work flow.
prompt writing and parsing the AI output, and thats still work you have to do - not sure why you bring up parallelism since you cant do other things while you're writing the prompts
Other agents can be working while you're writing prompts.
Let me put it more explicitly. For one project I have 10 folders clones of the same project on my local computer. Each one of those folders is responsible for working on a different ticket/feature. I prompt one folder, move on to the next. It takes practice to get used to this style.
Again it's not about typing speed. High level plans simply don't work very well, especially for big tasks where the optimal solution actually would take 2k lines. Unless you are building something that is extremely generic, AI coming up with the optimal solution rarely ever happens.
> He is either a liar or like many other people lacks skill in using AI
Not a liar, and I'm sorry to say, but AI really doesn't take much skill to use. People who say such statements give me the impression that their ceiling for skills is quite low.
Their are areas I do and will continue to use AI and it works well enough. Giving me prototypes for projects I don't have a lot of knowledge about is one thing. But I use those prototypes to learn.
> configure infrastructure
I make templates I can copy and tweak to do this faster than it takes to tell an agent what to do.
> database administration
Don't do that... Sure get it to write you some SQL to update a table, but don't give it DB admin access for fucks sake.
> deploy code
Tell me, how is your agent able to deploy code more effectively than hitting merge on a PR? Or do you simply mean setting up CI/CD for you? That's usually a set and forget thing that doesn't take much time, so I'd rather do it myself.
>Again it's not about typing speed. High level plans simply don't work very well, especially for big tasks where the optimal solution actually would take 2k lines. Unless you are building something that is extremely generic, AI coming up with the optimal solution rarely ever happens.
Nope. Not universally true. It depends on randomness of the rng, the type of task, the agent, and also the current state of AI. Right now for frontier models... what you're saying is generally true only in the minority of times ime.
>Not a liar, and I'm sorry to say, but AI really doesn't take much skill to use. People who say such statements give me the impression that their ceiling for skills is quite low.
It does take a little skill. Very little and it requires new habits that are harder to pick up. For example. I never work on one project at a time anymore. I work on 5 projects and context switch between all of them. Prompt, switch, come back, prompt, switch, prompt switch, review... etc. That takes getting used to.
>I make templates I can copy and tweak to do this faster than it takes to tell an agent what to do.
I have a huge change, and within that change the agent does this automatically.
>Don't do that... Sure get it to write you some SQL to update a table, but don't give it DB admin access for fucks sake.
You can fuck off prick, don't fucking talk like that to my face. I do it and I have no problems with it. If you don't want to, that's your own fucking prerogative.
>Tell me, how is your agent able to deploy code more effectively than hitting merge on a PR? Or do you simply mean setting up CI/CD for you? That's usually a set and forget thing that doesn't take much time, so I'd rather do it myself.
Because the agent merges for me. Prompt: "Complete task A". Agent: "Task completed", Me: "reviewed and good to go"
The agent then does it's thing. Of course there's always some adjustments and more conversation then this but that's the jist of it.
I interpret "faster than AI" to include writing the prompt. For me (scientific computing) it is more often than not faster to write out a simulation or design in a language I know inside out like fortran or mathematica than explicate the requirements to an LLM to request the code. Obviously if someone wrote out a prompt to me and the LLM it would be way faster, but I don't think that's what the commenter had in mind.
If you're good at SQL, or SQL-like languages like Linq, it might be more efficient precisely writing a reasonably complex query than trying to explain it in detail to an AI.
I am very good at SQL, I worked half my life with SQL and teached it and know all kinds of SQL flavour. But good luck getting ahead of AI on a complex query with recursive CTEs, left outers, 625-column tables that change semantics conditional to certain prop, and then some obscure Oracle package APIs.
No way U beat an LLM on this, even on trivial ones. LLMs are better at that since at least 2024, if you haven't noticed, then you're not doing enough SQL perhaps.
But, of course it took years for people to realize they cannot outpace Visual Studio in the 90s by being very good at x86 assembly.
Not the parent but I've had this happen when debugging for sure. Sometimes I ask Claude Code to help me debug something and it makes a wrong assumption and just churns in circles burning tokens. While it's doing that I realize the problem and fix it.
What I meant is that only sometimes I am faster than Claude with debugging. When it's a standalone problem, a report in Sentry, and I just know immediately where I need to go to fix it. Then it's faster to do myself, than telling Claude what's the problem and where to look and wait.
Bugs happen during feature development, as you say, but then Claude is in the context, and I don't need to tell it where to go, it sees the bug with failing tests, or smth similar.
BTW. One thing that helps my Claude with debugging harder problems is that I tell it to apply scientific method to debugging. Generate hypotheses, gather pros/cons evidence, write to a journal file debug-<problem>.md, design minimal experiments to debunk hypotheses.
You can add that as a skill, and sometimes it will pick it up automatically, but it works wonders just as a single sentence in the input.
..but then you ignore all other times CC got it right, and statistically I would put my bets CC does it right (or Codex (or PI)) than you would, and more often is right than tis not.
besides it is a system that you query, it responds. I'm sure your dbs are not always 'right' and particularly when you as the wrong questions.
In my experience AI can write _something_ from scratch, but often edge cases won't be handled until I go through and read the results or test it. Usually when I'm writing by hand I will naturally find the majority of edge cases as I go.
By the time I've read through the results and fixed said edge cases, I usually would have been faster just doing it myself.
My experience is the opposite: AI takes too many edge cases into account and guard against even the most unlikely thing. The upside is that it often handles edge cases that I either didn't think about or was too lazy to implement.
I can with full confidence say that the code AI writes is more robust and safe than if I would have done it myself. The code definitely becomes more bloated though.
My experience has been that it wraps all the obvious things, and even some obscure things, in error handling. In this sense it is safer.
It also fails to write abstractions unless they're carbon copies of a well established pattern, and when abstractions already exist, it needs babysitting to ensure it will use them appropriately. It won't introspect about its current direction unless forced to by the user or by an error, and when forced it will happily "fix" non-issues just because you pointed them out, since it's a happy little yes-man.
Because of this, code written by a good engineer is more likely to start out broken but converges towards correctness as more abstractions get built, while code written by AI duplicates abstraction layers, leaks between them, and never converges towards anything.
I've definitely had a lot of these same experiences (in fact I've been fighting it on one particular issue the past couple of days and I'm pretty much just giving up and going back to solving it manually now).
But it still seems to get it right (or at least close enough to right that I keep using it) more often than it gets into these traps.
This has been my experience thus far. Yes, a complete prototype can be made, but.. you don't really know until you read the code and test it. Just yesterday, small things came up in terms of Qt screen focus that wouldn't have come up otherwise save for initial testing.
I think, and I recognize it is mostly against the 'agentic' push, I will stick with slow iteration.
That is not true in startups, where people are getting work done. Maybe in later stage companies where 'stakeholders' are 'synergizing' in meetings over the Q2 roadmap.
Which is still false and not serious. It's one of the dumbest rationalizations I've seen. AI has many flaws but pretending that it's useless because of that is not it.
You can definitely be faster than frontier models. The number of tokens per second is not that high and they require a lot of tokens for thinking and navigating things.
Especially if you use auto-complete AI, ironically. You type a few characters, the line fills out in less than a second, as opposed to a reasoning model that takes maybe a second per 2-3 lines it writes out.
as i understood it he's referring to the overall time it takes to build a complete finished piece of software, accounting for the refactoring and bug fixes and all that. cause handn't you understood the tools you're using you would be running into roadblocks and that adds up
if you've never had the experience of handing something off to someone else being more laborious and slower than doing it yourself due to having to set constraints and define success, then you simply haven't held a senior enough position to comment on this with any authority
Your views might carry more weight if the crux of your rebuttal wasn't manufactured outrage that I used a laughably accurate nickname for a type of software.
AI is just revealing the two types of people in this line of work. Those who don’t actually like software and just do it because it’s lucrative, and the actual nerds who care.
You are probably talking about people who just crunch out some half baked solutions for the sake of getting somewhere.
But there are other nerds who care, just not about the code quality, but about conversion, testing out business ideas quickly, getting to know their customers better.
There are nerds who care about business strategy.
There are nerds who care about accounting principles and clean financial reporting.
There are nerds who care about sales targets and partnerships.
There are many types of nerds out there. Don’t limit nerds to engineers, because “tech” world is not just an engineering world anymore. All these nerds you can team up with to build meaningful things, because they do care.
This resonates with me. I'm a Mechanical Engineer who loves the process of coding. I did take an intro to business class in undergraduate though, and my professor said one thing that has stuck with me for 30+ years - 'The fundamental goal of a business is to make profit now and in the future'. Vibe coded slop might get some traction and make money now, but high quality code will reduce technical debt and allow it to be made in the future. So, in some ways, both camps are right. The PM/Manager/VP want to make money now, but if they completely disregard the nerdy engineer, they will sabotage their future.
I see a disconnect between these two camps that will probably cause a lot of chaos in the near future. Those that figure it out will thrive.
While Company A is building their product in perfect hand-coded Rust with zero defects, Company B is on their third iteration of vibe'd "slop" and getting actual customer feedback - which helps them iterate further.
It's mostly a matter whether Company B is smart enough to refactor the code to a stabler and more maintainable form or do they run headlong into a vibeslop wall.
I am not really sure. I wrote some scripts that aggregated data from several APIs with an LLM and the LLM had the foresight to create a caching layer for the API responses as it properly inferred that I would need the results over and over again as well as using asyncio to accelerate fetch speed. This would have been a v2 or v3 and it one-shotted it perfectly.
Yeah, they are good at applying generic patterns, but often it can be overkill/YAGNI that lead to more maintenance work in places that are fine with a much simpler/straightforward solution. But this is what the engineer can decide and with LLMs they wont be forced to make the trade off because it takes longer to build, but rather whether it is really necessary or not.
When it works, it feels genuinely miraculous. Working in a common problem space, like gluing together APIs, it generally does well. Doing something novel or even a little complicated, it can really lead you astray.
But business people always cared only about thr result. My PM (who speaks like a salesman) only cares about the results. My “head of” same. My ceo same. The only ones who ever cared about the process and quality were us the engineers… if we don’t have that care, well, to hell with everything
That's not true as a simple statement, many business people really do care about quality and process, and you may find you care much more about them than you think.
How often have engineers decried yet another rewrite that some project is doing? Or talked about "over-engineering" something that isn't needed, or that another person in a team has setup a full kubernetes gitops thing that's glorious to them but you just want to scp a go binary and be done with it?
I've seen truly excellent engineers hit this issue, I worked in a team years ago and people disagreed on the approach to take on a new project. So we all made a prototype and presented it, so we could pick a direction. There was a requirement that it be done in ruby since that was the language most of the developers were most fluent in. One of the engineers, remarkably smart, wrote a lisp interpreter in ruby so that technically it'd be "in ruby" but have the benefits of lisp.
He cared about the quality and process in one area. Deeply. However focussing on that would be at the detriment to the rest of the actual product we wanted to ship. If you considered the quality of the product as a whole and the process at the level of the organisation, you'd do something very different.
Now, none of this means all business people are good at this or long term vision or anything, just as it doesn't mean all engineers have a very narrow focus. But I've seen engineers focus on the quality or engineering of some component without looking at what it is you're actually trying to achieve as a business, and so push for a worse overall process and lower "quality" result. It's the same sort of disconnect that leads a lot of engineers to rail against meetings and PMs that slow them down without seeing from the other side that it's often better to build the right thing more slowly than the wrong thing more quickly.
Assuming it is accurate, the logical conclusion is that the race is over. The management can get their $result and fast. Now, whether it is good or bad, is a separate story, and only time will tell whether they will be forced to learn anything. Right now, the expectation is to push for results and management seems to ascribe current set of failures to: people not embracing AI enough.
I think that's a common experience but not universal.
Just about everyone cares about process and quality when things start falling apart. And at least with current technology, it seems like vibe coding your way into a large project will inevitably land you in that spot.
This means different things to different people, lot of people enjoy the process of engineering solutions with LLM agents, build out tailored skilled, custom approaches that make up their own flavour "agentic" workflow. There are also people who find joy in Javascript that other people cannot understand why. And other people again love system languages or even tinkering with assembly etc.
What I wanted to say is that LLM use does not automatically mean people just want to get results faster, there are still nerds enjoying the process of working with these new tools.
The results being a lot better crafted by hand I would agree with, if one removes any notion of a time constraint. Sometimes the comparison point is between the LLM authored software or nothing at all.
The benchmark is "do they do it for fun", i.e. personal projects.
But the real trick isn't "number of personal projects", but how weird they are. There's no "rational" reason to do them, they don't increase the person's marketability / hireability. They are done purely for intrinsic reasons.
(On reflection, this also seems to be a pretty robust predictor of autism. :)
It goes for all professions really, people who do it for work and people who care.
Apply to any profession, plumbers, doctors, carpenters, cleaners, etc etc. Most of us have experienced both types and I haven’t heard of anyone preferring the ”do it for work” over the ones who care. And like those other professions, in software we accept the worse of the two because finding people who care is both time consuming and often much more expensive.
I care a lot about software and I use LLMs extensively. There are some things I deeply understand yet I don't care for doing anymore because I've done them for years and there's nothing to be gained from doing them manually.
That’s just you using the tools responsibly. Not using LLMs to perform well defined virtually deterministic tasks that you fully understand is simply a waste of time. There’s a big difference between that and just letting agents go wild and do your design for you.
This is such a naive take. Most of the nerdiest and most "quality" oriented engineers are hard leaning in to agentic coding. I feel like the most impressive engineers I know have always leaned in to learning how to "sharpen the axe" and AI is really the biggest axe we have seen.
Where did I say they weren’t? We’re all using LLMs now, it would be stupid not to. It’s how we use them and how much care we’re willing to give up for speed that is at issue here.
I take software engineering and production reliability very seriously. But coding is just a small part of my job. It's not really the meat and potatoes. I'll vibe code (responsibility) where I can.
I care about solving problems for and delivering value to my users. The software is simply a means to that end. It needs to work well, but that does not mean every line of code requires an artisanal touch and high attention to detail.
I think there's some ambiguity in the discussion around what people mean when they say "good code".
Good code for a business is robust code, that's functionally correct, efficient where it needs to be and does not cost too much.
I believe most developers who care about good code are trying to articulate this, they care about a strong system that delivers well, which comes from good architecture.
LLMs actually deliver pretty well on the more trivial code cleanlines stuff, or can be made to pretty trivially with linters, so I don't think devs working with it should be worried about that aspect.
What is changing fast is that last point I mentioned, "that doesn't cost too much" because if you can get 70% of the requirements for 10% of the perceived up front cost, that calculus has changed. But you are not going to be getting the same level of system architecture for that time/cost ratio. That can bite you later, as it does often enough with human coders too.
I think the other aspect to this which you allude to at the end is that all of these arguments start with the assumption that all human software engineers produce high quality code that meets the requirements, but obviously that’s very much not the case in the real world. After all, 80-90% of drivers rate themselves as above average.
If one compares a single competent software engineer directing a number of agents against a random group of engineers (not necessarily working at FAANG or a YC startup), then those quality arguments are going to be significantly less compelling.
Once you’ve done the work to deterministically define your system; you’re not vibe coding anymore. You’re officially an engineer who cares about the consistency and robustness of your product, not just its superficial outcomes.
I think there's a continuum here, too. I've heard it said, in jest, mind, that LLM's square the dev. It turns a 1.5x dev into a 2.25x dev, but it also turns a 0.75x dev into a ~0.56x dev.
I think the exponent of 2 is probably too high, but it's not a bad approximation of a very messy reality.
There is also the division of people who value the thing being produced vs. valuing the actual production of that thing, whether or not its used. I don't see one side here being "right", necessarily, but when a company is behind it one is certainly more valued, and I think not incorrectly.
There are more types of people. I do it because it is lucrative, because it turns out I'm good at being a professional software engineer, but I also enjoy it more than other things I could be doing.
However, ultimately, I got into software because I was intellectually curious and programming was a tool I could use to explore that curiosity. When I stop working professionally, I will stop caring about the sorts of stuff I care about today and go back to using programming for what I love. A tool to explore.
I am a nerd who cared. Caring is not putting my food on the table though, delivering stuff is.
I still enjoy diving into documentation but AI has transformed how I work. I can quickly get code examples I can debug. I learn new things as sometimes AI generates approaches I haven't used before.
I've posited for a while now that the people who find spicy autocomplete to be exciting are the people who can't really do what it does.
I played with Image Playground last year some time. It was really fun. You know why? I can't draw, and I can't paint, to save my life. It's letting me do something I can't do well/at all on my own.
Using an LLM to do something I can do, with the caveat that it's pretty mediocre at the task, and needs to be constantly monitored to check it isn't doing stupid things? If I wanted that I'd just get an intern and watch them copy crappy examples from StackOverflow all day.
The same logic explains the use of LLM's to write emails/other long form text.
It makes accessible something that people otherwise cannot do well. Go look at submissions on community writing sites. The people who write because they're good at it, are adamant they don't use an LLM.
People use LLM's to do things they're otherwise not able to do. I will die on this hill.
"I've posited for a while now" and you post the most lukewarm and outdated take like it's an enlightenment. I've been coding for 20 years and can very well do everything the AI does, and so can all devs I know. We use it because it amplifies us, not because we couldn't otherwise. You've chosen a very ridiculous hill to die on.
Is your argument that there is no imaginable situation where someone who was competent at software development could find use for a semi-automated tool for writing software?
That would imply that either the person in question has infinite time, or has access to all software that could ever be of utility to them, which seems unlikely.
.... that an IDE providing a suggestion about what comes next as you type is not new, and the entire basis of how an LLM works is "what word probably comes next".
I'd have thought someone who's so enamoured with the tech would have at least a basic understanding of how it works.
Indeed. To be honest, I think everyone on HN is aware of how LLMs work at this point, it’s not actually adding a great deal to the discussion to keep going on about autocomplete or ‘stochastic parrots’.
At this point if someone calls it auto complete they can be written off as a Luddite with nothing valuable to say. The irony being they themselves are being a stochastic parrot by parroting the jargon other people say about llms.
While you are dying on a hill, with the help of LLMs, I'm shipping quality software and features to my customers at a pace I haven't been able to before. And no, not some nextjs slop. If you are letting your LLM look at StackOverflow, you are doing it wrong - it needs to be grounding in your stacks official docs and any other style/rules you prefer wired with other tooling like linting/formatting, duplication checking, etc. And yes, you have to constantly monitor the output and review every line of code - but it's still faster and if managed correctly, produces better code and (this is the hill I will die on) better test suites and documentation than I would have written.
I'd be more general and say it needs verification to guide it, and narrowed scope so it doesn't wander off. How those get provided can vary. While I can do what I'm asking it to do, and have so many times that I don't want to anymore, I can't do it as fast as it can. But as someone said, it is stupid really fast. The bottleneck is now me slowing down this intern who thinks fast by stopping it to redirect it when it does bad things. The more pre prompting and context and verification tools I give it the less I have to do that, so the faster it goes. Then I get to solve the parts of the problem I haven't done until its boring.
Initially I wanted to write more but I can boil it down to taste and context mismatch. By that I mean some people see LLM output as tasteless or kitsch (which I ascribe to generally) and another set of people (though sometimes overlapping more often than not) hold disdain or at the very least look funny at heavy LLM users like gym-goers would look at someone in the middle of the gym loudly suggesting using a dolly or forklift instead of barbell training.
So yeah, I guess the value of doodles has shot up simply because of optics.
Somewhere else in this comment section someone tried to broaden the definition of nerd so much so that pretty much anybody who is a consummate professional is also a nerd. The hill I will die on is that people don't actually dislike all this new AI stuff but more so the attitude of people heavily invested in it.
And to add another data point regarding your hill my drawing/painting moment was NLP stuff. Now if I want to do (rudimentary) sentiment analysis or keyword extraction I can lean on a local LLM. Yet I don't go around yelling Snowball (I think?) is obsolete.
I've been a software nerd all my life (and there was a time where I worked 60 hours a week at a startup working hard to make mobile games), but there's just been so much extra crap associated with it (especially web development, and especially corporate web development, what currently pays my bills) over the years that it's worn me down and I'm happy to let A.I. churn through the hard or frustrating or endless amounts of boilerplate bits, and let me focus on other things.
Part of me still wishes we were making websites with just HTML, CSS, PHP, and a little Javascript here and there (before AJAX). I'm still not convinced all this extra SPA functionality is really needed for most corporate website needs (something like Google maps or real-time chatting, sure, other things not so much), but I do it because they insist.
I also really like game design, and I had a fairly simple game idea that I prototyped a physical version of and playtested a few times and thought, 'yeah, this is pretty fun'.
But I don't have the energy to code it in my spare time anymore. Was curious how close to a working MVP it could get with me writing up a specification yesterday with the help of ChatGPT (after I brainstormed a few aspects of the design), and dumped that spec into a new repo on GitHub, and about 20 minutes later, it had a fully functional game that worked exactly like my physical prototype.
It was still missing other features, like tutorials and stats and sharing abilities and the like, and I'd like to adjust the presentation some, and the computer opponent A.I. was a bit weak and could have been stronger, but it was fully functional and even looked pretty good, kind of like a Wordle presentation, which was what I was going for anyway.
Something that would have taken me probably 40 hours of dedicated work at least to get everything working and looking as nice as it did.
So yeah, it's kind of like 'well what's the point of me manually coding this anymore'.
What I really like about software was solving puzzles, but now I can focus on the more interesting puzzle of what makes a good game design and 'how best to present this to players' instead of how to get five different libraries and/or APIs to play nice together and learn how it all works.
If coding hadn't become some labyrinthian monstrosity and got out of your way when coding, I probably would want to keep coding more.
Some languages/frameworks get close to that, Lua/Love2D is pretty smooth except when it gets to you wanting to distribute it on platforms other than PC/Mac/Linux, or integrate with external libraries, or for me work with shaders since I'm still pretty weak with shaders.
But even then, it was hard to deny how much faster A.I. could code a feature and I've started getting more hands-off there as well.
That being said, work has gotten less fulfilling, since I'm not doing any actual design work really, just implementing features and making them look according to Figma specifications or fixing bugs, so that's gotten less fulfilling without the busywork of solving coding puzzles (now it's 'how to say this to the A.I. to get it to fix this right, which is still a puzzle but a much weaker one). I'm starting to get tempted to make a go of starting my own business so I can have more autonomy again.
> Why is it a bad thing to know all the ins and outs of a programming language? To write and make all the decisions yourself? That shit is fun.
It's not just fun (i agree it is), but it is also essential for creation.
What we have done with the 'AI' is to create a lot of ignorant morons who think they can create a lot of things without knowledge. This is not gonna end well.
>Also, when did we stop liking to learn? Why is it a bad thing to know all the ins and outs of a programming language?
I do not know the inns and out of the assembly layer my high level code end up as. It's not because I don't like to learn, it's because I genuinely don't need to. At a certain level of AI performance, how will this be any different?
However, curious programmers who develop in high level languages will dabble with assembly maybe for fun, and will be much better off for it than those who treat parts of the stack like a black box never to be opened.
Because you may not know the specifics of the assembly being generated, but you’ve likely learned a language built on top of assembly. And the compilers do some great tricks behind the scenes to generate efficient assembly, but those tricks are specifically coupled to semantics of the source language.
An LLM is not coupled to anything and can generate output that simply does not relate to the input. This doesn’t happen with compilers, and if it does, then it’s a specific bug to be addressed. An LLM can never guarantee certain output based on the input.
If I write x < 100, I know exactly how the compiler will treat that code every single time, and I know what < means and how it differs from <=
If I tell an LLM that “I want numbers up to 100.” Will that give me < or <= and will it be consistent every single time, even the ten thousandth program that I write?
The language is ambiguous where the code is specific
To me this is semantics as far as it's related to "why don't you want to learn?"
I have a co-worker in another team that write java endpoins we consume. I can tell him what I need and I trust the output. I don't need to know java to trust him, it doesn't mean I don't want to learn.
There are thousand examples like this across every stack and abstraction level. From ssh-handshakes to gps.
Sure my co-worker is fundamentally different from a compiler which is fundamentally different from an LLM.
My argument is that the chain-of-trust where you offload knowledge to an external source is identical. We do it all the time but somehow doing it with an LLM means we no longer want to learn?
One difference is: to use a top notch compiler/assembler you don’t need to pay. They are open source and have a lot of support. To use the latest and greatest models (bc no one around likes to use non sota ones) you need to pay a premium price.
Multibillion dollars companies are now the gateway for every line of code you need to write. That’s dystopian. It sucks
Yes, but that's a completely different argument (that I agree with). Essentially, yes they are conceptually similar but one is bad because you have to pay rent to use it.
I have been building an iOS app that I had kicking around in my head for years but never had time to build. I have been a frontend UX engineer for the better part of a decade and went through a handful of tutorials on Swift. The project definitely sits in this uncanny valley for me. I have test suites for every aspect of the app and have the agent using TDD to avoid cheating - this has gotten me pretty far without having to look too close at the output other than general structure. As I'm reaching a more mature stage of the project though, I'm finding that I want to tweak a lot by hand in the code to get the details right without burning tokens.
The agents always do the best work IMO if you already know exactly what you want, but are too lazy to implement it. I like having the agent mock up a working solution before reimplementing it.
To split the difference, I now try to hand code as much as I can from the beginning, leave TODO comments for the agent to mop up and I'll ask it to complete the issue with reference to the current diff. It reduces the surface for agents to make stupid assumptions. If I can get it done fast on my own, win for me, if the agent finds issues or there's logic that needs checking, also a win. This way you stay sharp, but you have access to an oracle if you get stuck and it costs you fewer tokens.
Yeah, I like the "get out of jail free" card approach. The thing I always used to hate before this era was getting stuck in a hole on something that would take days or worse to grind through. It's nice to drop a little plank bridge across those now
In my view, AI is worst at crossing the rubicon from a 200-line script to a maintainable architecture of ~10kloc.
If you already have a decent architecture, adding a new feature is usually fine. If you have nothing and need it to write a 200-line script, that's usually fine. If you need it to figure out a maintainable architecture that will be easy to extend in the future... that;'s where the problems start.
> If you're trying to learn something new like an algorithm, protocol, or API write that shit by hand. You learn by doing, and when you know how the thing works and have that mental context, you will always be faster than an AI. Also, when did we stop liking to learn?
I vibe engineer to learn. I am currently doing this with a project to build a Vector DB extension in postgres. Several aspects of this project are very new to me. I don't write any of the code. I have never written a single line of Rust. I do, however, spend a significant amount of time discussing architecture and design with the agents.
I started with well known algorithms (HNSW, IVF, DiskANN, TurboQuant, RabitQ, PQFastScan) and have since moved on to a novel implementation based on fairly recent research papers.
My primary goal is to learn. That is a success and ongoing. A stretch goal is to contribute novel ideas back to the community, which may be useful even if what I build isn't ever production ready.
Fundamentally you need to start with "what am I trying to do?" and "given that goal, where is my time best spent?".
I made a checklist for my kids to stamp off items after they get back from school (sort bag, get changed, etc). I had two goals, 1) I was trying to solve a problem at home and would have pip installed a library that just straight up did this already and 2) I wanted to check out what the claude website outputs was like at the time. My time was best spent poking at claude a bit but mostly playing with my kids - so vibe coding it was.
Client test speedup issues, I'm trying to speed up tests for them and spend as little time as possible doing so. Vibe coded some analysis and visualisation tools, mostly AI but with some review guided multiple prototypes for timing and let it just fix whatever. More dedicated review for the actual solutions.
Learning a new thing - goal is to learn that thing. AI there is good for doing a lot of the work around that. Maybe I'm focussing on, say, Z3. AI there can help with debugging, finding docs, setting up an environment and leave me to do the central part.
Let’s see if someone can point me towards some resources over the following.
The problem is mixing vibe-coding and agentic-eng, and switching the brain in 2 different modes (fast-feedback gratification vs deep-focus gratification).
There’s no clear cut rule on what works. Different people, different brains, and especially amongst devs some optimized low-key neurodivergence.
And then there’s waiting mode, those N seconds/minutes that agents take to think and write.
What’s the right mix?
Keep a main focused project and … what do you do in the meantime?
Vibe code something else?
Hn? Social media?
Draw lines on a paper sheet?
Wood carving?
Exercise?
Rewatch some old tv series?
I have experimented….
There are side activities that help you go back to the task at hand in the correct mental framework for it.
Not just for productivity, but for efficiency and enhancing critical thinking on the main task.
Or whatever you choose to optimize for.
Can anyone point me towards some people talking about this?
Says who? One of the most enriching things about coding with agents is I have them provide new information, tools, patterns, whatever as a follow up to every feature I work on. I’m learning a ton and it’s helping me build better with agents, too.
I imagine my future will involve spending 40–60 hours a week using LLMs to do the work of multiple roles instead of just one, while wishing I could spend my remaining time doing other things.
When the economy got so bad for so many people, that every waking moment has to be either chasing fresh cash (or spent in recovery from cash-chasing, worrying about new cash), to the point they have to largely ignore their own long term goals or basic morals or principles.
You can blame all the new gadgets (phones/social media/tiktok/‘dopamine-things’) — but it’s a very much blaming the symptom, not the problem.
(It’s the meme. “Guys, this isn’t funny. Humans only do this when they’re very distressed”)
Just here to say I love the line 'A hammer is a really great tool that has thousands of purpose-designed uses. I still prefer my key to get into my car.'
Been saying the 'Hammer is a great tool but you need to know when to use it, just like AI.' to coworkers, and i'm ̶s̶t̶e̶a̶l̶i̶n̶g̶ borrowing your quote instead, now
Some people actually don't really like to learn new things. If the machine spits out plausible working code, they'd be perfectly happy with that. Personally I think AI is doing a lot more harm than good and I can't wait for the bubble to burst.
I don’t think it’s going to burst like how other people expect. The technology is already out there, when it loses steam people aren’t suddenly going to stop using it. I predit it’ll be more like the dot come crash where companies that can survive the downturn come out dominant.
It ends like this: all codebases become unmaintainable spaghetti after agentic AI spends years on it. Then after every agent in existence will spend minimum 24 hours reading the codebase to add a simple feature, the software is abandoned.
To use an analogy, LLMs are like the Ring of Power in Lord of the Rings. The Ring of Power does not corrupt one nor does it magically turn one evil. Rather, the Ring just serves as a catalyst for what is already inside the bearer.
Many that wore the Ring had pure and righteous intentions. The thought of, "If I were in power, I would..." was the arrogance and corruption which the Ring amplifies.
So, I cannot agree that it is AI doing the harm. Rather, AI just gives us the power to do the harm, the shortcuts, the cheats, etc. we have always desired. And just like the Ring, I believe much of the harm from LLMs often comes from people that started with good intentions, and the power it grants is just too tempting for many.
> If you're at work and they really care about getting something out of the door, do whatever you think is best.
If you don’t mind being jobless, sure do whatever you think is best. Not all of us can simply switch companies easily. Folks need to realise that AI in a company setting works for the benefit of the company, not for the individual.
But do companies really know how to use AI? I think most of it is experimentation - throwing things to the wall and seeing what sticks.
It's the practitioner who eventually figures out what really works. I see this the same way the agile movement emerged. It was initiated by people who were hands-on programmers and showed enough benefit at minimizing software waste before it took a life of its own and started getting peddled by people who didn't really understand the underlying principles.
> I think most of it is experimentation - throwing things to the wall and seeing what sticks.
This is true in macro, but I think we're specifically referring to LLM-generated /assisted code (vibe-coding). 'Getting something out the door' is not an necessarily in reference to an AI-infused product, just new code written by AI
If you've been writing Perl for 30 years, you might not want to learn JavaScript just to make a little fun idea in your head to show your wife. Vibe code that shit man. Who cares? Your wife does not care about LOC or those internal design decisions you made.
If you're trying to learn something new like an algorithm, protocol, or API write that shit by hand. You learn by doing, and when you know how the thing works and have that mental context, you will always be faster than an AI. Also, when did we stop liking to learn? Why is it a bad thing to know all the ins and outs of a programming language? To write and make all the decisions yourself? That shit is fun. I don't care if you disagree.
If you're at work and they really care about getting something out of the door, do whatever you think is best. If you just wanna ship vibed code and review PRs all day, all the power to you. If you wanna write it by hand, and use AI like a scalpel to write up boiler plate, review code, do PR audits, etc... go for it!
A hammer is a really great tool that has thousands of purpose-designed uses. I still prefer my key to get into my car. It's all tools, you are a person.
A lot of this stuff if coming top-down from people who do not have the experience you do. Wouldn't a smart employee use their expertise to advise the organization? If you work at a company where that would not be okay, maybe it's time to start looking for another firm.