> When I joined this company, my team didn't use version control for months and it was a real fight to get everyone to use version control. Although I won that fight, I lost the fight to get people to run a build, let alone run tests, before checking in, so the build is broken multiple times per day. When I mentioned that I thought this was a problem for our productivity, I was told that it's fine because it affects everyone equally. Since the only thing that mattered was my stack ranked productivity, so I shouldn't care that it impacts the entire team, the fact that it's normal for everyone means that there's no cause for concern.
Do not underestimate the ability of developers to ignore good ideas. I am not going to argue that AI is as good as version control. Version control is a more important idea than AI. I sometimes want to argue it's the most important idea in software engineering.
All I'm saying is that you can't assume that good ideas will (quickly) win. Your argument that AI isn't valuable is invalid, whether or not your conclusion is true.
P.S. Dan Luu wrote that in 2015, and it may have been a company that he already left. Version control has mostly won. Still, post 2020, I talked to a friend, whose organization did use git, but their deployed software still didn't correspond to any version checked into git, because they were manually rebuilding components and copying them to production servers piecemeal.
Writing unit tests where needed makes you more productive in the long run. Writing in modern languages makes you more productive. Remember how people writing assembly thought compiled languages would rot your brain!
But people just resist change and new ways of doing things. They don't care about actual productivity, they care about feeling productive with the tools they already know.
It's a hard sell when an application moves a button! People don't like change. Change is always a hard sell to a lot of people, even when it benefits them.
The teams making changes to software are, on average, moderately worse than the teams who originally developed the software, if only because they missed out on the early development experience, and often don't fully understand the context and reasons for the original design and don't reason from first principles when making updates, but copy the aspects they notice superficially while undermining the principles they were originally established on.
Even when the changes are independently advantageous, it is common for changes to one part of a system to gratuitously break a variety of other parts that are dependent on it. Trying to manage and fix a complex web of inter-dependent software which is constantly changing and breaking is an overwhelming challenge for individual humans, and unfortunately often not a sufficient priority for groups and organizations.
No, I don't remember that and I've been around awhile. (I'm sure one could find a handful of examples of people saying that but one can find examples of people saying sincerely that the earth is flat.) It was generally understood that the code emitted by early, simple compilers on early CISC processors wasn't nearly as good as hand-tuned assembly code but that the trade-off could be worthwhile. Eventually, compilers did get good enough to reduce the cases where hand-tuned assembly could make a difference to essentially nothing but this was identified through benchmarking by the people who used assembly the most themselves.
If you want to sell us on change, please stop lying right to our faces.
They eventually got there, (and I expect AI will eventually get there too), but it took a lot of evolution.
Modern ISA designers (including those evolving the x86_64 ISA) absolutely take into account just how easy it is for a compiler to target their new instructions. x86 in modern times has a lot of RISC influence once you get past instruction decode.
Debatable? It has positive effects for organizations and for the society, but from a selfish point of view, you gain relatively little from writing tests. In your own code, a test might save you debugging time once in a blue moon, but the gains are almost certainly offset by the considerable effort of writing a comprehensive suite of tests in the first place.
Again, it's prudent to have tests for more altruistic reasons, but individual productivity probably ain't it.
> Writing in modern languages makes you more productive.
With two big caveats. First, for every successful modern language that actually makes you more productive, there's 20 that make waves on HN but turn out to be duds. So some reluctance is rational. Otherwise, you end up wasting time learning dead-end languages over and over again.
Second, it's perfectly reasonable to say that Rust or whatever makes an average programmer more productive, but it won't necessarily make a programmer with 30 years of C++ experience more productive. This is simply because it will take them a long time to unlearn old habits and reach the same level of mastery in the new thing.
My point is, you can view these through the prism of rational thinking, not stubbornness. In a corporate setting, the interests of the many might override the preferences of the few. But if you're an open-source developer and don't want to use $new_thing, I don't think we have the moral high ground to force you.
It’s much more than this. You feel it when you make a change and you are super confident you don’t have to do a bunch of testing to make sure everything still behaves correctly. This is the main thing good automated tests get you.
Compilers did get better, and continue to--just look at my username. But in the early days one could make very strong, very reasonable, cases for sticking with assembly.
Well, how'd you describe web apps of today if not precisely brainrot?
> They don't care about actual productivity, they care about feeling productive
Funny you'd say that, because that describes a large portion of "AI coders". Sure they pump out a lot of lines of code, and it might even work initially, but in the long run it's hardly more productive.
> It's a hard sell when an application moves a button!
Because usually that is just change for the sake of change. How many updates are there every day that add nothing at all? More than updates that actually add something useful, at least.
You're assuming that the change is beneficial to people when you say this, but more often than not that just isn't true. Most of the time, change in software doesn't benefit people. Software companies love to move stuff around just to look busy, ruin features that were working just fine, add user hostile things (like forcing Copilot on people!), etc. It should be no surprise that users are sick of it.
I write a TON of one off scripts now at work. For instance, if I fight with a Splunk query for more than five minutes, I’ll just export the entire time frame in question and have GHCP (work mandates we use only GHCP) spit out a Python script that gets me what I want.
I use it with our internal MCP tools to review pull requests. It surfaces questions I didn’t think to ask about half the time.
I don’t know that it makes me more productive, but it definitely makes me more attentive. It works great for brainstorming design ideas.
The code generation isn’t entirely slop either. For the vast majority of corporate devs below Principal, it’s better than what they write and its basic CRUD code. So that’s where all the hyper productive magical claims come from. I spend most of my days lately bailing these folks out of a dead end fox hole GHCP led them into.
Unfortunately, it’s very much a huge time sink in another way. I’ve seen a pretty linear growth in M365 Copilot surfacing 5 year old word documents to managers resulting in big emails of outdated GenAI slop that would be best summarized as “I have no clue what I’m talking about and I’m going to make a terrible technical decision that we already decided against.”
Big tech's general strategy is get-big-fast - and then become too-big-to-fail. This was followed by facebook, uber, paypal, etc. The idea is to embed AI into daily behaviors of people whether they like it or not, and hook them. Then, once hooked, developers will clamor for it whether it is useful or not.
I've seen it all the time. Version control, code review, unit testing, all of these are top-down.
Tech tools like git instead of CVS and Subversion, or Node instead of Java, may be bottom-up. But practices are very much top-down, so I see AI fitting the pattern very well here. It feels very similar to code review in terms of the degree to which it changes developer practices.
Obviously developers invented these things and initially diffused the knowledge.
But you're agreeing with me that they then got enforced top-down. Just like AI. AI isn't new or different like this. Developers started using LLM's for coding, it "diffused" so management became aware, and then it becomes enforced.
There's a top-down mandate to use version control or unit testing or code review or LLM's. Despite plenty of developers initially hating unit tests. Initially hating code review. These things are all standard now, but weren't for a long time.
In contrast to things like "use git not Subversion" where management doesn't care, they just want you to use a version control.
AI seems to have primarily been pushed top-down from management long before any consensus has been reached from the devs on what it's even good for.
This is unusual; I suspect the reason is that (for once) the tech is more suitable for management functions than the dev stuff. Judging from the amount of bulletpointese generation and condensation I've seen lately anyway.
And there have been plenty of enthusiastic devs regarding LLM's.
And the idea that "until a consensus is reached" is just not true. These practices are often adopted with 1/3 of devs on board and 2/3 against. The whole point of top-down directives is that they're necessary because there isn't broad consensus among employees.
It was the same thing with mobile-first. A lot of devs hated it while others evangelized it, but management would impose it and it made phones usable for a ton of things that had previously been difficult. On the balance, it was a helpful paradigm shift imposed top-down even if it sometimes went overboard.
Early VCS was clunky and slow. If one dev checked out some files, another dev couldn't work on them. People wouldn't check them back in quickly, they'd "hoard" them. Then merges introduced all sorts of tooling difficulties.
People's contributions were now centrally tracked and could be easily turned into metrics, and people worried (sometimes correctly) management would weaponize this.
It was seen by many as a top-down bureaucratic Big Brother mandate that slowed things down for no good reason and interfered with developers' autonomy and productivity. Or even if it had some value, it wasn't worth the price devs paid in using it.
This attitude wasn't universal of course. Other devs thought it was a necessary and helpful tool. But the point is that tons of devs were against it.
It really wasn't until git that VCS became "cool", with a feeling of being developer-led rather than management-led. But even then there was significant resistance to its new complexity, in how complicated it was to reason about its distributed nature, and the difficulty of its interface.
AI does not have such curve. It is top down, from the start.
Management caught up and started to talk about them only years later.
I wasn't around to experience it but my understanding is that this is what happened in the 90's with object oriented programming - it was a legitimately useful idea that had some real grassroots traction and good uses, but it got sold to non-technical leadership as a silver bullet for productivity through reuse.
The problem then, as it is now, is that developer productivity is hard to measure, so if management gets sold on something that's "guaranteed" to boost it, it becomes a mandate and a proxy measure.
Let’s not let the smoke and mirrors dictate how we use the tool, but let us also not dismiss the tool just because it’s causing a fad.
Much like the internet era actually - obviously loads of value, but picking out the pets.coms from the amazon.coms ... well, it wasn't clear at the time which was which; probably both really (we buy our petfood online) except that only one of them had the cash reserves to make it past the dot com crash.
The core problem, as OP called out, is change aversion. It's just that for many previous useful changes, management couldn't immediately see the usefulness, or there would've been pressure too.
Let's not forget that well-defined development processes with things like CI/CD, testing, etc only became widespread after DORA made the positive impact clearly visible.
Let's face it: Most humans are perfectly fine with the status quo, whatever the status quo. The outward percolation of good ideas is limited unless a forcing function is applied.
"AI" on the other hand is shoved down people's throats by management and by those who profit from in in some way. There is nothing organic about it.
AI adoption is, for better or worse, voluntarily or not, very fast compared to other technologies.
The same could be true for coding agents too, or maybe not. Time will tell.
This adoption rate / shoving is insane. It is not based on anything but dollars.
No new real wealth can be created but financial wealth may transfer from the firms buying stuff to the large tech firms - thereby creating new financial wealth for big tech stockholders. In the long run the two should converge - but in the short run they can diverge. And I think that’s what we are seeing.
The attempt to compare it with Version Control, with sliced bread, with plumbing and sanitization practices. Think of any big innovation and compare it with it until people give in and accept this is the biggest bestest thing ever to have happened and it is spreading like wildfire.
Even AI wouldn't defend itself this passionately but it conquered some people's hearts and minds.
I use AI a lot myself, but being forced to incorporate it into my workflow is a nonstarter. I'd actively fight against that. It's not even remotely the same thing as fighting source control adoption in general, or refusing to test code before checking it in.
Wonder what'll happen to JPY once the Yen-carry unwinds from this massive hype-cycle - will probably hit 70 JPY to the dollar! Currently Sony Bank in Japan offers USD time-deposits at 8% pa. - that's just insanely high for what is supposed to be a stable developed economy.
Honestly I think the same thing happened with self-driving cars ~10 years ago.
Larry Page and Google's "submarine" marketing convinced investors and CEOs of automakers and tech companies [1] that they were going to become obsolete, and that Google would be taking all that profit.
In 2016, GM acquired Cruise for $1 billion or so. It seems like the whole thing was cancelled in 2023, written off, and the CEO was let go
How much profit is Waymo making now? I'm pretty sure it's $0. And they've probably gone through hundreds of billions in funding
How's Tesla Autopilot doing? Larry also "negatively inspired" Elon to start OpenAI with other people
I think if investors/CEOs/automakers had known how it was going to turn out, and how much money they were going to lose 10 years later, they might not have jumped on the FOMO train
But it turns out that AI is a plausible "magic box" that you extrapolate all sorts of economic consequences from
(on the other hand, hype cycles aren't necessarily bad; they're probably necessary to get things done. But I also think this one is masking the fact that software is getting worse and more user hostile at the same time. Probably one of the best ways to increase AI adoption is to make the underlying software more user hostile.)
[1] I think even Apple did some kind of self-driving car thing at one point.
https://en.wikipedia.org/wiki/Apple_car_project
>From 2014 until 2024, Apple undertook a research and development effort to develop an electric and self-driving car,[1] codenamed "Project Titan".[2][3] Apple never openly discussed any of its automotive research,[4] but around 5,000 employees were reported to be working on the project as of 2018.[5] In May 2018, Apple reportedly partnered with Volkswagen to produce an autonomous employee shuttle van based on the T6 Transporter commercial vehicle platform.[6] In August 2018, the BBC reported that Apple had 66 road-registered driverless cars, with 111 drivers registered to operate those cars.[7] In 2020, it was believed that Apple was still working on self-driving related hardware, software and service as a potential product, instead of actual Apple-branded cars.[8] In December 2020, Reuters reported that Apple was planning on a possible launch date of 2024,[9] but analyst Ming-Chi Kuo claimed it would not be launched before 2025 and might not be launched until 2028 or later.[10]
In February 2024, Apple executives canceled their plans to release the autonomous electric vehicle, instead shifting resources on the project to the company's generative artificial intelligence efforts.[11][12] The project had reportedly cost the company over $1 billion per year, with other parts of Apple collaborating and costing hundreds of millions of dollars in additional spend. Additionally, over 600 employees were laid off due to the cancellation of the project.[13]
Please don't use Hacker News for political or ideological battle. It tramples curiosity.
It's also no coincidence America has built no rail in many decades while centrally planned China built a massive HSR network in the past 15 years.
e.g. in 2018, over 7 years ago, I was simply pointing out that people like Chris Urmson (who had WORKED ON self-driving for decades) and Bill Gurley said self-driving would take 25+ years to deploy (which seems totally accurate now)
https://news.ycombinator.com/item?id=16353541
And I got significant pushback
Actually I remember some in-person conversations with MUCH MORE push back than that, including from some close friends.
They believed things because they were told by the media it would happen
People told me in 2018 that their 16 year old would not need to learn how to drive, etc. (In 2025, self-driving is not available in even ONE of their end points for a trip, let alone two end points)
Likewise, at least some people are convinced now that "coding as a job is going away" -- some people are even deathly depressed about it
Hacker News goes for anything that they think they might be able to make money off of, just like all middle-class people. They evaluate events based on how they could affect them personally. Actual plausibility isn't even secondary, they simply defer to the salesmen (whom they admire and hope one day to be.)
[0]: https://youtu.be/040ejWnFkj0?si=7yI3eKkirJdTWPwR [1]: https://en.wikipedia.org/wiki/Clanker [2]: https://youtu.be/RpRRejhgtVI?si=aZUVcsY8VyR_jbBA
I suspect stuff like lane following assist and adaptive cruise control
1) will ultimately provide the path to self driving eventually
2) wasn’t particularly helped by the hype cycle
1 is impossible to say at his point, for 2 I guess somebody who works in the field can come along and correct me.
That's where we are.
Waymo has been slow and steady, and has built something pretty great.
In 2016, GM acquired Cruise for $1 billion or so. It seems like the whole thing was cancelled in 2023, written off, and the CEO was let go
How much profit is Waymo making now? I'm pretty sure it's $0.
* https://www.cbtnews.com/waymo-hits-10m-driverless-rides-eyes...
But yeah, certainly 5-7 years behind the initial schedule. Which I guess was more of your point.
Let’s see it work in Minnesota in the winter where you can’t see lane markings, everything is white, and the camera lenses immediately get covered with road salt spray.
It's important to not confuse activity, with progress, with results.
At the same time, it's important to not confuse or downplay results, with progress, with activity.
There seems to be activity, progress, and results. It seems to be speeding up.
I don't have any preference for or against Tesla. Just observing.
What can incremental progress do to make a camera see through road salt deposited on its lens? I call bullshit. There isn't any incremental path because it's not physically possible. The photons are stopped by the salt. No amount of "AI" or what the fuck ever else will change this. There is no path towards "progress" here.
I don't operate from an assumption that cameras will remain the same as they are today.
Your comment did remind me about Comma, though.
which is what people like Chris Urmson and Bill Gurley already said prior to 2018 (see my sibling comment)
https://en.wikipedia.org/wiki/List_of_predictions_for_autono...
We're going to end up with complete autonomy
Ultimately you'll be able to summon your car anywhere … your car can get to you. I think that within two years, you'll be able to summon your car from across the country
---
(Also, in 2018 I said I'd be the first to buy a car where I could sleep behind the wheel while going from SF to Portland or LA. That obviously doesn't exist now.
Anyone want to take a bet on whether this will be possible in 2032, 7 years from now? I'd bet NO, but we can check in 2032 :-) )
1) crypto: raise funding, buy crypto as collateral, raise more funding with said collateral, rinse and repeat.
2) gpu datacenters: raise funding, buy gpus as collateral, raise more funding, buy more gpus, rinse and repeat.
3) zero day options: average folks want a daily lottery thrill. rinse and repeat.
All of the above are fed by fomo and to some extent hype, and ripe for a reckoning.
Marketers are trying to keep their jobs, sales people are trying to keep their jobs, etc.
I think my time frame is firmly after the invention of excel but before the web was it's own thing
On the energy side, Google recently estimated that an average Gemini inference consumes around 0.24 Wh, which is roughly the same as running a microwave for a single second. Older rule-of-thumb comparisons put the figure closer to 3–6 seconds of microwave use, or about 0.8–1.7 Wh per prompt. If you apply those numbers to U.S. usage, you get somewhere between 79 MWh and 550 MWh per day nationally, which translates to only a few to a few dozen megawatts of continuous load. Spread across the population, that works out to between 0.09 and 0.6 kWh per person per year — just pennies worth of electricity, comparable to a few minutes of running a clothes dryer. The bigger concern for the grid is not individual prompts but the growth of AI data centers and the energy cost of training ever-larger models.
The tire geometry causes a bit of oversteering, but they generally corner well, etc.
One of the major issues I'm seeing is how much technical people haven't been involved in the application of AI, which leaves non-technical people to pontificate and try.
With any new tech, after the hype is gone, what remains, is adopted and used.
The internet, social media, smartphones, all seemed foreign.
LLMs are no different. They will solve things other things haven't before.
LLMs are only as good as the users using it. Users only get better at using AI but putting in the repetitions. It's not a tool that's alive or a psychic.
For example, I work in operations, so most of what I touch is bash, Ansible, Terraform, GitHub workflows and actions, and some Python. Recently, our development team demonstrated a proposed strategy to use GitHub Copilot: assign it a JIRA ticket, let it generate code within our repos, and then have it automatically come back with a pull request.
That approach makes sense if you are building web or client-side applications. My team, however, focuses on infrastructure configuration code. It is software in the sense that we are managing discrete components that interact, but not in a way where you can simply hand off a task, run tests, and expect a PR to appear.
Large language models are more like asking a genie. Even if you give perfectly clear instructions, the result is often not exactly what you wanted. That is why I use Copilot and Gemini Code Assist in VS Code as assistive tools. I guide them step by step, and when they go off track, I can nudge them back in the right direction.
To me, that highlights the gap between management’s expectations and the reality of how these tools actually work in practice.
Doesn’t change the fact that it’s stupid, annoying, and bad design, but I don’t know that outright deception is needed to explain it.
Yes! "Forced features" are a misguided effort to drive internal usage metrics. There are other ways to let users know about new features, short of forcing it on them obnoxiously.
It's a rather perverse cycle.
Microsoft is a software company. They wouldn't have released this to begin with to have an extreme competitive edge!
Sometimes people are resistant to use things that improve their life and have to be convinced to work in their own self interest.
https://www.cnn.com/2022/05/14/business/grocery-shopping-car...
When I first heard about git, I knew that it would be very useful in the future, even if I had to spend some time and effort in mastering it. Same with CI, project planners, release engineering, etc. Nobody had to convince me to use them. But AI just doesn't belong to that category, at least in my experience. It misses results that a simple web/site search reveals. And it makes mistakes or outright hallucinates in ways even junior developers don't. It's in an uncanny valley between the classic non-AI services and plain old manual effort with disadvantages of both and advantages of neither. Again, others may not agree with this experience. But it's definitely not unique to me. The net gain/loss that AI brings to this field is not clear. At least not yet.
Since right now there is an aire of competition, I would guess that these companies believe its winner-take-all, and are doing their “one monopoly to aid another” to get this market before theres another verb-leader (like chatgpt for llm, or google for search).
It could also be that they think that people won’t know how good they are until they try it, that it has to be seen to be believed. So getting people to touch it is important to them.
But, I think I agree with you, its so heavy handed that it makes me want to abandon the tools that force it on me.