Debian is conservative so it makes sense that they have proposals for not using LLM's. They'll need another year or so but I am convinced it'll soon be obvious that any "no LLM" policy is untenable.
We are in the "cool new toy, let's make slop" phase, but we already see how careful use of LLM's can make high quality code faster and better than humans can do solo.
Once they are over the learning threshold, every good developer I know actually likes to use LLM's, as they allow them to realize their visions faster. If Debian has a "no LLM" policy I think they will eventually only have devs who like to type.
I should add that of course the "immoral companies burning too much energy" argument has actual merit, no matter how useful LLM's are or aren't. But I don't think Debian should die on that hill, as the only difference it will make is that we no longer have Debian.
>It could. It could make a simple note-taking app not take gigabytes of memory and take visible delay on each click.
But the taste that tells you a note taking app should be fast doesn't come from your knowledge of assembly. It comes from using the app.
Being able to have an AI generate 8 variants of an UI and 5 variants of a storage mechanism is more helpful to reach the goal of a good note-taker. Trying out those prototypes and tweaking them to perfection is also friction, only it happens closer to your actual goal than doing quicksort in assembly.
There are of course examples where the friction does help, and where the "aid" of the tool deteriorates useful skills, but I think that will sort itself out over time. Useful skills will remain, useless ones will disappear, as they always have.
>The skills to do so, however, are a function of someone who has experienced the friction and challenges over time that culminate in "good taste".
It's certainly sometimes true, but I don't think it's a general rule. Sometimes friction is just friction and sometimes you spend 1000 hours learning something that disappears and becomes obsolete or at least irrelevant to the goal.
Programmers used to need to know the instruction set of the CPU, assembly language and so on. Some still do but for most developers today that's not useful. Everything you know about 6800 assembly will not make your note-taking app any better.
I think we are in a state where AI tools so easily mimic what we used to do by hand that we think the friction is gone, but that's because we haven't raised the bar yet. One day we'll look at the Fable one-shot that's better than anything we ever made by hand ourselves and say "It could be even better".
And then the friction is back, just on a new level.
It's deceptively undefined I'd say. People can argue under the impression that everyone shares their idea of what "intelligence" means, before realizing that their counterpart actually has an entirely different idea of what it means.
I'm leaning towards there being a divide between those who feel "intelligence" is entirely separate from "sentience" and those who feel that one implies the other.
Can't comment on FP, haven't touched it since SMLNJ in the late 90s. I fear my mind is now congealed in OOP paradigms and the threshold to FP is too high.
Anyway I can say this - the free web interface to ChatGPT in 2024 vs what you get with agent harnesses and the latest large models now is like comparing a wombat fetus to a college graduate.
Get one of the 20 or so dollar subscriptions, install Claude code, codex or similar and start by explaining what program you want to make and which language you want to do it in. Have it make a plan first, and do some back-and-forth to refine it until you're ready to let it implement.
If your experience is from ChatGPT two years ago I think you will be floored by the results, even in Haskell.
>if he ever introduces a second developer to his project those 'solved' problems will become a point of friction. They'll go from 'solved' to 'solved, but in the wrong way' or 'solved, but not for this edge case', or 'solved, but why is the code so verbose?'
I agree with the problems you list, but I don't think a framework solves them. The same complaints can be made by the second developer because the first developer chose the "wrong" framework. Solved the wrong way, not covering the edge cases of your domain, too verbose etc.
Additionally a framework will likely be bloated and inefficient because they try to solve every problem for everyone, and you introduce a random breaking point where any framework update could in theory break your system.
"When you’re young, you look at television and think, There’s a
conspiracy. The networks have conspired to dumb us down. But
when you get a little older, you realize that’s not true. The networks
are in business to give people exactly what they want."
--Steve Jobs
I think the same goes for newspapers. They are businesses that make money from giving people what they want, and like all businesses they eventually care primarily about making money. Whatever else they were founded to care about is secondary at best.
Burke Holland has a few good videos that helped me. For example this on agents[1]. He uses Copilot but the principles are similar for Claude Code, Codex, OpenCode and other harnesses:
So far in the LLM coding revolution I still feel like it's software development. I just work with systems on the level of features and architecture instead of flow control statements. Some day we might lose that too, but I think it will take a while.
>How does one get to "half ten" in German? Is it simply starting from "half to ten"?
Never thought about it much but I think you're spot on. English uses "half past" and therefore "half 10" means 10:30, whereas most other languages use "half to" which causes "half 10" to mean 9:30.
One would think this should cause confusion for international meetings often enough to be common knowledge, but I didn't know until today...
Oh come on! I'll take a few years of expensive RAM in order for humanity to get wide access to something near as makes no difference to the Star Trek Ship computer.
Which is 100% what this has felt like to work with, all spring and summer.
So we're in a slop phase, it'll pass. The first few years of youtube gave no hints that we'd get stuff like Veritasium.
Ignore the slop and use the tools to create something you never thought you could do. That's what it's for!
In the time it takes me to make a single-node webservice with a CLI POC client I can now have a fully scalable SAAS with clients for iOS, Android, mac, linux, windows and web-based, user documentation in several languages and a suite of unit tests.
Surely that's both faster and further?
IMO AI agents are like a team of remote consultants that only talk shop and have no sense of humor.
>and Django was like this 15 years ago when I first started using it. The core design hasn't changed, it just sounds like most other ORMs don't really know what they're doing.
Django is an opinionated web framework that uses an ORM, not just an ORM.
Django can by all means be a great way to make a web site (I have little experience with it) but if you have a db that is accessed by various systems written in Java, dotnet, erlang or whatever else I suspect the smooth sailing of Django can run into headwinds quickly and the python plumbing you have to deal with then quickly becomes an issue in itself.
You have mixed the posts you are replying to - the domain being different from the database is stipulated here.
I was giving examples of how this typically happens, and the reasons are entirely independent of whether or not an ORM is being used.
I am fully aware that you can handle any mess using an ORM as well, which is why I was surprised at the original claim that ORM's force proper domain models. I haven't observed that so I was genuinely curious.
Separately from that I have to say your suggestions of things to do to force an ORM into the situation are bad ideas. The complexity of custom serialization, various mapping hooks or attributes to bless individual properties will lead to pain and misery down the line.
Just accept the extra layer of DTO's. They're a detour over pure SQL but are at least easy to maintain and hold no surprises. They say there's a special place in hell for people who write SQL triggers and I think people who override ORM serializers are welcome there. ;-)
It's a combination of small things really. The mentioned ability to easily call on various models in the same prompt, having agent definitions be able to orchestrate other agents just by mentioning it in the description, doing things like goal/loop automatically.
There is also IMO a distinct difference in "tone" in the dialogue. Claude seems to impersonate a human a bit more than I like.
Claude is of course very good as well and does a few things better than copilot too, but overall I'd prefer to use Copilot.
I am a huge fan of Copilot CLI. It just feels so logical and low-friction to use compared to Claude Code. Having the ability to juggle various models at will is really nice too. ("Plan this using Opus 4.6, let GPT 5.4 verify the plan and give feedback before implementing with Sonnet 4.6").
Unfortunately the June pricing change for Copilot forced me personally as well as my entire department at work to switch to Claude Code. With copilot we were hitting a few dollars of extra spend over the included credits in April and May, then in June we started chewing through the monthly budget every 2-3 days.
Just a completely insane price hike from the customer's perspective, I don't know what MS were thinking there.
Even if that is the price they need to be sustainable they should have waited until the competition changed their prices first. I wouldn't be surprised if Copilot lost 50% or more of their customer base last month.
Eventually this could be where all the major players set their prices, so the thought occurs to me that nations should run some form of "public access AI", just like they did for TV. Use the free open models and use tax money to finance a few datacenters. Geo-lock the use and set strict throttles to manage load, but let school children and citizens use that AI freely otherwise.
If Copilot's pricing is the level for all AI in a few years, only the unicorn companies can afford to use them, and everybody else has no chance of competing with a company that can use AI.
"After the Windscale fire released radioactive fallout onto grazing land in 1957, Britain discarded contaminated milk for 44 days, thereby avoiding any harm."
This is also not true, the actual reports estimate 33-100 deaths, 90 nonfatal cancers and 10 birth defects. (summary from wikipedia):
"These deaths were attributed not only to thyroid cancer, but also to lung cancer.[74] An updated 1988 UK government report (the most recent government estimate) estimated that 100 fatalities "probably" resulted from cancers as a result of the releases over 40 to 50 years.[75][76] The government report also estimated that 90 non-fatal cancers were caused by the incident, as well as 10 hereditary defects.[75]"
It's hard to imagine ignorance that manages to be familiar with Windscale yet not know anything about the estimated harm.
We are in the "cool new toy, let's make slop" phase, but we already see how careful use of LLM's can make high quality code faster and better than humans can do solo.
Once they are over the learning threshold, every good developer I know actually likes to use LLM's, as they allow them to realize their visions faster. If Debian has a "no LLM" policy I think they will eventually only have devs who like to type.
I should add that of course the "immoral companies burning too much energy" argument has actual merit, no matter how useful LLM's are or aren't. But I don't think Debian should die on that hill, as the only difference it will make is that we no longer have Debian.