You should qualify your statement with "amongst the few people I talk to and the narrow spectrum of media I consume."
Also, do you mean minority of the total US population or minority of the voting population?
For one reference point I fully support ICE. And I think it's wild you have local and state politicians encouraging actions against federal agents who are enforcing federal law.
Seriously. I've known for a very long time that our community has a serious problem with binary thinking, but AI has done more to reinforce that than anything I can think of in modern memory. Nearly every discussion I get into about AI is dead out of the gate because at least one person in the conversation has a binary view that it's either handwritten or vibe coded. They have an insanely difficult time imagining anything in the middle.
Vibe coding is the extreme end of using AI, while handwriting is the extreme end of not using AI. The optimal spot is somewhere in the middle. Where exactly that spot is, I think is still up for debate. But the debate is not progressed in any way by latching on to the extremes and assuming that they are the only options.
The "vibe coding" term is causing a lot of brain rot.
Because when I see people that are downplaying LLMs or the people describing their poor experiences it feels like they're trying to "vibe code" but they expect the LLM to automatically do EVERYTHING. They take it as a failure that they have to tell the LLM explicitly to do something a couple times. Or they take it as a problem that the LLM didn't "one shot" something.
I'd like it to take less time to correct than it takes me to type out the code I want and as of yet I haven't had that experience. Now, I don't do Python or JS, which I understand the LLMs are better at, but there's a whole lot of programming that isn't in Python or JS...
I've had success across quite a few languages, more than just python and js. I find it insanely hard to believe you can write code faster than the LLM, even if the LLM has to iterate a couple times.
But I'm thankful for you devs that are giving me job security.
And that tells me you're on the dev end of the devops spectrum while I'm fully on the ops side. I write very small pieces of software (the time it takes to type them is never the bottleneck) that integrates in-house software with whatever services they have to actually interact with, which every LLM I've used does wrong the first fifteen or so times it tries (for some reason rtkit in particular absolutely flummoxes every single LLM I've ever given it to).
I pretty well span the devops spectrum from building/maintaining services to running/integrating/monitoring them in prod. LLMs are definitely better at the dev side than the ops side, no doubt about that. And when it comes to firewalld and many other sysadmin tools I agree it can often be faster to just hand type than to have the LLM do it. Even just writing Dockerfiles it's often faster to do it by hand than the LLM because the LLM will screw it up 6 to 12 times before getting it right, and usually "getting it right" is because I told it something like, "dude you can't mount, you need to copy." It's especially insanely stupid when it comes to rootless podman.
But that said, there are still plenty of ops-y situations where AI can be very helpful. Even just "here's a 125k lines of prod logs. Can you tell me what is going wrong?" has saved me lots of time in the past, especially for apps that I'm not super familiar with. It's (sometimes) pretty good at finding the needle in the haystack. The most common workflow I have now is to point an agent at it and while it's griding on it I'll do some hand greps and things. I've gotten to the bottom of some really tricky things much faster because of it. Sometimes it points me in the wrong direction (for example, one time it noticed that we were being rate-limited by the Cloudflare API, and instead of adding a single flag to the library calls it wrote it's own very convoluted queue system. But it was still helpful because at least it pinpointed the problem).
The other "small pieces of software" I find it very helpful for are bash functions or small scripts to do things. The handwritten solution is usually quick, but rarely as resilient/informative as it could be because writing a bunch of error handling can 5x or 10x the handwritten time. I will usually write the quick version, then point AI at it and have it add arg passing/handling, error handling, and usage info/documentation. It's been great for that.
As a former “types are overrated” person, Typescript was my conversion moment.
For small projects, I don’t think it makes a huge difference.
But for large projects, I’d guess that most die-hard dynamic people who have tried typescript have now seen the light and find lots of benefits to static typing.
I was on the other side, I thought types are indispensable. And I still do.
My own experience suggest that if you need to develop heavily multithreaded application, you should use Haskell and you need some MVars if you are working alone and you need software transactional memory (STM) if you are working as part of a team, two and more people.
STM makes stitching different parts of the parallel program together as easy as just writing sequential program - sequential coordination is delegated to STM. But, STM needs control of side effects, one should not write a file inside STM transaction, only before transaction is started or after transaction is finished.
Because of this, C#, F#, C++, C, Rust, Java and most of programming languages do not have a proper STM implementation.
For controlling (and combining) (side) effects one needs higher order types and partially instantiated types. These were already available in Haskell (ghc 6.4, 2005) at the time Rust was conceived (2009), for four years.
Did Rust do anything to have these? No. The authors were a little bit too concerned to reimplement what Henry Baker did at the beginning of 1990-s, if not before that.
Do Rust authors have plans to implement these? No, they have other things to do urgently to serve community better. As if making complex coordination of heavily parallel programs is not a priority at all.
I'm only writing 5-10% of my own code at this point. The AI tools are good, it just seems like people that don't like them expect them to be 100% automatic with no hand holding.
Like people in here complaining about how poor the tests are... but did they start another agent to review the tests? Did they take that and iterate on the tests with multiple agents?
I can attest that the first pass of testing can often be shit. That's why you iterate.
> I can attest that the first pass of testing can often be shit. That's why you iterate.
So far, by the time I’m done iterating, I could have just written it myself. Typing takes like no time at all in aggregate. Especially with AI assisted autocomplete. I spend far more time reading and thinking (which I have to do to write a good spec for the AI anyways).
One might argue the difference is that they are ignorant of the suffering caused by their behavior, and that the knowing and doing anyways is the moral problem, not just the doing.
Alternately, one might argue the difference is that they have no alternative to inflicting suffering, and that having the option to reduce suffering and choosing to inflict it anyways is the moral problem, not just inflicting it.
I don’t think that mammals are, in general, ignorant of the character of harm, violence, and death. Animals even kill to end suffering. Life is short, brutal, and violent. We do what we can to make it less so.
That does track with those who are most stridently Good and Moral and Kind and Right having some glaring blind spots when it comes to understanding the consequences of their actions.
Or crows that attack a member of the flock that misbehaved to a minor of the flock? (this is one of the animals that seem to have their own morals).
Anyway: humans should not project our sense of moral to animals.
And humans are no carnivores. Most likely we're omnivores (like our close animal relatives the primates: and they prefer fruit over meat any day, just like human babies).
Morality is a human construct and applies to humans, arguments that try to argue morality on the basis of applying naturalistic arguments to humans do exist, but I don’t think they have much credence in modern moral frameworks ?
I'm sure the concept of self-restraint exists in the animal kingdom among apex predators. Don't hunt too much or otherwise you will destroy your habitat.
This applies to humans too, and not just in the context of eating meat.
It does not. One predator eats all the prey, because if he doesn't, the other predators will. The next year they all starve. This is a documented effect. No reference to geopolitics intended.
Five engineers could be turned into maybe two, but probably not less.
It's the 'bus factor' at play. If you still want human approvals on pull requests then If one of those engineers goes on vacation or leaves the company you're stuck with one engineer for a while.
If both leave then you're screwed.
If you're a small startup, then sure there are no rules and it's the wild west. One dev can run the world.
This was true even before LLMs. Development has always scaled very poorly with team size. A team of 20 heads is like at most twice as productive as a team of 5, and a team of 5 is marginally more productive than a team of 3.
Peak productivity has always been somewhere between 1-3 people, though if any one of those people can't or won't continue working for one reason or another, it's generally game over for the project. So you hire more.
This is why small software startups time and time again manage to run circles around with organizations with much larger budgets. A 10 person game studio like Team Cherry can release smash hit after smash hit, while Ubisoft with 170,000% the personnel count visibly flounders. Imagine doing that in hardware, like if you could just grab some buddies and start a business successfully competing with TSMC out of your garage. That's clearly not possible. But in software, it actually is.
Fighting that people can decide what and how they want to sell and buy, results in a society I don't want to live. To enforce it you will eventually free the people from a bunch of other decisions, as they strangely refuse to follow your great ideas.
What the problem is, is the asymmetry in the market, not the market itself.
Citation needed. A healthy market has so many sellers and buyers that no side can force a price above the other. Think your local bakery or butcher. In a healthy market profits are nearly zero.
Any market inherently results in consolidation. My local bakery is a giant chain. My local butcher has been driven out of business by supermarket chains.
That is exactly my point. Local artisan bakers are being priced out by crappier quality baking shops due to their economy of scale. The market optimizes for the cheapest slop made by the biggest conglomerate, the opposite of what I want.
And yet that is a problem of the past twenty years while we had markets for centuries. The concept of markets doesn't seem to be the problem.
If you say we need more regulation and an actual Antitrust Division that does things, then I agree. If you say we need to get rid of free markets and capitalism and return to socialism, then I am strongly against that.
A cancer doesn't kill you as soon as the first cancerous cell division happens. It takes time for the processes of markets to develop into something that threatens our existence.
>My local bakery is a giant chain. My local butcher has been driven out of business by supermarket chains.
Is that an inherent property or is it the result of people in government who believe what you believe putting their thumb on the scale of the market in piecemeal?
1) Government wants to know its own population so it knows how much tax revenue to expect.
2) Government wants to appear larger to appear stronger to both enemies and friends.
reply