correct me if I'm wrong those studies would not have looked at TypeScript itself, which for all I know could be complete garbage designed to lock you into MSFT products.
It’s a formal acknowledgement that humans make mistakes, implicit assumptions are dangerous and that code should be validated before it runs. That’s literally the whole point, and if developers by type were YOLO I’ll push it anyway, TS wouldn’t have got anywhere near the traction it has. Static typing is a monument to distrust.
Yes, we have decades of such research, and the aggregate result of all those studies is that no productivity gain can be significantly demonstrated for static over dynamic, and vice-versa.
Where is the proof that Javascript is a better language than Typescript? How do you know if you should be writing in Java/Python/C#/Rust/etc? Probably should wait to create your startup lest you fall into a psychological trap. That is the ultimate conclusion of this article.
It's ok to learn and experiment with things, and to build up your own understanding of the world based on your lived experiences. You need to be open minded and reevaluate your positions as more formalized understandings become available, but to say it's too dangerous to use AI because science hasn't tested anything is absurd.
This is an interesting question really. It feels like it would be really hard to do a study on that. I guess the strength of TS would show up mainly as program complexity grows such that you can't compare toy problems in student exams or what ever.
It seems messy. Just one example that I remember because it was on HN before: https://www.hillelwayne.com/post/this-is-how-science-happens...
We have one study on test driven development. Another study that attempted to reproduce the results but found flaws in the original. Nothing conclusive.
The field of empirical research in software development practices is... woefully underfunded and incomplete. I think all we can say is, "more data needed."
hwayne did a talk on this [0].
If you ever try to read the literature it's spartan. We certainly haven't improved enough in recent years to make conclusions about the productivity of LLM-based coding tools. We have a study on CoPilot by Microsoft employees who studied Microsoft employees using it (Microsoft owns and develops CoPilot). There's another study that suggests CoPilot increases error rates in code bases by 41%.
What the author is getting at is that you can't rely on personal anecdotes and blog posts and social media influencers to understand the effects of AI on productivity.
If we want to know how it affects productivity we need to fund more and better studies.
I'd be interested in the type of structured research the author is interested in. Could it also be researched whether Go or PHP is better for web development? In some sense, I guess. Both are probably more efficient than writing Apache extensions in assembler, but who knows?
The FUD to spread is not that AI is a psychological hazard, but that critical reasoning and training are much, much more important than they once were, it’s only going to get more difficult, and a large percentage of white-collar workers, artists and musicians will likely lose their jobs.
Not sure which side of the argument this statement is promoting.
There must be something for which humans are essential. Right? Hello? Anybody? It's not looking good for new college graduates.[1]
[1] https://www.usatoday.com/story/money/2025/06/05/ai-replacing...
> But Cialdini’s book was a turning point because it highlighted the very real limitations to human reasoning. No matter how smart you were, the mechanisms of your thinkings could easily be tricked in ways that completely bypassed your logical thinking and could insert ideas and trigger decisions that were not in your best interest.
The author is an outspoken AI skeptic, who then spends the rest of the article arguing that, despite clear evidence, LLMs are not a useful tool for software engineering.
I would encourage them to re-read the first half of their article and question if maybe they are falling victim to what it describes!
Baldur calls for scientific research to demonstrate if LLMs are useful programming productivity enhancements or not. I would hope that, if such research goes against their beliefs, they would chose to reassess.
(I'm not holding my breath with respect to good research: I've read a bunch of academic papers on software development productivity in the past and found most of them to be pretty disappointing: this field is notoriously difficult to measure.)
I took a template (very few of the code should be the same), added language support, included RSS feeds. Here it is: http://news.expatcircle.com/
(registration does not work. Have to upload the latest version. This thing is not really live yet. I will make it available on my github).
BTW, VS Studio is the best software MS ever produced.
The better question should be whether long-term LLM use in software will make the overall software landscape better or worse. For example, LLM use could theoretically allow "better" software engineering by reducing bugs, making coding complex interfaces easier --- but in the long run, that could also increase complexity, making the overall user experience worse because everything is going to be rebuilt on more complex software/hardware infrastructures.
And, the top 10% of coder use of LLMs could also make their software better but make 90% of the bottom-end worse due to shoddy coding. Is that an acceptable trade-off?
The problem is, if we only look at one variable, or "software engineering efficiency" measured in some operational way, we ignore the grander effects on the ecosystem, which I think will be primarily negative due to the bottom 90% effect (what people actually use will be nightmarish, even if a few large programs can be improved).
1. Attempt to prevent LLMs from being used to write software. I can't begin to imagine how that would work at this point.
2. Figure out things we can do to try and ensure that the software ecosystem gets better rather than worse given the existence of these new tools.
I'm ready to invest my efforts in 2, personally.
This is a bad introduction in my view, because it makes me imagine the author as the opposite of what they paint themselves as:
> The reason why I’m outlining just how weird I was as a teenager and a young man is that software developers in particular are prone to being convinced by these hazards and few in the field seem to have ever had that “oh my, I can’t always trust my own judgement and reasoning” moment that I had.
Complaining about "biases" that you don't have yourself, as one of "very few" in your profession, makes me want to quit the article. I'm reading on, because it's not written badly in form, and might make interesting points.
But painting oneself explicitly as one the of the few humble people there are (while composing a blog post about a widely discussed topic, arguing for a widely discussed opinion): it doesn't inspire confidence.
Sure, I skimmed the top-level comment before reading (about typescript), that might have biased me in some way.
But in the end, this thorough interest in psychological manipulation, along with the belief that only a select few would know about this, like it's a secret, has been a trait of a certain kind of person in my life to whom I'm not interested in listening to.
Maybe it's just a tone thing, so now, I'm gonna continue the article.
The mentioned popular book is certainly interesting, I wanted to read that for a while.
So maybe the author did convince me of something there.
> Our only recourse as a field is the same as with naturopathy: scientific studies by impartial researchers. That takes time, which means we have a responsibility to hold off as research plays out, much like we do with promising drugs
Author in another article:
> Most of the hype is bullshit. AI is already full of grifters, cons, and snake oil salesmen, and it’s only going to get worse.
https://illusion.baldurbjarnason.com/
So I assume he has science research at hand to back up his claim that AI is full of grifters, cons, ... and that it will get worse.
I also have to point out that the author's maligning of the now famous Cloudflare experiment is totally misguided.
"There are no controls or alternate experiments" -- there are tons and tons of implementations of the OAuth spec done without AI.
"We also have to take their (Cloudflare’s) word for it that this is actually code of an equal quality to what they’d get by another method." -- we do not. It was developed publicly in Github for a reason.
No, this was not a highly controlled lab experiment. It does not settle the issue once and for all. But it is an excellent case study, and a strong piece of evidence that AI is actually useful, and discarding it based on bad vibes is just dumb. You could discard it for other reasons! Perhaps after a more thorough review, we will discover that the implementation was actually full of bugs. That would be a strong piece of evidence that AI is less useful than we thought. Or maybe you concede that AI was useful in this specific instance, but still think that for development where there isn't a clearly defined spec AI is much less useful. Or maybe AI was only useful because the engineer guiding it was highly skilled, and anything a highly skilled engineer works on is likely to be pretty good. But just throwing the whole thing out because it doesn't meet your personal definition of scientific rigor is not useful.
I do hear where the author is coming from on the psychological dangers of AI, but the author's preferred solution of "simply do not use it" is not what I'm going to do. It would be more useful if instead of fearmongering, the author gave concrete examples of the psychological dangers of AI. A controlled experiment would be best of course, but I'd take a Cloudflare style case study too. And if that evidence can not be provided, then perhaps the psychological danger of AI is overstated?
If you think the shoddy code currently put into production is fine you're likely to view LLM generated code as miraculous.
If you think that we should stop reinventing variations on the same shoddy code over and over - and instead find ways of reusing existing solid code and generally improving quality (this was the promise of Object Orientation back in the nineties which now looks laughable) then you'll think LLM's are a cynical way to speed up the throughput of garbage code while employing fewer crappy programmers.
'kentonv said this best on another thread:
It's not the typing itself that constrains, it's the detailed but non-essential decision-making. Every line of code requires making several decisions, like naming variables, deciding basic structure, etc. Many of these fine-grained decisions are obvious or don't matter, but it's still mentally taxing" [... they go on from here].
(Thread: https://news.ycombinator.com/item?id=44209249).
What does that look like on a scoreboard? I guess you'll have to wait a while. Most things that most people write, even when they're successful, aren't notable as code artifacts. A small fraction of successful projects do get that kind of notability; at some point in the next couple years, a couple of them will likely be significantly LLM-assisted, just because it's a really effective way of working. But the sparkliest bits of code in those projects are still likely to be mostly human.
...and yet, the author literally just published a book called "The Intelligence Illusion: Why generative models are bad for business": https://www.baldurbjarnason.com/2024/intelligence-illusion-2...
It seems they might have missed "motivated reasoning" in their study of human cognitive faults.
whatevermom•4h ago
rblatz•3h ago
tptacek•3h ago
mwcampbell•13m ago