law moves much slower and is much less complex than code. it isn't like computer code though. the interpretations and rulings are mostly fugazi to justify power relations and corruption, so I doubt that an LLM can grok law the way it can computer code, because if you think that logic and precedent actually matter, you are missing the point.
most law firms are basically assembly line processes that have one fixed specialty, with a small set of claims that they will file, and typically targeted at insurance companies, so there is very little real practice of law. you just set up your assembly line to scam insurance in your particular niche and then search for clients that fit your cut out. LLMs can definitely disrupt this model in interesting ways.
> their current moat is the fact that they're ahead
the problem is that they are not ahead. they are ahead on producing one-shot demos, which are useless party tricks, but when it comes to shipping real products these large models are just a big expensive waste of time and what you need is deterministic systems that integrate small efficient purpose built models in the places where they are actually the best solution for the problem.
the anthropic game plan was to wrap the entire software industry up in a magic box called "AI" and then rule the world but these people are delusional and their house of cards is rapidly collapsing. the technology is real, but they didn't invent it and they don't own it. it is kind of amazing to think of a $2T company with zero IP ... they didn't invent a single thing that they are selling, and for the most part they are implementing it worse, and serving it less efficiently than at least a half-dozen other competitors.
almost certainly not. writing down threats in your own personal chat session is like writing in a diary. there is no communication to any other person, so the idea that this is actually criminal is highly unlikely and it almost certainly won't be charged. it's a pretext arrest for police to assess the threat, which is not entirely unreasonable, but it is not a crime.
> The arrest report states that on Sept. 26 at approximately 5:10 a.m., Heller reportedly wrote, "I'm going to shoot up the sheriff's right the [expletive] now." The following day, at approximately 1:07 a.m., she was accused of posting, "This is 100% last chance I'm done. I got a new [expletive] gun today. [Expletive] you."
this is certainly reads as somebody venting in what they believed was a private personal space.
i guess using claude for mass surveillance is ok when anthropic does it. once again why nobody takes these high horsing hypocritical liars seriously.
I read earlier that the crime is making such threats in any manner where another person could see them.
I do not know whether it matters if the suspect knew that their chats could be viewed by Anthropic staff, or if the only thing that matters is whether another person was able to view the chats.
Edit: Upon searching I now also agree, it seems to require a state of mind and perhaps awareness of the possibility that the threat would be seen.
this is done on the model side so it is invisible to the caller. all of deepseeks kv cache compression stuff is basically the same thing. it doesn't really put the entire context into kv cache and does various inference side stuff to decide what to actually use as context.
it is trivial now to create synthetic multi-platform personas that generate real looking post histories at unlimited scale. the baseline assumption should be that everything on the internet is fake until proven otherwise.
> Reading the code does not mean you understand the code
this is delusional hubris from people who are not real engineers. anyone who actually writes high assurance software or does low level performance optimization knows that the only thing that matters is what can be demonstrated in reproducible tests.
the full stack requires about a 1000 different specialties that each require about 10 years of experience to master. and that is just one computer. we are building distributed systems of millions of these computers, operating at global scale, across dozens or hundreds of legal jurisdictions, which takes the complexity of a single computer, and multiplies it many times over, across several other dimensions.
anyone who thinks that they can understand the systemic effects of changing 0.00001% of this system by reading the code is a dangerously naive fool.
You aren't coding though. The LLM is coding and you are specifying.
It is just a function. A next token prediction function. Garbage-in/Garbage-out is as true as ever.
Coding is solved. Specification and translating requirements into specifications is an unbounded domain and unsolvable by definition.
What LLMs change is that now you develop the specification through iterative implementation and testing.
You start with a weak specification which produces slop, then you progressively build the specification with different approaches to automated testing. The tests are the specification. Ultimately, what you ship is the tests. They are the only thing that proves the functionality of the program. An LLM can produce code that passes any test suite you give it. If the result is bad, the problem is not the code, the problem is the specification.
Nobody at this level is "vibe coding." They are using LLMs as a tool in a whole suite of tools that they have spent decades mastering, and LLMs happen to be the most powerful tool ever created. When you understand the existing tool suite, and can integrate this new super tool, the results are order-of-magnitude improvements in velocity, with much higher levels of quality and assurance.
Anybody talking about "code," like it is actually important, simply lacks the perspective to understand this.
We went from punch cards, to assembly, to C, to interpreted languages, to frameworks, to AI, and every cycle had the exact same debates.
A lot of it is Ego. Everyone thinks they are smarter than they actually are and that their work is uniquely valuable.
Computer programmers are monkeys who get paid to press buttons. We get paid because we know which buttons to push and in what order. It's a great gig. It's made me more money than I ever imagined possible, and I have fun doing it, but the flip side is that it is the most competitive industry on earth.
If you slow down, fall behind, and refuse to adapt, you will get eaten alive.
I have some sympathy for people, but an the end of the day, if you want to get paid better that 99% of people on earth, you are going to have to work for it. That is not an entitlement, and if you think it is, you will not make it.
This guy worked with me. He was a liability. When he was on the duty pager, he wouldn't understand what was going on and wouldn't call anyone to help. Our customers had real issues and he would ignore them. I would have to clean up his mess in the morning. It sucked and he was let go. Not sure why he said he has all this experience when he couldn't handle managing a few customer workflows.
I went to his profile and it goes to a github repo that had his linkedin and I instantly knew who he is. If you run his github through scanaislop.com, an 11/100. Real winner here. I wonder how much he's paid for AI and still produces slop?
The audacity of publishing self-promotional AI slop clickbait claiming that AI can't code and everyone who doesn't agree with your asinine assertions is incompetent is bold. Respect the hustle I guess.
But to anyone even vaguely thinking of taking this seriously, go look at what antirez, dhh, jared sumner, mark brooker, and many other real engineers who have ship real things are doing and saying.
Most of these people have spent their entire lives contributing to open source, and they have proved their skill shipping working software and scale for decades. They are really trying to help people by showing and telling them exactly how AI works and how to use it to make better software.
The audacity of skimming through and article and completely missing the point and coming to hackernews ranting about it. Respect the attention span, I guess.
The true reason why code review is universal is that it provides a liability shield for negligence. Negligence is interesting. It has nothing to do with whether or not you ship something broken. As long as you follow a process that attempts to not ship something broken, then you are not negligent.
Engineers played along with this farce because code review served valuable team collaboration, coordination and management functions, about which the author of the article is correct.
Understanding a system by reading code is harder than understanding a system by writing code.
If AI can generate code at 100X, 1000X, or 10000X human capacity (no ceiling here), and you are gated on code review as your mechanism for system understanding, then a team's productive output will barely increase.
If companies want to compete in the world of AI generated code, human code review has to go. The only question is, what replaces it?
Continuing to apply human code review to AI generated code is negligent, if you are shipping at AI generation speed, with that as your only gate, and no other systems and processes to validate correctness and limit risk.
On the engineering side we can adapt easily.
Code review was never about finding bugs. When we do code review the first thing we check is: "do the tests pass?" Then we look at the change and the test coverage added for it and ask: "does the test coverage adequately demonstrate the functionality of the code?" The we ask: "What is the scope and potential impact of this change?" "What is the deployment and rollback plan and how will we monitor and detect defects after deployment?"
Code review was never about the code. It made the lawyers happy and provided a vehicle for doing the things that actually make systems work.
> If companies want to compete in the world of AI generated code, human code review has to go.
This is a HUGE non-sequitur. It only follows if by "compete" you mean producing more LoC. How often does that translate to market fit or economic success?
This is the mindset that makes me want to leave this industry immediately. Somehow, an industry that already annoyed me with how much "mediocre is good enough" was an acceptable stance, with the emergence of LLM coding tools suddenly decided that "absolute dogshit is good enough" was just as acceptable, as long as everybody else is also fine with eliminating the few quality standards they might have had.
People forget that pull requests and doing code reviews in the context of those is still a fairly recent thing. People did some code reviews before that of course but nowhere near as strictly. Same with testing practices, static code analysis, etc. Most of that wasn't all that common until beginning of this century. I remember using findbugs with Java around 2004. It actually found bugs in my code the first time I used it. No review had caught those. And we got lucky not finding them in production. But they were definitely bugs. Our system didn't have unit tests; it was all manual. Junit was a fairly recent system that hadn't been around for that long yet. Our build was done with Ant. There was no test phase. Our tech lead would of course check my work and correct & educate me (I learned a lot). But a lot of bugs slipped through as well.
Git did not exist either, I migrated out cvs to a beta release of Subversion. We only used branches for releases. We'd cut a branch just before a release. Test it (manually) and then ship. That was a process I helped put in place actually. After release, master would diverge quickly so back porting fixes was not really a thing. We'd support releases for as long as our customers used them. Often that involved just upgrading them to the recent version. We shipped when things were good enough.
I think the notion of people reviewing any meaningful amount of generated code is simply delusional. As you say, we do need alternative means to replace those checks. And a lot of that is going to be AI driven as well. AI driven testing, code reviews, and all the rest. Essentially all the stuff we used to do manually (poorly).
And we do have an important new tool as well: clean room code replacement. That used to be prohibitively expensive but now it's not. If you have something that is well specified through documentation, APIs, specifications, tests, etc. replacing it is fairly straightforward now. There are some early examples of people using LLMs to generate functioning replacements for things like Postgresql, browsers, compilers and similarly large and complex systems. While not perfect, these things seem to work, pass their tests, and generally not be completely horrible. It's only going to get better from here.
The notion that people are going to ever manually review code that was generated for such systems in mere hours/days is beyond imagination. How? When? Who? Why? It simply does not scale. It's only going to be more and more code. The amount of code no person will have ever looked at will soon dwarf the amount of code that is still manually inspected/created pretty rapidly.
"does the test coverage adequately demonstrate the functionality of the code?"
and is this a solved problem? If not, then the bottleneck is right here, if it is solved, then yeah we shouldn't need anymore software engineers other than the elites
yes. it was solved before but when writing code by hand the cost of building exhaustive test suites was far to high to do it in practice, except in very narrow cases where high assurance was required. now that AI can implement all of the testing frameworks for you it can be done for everything.
> we shouldn't need anymore software engineers
no. the job changes, but the skills that software engineers have are more valuable than ever because they now gate a much higher level of productive output.
corporations aren't really ruthless profit optimizers. micro incentives don't actually favor efficiency. hiring decisions don't actually have much to do with output and productivity. for example: it has been known forever that adding more people to a project usually decreases velocity, but that has never stopped anyone.
technology changes but people don't. AI makes higher quality software faster and at greater scale, and velocity is what is really valuable, so companies that master AI development will be making more money, and they will hire more people, because that is what they do.
most law firms are basically assembly line processes that have one fixed specialty, with a small set of claims that they will file, and typically targeted at insurance companies, so there is very little real practice of law. you just set up your assembly line to scam insurance in your particular niche and then search for clients that fit your cut out. LLMs can definitely disrupt this model in interesting ways.
reply