@pluralistic At the tech conference I was at last week, which was of course 2/3 AI, it was often taken as self-evident that AI had given us huge gains. I should look up some of those people and send them this ...
@veronica You can probably anticipate their reactions as much as I do. It's pointless. AI is a waste of time. Even warning of AI is a waste of time.
@burningTyger There were several good talks on AI there too, so a good chunk of the audience got a balanced message overall. I also attended a few talks on AI usage, but only those directly relevant to my work (they did after all pay for my ticket).
@pluralistic One talk, that was quite interesting, was from a company with 180 developers that did a slow and careful rollout of AI, mainly due to high demand. They did a self-assessment, and developers claimed increased productivity. They said it was too early to say if it was actually true though, and promised to come back with results (presumably another year) if they had any.
It's the same where I work. Developers *feel* more productive, but I have yet to see any numbers backing it up.
Oct 25, 2026, 1:35 PM@veronica @pluralistic I think they are more productive, given a definition of 'productive' that measures output.
You can definitely produce much more... 'stuff'. Some of it might even be useful. A lot of it turns out to waste other people's time. But as long as you have a definition of productivity that only measures output and not bottom line results, it's a useless metric.
@loke Indeed. If your metric is output, then sure. It's the age old "quality or quantity" conundrum. If it's not useful output, or you need to frequently replace it with new generated code, is it then productive in a meaningful sense? Or, in my opinion, worse: Is it just increased complexity and fragility for no or minimal gain?
Oct 25, 2026, 4:48 PM@veronica @pluralistic The metric is output. And it is that because everything else is difficult to measure. And if it's difficult to measure it's better to just ignore it or something. I'm sure it won't show up in the next quarter's earnings.
Oct 25, 2026, 1:51 PM@veronica @pluralistic I have looked at two AI tools, one is a simple line completion model that guesses at what I'm about to type. It's a simple model that runs locally and is right about 80% of the time. Overall I think it offers a benefit.
The other is a big model that tries to figure out the next few lines, and even after letting it at a code base for some time, the guesses are wildly inaccurate, and mess with keystrokes, so I wind up having that inaccurate code injected, which means I then need to remove it before typing what I was already planning to type. This has lowered my productivity. I have used this model to generate test cases; about 80% of the cases made sense, the rest needed minor tweaks, so there's a potential use case there.
I will try getting an advanced model to build a small application, but at this point I expect I'll spend as much time fixing the generated code as it would have taken to write it in the first place.
One place where it might be useful is generating code in a language I am familiar with but haven't mastered. At that point the logic would still be auditable, and I could use that review to raise my level of expertise.
@alan I find the VSCode auto-complete feature highly annoying and I mostly just keep it off. Some of the stuff I work on is pretty obscure, like parsing streaming binary subtitle data from DVD/Bluray, and it keeps suggesting code that is obviously stolen from somewhere else (and also doesn't fit my use case). I've also had it echo back my own code too, when it's relatively rare stuff. Funnily, it came with a license warning last time. I cannot recall them asking to ingest my code without credit!
Oct 25, 2026, 3:19 PM@veronica The sort of stuff my line completion (well, line plus a bit) is I type, in a loop, "if variable is empty" and it suggests completing the if with a continue statement, so a tab saves 10-11 keystrokes. I can live with that.
@alan @veronica @pluralistic For your first use case (completion), yes, qwen models from last year did that pretty well, very small distillations of 3B or less, did useful work, but that's still depending on you validating each suggestion.
For agentic coding, the code is not generated first try reliably, you need the agent to be ble to run the code, see breaking tests, syntax errors, etc, and self-correct.
I have been disapointed so far with the ability of local models, even when it works, it's too slow, though i had a quick test of the newly released "flint" on friday, that runs at 50 tokens/s on my macbook pro M2 max, and reportedly a lot faster on an M4, it looks good enough to attempt actual work, in replacement of claude.
Regarding productivity, i think closed/frontier model are good at building things very fast, but the bottleneck of choosing what to build, and making sure we understand what we have, don't really go away.
Oct 25, 2026, 3:49 PM@tshirtman @veronica @pluralistic My personal feeling is that it should be starkly obvious that the current algorithms are woefully inefficient. In fact, so inefficient that no computer scientist would say that it's reasonable to deploy them commercially.
Unfortunately, a bunch of entrepreneurs and VC's seem to have missed or ignored this fact and we've taken this path of building it out instead of waiting for reasonably efficient innovations.
As a result we have this looming, massive bubble that when it bursts, in addition to the massive real economic harm it will do, will set back the theoretical development, research that could discover more efficient approaches, for years.
@alan @veronica @pluralistic Inefficient compared to what? I agree they are energy intensive, but they are doing a thing we didn't know how to do before, which is to have computers write, operate, improve, verify programs from natural language prompts (not even just English, but about any human language sufficiently documented).
And while they are indeed energy intensive, the efficiency has been increasing a lot over the last couple years, although it's hard to get clear data, the companies are secretive about it, the massive energy costs seems to be mostly on the training on newer, bigger models, not producing output from the existing ones, and we can run relatively large models, that are doing useful work, today, on customer hardware (admittedly high end).
I think what the VC have missed, is that they won't be able to capture the value created, because their product will be commoditized and run for cheaper on hardware they don't own.
I agree the bubble popping will hurt, yes.
Oct 25, 2026, 5:35 PM@tshirtman @veronica @pluralistic I would use as a baseline for efficiency comparisons, the power consumption of a human brain. I don't expect we'll reach that anytime soon, but it seems clear that we're at least a few orders of magnitude away from that at the moment. However we're far enough away that I expect some big steps in closing that gap are not that far out of reach.
I think that's an excellent point about model commoditization. Maybe that's a disincentive for VCs to seek more efficiency.
@alan @veronica @pluralistic interesting point, but human brains sadly don't run on solar panels, and feeding us is pretty energy intensive, given all the loops energy has to jump through before it gets to occasionally allow a brain to fix issues in a program, i'm not sure the comparison is as clear cut. Also, getting more brains apt at this particular task is a very lengthy and energy intensive process, while spawning a new inference context for a model is very straightforward, if still not cost-free, and that model will work at speed i can't imagine humans rivaling with.
I'm vegan, so i imagine my brain is a bit less intensive in primary-energy to run, as eating plants is more efficient, but still, a frontier model doing what used to take weeks, in hours if not minute, gives a solid ratio to start with to the machine.
I'm all for making things more efficient though, and i think it'll happen whether VCs want it or not, competition is a rough mistress.
Oct 25, 2026, 6:08 PM@tshirtman @veronica @pluralistic Then to be fair in that wider estimate you need to include the energy cost of extracting, refining, packaging, shipping, and replacing the components in an AI data centre. I think that balances it out to some extent, even when ignoring the environmental impact of those activities.
Excluding all these inputs, can these processes become more efficient than the human brain? My guess is that they can, and that's when concerns of AGI become much more pertinent. It also illustrates just how far I think we are away from getting there.
We learn by doing. Reviewing isn’t doing, or you could just read existing code to learn a language.
Evidence I have seen so far is that AI will stop development of expertise.
Oct 25, 2026, 9:37 PM@ThreeSigma @veronica @pluralistic with a few exceptions (eg. APL, Lisp) a new language is just syntax and a handful of different operators. I say this as someone with experience with maybe two dozen programming languages, many obscure.
Oct 25, 2026, 9:39 PM@ThreeSigma @veronica @pluralistic That said, your concern is valid for people just entering the field. There's little market for junior developers if an AI can fulfill that role cheaper and faster.
How we educate developers is going to have to undergo radical change.
@veronica @pluralistic @alan
Then why need the AI at all? You’re being inconsistent. Either the language is trivial and you could just do it yourself, or it’s tricky and the AI saves you time (that I claim is valuable learning).
I’m also an old hand at this but I’m still learning or I get bored.
Oct 26, 2026, 3:45 PM@ThreeSigma @veronica @pluralistic It's a case of learn by doing. As an example, I might ask for an implementation of something I've written in one language to be rewritten in Zig. Then I'm going to get a big pile of code that is a rough approximation of the port. I could go burning more credits or tokens or whatever to have the AI refine it into something with a bunch of subtle and difficult to find bugs, or I could use it as a baseline and start to explore, rewrite, and debug from that first pass.
That's my preferred modality of learning. Reading a language reference manual is a little dry, but now I'll be digging into it repeatedly to get an understanding of the nuances of the language. Instead of tutorials that circumnavigate quirks and edge cases, I'll run into something I don't understand and go digging until I do. At the same time I'll gain familiarity with build and debugging tools, assorted libraries, the ecosystem in general.
And if I'm lucky, in a reasonable amount of time I'll also have my application implemented in an environment more suited to the job. Most importantly, I'll actually know how that application works.