Hacker Newsnew | past | comments | ask | show | jobs | submit | Uehreka's commentslogin

> Writing and programming are both a form of working at a problem through text…

Whoa whoa whoa hold your horses, code has a pretty important property that ordinary prose doesn’t have: it can make real things happen even if no one reads it (it’s executable).

I don’t want to read something that someone didn’t take the time to write. But I’ll gladly use a tool someone had an AI write, as long as it works (which these things increasingly do). Really elegant code is cool to read, but many tools I use daily are closed source, so I have no idea if their code is elegant or not. I only care if it works.


Users typically don't read code, developers (of the software) do.

If it's not worth reading something where the writer didn't take the time to write it, by extension that means nobody read the code.

Which means nobody understands it, beyond the external behaviour they've tested.

I'd have some issues with using such software, at least where reliability matters. Blackbox testing only gets you so far.

But I guess as opposed to other types of writing, developers _do_ read generated code. At least as soon as something goes wrong.


Developers do not in fact tend to read all the software they use. I have never once looked at the code for jq, nor would I ever want to (the worst thing I could learn about that contraption is that the code is beautiful, and then live out the rest of my days conflicted about my feelings about it). This "developers read code" thing is just special pleading.

You're a user of jq in the sense of the comment you're replying to, not a developer. The developer is the developer _of jq_, not developers in general.

Yes, that's exactly how I meant it. I might _rarely_ peruse some code if I'm really curious about it, but by and large I just trust the developers of the software I use and don't really care how it works. I care about what it does.

As a developer of software I often have to care because it matters and so I read the code.

Source code is often written for other humans first and foremost.


I've had to dig into node modules to try to debug code from a closed source library that we depended on.

I'd much rather wade through AI slop than minified code, which may have previously been AI slop.


Minified code is not for humans, it may as well been bytecode.

Agreed! That's why I told my llm to help me.

But I think larger point being, it's not always feasible for humans to understand every line of code that runs in their software.


That’s where accountability comes in. It should be possible to have a non empty set of people that understand all the code. If I choose a dep to do unicode string parsing, that means I trust the author have good knowledge about unicode string parsing. And they should have the skills to maintain their code even if what I got is bytecoded or compiled.

What do you mean, you can't quote the Linux kernel by heart? I thought it was gospel for all nerds:

Loongarch kernel, first paragraph, the lord Linus said, in all his wisdom: /* Hardware capabilities */ unsigned int elf_hwcap __read_mostly EXPORT_SYMBOL_GPL(elf_hwcap)


Both can be equally bad. Especially if you could get the source of the minified dependency and find that it is also slop.

What a world when we’re playing Would you rather with people’s property and information.


We're talking about Show HN here.

But you read your coworkers PRs. I decided this week I wouldn't read/correct the AIgen doc and unit tests from 3 of my coworkers today, because else I would never be able to work. They produce twice as much poor output in 10 time the number of line change, that's too much.

Right, I'm not arguing developers don't read their own code or their teammates code or anything that merges to main in a repo they're responsible for. Just that the "it's only worth reading if someone took the time to actually write it" objection doesn't meaningfully apply to code in Show HN's --- there's no expectation that code gets read at all. That's why moderation is so at pains to ensure there's some way people can play with whatever it is being shown ("sign up pages can't be Show HN's").

Key part is *where reliability matters*, there are not that many cases where it matters.

We tell stories of Therac 25 but 90% of software out there doesn’t kill people. Annoys people and wastes time yes, but reliability doesn’t matter as much.

E-mail, internet and networking, operations on floating point numbers are only kind of somewhat reliable. No one is saying they will not use email because it might not be delivered.


10% is still quite a lot!

Reliability matters in lots of areas that aren't war. Ignoring obvious ones like medicine/healthcare and driving, I want my banking app to be reliable. If they charge me $100 instead of $1 because their LLM didn't realize their currency was stored in floating point dollars and not cents, then I may not die but I'd be pretty upset!


I was writing about Therac 25 that’s not war that’s medical equipment and code written by a human that killed people. Without LLM.

We guarantee 5 nines of uptime, and 1 nine of not killing people

<< 90% of software out there doesn’t kill people.

As we give more and more autonomy to agents, that % may change. Just yesterday I was looking at hexapods and the first thing it tells you ( with a disclaimer its for competitions only ) that it has a lot of space for weapon install. I had to briefly look at the website to make sure I did not accidentally click on some satirical link.


Main point is that there is many more lines of code of CRUD business apps running on AWS and instances of applications than even non-autonomous car software even though we do have lots of cars.

Most code will not kill people, but a lot of code could kill a business.

> even if no one reads it

I gotta disagree with you there! Code that isn't read doesn't do anything. Code must be read to be compiled, it must be read to be interpreted, etc.

I think this points to a difference in our understanding of "read" means, perhaps? To expand my pithy "not gonna read if you didn't write" bit: The idea that code stands on its own is a lie. The world changes around code and code must be changed to keep up with the world. Every "program" (is the git I run the same as the git you run?) is a living document that people maintain as need be. So when we extend the "not read / didn't write" it's not using the program (which I guess is like taking the lessons from a book) it's maintaining the program.

So I think it's possible that I could derive benefit from someone else reading an llm's text output (they get an idea) - but what we are trying to talk about is the work of maintaining a text.


Correct me if I’m wrong, but if you wrote a dependency-free recursive descent parser in C89 thirty years ago it should still compile and return the same AST.

Well, if it made use of any UB alongside its code, and it gets compiled with the latest version of a modern compiler in -O3, it might, or might not.

I mean....it will compile and return the same AST on the OS and hardware from 30 years ago. But if you want to get the same result today on modern hardware / software you may discover you need to make some changes (or rather people have been making little changes for 30 years to ensure you can still get the same AST). Generally software has either had little bits and bobs added and removed to keep it relevant or its fallen away and been forgotten.

>Code has a pretty important property that ordinary prose doesn’t have

But isn't this the distinction that language models are collapsing? There are 'prose' prompt collections that certainly make (programmatic) things happen, just as there is significant concern about the effect of LLM-generated prose on social media, influence campaigns, etc.


Sometimes (or often) things with horrible security flaws "work" but not in the way that they should and are exposing you to risk.

If you refuse to run AI generated code for this reason, then you should refuse to run closed source code for the same reason.

I don't see how the two correlate - commercial, closed source software usually have teams of professionals behind them with a vested and shared interest in not shipping crap that will blow up in their customers' face. I don't think the motivations of "guy who vibe coded a shitty app in an afternoon" are the same.

And to answer you more directly, generally, in my professional world, I don't use closed source software often for security reasons, and when I do, it's from major players with oodles of more resources and capital expenditure than "some guy with a credit card paid for a gemini subscription."


It makes sense. A vibe-coded tool can sometimes do the job, just like some cheap Chinese-made widget. Not every task requires hand-crafted professional grade tools.

For example, I have a few letter generators on my website. The letters are often verified by a lawyer, but the generator could totally be vibe-coded. It's basically an HTML form that fills in the blanks in the template. Other tools are basically "take input, run calculation, show output". If I can plug in a well-tested calculation, AI could easily build the rest of the tool. I have been staunchly against using AI in my line of work, but this is an acceptable use of it.


"A vibe-coded tool can sometimes do the job"

How do you know it ever does the job?

I don't know either for most code that I use, but I do have reason to trust that the author does know. I don't really trust any code itself, only the people and processes (organizational, not computer) that generated it.

I have no reason to trust that ai generated code is doing the correct thing. I know enough about the way code works to know that merely observing it seem to work in a test case means absolutely nothing at all. Multiply that zero by a million more test cases and it's the same zero.

The only thing I trust is that someone actually understood a problem they were trying to solve, and cares about avoiding edge cases, and tries to develop logic to make unintended outcomes impossible etc...

It's not possible for an ai to do any of that regardless what the prompts are. But what they can do is emit stuff that some person once wrote which did exhibit these qualities, and so looks ok, and causes idiots to think they found the cheat code to life, and worse, foist that shit off on everyone else.

My mom does not have my awareness that any of this is going on. She's just out there in the world running into this crap blindly as an unwitting end-user who has no idea how badly she's being served these days when she uses basically any app or service. Thanks for that vibe coders of the world.


> How do you know it ever does the job?

Because the part of the job it automates is simple, and can be tested. I cannot overstate how simple the tools I am thinking of are. Think tipping calculator. Neither new nor creative nor complex. The real value here is being familiar with the problem.

You are missing the point here. I am talking about people who were not served at all by software developers. The alternative is not craftsmanship, but at best duct taping wordpress plugins together.


There is a sentiment around tools and a particular business sells perfectly fine, cheap, one use tools, for those jobs that you'll only need to do once, maybe twice. But if you want a good quality tool, you spend money on it and buy it elsewhere.

That's how I perceive vibe programming. A small one-off job that it would literally take me longer to write than to have generated? Perfectly fine. For anything else, there are professionals who get it done.


That's a very appropriate analogy. It's also fine to start cheap and replace with better tools once the needs are established.

I am a software engineer, but I think code pales in comparison to the impact of every book, speech and essay had on our society throughout history.

> But I’ll gladly use a tool someone had an AI write, as long as it works (which these things increasingly do).

It works, sure, but is it worth your time to use? I think a common blind spot for software engineers is understanding how hard it is to get people to use software they aren’t effectively forced to use (through work or in order to gain access to something or ‘network effects’ or whatever).

Most people’s time and attention is precious, their habits are ingrained, and they are fundamentally pretty lazy.

And people that don’t fall into the ‘most people’ I just described, probably won’t want to use software you had an LLM write up when they could have just done it themselves to meet their exact need. UNLESS it’s something very novel that came from a bit of innovation that LLMs are incapable of. But that bit isn’t what we are talking about here, I don’t think.


> It works, sure, but is it worth your time to use?

This is something I like about the LLM future. I get to spend my time with users thinking about their needs and how the product itself could be improved. The AI can write all the CSS and sql queries or whatever to actually implement those features.

If the interesting thing about software is the code itself - like the concepts and so on, then yeah do that yourself. I like working with CRDTs because they’re a fun little puzzle. But most code isn’t like that. Most code just needs to move some text from over here to over there. For code like that, it’s the user experience that’s interesting. I’m happy to offload the grunt work to Claude.


Every little detail matters though. In SQL, do you want your database field to have limited length? If so, pay attention to validation, including cases where the field's content is built up in some other way than just entering text in a free-form text field (e.g. stuffing JSON into a database field). If not, make sure you don't use some generic "string" field type provided by your database abstraction layer that has an implicit limited length. Want to guess why that scenario's on my mind? Yeah, I neglected to pay attention to that detail, and an LLM might too. In CSS, little details affect the accessibility of the UI.

So we need to pay attention to every detail that doesn't have a single obviously correct answer, and keep the volume of code we're producing to a manageable enough level that we actually can pay attention to those details. In cases where one really is just literally moving data from here to there, then we should use reliable, deterministic code generation on top of a robust abstraction, e.g. Rust's serde, to take care of that gruntwork. Where that's not possible, there are details that need our attention. We shouldn't use unreliable statistical text generators to try to push past those details.


> So we need to pay attention to every detail that doesn't have a single obviously correct answer

I really, really wish that were the case. But look at the modern web. Look at iOS apps. Look at how long discord takes to launch on a modern computer. Look how big and slow everything is. Most end user applications released today do not pay attention to those small details. Definitely not in early versions of the software. And they're still successful. At least, successful enough.

I'd love a return to the "good old days" where we count bytes and make tight, fast software with tiny binaries that can perform well even on 20 year old computers. But I've been outvoted. There aren't enough skilled programmers who care about this stuff. So instead our super fast computers from the future run buggy junk.

Does claude even make worse choices than many of the engineers at these companies? I've worked with several junior engineers who I'd trust a lot less with small details than I trust claude. And thats claude in 2026. What about claude in 2031, or 2036. Its not that far away. Claude is getting better at software much faster than I am.

I don't think the modern software development world will make the sort of software that you and I would like to use. Who knows. Maybe LLMs will be what changes that.


> But look at the modern web. Look at iOS apps. Look at how long discord takes to launch on a modern computer. Look how big and slow everything is. Most end user applications released today do not pay attention to those small details. Definitely not in early versions of the software. And they're still successful. At least, successful enough.

The main issue is that we have a lot of good tech that are used incorrectly. Each components are sound, but the whole is complex and ungainly. They are code chimeras. Kinda like using a whole web browser to build a code editor, or using react as the view layer for a TUI, or adding a dependency just to check if a file is executable.

It's like the recently posted project which is a lisp where every function call spawn a docker container.


Yep I think this is broadly true. Though its still not clear to me if vibe coding is going to make this better or worse.

probably won’t want to use software you had an LLM write up when they could have just done it themselves to meet their exact need

Sure... to a point. But realistically, the "use an LLM to write it yourself" approach still entails costs, both up-front and on-going, even if the cost may be much less than in the past. There's still reason to use software that's provided "off the shelf", and to some extent there's reason to look at it from a "I don't care how you wrote it, as long as it works" mindset.

came from a bit of innovation that LLMs are incapable of.

I think you're making an overly binary distinction on something that is more of a continuum, vis-a-vis "written by human vs written by LLM". There's a middle ground of "written by human and LLM together". I mean, the people building stuff using something like SpecKit or OpenSpec still spend a lot of time up-front defining the tech stack, requirements, features, guardrails, etc. of their project, and iterating on the generated code. Some probably even still hand tune some of the generated code. So should we reject their projects just because they used an LLM at all, or ?? I don't know. At least for me, that might be a step further than I'd go.


> There's a middle ground of "written by human and LLM together".

Absolutely, but I’d categorize that ‘bit’ as the innovation from the human. I guess it’s usually just ongoing validation that the software is headed down a path of usefulness which is hard to specify up-front and by definition something only the user (or a very good proxy) can do (and even they are usually bad at it).


> but I’d categorize that ‘bit’ as the innovation from the human.

Agreed.


Yeah, sure, you could create a social media or photo-sharing site, but most people that want to share cat photos with their friends could just as easily print out their photos and stick them in the mail already.

Hell, I'd read an instruction manual that AI wrote as long as it accurately describes.

I see a lot of these discussions where a person gets feelings/feels mad about something and suddenly a lot of black and white thinking starts happening. I guess that's just part of being human.


> it can make real things happen even if no one reads it (it’s executable).

"One" is the operative word here, supposing this includes only humans and excludes AI agents. When code is executed, it does get read (by the computer). Making that happen is a conscious choice on the part of a human operator.

The same kind of conscious choice can feed writing to an LLM to see what it does in response. That is much the same kind of "execution", just non-deterministic (and, when given any tools beyond standard input and standard output, potentially dangerous in all the same ways, but worse because of the nondeterminism).


>but many tools I use daily are closed source

I wonder if this is a major differentiator between AI fans and detractors. I dislike and actively avoid anything closed source. I fully agree with the premise of the submission as well.


I don’t think so. With closed source, it depends on whether you trust the authors. As someone who grew up with shareware (which is generally closed source), you learned to trust authors based on their documentation and reputation. AI-generated code you simply can’t trust as-is. You have to trust whoever reviews it. Of course, with open source you can be the one who reviews it. But typically few people do, and usually almost no one does as thoroughly as the original authors and maintainers — except if they are an AI.

I guess it depends on whether you're only executing the code or if you're submitting it for humans to review. If your use case is so low-stakes that a review isn't required, then vibe coding is much more defensible. But if code quality matters even slightly, such that you need to review the code, then you run into the same problems that you do with AI-generated prose: nobody wants to read what you couldn't be bothered to write.

There’s lots of times where I just don’t care how it’s implemented.

I got Claude to make a test suite the other day for a couple RFCs so I could check for spec compliance. It made a test runner and about 300 tests. And an html frontend to view the test results in a big table. Claude and I wrote 8500 lines of code in a day.

I don’t care how the test runner works, so long as it works. I really just care about the test results. Is it finding real bugs? Well, we went though the 60 or so failing tests. We changed 3 tests, because Claude had misunderstood the rfc. The rest were real bugs.

I’m sure the test runner would be more beautiful if I wrote it by hand. But I don’t care. I’ve written test runners before. They’re not interesting. I’m all for beautiful, artisanal code. I love programming. But sometimes I just want to get a job done. Sometimes the code isn’t for reading. It’s for running.


What is it about the tests that make you not care about how it’s implemented versus other code? Just the fact that it isn’t interesting to you? I happen to like spec-testing code and find it an interesting design space. It is vital to review it thoroughly for correctness. But I also think that whether I find something interesting or not doesn’t have much bearing on whether code quality is important. Code quality can even be more important for uninteresting code, because due to the lack of interest I’ll have a lower attention span when reviewing it.

> What is it about the tests that make you not care about how it’s implemented versus other code?

Huh this is a thought provoking question.

I think there's a few reasons. In a test suite:

- I don't care about performance.

- I don't care (as much) about reliability. My users aren't affected by crashes and other failures in my tests.

- I don't care (as much) about correctness. Erroneously failing tests will get human attention. Tests that erroneously pass are a bigger problem, but my test suite is not the last line of defence against bugs reaching users.

- If I had infinite time, I'd love every line of code to be a mathematically beautiful work of art. But I don't. Writing this test suite by hand would have taken me about 3 weeks. Instead, I did it in 1 day with claude. This let me spend 14 productive days working on other things. I would rather have a good-enough test suite and 14 days of productive work than an excellent test suite and nothing else. I could spend those 14 days fixing all the bugs it found. Or writing more tests. Or getting claude to write more tests. Or going outside with my friends. These are all better uses of my time.

If I was writing the core of a new game engine, the scheduler of an operating system or the data storage engine for a new database, then I would think hard about every line of code. But not all code is like that. We must adapt ourselves to the project at hand. Some lines of code matter a lot more than others. Our workflow should take that into account.


>Whoa whoa whoa hold your horses, code has a pretty important property that ordinary prose doesn’t have: it can make real things happen even if no one reads it (it’s executable).

When your boss (assuming you have one) tells you to do something, do you just ignore it?


AI is excellent for helping to write things like tech specs, procedures and manuals.

As long as we're all aware that it'll probably mostly be AI reading them...

I agree with your sentiment, and it touches on one of the reasons I left academia for IT. Scientific research is preoccupied with finding the truth, which is beautiful but very stressful. If you're a perfectionist, you're always questioning yourself: "Did I actually find something meaningful, or is it just noise? Did I gaslight myself into thinking I was just exploring the data when I was actually p-hacking the results?" This took a real toll on my mental health.

Although I love science, I'm much happier building programs. "Does the program do what the client expects with reasonable performance and safety? Yes? Ship it."


similarly, i think that something that someone took the time to proof-read/verify can be of value, even if they did not directly write it.

this is the literary equivalent of compiling and running the code.


> I only care if it works

Okay but it is probably not going to be a tool that will be reliable or work as expected for too long depending on how complex it is, how easily it can be understood, and how it can handle updates to libraries, etc. that it is using.

Also, what is our trust with this “tool”? E.g. this is to be used in a brain surgery that you’ll undergo, would you still be fine with using something generated by AI?

Earlier you couldn’t even read something it generated, but we’ll trust a “tool” it created because we believe it works? Why do we believe it will work? Because a computer created it? That’s our own bias towards computing that we assume that it is impartial but this is a probabilistic model trained on data that is just as biased as we are.

I cannot imagine that you have not witnessed these models creating false information that you were able to identify. Understanding their failure on basic understandings, how then could we trust it with engineering tasks? Just because “it works”? What does that mean and how can we be certain? QA perhaps but ask any engineer here if companies are giving a single shit about QA while they’re making them shove out so much slop, and the answer is going to be disappointing.

I don’t think we should trust these things even if we’re not developers. There isn’t anyone to hold accountable if (and when) things go wrong with their outputs.

All I have seen AI be extremely good at is deceiving people, and that is my true concern with generative technologies. Then I must ask, if we know that its only effective use case is deception, why then should I trust ANY tool it created?

Maybe the stakes are quite low, maybe it is just a video player that you use to watch your Sword and Sandal flicks. Ok sure, but maybe someone uses that same video player for an exoscope and the data it is presenting to your neurosurgeon is incorrect causing them to perform an action they otherwise would have not done if provided with the correct information.

We should not be so laissez-faire with this technology.


> how can they even enforce this?

Many ways, and they’re under no obligation to play fair and tell you which way they’re using at any given time. They’ve said what the rules are, they’ve said they’ll ban you if they catch you.

So let’s say they enforce it by adding an extra nonstandard challenge-response handshake at the beginning of the exchange, which generates a token which they’ll expect on all requests going forward. You decompile the minified JS code, figure out the protocol, try it from your own code but accidentally mess up a small detail (you didn’t realize the nonce has a special suffix). Detected. Banned.

You’ll need a new credit card to open a new account and try again. Better get the protocol right on the first try this time, because debugging is going to get expensive.

Let’s say you get frustrated and post on Twitter about what you know so far. If you share info, they’ll probably see it eventually and change their method. They’ll probably change it once a month anyway and see who they catch that way (and presumably add a minimum Claude Code version needed to reach their servers).

They’ve got hundreds of super smart coders and one of the most powerful AI models, they can do this all day.


the internet has hundreds of thousands of super smart coders with the most powerful ai models as well, I think it's a bit harder than you're assuming.

you just need to inspect the network traffic with Claude code and mimic that


OK sure, but you’d better hope Claude Code gets it right on the first try, or that’s $200 down the drain. Also, what if the detection mechanism involves a challenge-response that happens once a week? Or randomly a couple times a month? Or after 15 minutes of use from a new public IP? Or arbitrarily if you ask it to code something with a particular topic?

There are lots of ways they could be doing this. And remember again, if they get you, they don’t have to tell you how they got you (so you might not be able to even glean information in return for the $200 you’d be losing).

Sure the internet has hundreds of thousands of super smart coders, but the subset who are willing to throw money and credit cards down the drain in order to maintain a circumvention strategy for something like this is pretty low. I’m sure a few people will figure it out, but they won’t want to tell anyone lest Anthropic nerf their workaround, so I doubt that exploits of this will become widespread.

And if you’re Anthropic, that’s probably good enough.


Then just run Claude Code in a PTY and proxy requests in and out?

> Then just run Claude Code in a PTY and proxy requests in and out?

Exactly something I said too. There are projects which can do this and hook natively to opencode and even its sdk/api.

https://news.ycombinator.com/item?id=47069299#47070204 (I list a project which does this)

I really don't know how anthropic can somehow detect something like this.


When they blocked OpenCode, I was in the middle of adding a feature. I don't think it's possible to mimic CC in an undetectable way and have the feature work.

The feature allows the LLM to edit the context. For example, you can "compact" just portions of the conversation and replace it with a summary. Anthropic can see that the conversation suddenly doesn't share the same history as previous API calls.

In fact, I ported the feature to Claude Code using tweakcc, so it literally _is_ Claude Code. After a couple days they started blocking that with the same message that they send when they block third party tools.


If your service's traffic is literally indistinguishable from Claude Code, then all it can do is what Claude Code does. Then why are the users going to choose your service instead of Claude Code?

Maybe because the UI doesn't flicker? There's a lot you can do to improve the UI for starters, and then the harness around the agent could also be improved upon, as long as the prompts are the same.

see my comment here but I think instead of worrying about the decompile minified JS code etc., you can just essentially use claude code in the background and still do it even using opencode/its SDK thus giving sort of API access over CC subscription https://news.ycombinator.com/item?id=47069299#47070204

I am not sure how they can detect this. I can be wrong, I usually am but I think its still possible to use CC etc. even after this change if you really wanted to

But at this point, to me the question of GP that is that is it even worth it is definitely what I am thinking?

I think not. There are better options out there, they mentioned mistral and codex and I think kimi also supports maybe GLM/z.ai as well


easily "bypassable", trust me :)

Speaking as a fellow job-displacement-worrier, I don’t think people have answers. But contrary to what a lot of people say, there is a ton of utility in pointing out a problem without having a solution. In this case, I think a lot of people who might have good ideas are currently under the mistaken impression that this isn’t a problem.

To the extent that I’ve heard people propose solutions, many of them have pretty big flaws:

- Retraining - AI will likely swoop in quickly and automate many of the brand new jobs it creates. Also retraining has a bit of a messy history, it was pretty ineffective at stopping the bleeding when large numbers of manufacturing jobs were offshored/automated in the past.

- “Make work” programs - I think these are pretty silly on the face of it, although something like this might be mecessary in the really short term if there’s very sudden massive job loss and we haven’t figured out a solution.

- Universal Basic Income - Probably the best system I’ve heard anyone propose. However there are 3 huge issues: 1 - politically this is a huge no-go at the moment (after watching the massive Covid stimulus happen in 2020 I have a sliver of hope, but not much). 2 - Even a pretty good UBI probably wouldn’t be enough to cushion the landing for people who make a lot right now and have made financial decisions (number of kids, purchasing a house, etc) on the basis of their current salary. 3 - Even if this happens in America (presumably redistributing the wealth accruing to American AI companies) it would leave non-Americans out in the cold, and we currently have no globally powerful institution with the trust and capability to manage a worldwide UBI.


I feel like people underrate make work a bit. If you look around at our infrastructure in the us, the number of roads and bridges with flaws, decaying buildings, the lack of housing in areas...

It's clear there's some things out there that aren't economically very profitable to do but would be nice to have done. So public works programs could soak up a lot of that and turn labor power on various stuff pretty easily I think.


Yup, there's a huge number of entirely physical/analogue ways that "many hands" could make the world a significantly nicer and more sustainable place. Public works, environmental works, having the capacity to do more than the bare minimum for the quality of the built environment - there is no shortage of things worth doing, just things worth doing profitably.

>I feel like people underrate make work a bit.

I think those are the same people that ignored the history of the https://en.wikipedia.org/wiki/New_Deal and the massive amount of infrastructure it built in the US that we still use to this day.



>> Universal Basic Income - Probably the best system I’ve heard anyone propose.

I can't understand how that would work. If you put an income floor under everyone, their rents and other basic bills will simply increase to eat the free money. None of the experiments on how people will use UBI have taken that into account since the experiments were on relatively few people in an area. The other issue is how to pay for it - it has to come from taxes somewhere.


Doesn't that kinda show that these services are not actually based on not creating any genuine value, but are rather just parasites that squeeze as much money from their victims as they can based on the victim's income, rather than the product they can offer?

rent control and/or maintain an oversupply of housing by law

(if you have ubi, you also have less of an incentive of having everybody living in the same overcrowded cities)


A simpler answer would simply be that, if you lay someone off on the basis that an AI can replace their entire job functionality, you have to keep paying their salary dollar for dollar until they find something else to do. This incentivizes companies to try and figure out creative ways to continue using their existing workforce to maximize the value they get out of AI systems.

You’d counterbalance that - and solve the other problem - by offering massive tax relief for companies who hire junior employees. In the same way that we use tax relief to encourage real estate and infrastructure investment in underserved areas, we can use it to tip the scales of economic rationality toward continuing to employ young people with no experience or specialized expertise.

Notice that neither of these proposals requires redistribution as such (seizing wealth).


> A simpler answer would simply be that, if you lay someone off on the basis that an AI can replace their entire job functionality, you have to keep paying their salary dollar for dollar until they find something else to do.

This just incentivize them to find different official reason for firing. Like missed deadlines (that sudently became shorter) or in computing job code quality (due to reduced deadlines).

> This incentivizes companies to try and figure out creative ways to continue using their existing workforce to maximize the value they get out of AI systems.

This doesnothing for the current issue of job market entry positions, where there is the most pressure from AI. Only help people only in position.


So then the corps find a way to fire you for something other than AI displacement, replace you with AI anyway, and you’re on your own. Basically identical to firing someone in a clever way that avoids having to pay unemployment, which already happens quite frequently.

I don’t understand why taxation is so off limits to this crowd. We seem to live in a death cult where avoiding a slight inconvenience to 100 people is more important than providing a decent standard of living for the other 345 million people. You can invent whatever clever little solution you want in the meantime but eventually the chickens will come home to roost.


>I don’t understand why taxation is so off limits to this crowd.

HN is filled with lots of temporarily depressed millionaires and many actual millionaires too. These are the ones that have bought into zero tax, government is all bad, free market capitalism for me Rand'ian ideas without any systematic thought on how their ideas would work out in practice.

Add to this that a lot of media, and pretty much everything on TV, is owned by billionaires these days that use the news as their platform to propagandize on why they should own more of everything and become richer, so it's not exactly surprising we're at this place.


My personal worry about UBI is that it will simply be transferred to landlords. We need to figure out how to solve the housing problem.

there is a 2nd order effect with ubi.

you have less of an incentive of having everybody in the same overcrowded cities (reducing rent and making ownership easier).

you can also do rent control and/or maintain an oversupply of housing by law.


> Even a pretty good UBI probably wouldn’t be enough to cushion the landing for people who make a lot right now and have made financial decisions (number of kids, purchasing a house, etc)

The UBI should take number of underage children into account.

If the house turned out to be too much they’d have to sell.



There are people in this thread saying tens of billions isn't that much in the long term (I'd agree) but there's a bigger point that comes into play whatever the price: The universe doesn't care if exploring it is expensive. You can't make a "that's not sustainable" argument to the universe and have it meet you half way. And that's who you're arguing against: not the scientists, the universe. The scientists don't decide how expensive future discoveries will be.

Last night I tried out Opus 4.6 on a personal project involving animating in Gaussian Splats where the final result is output as a video.

In the past, AI coding agents could usually reason about the code well enough that they had a good chance of success, but I’d have to manually test since they were bad at “seeing” the output and characterizing it in a way that allowed them to debug if things went wrong, and they would never ever check visual outputs unless I forced them to (probably because it didn’t work well during RL training).

Opus 4.6 correctly reasoned (on its own, I didn’t even think to prompt this) that it could “test” the output by grabbing the first, middle and last frame, and observing that the first frame should be empty, the middle frame half full of details, and the final frame resembling the input image. That alone wouldn’t have impressed me that much, but it actually found and fixed a bug based on visual observation of a blurry final frame (we hadn’t run the NeRF training for enough iterations).

In a sense this is an incremental improvement in the model’s capabilities. But in terms of what I can now use this model for, it’s huge. Previous models struggled at tokenizing/interpreting images beyond describing the contents in semantic terms, so they couldn’t iterate based on visual feedback when the contents were abstract or broken in an unusual way. The fact that they can do this now means I can set them on tasks like this unaided and have a reasonable probability that they’ll be able to troubleshoot their own issues.

I understand your exhaustion at all the breathless enthusiasm, but every new models radically changes the game for another subset of users/tasks. You’re going to keep hearing that counterargument for a long time, and the worst part is, it’s going to be true even if it’s annoying.


Not surprising, since being able to "see" images effectively is key to unblocking LLM augmentation for use in web and app frontend work.


> Oddly none of the anti-‘s were musicians themselves.

It is clearly plain to anyone who is a musician or hangs out with a lot of musicians that the independent music world is livid about this stuff. Everyone I’ve talked to, from acoustic songwriters to metal singers to circuit-bending pedalheads are united in their absolute hatred of this technology.

(Yes, follow-up commenter, I’ve seen the Timbaland interview)


As an independent musician, I for one welcome our AI overlords. They should not be worried about any technology that needs a human to make it remotely interesting.

They should not be worried if they aren't generic sounding independent musicians already.

Lastly, and a historical case in point, this whole conversation is a repetition of the anti-Sampler movement of the 80s and 90s. Look what that techno-leap brought us.

A new technology brings new sounds, if we all stopped treating a megalithic search engine as a personality, we'll move forwards with a lot less drama.


AI music or AI-produced music sounds a bit boring and too-perfect, like auto-tune on steroids.

Needs significant human involvement to make it interesting.

How long that remains true is another question…


> this whole conversation is a repetition of the anti-Sampler movement of the 80s and 90s.

Apples to oranges. samples them selves were just another tool. The music was still handmade.

> I for one welcome

Sorry I can’t tell if you are being sarcastic or not.


That's pretty much my point:) A new technology brought new ideas to a cultural discipline, new forms of music, twisting and morphing the old forms, especially in the hands of the naive, yet creative youth. I see the same opportunities here, another new tool for the artistic arsenal.

The sarcasm is irrelevant, my use of that term is more a nod towards this platform and historical replies in past discussions, in regard to similar situations. I'll make an effort to excise any superfluous attempts at humour in future posts!


The answer to “which coding agent should we standardise on?” is really simple: Don’t.

The tradeoffs of the different models are complicated and difficult to wrap your head around, and if you have the resources to try a bunch and form a conclusion, next week new models will come out and change the equation in small but difficult-to-understand ways again.

The solution is to ask your engineers which models they like, get them access to as many of those as you can, and expect their preferences to change and price that in.

“But I don’t have the budget to buy subscriptions to all the models my engineers want! And there are compliance issues with some of them!”

Note that I didn’t say you have to get access to all of them: as many as you can. And try to push the envelope as much as possible. Get creative. Perhaps give engineers a $200/mo AI coding budget and let them pick from a selection of subscriptions. You’re going to have different engineers using different AI coding tools, and if you refuse to let them, your competitors will.

Maybe in the future “standardizing on one coding agent” will be a thing that makes sense. But that time is not now.


How have you been here 12 years and not noticed where and how often the username tptacek comes up?


OpenClaw uses Opus 4.5, but was written by Codex. Pete Steinberger has been pretty a pretty hardcore Codex fan since he switched off Claude Code back in September-ish. I think he just felt Claude would make a better basis for an assistant even if he doesn’t like working with it on code.


What’s weird though is that modern OSes often auto-capitalize the first letter of a sentence, so it actually takes more effort to deliberately type in all-lowercase.


Only mobile does that in my experience - you can tell what platform people send discord messages on based on this usually


simple toggle to disable it permanently

my reasoning is that i don’t want identifiable markers for what device im writing from. so all auto-* (capitalization, correct, etc.) features are disabled so that i have raw input


Being part of the minority that disables those things (and then admitting to it in public) provides a lot more analytical signal than you’re aware of. That’s a remarkably poor reason to disrespect your readers.


i don't care about the 'analytical signal'. the purpose is people can't tell if im writing a (discord, slack, etc.) message from my phone or laptop or desktop, and it works for that


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: