staticassertion

Not really. I stopped using it at some point a very, very long time ago, and I don't recall why. I've moved to Youtube so it hasn't occurred to me to revisit.

I can't tell if you're joking?

I listen to a lot of old music - 1950s, 1960s. I don't really have peers who listen to it so discoverability is a real issue. Pandora was amazing for me ~20 years ago, it introduced me to songs I never would have heard. Especially in the 50s you had a lot of "one hit wonders" so just listening to a band wasn't a great way to find other songs that I would like.

I don't really use Spotify so I can't compare but Pandora was awesome. I've found Youtube playlists to be the best replacement so far.

> Lacking in empathy could also be said of the software devs who think that software devs are a significant customer group in the economy, when they are a tiny percentage of the work force.

This is silly equivocation. I'm telling you that your statement lacks empathy, and you're making vague, unclear gestures to an entire field.

Anyway, reading your post it's clear that you have a rather pathetic grudge because software devs weren't interesting in working with you and now you get to grin gleefully as you see AI take away jobs. You obviously have zero insight into software development as a practice, nor how software devs think - this is glaringly obvious by your detraction that software devs give software away for free as somehow snobbery because they wouldn't work on whatever project you clearly hold a grudge over. Further, your comments from start to finish demonstrate a complete lack of understanding of what the job actually entails.

> BTW, you are hearing a lot more hostility in my comments than is actually there.

Maybe so! I can't tell you what you actually think, but it comes off as really pathetic, so maybe reread your post and consider why I'm hearing it.

Best of luck in your ventures.

> What I'm saying is that it's a non-issue for customers if software has good engineering or not, if it fulfills their needs at a price they can pay.

You think that good engineering is unrelated to fulfilling needs at a price they pay? I think you're confused. Software engineers are tasked with exactly this problem - determining how to deliver utility at a price point. That's... the whole job. We consider how much it costs to run a database, how to target hardware constraints, how to build software that will scale accordingly as new features are added or new users onboard, etc. That's the job...

That's sort of the whole point of the article. The job isn't "write code", which is what AI does. The job is "understand the customer, understand technology, figure out how to match customer expectations, business constraints, and technologies together in a way that can be maintained at-cost".

> While human programmers are unwilling to provide this software for even a high price.

Sorry, but this is just you whining that people didn't want to work for you. Software engineers obviously are willing to provide software in exchange for money, hence... idk, everyone's jobs.

> And AI code will serve that field.

That may be true, just as no-code solutions have done in the past.

> Software engineers like you are the people who can best exploit this market segment, probably by leveraging these new AI tools.

Yes, I agree.

> Otherwise more and more people will do like me and have AI make their own bespoke solutions.

I'm a bit skeptical of this broadly in the long term but it's certainly the case that some portion of the market will be served by this approach.

> If they're too precious to adapt or take a different job, then starve.

Yeah I mean I think everyone is with you except for the "then starve", this is just weirdly combative and lacking in empathy, I find it totally strange.

> Me and hundreds of thousands of other organizations who have software needs that were under served by the market.

And... you blame software developers for that? You blame software devs for a lack of capacity in the field? So weird.

> Now we will have AI write that code for us - or more realistically, now we will purchase this software from any of the thousands of boutique software development shops that will emerge, which use AI + talented human developers to serve us.

Okay, I mean, this has always been an option. I guess it will be more of an option now. There have been consulting agencies or "WYSIWYG" editors like Wix or other "low code/ no code" platforms for ages. No one is going to be upset that you're using them. This hostility is totally one sided lol

> I have the strong impression that programmers in many cases have a good deal of snobbery regarding what tasks they are willing to work on.

We like to work on interesting projects... is that surprising? Is that snobbery? I don't get it.

> If it's not giant enterprise software, then it's usually just filed under "hobbyist" or open source.

I find this funny because hobbyist/ open source projects are by far the ones that are glamorized by the field, not enterprise software.

> Hopefully many programmers will find a well paying career serving less glamorous customers with software that solves real world problems. But many will have to change their attitude if they want to do that.

I have no idea where you get this impression from. Most software devs I've worked with are motivated heavily by solving real world problems. I think you have very, very little insight into what software development actually looks like or what software engineers are motivated by. Frankly, this comes off as very much "I was snubbed and now I'm happy that the people who I perceive as having snubbed me will be replaced by AI", which I think is quite lame. You definitely seem to have a resentful tone to your posts that I find weird.

Yeeesh. Looking at other posts from that user, they seem to have a serious grudge against software devs, presumably for not responding to their emails. "You should starve" - words taken from another post.

Look, no one wanted to write code for you idk what to tell you. Now you can have AI do that for you. Congrats, best of luck. Whatever weird personal issue you have, I doubt anyone was not working for you out of some whatever this perceived snobbery is and it's just like... we all have jobs?

I mean, of course not everyone can code. I'm not saying that programming is trivial, or anyone can just naturally write code. What I'm saying is that if you're a full time engineer then some part of your day is spent programming but the difficult work is not encompassed by "how do I write the code to do this?" - sometimes it is, but mostly you think about lots of other things surrounding the code.

"That's an old run, rebuild and the new version will work" lol

Right... I mean, no engineer is going to tell you that customers care about unit tests, so I think you're arguing against a straw man here. What engineers will tell you is that bugs cost money, support costs money, etc, and that unit tests are one of the ways we cheaply reduce those costs in order to solve problems, which is what we're in the business of doing.

We are all very aware of the fact that customers pay us... it seems totally strange to be that you think we wouldn't be aware of this fact. I suspect this is where the disconnect comes in, much to the point of the article - you seem to think that engineers just write tests and code, but the article points out how silly that is, we spend most of our time thinking about our customers, features, user experience, and how to match that to the technology choices that will allow us to build, maintain, and support systems that meet customer expectations.

I think people outside of engineering might be very confused about this, strangely, but engineers do a ton of product work, support work, etc, and our job is to match that to the right technology choices.

It's hard to reconcile "I don't think I can take this seriously" followed by an immediate admission that you agree but that there's some nuance.

I think the author's post is far more nuanced that this one sentence that you apparently agree with fundamentally.

It's unclear what point you're even trying to make, other than that AI has been helpful to you. But surely you understand that if you don't know what a unit test is you're probably not in a position to comment on the value of unit testing.

> Snobby programmers would never even return an email offering money for their services.

Why the would they? I don't respond to the vast majority of emails, and I'm already employed.

I think it's easier for good engineers to be good, perhaps. For example, I think property testing is "good" engineering. But I suspect that if you took a survey of developers the vast majority would not actually know what property testing is. So is AI really of any use then for those devs?

> if we found a way to make the hard parts easier and prevent software projects from devolving into balls of chaos and complexity.

I don't really believe this is possible. Or, it's the sort of thing that gets solved at a "product" level. Reality is complicated. People are complicated. The idea that software can exist without complexity feels sort of absurd to me.

That said, to your larger point, I think the goal is basically to eliminate the middle class.

> Code Was Never the Hard Part

I can't believe this has to be said, but yeah. Code took time, but it was never the hard part.

I also think that it is radically understated how much developers contribute to UX and product decisions. We are constantly having to ask "Would users really do that?" because it directly impacts how we design. Product people obviously do this more, but engineers do it as a natural part of their process as well. I can't believe how many people do not seem to know this.

Further, in my experience, even the latest models are terrible "experts". Expertise is niche, and niche simply is not represented in a model that has to pack massive amounts of data into a tiny, lossy format. I routinely find that models fail when given novel constraints, for example, and the constraints aren't even that novel - I was writing some lower level code where I needed to ensure things like "a lock is not taken" and "an allocation doesn't occur" because of reentrancy safety, and it ended up being the case that I was better off writing it myself because the model kept drifting over time. I had to move that code to a separate file and basically tell the model "Don't fucking touch that file" because it would often put something in there that wasn't safe. This is with aggressively tuning skills and using modern "make the AI behave" techniques. The model was Opus 4.5, I believe.

This isn't the only situation. I recently had a model evaluate the security of a system that I knew to be unsafe. To its credit, Opus 4.6 did much better than previous models I had tried, but it still utterly failed to identify the severity of the issues involved or the proper solutions and as soon as I barely pushed back on it ("I've heard that systems like this can be safe", essentially) it folded completely and told me to ship the completely unsafe version.

None of this should be surprising! AI is trained on massive amounts of data, it has to lossily encode all of this into a tiny space. Much of the expertise I've acquired is niche, borne of experience, undocumented, etc. It is unsurprising that a "repeat what I've seen before" machine can not state things it has not seen. It would be surprising if that were not the case.

I suppose engineers maybe have not managed to convey this historically? Again, I'm baffled that people don't see to know how much time engineers spend on problems where the code is irrelevant. AI is an incredible accelerator for a number of things but it is hardly "doing my job".

AI has mostly helped me ship trivial features that I'd normally have to backburner for the more important work. It has helped me in some security work by helping to write small html/js payloads to demonstrate attacks, but in every single case where I was performing attacks I was the one coming up with the attack path - the AI was useless there. edit: Actually, it wasn't useless, it just found bugs that I didn't really care about because they were sort of trivial. Finding XSS is awesome, I'm glad it would find really simple stuff like that, but I was going for "this feature is flawed" or "this boundary is flawed" and the model utterly failed there.

Most devs aren't very good. That's the reality, it's what we've all known for a long time. AI is trained on their code, and so these "subpar" devs are blown away when they see the AI generate boring, subpar code.

The second you throw a novel constraint into the mix things fall apart. But most devs don't even know about novel constraints let alone work with them. So they don't see these limitations.

Ask an LLM to not allocate? To not acquire locks? To ensure reentrancy safety? It'll fail - it isn't trained on how to do that. Ask it to "rank" software by some metric? It ends up just spitting out "community consensus" because domain expertise won't be highly represented in its training set.

I love having an LLM to automate the boring work, to do the "subpar" stuff, but they have routinely failed at doing anything I consider to be within my core competency. Just yesterday I used Opus 4.6 to test it out. I checked out an old version of a codebase that was built in a way that is totally inappropriate for security. I asked it to evaluate the system. It did far better than older models but it still completely failed in this task, radically underestimating the severity of its findings, and giving false justifications. Why? For the very obvious reason that it can't be trained to do that work.

I absolutely have the hang of Claude and I still find that it can make those ridiculous mistakes, like replicating logic into a test rather than testing a function directly, talking to a local pg that was stale/ running, etc. I have a ton of skills and pre-written prompts for testing practices but, over longer contexts, it will forget and do these things, or get confused, etc.

You can minimize these problems with TLC but ultimately it just will keep fucking up.

Agreed. When I've written very low level code where there are "odd" constraints ("this function must never take a lock, no system calls can be made" etc) the LLM would accidentally violate them. It seems sort of obvious why - the vast majority of code it is trained on does not have those constraints.

Maybe, but the person they're responding to seemed to be genuine in their question, and I worry that they'll read a statement like "they mostly ate meat" and think it's plausible when it's insanely incorrect.

lol this is such utter bullshit? I'm blown away by how confidently stated and how utterly incorrect this is.

1. Ancient egyptians ate fucktons of wheat and barley, lentils, chickpeas, etc. They ate massive amounts of fiber lol I mean holy fuck I just can't believe how wrong you are?

2. Fiber is very, very well understood by ALL health organizations to be preventative for colon cancer.

> Yeah, i wonder what was the fiber i take for someone from egypt or hunter gatherers.

Very high.

> But if a person is regular and does not have any gut issues, how would more fiber help?

There is a ton of research about this and it's why WHO and other orgs state explicitly that fiber reduces rates of colon cancer.

I think that's all very fair.

That's fine. It's just unclear to me if the parent poster is being critical exclusively of people "irl" giving unsolicited advice or if they're speaking to the forum of users who come here explicitly to discuss topics like these.

If it's the former, I'm ambivalent. I don't give advice as a general rule. If it's the latter, I find that totally silly.

> My comment is that it is not ONLY low fiber diets.

Well, you said "can't" and I asked "why", which feels very reasonable to me. Your argument seems to be that it wouldn't account properly for the data - specifically, you're saying we would have seen colon cancer rates rise earlier.

> Western diet collapsed its fiber intake well over 80 years ago - it would have shown up already.

I don't really buy this for a lot of reasons. Probably the two most important are (a) ability to screen historically and (b) the timing isn't particularly "off" for the fiber argument. We did see it already, we've been seeing increases in color cancer risks for decades.

Now, I'm not married to it "just" being fiber whatsoever, but if I were to "bet" on the major contributing factor, naively, that's where my money would go. I think it's very reasonable to not place your bet there.

You're on a discussion forum where the topic is colon cancer. Surely you understand that people are going to discuss it?

It's a bit hard to tell from your post what you're saying. Certainly I can imagine being annoyed by constantly being given health advice from layman. But this is... a forum.

Uh, what? I have not made a presuppositional argument (I made no argument at all...). I made a statement about my epistemic state - ie: that I would "bet" on low fiber being the major contributor to colon cancer rates. Someone then asserted that it can't be that, and I asked "why?".

> Why would more fiber help?

Because there is an incredible amount of research into high fiber diets being good for your gut, including reduced colon cancer rates. This is the consensus of various organizations such as WHO - high fiber diets have lower risks of colon cancer.

Why?

This is my personal bet. It's just low fiber diets.

Yeah for sure, it's a real issue. In general, seccomp feels hard to use unless you own your stack top to bottom.

This is a problem but fwiw libc's should be falling back to old system calls. You can block clone3 today and see that your libc will fall back to clone.