Posted by fagnerbrack 1 hour ago
There are too many product managers and decision makers that are unable or unwilling to do the hard work of actually thinking through what they want, and re-evaluating their priors as new feedback and learnings come in. Similarly, there are too many engineers who are distant from the customer and the problem at hand, and end up chasing their own idea platonic ideal of good software, detached from the hard tradeoffs of what is truly needed right now vs what we anticipate needing in the future. The less software we can write to solve the problem now, while minimizing one way door decisions, and deferring as many "scaling" challenges as long as possible to make decisions with more complete information the better.
This is why AGI won't magically solve software development—because people don't actually know what they want until they try it and then they want something else. Raw intelligence can not solve for purpose or human goals. The better it gets, the more it will become like an evil genie or monkey's paw that never quite does what the feeble-minded human prompters want.
Low quality = cascading bugs, issues, slow to iterate and add or change features
This is just as true for human written as it is for AI
Instead we have everyone giving up on code quality as if it was just "beautiful code" perfectly indented that was only there for people to ooh and aah at
After using OpenBSD for a while, I fully adopted the “write less code” approach. Create the simplest solution and leave “features” out until you need them. Nice to have should be practically banned.
The problem with this thinking is it requires certainty about the future. It's much cheaper right now IF AND ONLY IF you end up needing the thing. If you don't need it, then you've threw time and money down the drain.
Where I think this analogy weakens is you probably have far more certainty of whether or not you want a big family then you do on whether or not a new product line will see major adoption.
Sometimes it's building a house, sometimes it's writing a book, sometimes it's the difference between a Ford and a kit car, sometimes it's how you build a bridge.
None of them stand up to full scrutiny. You can pick every single one apart.
That's not the point of analogies. The point is to explain just one of the many aspects of software engineering in a more understandable format to the listener. Software engineering is nothing like building a physical thing. But some of the many, many problems and complexity you hit have physical product analogies.
Don't stretch analogies too far as they all pop.
By loosely specifying things in a prompt, there's simply not enough context for the AI tool to know the "right" output to produce for all possible inputs. What's "right" is often subjective anyway ("Should this button be red or blue?").
My job is to wire to our backend data, and a lot of these wiring require me to be in there and actually think about the features. These take time, and I just haven't figure out a way to speed this process up with Claude.
Why won't smarter and cheaper models in the future be able to automate this part for your manager as well? How novel is the feature set? Is it he has a knowledge gap or the model is incapable of something? What expertise are you bringing to bear that is beyond the scope of a future harness/model? Why wouldn't such a model simply fill in the blanks for your management, perhaps observing a diff of whatever you did? How do you verify the correctness of your thinking? Why could a future model not replicate this process?
I am just very puzzled by these sort of takes as we approach the end of 2026.
Making a calculator a billion times "smarter" isn't going to make it able to wash dishes
Anyway I hope I get an answer to my actual questions. Engaging with your "it's just a calculator" denialism is an obvious dead-end. Have a good day buddy.
Name me one human that can describe grandmaster level chess strategy but also loses to a random-only chess bot - that was the case for LLMs for a long time
My point is LLMs aren't humans. They're not a toddler slowly getting smarter, and when they're smarter they'll be able to do everything a human can do. It's a different scale entirely.
Why don't you calm down and read my question again and you will see the only one "completely missing the point" is you.
You're arguing with someone else. I didn't make a claim that LLMs were human. If you're going to respond to me then engage with what I'm exactly saying. Go back and read it again, if you can manage it.
I'm asking why is it reassuring about his job? Surely your big human brain can understand to be automated away doesn't mean the machine is "smart as a human" whatever that means. There is probably not a lot of utility in comparing synthetic and organic intelligence from such a reductive perspective.
Factory workers got automated by machines. Is a robotic arm smarter than a human? Is a tractor smarter than a bovine?
My question is simply what is he doing that is so "smart" or novel that it cannot be automated or mechanized. This should not be so hard to understand.
The problem with software is that it is never done. There is always another feature you could have and worse than building a property the work is only done by the people on the outside.
When clients ask why something takes so long, I explain that I'm not building what you asked for today, I'm building something that will be easy to turn into what you asked for today and possible to turn into whatever you ask for tomorrow.
More useful would be to be able to explain at some high level what the the inherent and accidental complexity is, the tradeoffs to navigate, long-term vs short-term decisions, etc.
Saying "it is hard" makes the audience think you're less of an expert in your domain and they are then inclined to find someone who doesn't say "this work is hard".
Yeah, I'm not sure that's a good idea. At the end of the day, Lovable is still a TypeScript web-app with a Supabase backend full stack system. If you don't understand what you have the LLMs actually build, then there is no way you can maintain it or debug it if something goes wrong.
All these no code/vibe code website generators don't make the code go away; the code maintenance burden just shifted to somebody else.