What I would like to add
Slop is not necessarily the future
291–300 of 512 posts
Re: Slop is not necessarily the future
#292I find most developers fall into one of two camps: 1. You treat your code as a means to an end to make a product for a user. 2. You treat the code itself as your craft, with the product being a vector for your craft. The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate…
Can I be both? When I wish I can take great pride in the craft of a particular piece of code.
But also I know when to put up and make the damn thing work.
Re: Slop is not necessarily the future
#293these economic incentives for good code would also apply to code before llms no? And we have had plenty of shit code that stayed shit for a long time. I find this idea that economic incentives will necessarily drive the outcomes you desire to be akin to a religious belief for some people.
Yeah you could say the same thing about teleporting to Paris, or infinitely flavorful bananas. Just because the market would reward something doesn't mean it will come to be. There may be too many tradeoffs, or technical limits, or just that the future is 200 years away so you won't be around for it anyways.
Re: Slop is not necessarily the future
#294What I would like to add is that coding in the flow state is underestimated. When your brain just clicks with every change and variable it's just different AND more efficient than doing with AI.
Re: Slop is not necessarily the future
#295I find most developers fall into one of two camps: 1. You treat your code as a means to an end to make a product for a user. 2. You treat the code itself as your craft, with the product being a vector for your craft. The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate…
> No one has ever made a purchasing decision based on how good your code is. absolutely false. > The general public does not care about anything other than the capabilities and limitations of your product. also false. People may not know that the reason they like your product is because the code is so good, but everyone likes software that is mostly free from bugs, performs extremely well, helps them do their work qu…
There's a big gap though between bug free, performance, etc and craft
Re: Slop is not necessarily the future
#296I find most developers fall into one of two camps: 1. You treat your code as a means to an end to make a product for a user. 2. You treat the code itself as your craft, with the product being a vector for your craft. The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate…
Okay tell this to game devs
Re: Slop is not necessarily the future
#297Earlier quoted context omitted.
I respect your opinion and especially your honesty. And at the same time I hope that you will some day be forced to maintain a project written by someone else with that mindset. Cruel, yes. But unfortunately schadenfreude is a real thing - I must be honest too. I have gotten to old for ship now, ask questions later projects.
I'm in camp 1 too. I've maintained projects developed with that mindset. It's fine! Your job is to make the thing work, not take on its quality as part of your personal identity. If it's harder to work with, it's harder to work with, it's not the end of the world. At least it exists, which it probably wouldn't have if developed with "camp 2" tendencies. I think camp 2 would rather see one beautiful thing than ten use…
> If it's harder to work with, it's harder to work with, it's not the end of the world.
Yeah it just takes longer and makes you miserable in the process. No biggie!
Re: Slop is not necessarily the future
#298If "good code" == "useful code", then yes. People forget that good engineering isn't "the strongest bridge", but the cheapest bridge that just barely won't fail under conditions.
Engineers don't build the cheapest bridge that just barely won't fail. They build the cheapest bridge that satisfies thousands of pages of regulatory requirements maintained and enforced by dozens of different government entities. Those regulations range from safety, to aesthetic, to environmental, to economic, to arcane. Left to their own devices, engineers would build the cheapest bridge they could sell that hopefu…
I don't think that's true. Engineers would largely want to build the best bridge costs be damned. But they would end up undercut by anyone who cuts corners resulting in the only companies getting contracts are the ones who cut the most corners. Even if no one wants to build bridges that collapse, it would be impossible without some counter forces of laws and accountability.
Re: Slop is not necessarily the future
#299Earlier quoted context omitted.
> What if we built things that are meant to last? Would the world be better for it? You'd have a better bridge, at the expense of other things, like hospitals or roads. If people choose good-enough bridges, that shows there is something else they value more.
Once the good-enough bridge deteriorates and we have to spend more money maintaining or replacing it Don't we end up just spending the same? Just now we're left with a crappy bridge.
"Good enough" bridges still last 50+ years. We could design a bridge to last 200 years but we won't even know if the design we have today will even be needed in 200 years. Maybe by then we all use trains in underground tunnels.
Re: Slop is not necessarily the future
#300I find most developers fall into one of two camps: 1. You treat your code as a means to an end to make a product for a user. 2. You treat the code itself as your craft, with the product being a vector for your craft. The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate…
We crossed a threshold in the past couple months where I'm not sure I'd agree that "libraries other devs depend on" is the right cutoff for LLMs. In many cases, LLMs will write more concise, faster, and more accurate code. Not by one-shooting, but through a deeper search of possibility space - not dissimilar to how stockfish and other pre-llm search algorithms worked
Modern harnesses are systems built with LLMs as one of many building blocks (incl. regex, test suites, linters). If it can be measured and verified, there's a good chance LLMs will optimize it
This is not a new concept. Humans stopped writing "artful" assembly many years ago, because Lattner and others made it much more efficient to rely on LLVM than hand-optimizing assembly
It's also been demonstrated in other domains within Google (4x4 matmul, silicon photonics, protein folding)
Interface heavy apps are not purely about objective function, they are about feel, comfort, usability - those apps will benefit heavily from humans. But subcomponents of these apps (eg. an algorithm to route packets efficiently) can often be better solved (somewhat objectively) by LLM-based solvers or other forms of RL.
However, writing assembly for the sake of art sounds rather interesting in an 2026. Many of my favorite musicians and DJs are driving a resurgence in vinyl to help balance the computed future - and I think that's a great thing