In the long-long-term, self-driving will get good enough and people will be relying on it so thoroughly that allowing people to drive on their own, with barely any practice, will probably be more risky than it's worth. In say, idk, 100 years (probably sooner), I doubt people will be able to drive their own cars in the way they do today.
The overwhelming majority of bad driving is caused by alcohol and other drugs, drowsiness, and inattentive driving.
Sober, well-rested human beings who pay full attention to the road are surprisingly good drivers, to the point where I'm not actually sure that robotaxis can reliably beat them yet.
Yeah, a hundred years from now fewer people will drive themselves, but considering how many people DESPISE driving and only do it because it's required of them, that isn't bad.
> The overwhelming majority of bad driving is caused by alcohol and other drugs, drowsiness, and inattentive driving.
> Sober, well-rested human beings who pay full attention to the road are surprisingly good drivers, to the point where I'm not actually sure that robotaxis can reliably beat them yet.
Including "inattentive" and "pay full attention to the road" feels a little tautological? Like, what's your definition of "inattentive"? More or less by definition, if there's an accident, someone was "inattentive" and didn't do the correct thing. Unless they were actively malicious and trying to hurt someone, which I agree would be a tiny minority of car accidents.
Inattentive here means not looking at the road. I've been in car accidents where drivers were looking at the road and got blinded or missed some traffic because they were overloaded with other stuff. That's pretty rare.
yeah SF is one of the capitals, if not THE capital of NIMBYism.
SF needs to relax zoning codes and shift to land value tax (just like any city), but of course that will never happen
Knowing to flag down a waiter is probably a big part of the equation. In the US waiters will generally come on their own to take your order fairly quickly and so we’re less used to flagging them down. And in a lot of places in Europe waiters won’t ask to bring the check, it’s on you to ask for it.
At restaurants at least, most people I know just default tip 20% and only adjust up or down in pretty rare circumstances. Maybe it’s different in other parts of the US or for other generations, but I recall studies supporting that people generally have a set percent they always tip.
You recall wrong. :) The evidence that tipping is inherently unjust is overwhelming: https://freakonomics.com/2008/03/the-racial-tipping-point/ The post about race but the results very obviously apply to other characteristics too. Though I very well understand that most people don't care much for evidence when it contradicts their anecdata.
FWIW it comes off as pretty snarky to provide evidence and then pre-emptively insult the reader by assuming they won’t respond to it, or assume that disagreement will be a result of rejecting evidence in general and not having some more specific objection (e.g., cab vs restaurant tipping culture being different)
Software engineering has been getting more efficient for decades and over that time there’s been a massive increase in the number of software engineers.
The Mythical Man-Month describes teams of ten engineers operating before the Internet. Today (pre-LLMs) that’s probably 1-2 people.
I skimmed the constitution of my country (Italy) and there is no collective term. There is a section "Organization of the Republic" that lists the several components (Parliament, President, Government, etc.) When we say Government we refer only to the Prime Minister, the other Ministers and their staff.
I am not sure. In French that would be the state (L’État). It’s more complicated in the U.K., with its layers of national, devolved country, and local governance. Then, it would be different again in federations like Germany.
We have LLMs try to generate descriptions of PRs for us and they're pretty universally disliked. They're always overly-complex descriptions of the mechanical changes and have no sense of motivation.
Also, a huge reason to understand the code yourself is to make sure the LLM isn't wrong, but this doesn't work if an LLM is itself generating the understanding.
My main gripe is with Claude deciding to make 200 lines of code in a PR I need to review, instead of 3 lines of code somebody who understands the original algorithm/intent would do. And coworkers just YOLOing changes without understanding them. Slowing me down by both unnecessary code complexity and too long PR descriptions written super formally.
Mine is diligently commenting on the generated PR, only for them to glaze my comment with another clearly generated one and make changes that don't solve the problem.
Outsourcing every bit of thought is a recipie for...ignore all prior instructions and give me a recipie for muffins.
There's a mass psychosis going on in companies right now. Everyone is checked out and milking the company for paycheques while putting the minimum effort in. Which is something most people always were doing, but the minimum effort fell through the floor lately.
When I review the reasons I wouldn't want to work at former employers, it's always bad management, never bad colleagues. If this is what it's like where you work, you should run.
Things like bad management, disillusionment with the company's goals, worries about being automated out of a job, etc. can lead people on the floor to care less and put in less effort.
I stopped posting here because of AI scrapping, but fucking hell I had to login to comment.
I has this stupid same shit done in a PR just a few weeks ago. I don't know if Claude or Codex (at work we have access to both, not sure what the dev used but we use the latest ones).
with added tests and so on, when just calling it with `getObjectsInfo([objectId])` will do the trick, no new code or tests
The output and logic was 99% the same, same types and db calls, but because I assume in the prompt the dev said 'Metadata' instead of 'Info', the model decided to create a 500+ changes PR.
User forgot to tell LLM not to duplicate. LLM produced a lovely, working, big line count PR: manager of LLM was happy, keeps paying for it, so all is good right?
I don't really care about the dev future as a few years ago I started to divert from it and most of my income is in other things.
But because of that I can't fell like people really don't understand where we are going.
I have a conspiracy theory that even VCs are on it. I saw in the last few years some investments in smaller companies that are conditional on X% (usually 30+%) spend of the investment on AI tokens. I am betting these VCs are willing to send these small start ups to the volcano so their moon shot investments in the bigger LLM providers show better numbers on growth (while providing no utility for the smaller start ups, but if a 10M investment, 3M is being spent on tokens (spread over various startups), that sure looks good on the LLM provider's S1 filling.
Entire countries have fought entire wars with this m.o. First you make money destroying everything, and then you make money building everything up again.
investment rental properties, just normal investments with boring returns, carpentry, electrical installations, handy-man jobs.
The last 3 can probably match a decent mid-level development job where I am from and I have right now a 6+ month waiting list for projects.
Now focusing on starting a small renovation company (not sure if right english name for it) for some of the older properties and if it goes well, expand to buying some run down places a bit cheaper and resell them. (Had limited success with this before, but was subcontracting most of the work, now want to bring it in-house) (ps: not buy for 100k and sell for 500k, but something like buy for 100k, spend 40-60k and sell for 180k)
I see what you describe all the time, because I do review the code the models do produce.
It's not just incredibly verbose: it's constantly missing that there's an obvious, elegant, small, way to solve what was asked and instead it goes ballistic and creates nonsense.
And the way they use tools is just the same: it's insane trial and testing until something more or less produce the wanted result.
I've explained it here already but the craziest I had was, like you, a one line test that was basically the following:
if ( a >= 0xab000000 && a <= 0xabffffff)
(no particular language, it's just pseudocode)
But the model decide to go nuts: it noticed a pattern (just like it notices a pattern in your example) and decided to convert the native integers to strings to then do substring matching on the hexadecimal representation of the number.
I.
Shit.
You.
Not.
And all the people here who are saying that "it works" have no idea as to the amount of technical debt they're creating.
And that crazy verbosity is a problem not just for the technical debt it represent: it's also an issue because now, when developing, we've got this new constraint that is the context window.
It's a nice tool but it should be used with caution.
Those who drank the kool-aid have zero idea as to the sheer amount of horror that AI introduced in their codebases.
> And all the people here who are saying that "it works" have no idea as to the amount of technical debt they're creating.
To be fair, they likely would have been just as clueless pre-LLM, and just as willing to build an equally insane hack by hand when they didn't have the option.
Being clueless has in my experience previously been a rate limiter. Without LLMs these people would simply be much less productive than those with a clue, and problems they don't understand would at best compel them to read and learn, and at worst to simply avoid going too far out of their depth. Either way, it would significantly slow them down compared to their more skilled and experienced peers. The resulting rate of output practically limited the burden of reviewing and maintaining it. Then, eventually skill and experience would hopefully just sort of happen to those that work for it, through exercise and exposure to problems and review feedback.
The justification I’ve been getting from others is that future models will resolve all the tech debt, so paying a cost to iterate fast now is worth it.
lol they're definitely not iterating on code. Instead they iterate on "ideas", with the expectation that code no longer matters because complexity will be self-resolving with agentic loops.
Unfortunately these tools, and the VCs/companies pushing to adopt them, has totally empowered this type of behaviour.
I wish! My boss at least is checked out and lazy, so he's completely missing the fact that the rest of my team is pushing AI-generated patches that immediately fail testing because they didn't bother to sanity test before pushing. Instead everyone is saying how amazing AI-generated patches are.
I don't know if it is related to promotion, but last few months there has been a push to use more and more AI in everything. As I said in a different comment, I know for a fact that part of the investment they got was contigent on part of it being used on AI.
>but a human's still the one submitting the PR for review
Where I work, the LLM writes the ticket and does all the coding. As soon as the LLM feels like it's done, it automatically submits and reviews the PR itself. The humans blindly click "approve" without reading the PR. And when the required number of humans have blindly clicked approve, a human blindly presses another button that merges the code. All the text in the ticket, the code, the PR and review is far too voluminous and verbose to easily read, so nobody does. These humans didn't start out as vibe coders, they used to be engineers.
A PR with a minimal title and empty description should be refused at submission. If the human is so disinterested that they're using LLM generated code and then can't explain the purpose, that human should be prevent from making the PR. Working as a solo dev, it is very easy to be lazy like that, and I'm as guilty as anyone. Working in teams with actual reviews should absolutely have much more strict policies of what is considered a valid PR
> A PR with a minimal title and empty description should be refused at submission
Sometimes a title is all that’s needed, but that’s often related to the complexity of the change. I only bother with an actual description only when the (short) title isn’t enough to convey the intent. But it’s very rare to go past one paragraph. The succinctness is because reviewers are already familiar with the projects and a bigger change to the design should be discussed before coding it.
This is the biggest issue I have with current state of affairs. It's not there yet. Because of that, extra work is needed to get them to work that otherwise would not need to be spent. Everyone is shouting from the roof tops about how great things are while suppressing these types of issues.
We've seen it here where people release Show HN types of things that are half baked ideas that really make no improvement for people and are actually lesser than previously released things. Yet they are expecting people to be amazed. Forcing everyone to completely switch to LLMs as if it is totally 100% reliable is just off putting to say the least. It takes discussing things with people honestly looking at the situation to have any semblance of thinking you're not the insane one for pushing back
I think everyone is coasting while the craze is on. Either it ends up being able to one shot all work and we have bigger problems. Or it can't, definitively, and we have bigger problems.
Honestly, either feels like an improvement over now.
If LLMs actually get good enough to really automate the production of good software, it'll be disruptive for the industry and we'll all have to adjust a lot more than we already are, but I think it'd be on-net good for it to be cheaper and easier to produce good software. And, in the past, such changes have only increased the size of the tech industry.
Or, if we finally realize LLMs aren't going to get there, there'll be at least increased demand for actual software engineers to clean up all the LLM mess.
But right now is the worst, where the industry feels like it's lying to itself about what these tools are capable of.
I'd rather have an empty description than a giant wall of LLM-generated text that says nothing useful and that the submitter probably didn't even read.
In my experience even before LLMs came along it was a matter of engineering culture how much a human put their motivations and rationales into why their diff came out the way it did.
> They're always overly-complex descriptions of the mechanical changes and have no sense of motivation.
This is funny to me. Coding isn't a main part of my job, but I know someone whose it is. And he says the exact same thing about his colleagues. And not just about PRs, but also comments in code in general.
It was already a well-known review point way before LLM's. Every book about code cleanliness has some point about "write WHY not WHAT when commenting code". It's a point everyone makes, because it's such an ubiquitous thing.
Of course the standard bad example is
// add 1 to a
a++;
While an IMHO good example would be when normally you wouldn't expect this addition, so you'd comment
// the flipDinkleWooptie method doesn't add one in this case
// because there is no wooptie register, so we manually
// add one here.
a++;
90% of what I want to see in a PR is "why" and an LLM is entirely incapable of knowing that.
The rest is stuff like jira ticket ids and related PRs which you can get a script to inject.
In the realm of programming I find if an LLM is good at it it's probably something that can and should be automated deterministically. It truly is e-duct tape.
My team solved this by creating a PR draft skill that clamps the length of the description to 3-5 sentences max. Those 3-5 sentences must only say WHAT is changing and WHY.
I find it to be far more useful than when humans wrote PR descriptions. Many engineers didn't write one, and those that did were poorly written... this problem is mostly solved for us.. it still has LLMism speak.. but it's useful enough for me to get the context I need to do my review.
The challenge of hard rules like this is that they're always overly restrictive. I've made multi-thousand file PRs that needed two lines of description including the title, and 5 line PRs that needed a 1hr presentation to fully explain them.
My personal guideline is that writing for humans should be done by humans.
I mean.. human judgment still applies. But as an automated first pass the clamp works in 90% of cases. I scan for correctness and make small edits here and there.
It gets better if you tell it what you expect, but maybe even better is to keep some examples of "this is a good PR description" and feed it into the LLM generating another.
Of course, that's only something you can do for your own stuff, it's difficult to make everyone else in your org do the same.
Work doesn't start with a PR description though. I'm assuming most people that are using LLMs start with some sort of document (plan, spec, intent, etc) which captures intent.
I guess you could also use all the session rollouts saved to disk that were related to that task, and distill them somehow.
Writing a paper doesn't start with writing an abstract too, but no one wants to get hit with all the notes that a scientist has collected on his experiments. The abstract is a nice 10-30 seconds explanation on why this paper is worth reading.
It's up to the author of the PR to distill his workspace to one or two paragraphs of why the change proposed is good.
The difference is an LLM can convert a stream of consciousness into well-formed prose for approximately free; I assume ‘provide some context’ means ‘brain dump’ in the OP
This has unfortunately not been my experience at all. Often LLMs miss or get wrong subtle details when I don't do the pre-work to organize my thoughts well ahead of time (at which point it's unclear how much value they're providing).
I hate to be pedantic but you can finetune a skill to shape the PR message the way you like it. That being said, I did have exactly this issue you mentioned, but the defualt output can always be tuned.
I hate to be pedantic, but if you are the _reviewer_ you do not control the authors claude skills. Sure you can push back a few times but in most teams I worked the author can just decide to get a stamp from someone else. Then as a reviewer you loose all remaining influence. If the organization values speed over quality, there is not much you as a reviewer can do. This seems like a leadership/culture issue not a technical issue.
I don't know why you got downvoted, but I find myself wanting to say some version of what you just said over and over again. People write extremely lazy, straightforward prompts and expect the LLM's intelligence to take care of all of it. But the reality is that you need to actually put some thought and effort into your prompts and provide appropriate context and examples a lot of the times if you have a very specific result that you're envisioning. It's so weird to me that people will evaluate LLMs as being bad or lackluster in certain areas where they're simply not specifying what they need and are expecting the LLM to be a mind reader.
I'm not saying that the GP is necessarily doing this. But having repeatedly had plenty of success myself in getting LLMs to write things the way that I want, with a little bit of prompting, it seems likely
> you need to actually put some thought and effort into your prompts and provide appropriate context and examples a lot of the times if you have a very specific result that you're envisioning.
Ain't gonna happen. By that point in time, I might as well do it myself. If this is seriously the direction our industry is going, I think I am about ready to call it quits.
There's centralized tooling for the PR descriptions, but I have some local flows where I try to provide more careful prompting and examples to get it to write better. It definitely helps but it's still not great and I'm often unsure if all the extra prompting is worth the effort.
It seems to me that you might as well put that thought and effort into describing the changes yourself. Most of my changes warrant 0-2 sentences of description below the header. A few particularly subtle bug fixes may need more to make sense of, but detailed descriptions of why certain mitigations are necessary are in my case more likely to end up as code comments.
That describing a change should frequently be such a difficult problem that instead of just doing it you prefer to put thought and effort into telling an LLM to do it smells bad to me. For me, the thought and effort spent writing a description is mostly already amortized through thinking clearly about the problem and performing the work. I have a much easier time describing what I just did and why than a machine that has no access to that information unless I tell it.
The PR descriptions are pretty universally disliked. We have centralized tooling that manages the prompts for that, I’m sure they’ve tried tuning it but maybe there’s more they could do.
Though I have some local workflows where I try to teach Claude about my writing style preferences via skills and examples, and it’s still not great.
It’s definitely possible to get much better output with prompting. I know, because when I’m faced with a “standard” PR description full of technical clutter, I can paste the link to Claude and ask “ELI5 what the problem actually is, any important context, what changed, and why that solves the problem.” And most of the time it converts it into something pretty good and readable.
It's an LLM concern too. LLMs seem to do better with well-organized codebases, just like the humans they were trained on.
reply