>citing that it's illegal even though I own the games
In the. US at least it is actually illegal to download ISOs/roms of games, even if you own a physical copy. It's a stupid law and as a downloader (as opposed to the people hosting the files) your chances of getting into any kind of actual legal trouble are effectively 0, but it is still against the law.
Thanks for pointing that out! I'm not in the US and I guess it's not illegal in China (given that Deepseek was more than happy to do it).
That does raise an interesting question, what kind of laws should LLMs (attempt to) follow? It's easy enough to spoof the country in the system prompt. I wonder how ChatGPT would respond if I told it I was located in a developing country without any piracy laws.
I'd love to see credible numbers on that. I find it hard to believe that stupid corporate mandates are responsible for more than a small fraction of usage, but without data I have just my own instincts to go on there.
At my employer (megacorp with tens of thousands of employees) daily use is mandated. Our annual bonuses and pay raises for our performance reviews were explicitly tied to this.
Because typing “code” takes time and significant amounts of it.
We are slowly waking up to the fact, which was always true, that “coding” is just a fanciful preparatory task in order to appease the spirits properly so that we may invoke the spirit of what we are actually after: a live, running process that does useful things. Code is completely useless when separated from that fact.
Typing it is a complete waste of time unless getting up close and personal with it will result in some kind of useful and actionable improvement in you or your understanding. Knowing when it does and when it does not have this property is a skill of its own.
> Typing it is a complete waste of time unless getting up close and personal with it will result in some kind of useful and actionable improvement in you or your understanding.
I believe this is the general belief about basically every human skill, that if you stop doing the technical fundamentals you get worse at understanding the activity. The question is whether coding is like sailing a square-rigged wooden ship, which became completely useless knowledge after the invention of the steam engine, or if it's like playing an instrument, which while technically unnecessary after the advent of MIDI and other tools, absolutely hurts your ability to arrange, compose and perform if the skill is neglected.
For my money: I think the AI scenario is more like the latter, but "humans are worse at coding" isn't the consequence I see coming. I worry that in ten years we will be awash in software that's impossible to understand. I don't think that's happened in any human industry ever. Someone has always understood how the machines are built, even if they're very remote from the users of the machine.
The sci-fi novel A Fire in the Deep starts with describing a Software Archeologist, who digs through millennia of strata of layers of indirection and I think we could end up needing that one day.
No serious programmer is regularly bottlenecked by typing speed. Even the ones who type slowly.
If you find yourself writing repetitive code you should consider adding a layer of abstraction. If your language isn't powerful enough you can write a code generator.
> Typing it is a complete waste of time unless getting up close and personal with it will result in some kind of useful and actionable improvement in you or your understanding.
Like, perhaps, understanding that it is free of security and functionality bugs.
That is one of the things code does. It also communicates the developer's thoughts about how that process should work to others. If the latter is neglected, the code becomes very difficult to collaborate on. Very few lines of code that are written are "write once". Mostly they're changed, repeatedly, over time by many people. The live, running process is a very temporary entity by comparison. Yes, it needs to exist and do useful work. No, it is absolutely not the only thing that matters.
It depends on where you're using AI. If you're working on a project for yourself or in a tiny company. Then sure, writing the code probably was your bottleneck. But at mid to large companies writing code is maybe 50% of the job, and the other 50% is the process around it. All those processes are the bottle neck, no matter how fast you can write the code. And this was a bottleneck I was hitting well before AI.
I'd put it even lower than that, since there's also the "understand the problem space" portion outside of the external processes and before writing the code.
Yeah, so again the point of text editors is you shouldn't be typing all that much with them. That's why we use them. Macros. Shortcuts. Metaprogramming. Snippets. Identifier completion.
Were people actually typing out the full text of source code before LLMs? Why?
> Can you type a hundred lines a second? If not, then it is.
No one has ever needed to do that for something that is new. And if it’s not new, you want to do it repeatedly with some guarantee of reliability. Not just in an uncontrolled manner.
That is why we have snippet systems, macros and code generators. And the best with code is to solve problem once and reuse the solution. Which we have done with libraries, frameworks and supporting software.
This is such a delusional take it's borderline trolling. Code is an expression tool to precisely describe a process that does useful thing. Typing prompts is not too different from writing some very vague code, which is arguably a waste of time by itself.
> Typing it is a complete waste of time unless getting up close and personal with it will result in some kind of useful and actionable improvement in you or your understanding.
I would argue that this is nearly always the case. I don't think people really understand programs that they've only read at more than a very superficial level. This is why I tend to make (temporary) small changes, printlns, etc. when exploring a new code base: it aids greatly in understanding how a program actually works.
And it's even worse (in my experience) with LLM generated code, as it tends not to result in particularly understandable code. It is a lot like LLM generated prose: it often looks entirely reasonable at a surface level, but has a of weirdness/incorrectness hidden beneath the surface. But that surface level makes it very hard to avoid glossing over the details when reviewing the code. For this reason, I personally find it's much more effort to carefully review code than it is to write it.
Humans make mistakes all the time, but their code tends to naturally be structured for human understanding (to some degree based on skill/experience) because they themselves needed to understand it to write it.
I think LLMs are very useful tools, but after quite a lot of experience using them, I think it's generally better to use them as a sounding board, or to help you get unstuck or remove points of friction. Using them to write all of your code (at least for me) seems like a net negative.
I also think it's extremely easy to overestimate how much time they save. It feels like they're a productivity boost because it takes less intense focus to implement something. But I've experienced several instances where actually writing the code myself would have been both quicker and have resulted in better code.
All that being said, it can also be really hard to not write all of your code with agents once you get used to it. There's also a kind of slot-machine-like effect where you write a prompt, excited for the result, and when it doesn't quite come out right, you think "ah just one more prompt and it'll be good." It's hard to see when you're actually doing it though.
It's also weird to me how much people think typing is what the LLM is replacing. Typing was never the hard part. It's the translation of the high-level idea into an unambiguous process that's hard. That's also the valuable part, that requires thinking through the edge cases and consequences of decisions, and that just gets glossed over when using an LLM unless you rigorously review what the LLM has done.
At the end of the day there's a real tradeoff to be made, and it's worth being conscious of what's being given up.
If you already know what the inputs/outputs are, why should you spend days or weeks of your life typing it out rather than giving it in a well-specified and tested form to an LLM to get it done a hundred times faster?
Because it’s rarely so black and white. Knowing the inputs and outputs is merely the first steps, you need to think about the transitions too as they have their own costs.
Those costs don’t disappear and it’s truly naive to think they don’t matter. Take security issues, they may arise because what you thinks was the input is merely a subset of the true input range. And the extra possibilities lead to unforeseen behavior.
A lot of programming is about ensuring that the input and the output are the sets defined in the specs. And the rest is that the transition/relation is the right tradeoffs of performance, correctness, and costs.
Libraries like Guidance guarantee that the output of an LLM will be syntactically correct (i.e. it will be valid JSON or whatever output format you are wanting). They do not, and fundamentally cannot guarantee that the data contained in them is actually correct, and cannot make the actual behavior of the LLM "well-specified". Or, as you put it, trumps voice wrong.
>what "sense of rigour"? it's way too soon to put those rose-tinted glasses on.
I don't think OP is claiming that prior to LLM coding everything in the software development world was super rigorous (I assume that's effectively what you mean with the "rose-tinted glasses" comment). But rigor was actually possible and in a deterministic way too, which is fundamentally impossible with LLMs. You can build all kinds of guardrails and processes around LLMs that make it somewhat approach rigor again, but it's still fundamentally based on a bunch of statistical probabilities instead of deterministic, repeatable results.
All of the methods I see to mitigate the fundamental and inherent issues of LLMs seem roughly equivalent to the kind of crap you see in astrology groups or palm reading etc. You need Venus and Mercury to be in alignment while Mars is retrograde if you want to be able to get the right results from your token predictor.
Sure, but LLMs are non-deterministic in ways that no sane human ever would be. See the "Is it better to drive or walk to the carwash" scenario from a few months ago as one of many, many examples. Or a personal example I encountered just a week ago: I asked Claude (Opus 4.8 in case any of the "you aren't using the latest model that totally fixes that issue" types are interested) to convert a bunch of DB calls that currently use raw ADO.NET calls to use Dapper instead.
The projects in this repo were on .NET 4.8.1 and were still using the older format for the .csproj file instead of the newer (and far better) "SDK-style" format that Microsoft introduced a few years ago. It tried to use the dotnet CLI to add references to Dapper, even though the older format of .csproj doesn't work with that. The dotnet CLI returned errors about trying to add the package references for Dapper, which Claude completely ignored while continuing to try and convert the ADO.NET calls to Dapper. And at the end it tried building the project, which of course failed, and then it confidently informed me that the conversion had been completed successfully and that the build completed successfully and all tests were passing successfully, even though the output from the build it had done immediately prior clearly told the LLM otherwise.
A real human, despite being non-deterministic, would have caught the issue at multiple stages. They would have seen the error when trying to add the reference. If they ignored that then they would have seen the red squiggly lines all over the (deterministic) IDE telling them there was something wrong, along with autocomplete for Dapper calls not working. And if they continued to ignore those and managed to keep going anyways, they would have clearly seen that the build failed, with tons of errors specifically about references to Dapper failing to resolve. An LLM keeps going on its merry way in ways that effectively 0 humans would.
I think we're going to see a big scramble to pick up the pieces in a few years when a bunch of vibe-slopped houses of cards come crashing down. I imagine it will be like the demand for COBOL developers but on a much more massive scale.
A few major failures will scare the risk mitigating bejesus out of some kinds of businesses, but maybe AI will be better than us at fixing those kinds of problems by then.
COBOL was mostly outsourced to India, and it's a terrible professional path for anyone in the EU or US, and has been since the Y2K bugs got fixed at the last minute.
(And probably a bad path in India, too, but I have no data one way or the other. It's just that all the excellent Indian devs I know use almost exactly the same tech stacks I do.)
Then why did it take Anthropic over a year just to fix the flickering issue in one of their main products when they have internal access to the latest and greatest models?
In the case of vibe-coded slop like OpenClaw it's not a question of some vague notion of "code quality", it's a case of the software shitting the bed and not working anymore, with no recourse of fixing it. (Neither humans nor LLMs have the context window to analyse and fix tens of millions of lines of code slop.)
> and Anthropic banned OpenClaw usage
If OpenClaw wasn't broken it would just use a standard token API.
But see above - as software it is fundamentally broken and unfixable.
>All else being equal, and assuming you are building the right thing, being able to deliver more correct lines of code is a good thing.
Why? If you can deliver the same thing in fewer correct lines of code wouldn't that be preferable? At a bare minimum if you're still insisting on using AI to slop out your project, having it do things in fewer lines of code means you can fit more into your LLM's context window.
> If you can deliver the same thing in fewer correct lines of code
it really depends on what you're doing. If your goal is "become interoperable with the N different and incompatible network protocols that people have devised for doing task X" I'd really like to know a solution that doesn't have at least some part of the amount of code that scales with N.
Example: consider https://bitfocus.io/connections which connects to 700 different things. Right now it's written with Node.JS, with one repo per connection (example: https://github.com/bitfocus/companion-module-meyersound-gala...). Let's say you want to make a similar product but that runs on ESP32 where performance is paramount so you need C++ or Rust. How do you do that without at least as many lines of code as the existing JS implementations for every system supported by Companion?
Without looking at the details, I expect that each network protocol has a checksum of some form, and there are likely a lot less than N different checksum algorithms. Similarly I expect several will have encryption - using one of a few standard algorithms (if any doesn't use a standard algorithm you have a strong case to say not supported). I also expect that there is a lot of protocol parsing - this can be done as custom hand coded for each, or using a parsing framework (and likely there are some places of generic code in between).
This is still not an argument for more lines of code. It demonstrates that lines of code are positively correlated with number of features, yes. But that's like saying the number of nails scales with the size of a house. More nails does not create more house.
The entire Linux kernel is about 40 million LoC, and only something like 16 million LoC after you remove drivers. I have a hard time imagining whatever OpenAI was talking about there having anywhere close to 6% as much utility as the Linux kernel, despite having 6% as many lines of code. And I have a hard time imagining it's anywhere close to maintainable, regardless of how powerful their LLMs might be.
To be fair, few things of any number of LOC have as much utility as the Linux kernel, and it's also a particularly dense example of code. There's plenty of other examples that have higher LOC / utility ratio without being vibe coded. For example, Google's monorepo famously has 2 billion LOC, which is a statistic I've heard long before LLM coding took over.
Clarification: Google claimed to have 2 billion lines of code in their repo ten years ago, and a commit rate of 50,000 changelists per day, both on exponential growth trends.
That's certainly a way to look at it. And that repo contains a "third party" directory which itself contains Linux, LLVM, and much of the rest of the open source world. But I would suggest that the largest of those thousands of applications probably has a transitive closure of hundreds of millions of lines of code.
I'm aware. I worked on that specific project (assuming we are talking about the same one) back in the day. :-)
There are certainly very large applications in that repo in the hundreds of millions of lines of code. But comparing the entire repo to single applications is not an apt comparison.
The Linux kernel is not in any way at top of big projects. A kernel, as the name suggests, deals with specific issues and tries to remain small.
The world’s biggest software is usually built over endless adapters of different data and a need to reconcile endless edge cases with laws, regulations and real world complexities.
When I was young, I remember a (joke) program from a book or magazine, called something like report writer or something. It was written in basic and you typed it in.
You would run it and it would say:
how many pages? _
You would type in a number, and it would generate that many pages of a complex-sounding report.
something like "the subsystem design interface is ..." blah blah
Sure but it certainly seems that way. There were already thousands and this PR adds a fair bit more too.
It is possible to have thousands of tests and a lot of blind spots, but it's easier to get a grip on that using instrumentation like code coverage and indeed by using LLMs to prod at edge cases.
I am OK with trusting that it is likely the React team understands how to rigorously test based on how well-tested React itself is.
You might want to read *A Market for Lemons".
reply