On aggregate, humans will engage in exactly as terrible and selfish behaviour as society lets them get away with, without fail. Murder, rape, theft are the way of nature. We don't need a spotlight to know this. The only thing we can do is use our collective power as a social species to shut down each type of harmful individual behaviour, which does not solve such behaviours completely but does drastically reduce them.
The discussion shows just how many different communication styles there are. So many comments about "XYZ is the right way", "ABC is always wrong" or "I did UV to someone who says they like UV and they took offence".
It shows me:
- there are many communication styles and people tend to think their preferred one is obviously right
- people are often unclear on what they actually value in communication (and might like the opposite of what they say they value)
- people seem also to, at times, confuse other people's different communication style for rudeness, indecisiveness or small-mindedness.
So I guess the reasonable policy is to adopt a hybrid approach. Be tolerant of other people's comms style, try to be concise with enough politeness added in that you don't offend people, even if they say they want you to be ruthlessly direct. When you need to, try to steer the conversation towards your preferred style. Maybe "ok, I understand the background, let's try to distill the facts now", or equally "I feel I need more context before we continue, let's slow down and...".
For example, I have worked in a number of medium sized (50-200) companies that were so proud of being flat structured meritocracies, where anyone can say anything directly to their superiors. Every single time it turned out to be BS, higher ups wanted deference and following chains of command. But that sounds less catchy.
Doesn't really answer you question but IME this is sort of unavoidable unless you're massive and you can afford to have people who just document this kind of stuff as their job.
Reason being, a lot of this stuff happens for no good reason, or by accident, or for reasons that no longer apply. Someone liked the tech so used it - then left. Something looked better in a benchmark, but then the requirements drifted and now it's actually worse but no one has the time to rewrite. Something was inefficient but implemented as a stop gap, then stayed and is now too hard to replace.
So you can't explain the reasons when much of the time there aren't any.
The non-solutions are:
- document the high level principles and stick to them. Maybe you value speed of deployment, or stability, or control over codebase. Individual software choices often make sense in light of such principles.
- keep people around and be patient when explaining what happened
- write wiki pages, without that much effort at being systematic and up to date. Yes, they will drift out of sync, but they will provide breadcrumbs to follow.
I'm not sure you can blame this on deities. Nazis and Stalinists (especially the latter) were very atheistic. Both at some level thought they're building a better world, literally by murdering millions of people and enslaving orders of magnitude more.
> The third angel blew his trumpet, and a great star fell from heaven, blazing like a torch, and it fell on a third of the rivers and on the springs of water. The name of the star is Wormwood. A third of the waters became wormwood, and many people died from the water, because it had been made bitter.
> [...] If my requests are [not] heeded, Russia [...] will spread her errors throughout the world, causing wars and persecutions of the Church. The good will be martyred; the Holy Father will have much to suffer; various nations will be annihilated.
I'm not sure it is fair to call it propaganda when it is bang on the money. Even the Holy Father bit checks out, seeing how John Paul II narrowly survived a KGB-sponsored assassination attempt.
I keep thinking what the world would look like if the Bush wars didn't happen and the money went instead into global development - green energy transition, education, healthcare. How much solar and nuclear does 1.2T USD buy you?
But then I take off my red communist beret off and salute the stars and stripes and remember what really matters.
In all seriousness, if I ever had access to a time machine, I would want to see what the world looks like now in the timeline that Al Gore became president. I fully suspect that September 11 is one of those events that, in Doctor Who parlance, is a static point in all timelines, so I want to see how Gore would have responded, and what ramifications that would have had over the next 20 years.
just created an account on HN so I could reply to this comment: why the heck did you have to remind me of that! 20 something years removed I had forgotten that little detail and was so happy in my ignorant bliss!
I find the "K-shaped" recovery a very compelling narrative. Some companies are going stratospheric, some are decaying, the average is +1% growth or so. So depending on where you are, you will see the economy as either booming or floundering.
There's plenty of little nuggets like this to point to. US 2025 GDP ex AI investment was in a recession. US equity market ex tech does not outperform e.g. Europe. And so on.
Is there any report on the distribution of growth per firm ? (Interested for example by the median of firm growth). Could be a good evidence to support this inequal repartition of growth argument).
Depends where the money came from. If it's debt / optimistic raises based on great faith in AI, not necessarily. But agreed overall.
The tech one is more compelling. The US equity market dominance has been driven by it's very successful tech business. Everything else is perhaps in a similar malaise to eg Europe.
Imagine a consumer packaged goods fund that focuses on premium consumer packaged goods, like the kind of more cutesy stuff you may have seen on the shelves at places like Whole Foods. You would think that the fund is doing poorly because people have less money to spend in general. However, in a K-shaped recovery, the premium goods should actually over-perform the standard options, because the people who are on tight budgets and moving to the value options, well, they weren't really buying the premium items in the first place.
Markets have an obscene number of variables to consider in any analysis. An industry can be doing both good and bad depending on what the product is, and who the customer is.
At the end of the day, I continue to believe the Housing Theory of Everything thesis when it comes to the sense that people are on an economic treadmill where nothing ever gets better. And it helps describe the engine behind the K-shaped recovery. If we can fix the rent-seeking, we should be able to get back to a world where a rising tide lifts all boats.
I find LLMs are good at essentially boilerplate code. It's clear what to do and it needs to be typed in. Or areas where I really have no idea where to start, because I'm not familiar with the codebase.
I find anything else, I spend more time coaxing them into doing 85% of what I need that I'm better off doing it myself.
So they're not useless but there's only so many times in a week that I need a function to pretty-print a table in some fashion. And the code they write on anything more complex than a snippet is usually written poorly enough that it's a write-once-never-touch-again situation. If the code needs to be solid, maintainable, testable, correct (and these are kind of minimal requirements in my book) then LLMs make little impact on my productivity.
They're still an improvement on Google and Stack exchange, but again - only gets you so far.
> I find anything else, I spend more time coaxing them into doing 85% of what I need that I'm better off doing it myself.
You must be working in a very niche field with very niche functionality if that's the case? I work at a company just outside of FAANG and I work in compliance. Not a terribly complex domain but very complicated scale and data integrity requirements.
I haven't written a single line of code manually in 2 weeks. Opus 4.6 just... works. Even if I don't give it all the context it just seems to figure things out. Occasionally it'll make an architectural error because it doesn't quite understand how the microservices interact. But these are non-trivial errors (i.e. humans could have made them as well) and when we identify such an error, we update the team-shared CLAUDE.md to make sure future agents don't repeat the error.
I often wonder what I am missing. Recently I wanted to wrap a low level vendor API with a callback API (make a request struct and request id, submit, provide a callback fn, which gets called with request IDs and messages received from vendor) to async Python (await make_request(...)). Kinda straightforward - lots of careful code of registering and unregistering callbacks, some careful thread synchronisation (callbacks get called in another thread), thinking about sane exception handling in async code. Fiddly but not rocket science.
What I got sort of works, as in tests pass - this with Opus 4.5. It is usable, though it doesn't exist cleanly on errors despite working to death with Claude about this. On exception it exits dirtily and crashes, which is good enough for now. I had some fancy ideas about logging messages from the vendor to be able to replay them, to be able to then reproduce errors. Opus made a real hash of it, lots of "fuck it comment out the assert so the test passes". This part is unusable and worse, pollutes the working part of the project. It made a valiant effort at mocking the vendor API for testing but really badly, instead of writing 30 lines of general code, it wrote 200 lines of inconsistent special cases that don't even work altogether. Asked to fix it it just shuffles around the special cases and gets stuck.
It's written messily enough that I wouldn't touch this even to remove the dead code paths. I could block a few days for it to fix but frankly in that time I can redo it all and better. So while it works I'm not gonna touch it.
I did everything LLM proponents say. I discussed requirements. Agent had access to the API docs and vendor samples. I said think hard many times. Based on this we wrote a detailed spec, then detailed inplementation plan. I hand checked a lot of the high level definitions. And yet here I am. By the time Opus went away and started coding, we had the user facing API hammered out, key implementation details (callback -> queue -> async task in source thread routing messages etc), constraints (clean handling of exceptions, threadsafe etc). Tests it has to write. Any minor detail we didn't discuss to death was coded up like a bored junior.
And this also wasn't my first attempt, this was attempt #3. First attempt was like, here's the docs and samples, make me a Python async API. That was a disaster. Second was more like, let's discuss, make a spec, then off you go. No good. Even just taking the last attempt time, I would have spent less time doing this by hand myself from scratch.
Based on what I've seen and heard, you have the happy path working and that's what the pro-AI people are describing with huge speedups. Figuring out and fixing the edge cases and failure modes is getting pushed into the review stage or even users, so it doesn't count towards the development time. It can even count as more speed if it generates more cases that get handled quickly.
I'm not sure I agree with this approach, or at least it doesn't work in my area. It's like self driving cars. Having 90% reliability is almost as good as 0%. I have to be confident the thing is gonna work, correctly, or at worst fail predictably.
I can see that there's a lot of applications where things can just randomly fail and you retry / restart, that helps with crashes.
But the AI can't make it not crash, what's to say it does the right thing when it succeeds? Again, depends on the relative cost of errors etc.
Just a guess, but to me it sounds like you're trying to do too much at once. When trying something like this:
> lots of careful code of registering and unregistering callbacks, some careful thread synchronisation (callbacks get called in another thread), thinking about sane exception handling in async code. Fiddly but not rocket science.
I'd expect CC to fail this when just given requirements. The way I use it is to explicitly tell it things like: "Make sure to do Y when callback X gets fired" and not "you have to be careful about thread synchronisation". "Do X, so that Exceptions are always thrown when Y happens" instead of "Make sure to implement sane Exception handling". I think you have to get a feeling for how explicit you have to get because it definitely can figure out some complexity by itself.
But honestly it's also requires a different way of thinking and working. It reminds me of my dad reminiscing that the skill of dictating isn't used at all anymore nowadays. Since computers, typing, or more specifically correcting what has been typed has become cheap. And the skill of being able to formulate a sentence "on the first try" is less valuable. I see some (inverse) parallel to working with AI vs writing the code yourself. When coding yourself you don't have to explicitly formulate everything you are doing. Even if you are writing code with great documentation, there's no way that it could contain all of the tacit knowledge you as the author have. At least that's how I feel working with it. I just got really started with Claude Code 2 months ago and for a greenfield project I am amazed how much I could get done. For existing, sometimes messy side projects it works a lot worse. But that's also because it's more difficult to describe explicitly what you want.
> The way I use it is to explicitly tell it things like: "Make sure to do Y when callback X gets fired" and not "you have to be careful about thread synchronisation". "Do X, so that Exceptions are always thrown when Y happens" instead of "Make sure to implement sane Exception handling".
At this point I'm basically programming in English, no? Trying to squeeze exact instructions into an inherently ambiguous representation. I might as well write code at this point, if this is the level of detail required. For this to work, I need to be able to say "make this thread-safe", maybe "by using a queue". Not explaining which synchronisation primitive to use in every last piece of the code.
This is my point actually. If I describe the task to accuracy level X, it still doesn't seem to work. To make it work, perhaps I need to describe it to level Y>X, but that for now takes me more time than to do it myself.
There's lots of variables here, how fast I am at writing code or planning structure, how close to spec the things needs to be, etc. My first "vibe code" was a personal productivity app in Claude Code, in Flutter (task timing). I have 0 idea about Dash or Flutter or any web stuff, and yet it made a complete app that did some stuff, worked on my phone, with a nice GUI, all from just a spec. From scratch, it would take me weeks.
...though in the end, even after 3 attempts, the final thing still didn't actually work well enough to be useful. The timer would sometimes get stuck or crash back down to 0, and froze when the app was minimised.
I'm reminded of the notion of "komolgorov complexity" here. There might be some tasks for which a short natural language description is sufficient, and others for which a sufficiently formal description is needed to the point that it's easier to actually write the code than describe it in English.
> At this point I'm basically programming in English, no?
Yea, except they can handle some degree of complexity. Its usefulness obviously really depends on that degree. And I'm sure there are still a lot of domains and types of software where that tradeoff between doing it yourself or spelling it out isn't worth it.
Consistently over time, ive gotten really bad results trying to make anything with python using claude, so that might be it.
i think ive done some python on each major model release, not necessarily woth claude code, but it feels like if it touches python, it gets stupid, quickly.
and not just for the python, it stays stupid when it wants to say, write html. for a tiny data labeling tool, it turned off user select, for instance
> On exception it exits dirtily and crashes, which is good enough for now
Silent failures and unexplained crashes are high on my list of things to avoid, but many teams just take them for granted in spite of the practical impact.
I think that a lot of orgs have a culture of "ship it and move on," accompanied by expectations like: QA will catch it, high turnover/lower-skill programmers commit stuff like this all the time anyway, or production code is expected to have some rough edges. I've been on teams like that, mostly in bigger orgs with high turnover and/or low engineering standards.
Two use-cases recently where Claude sucked for me:
1. Performance-critical code to featurize byte slices for use in a ML model. Claude kept trying to take multiple passes over the slice when the featurization can obviously be done in one. After I finally got it to do the featurization in one pass it was double-counting some bytes but not others (double counting all of them would have been fine since the feature vector gets normalized). Overall it was just very frustrating because this should have been straight-forward and instead it was dogshit.
2. Performance-critical code that iterates over lines of text and possibly applies transformations, similar to sed. Claude kept trying to allocate new Strings inside of the hot-loop for lines that were not transformed. When I told it to use Cow<'a, str> instead so that the untransformed lines, which make up the majority of processed lines, would not need a new allocation, Claude completely fucked up the named lifetimes. Importantly, my CLAUDE.md already tells Claude to use copy-on-write types to reduce allocations whenever possible. The agent just ignored it, which is _the_ issue with LLMs: they're non-deterministic and any guidance you provide is ultimately just a suggestion.
So we don't want that spotlight (or maybe do as a honeypot operation) but I'm not as of yet concerned for the effect they have on humanity.
reply