It’s 1 pm on the final day of the Hackathon, 5 hours left. For the last 2 hours, we made ZERO progress. I’m cursing the day Lovable was born. As soon as I…
59 comments
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
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.
I'm not a 90s engineer and that is crazy. The amount of inefficiency that people tolerate from JS and other web stuff is completely unreasonable in my view. It's also why software today is much worse than it was 20-30 years ago.
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.
The only difference right now between my manager getting this claude design web app to production are the infrastructure and interfacing with it.
To get to prod it has to go through our monorepo pipeline, which currently requires using a cli, using a cli/command prompt requires using terminal, getting claude to use terminal also requires you to even know what a terminal is and spawning claude in there. Steering claude to do all that without knowing what or how to use a terminal is, and setting up your environment still all requires some technical knowledge or the language to tell claude to do that.
That's just getting to production. What about getting the claude design which is in a web environment without any context of all that monorepo with all its backend services. So all the interactivity that are all faked or mocked. Has to be converted to a real react components that's actually wired to the Rest API. How do you get the manager to speak to claude to do all that, with claude only being on the claude design harness?
What if manager designed a new feature that the backend service doesn't support? now your asking to make changes on the backend too.
So I think your points are valid that sure we may get to this at some point. But how exactly without the manager having to learn some technical language of steering claude and the infrastructure to support it.
Taking a visual proof-of-concept and turning it into a real product with integration to an existing complex system requires the developer to re-do a-lot of the work. And reading code; especially AI code someone-else wrote, is a miserable experience.
Making a calculator a billion times "smarter" isn't going to make it able to wash dishes
* If a business person thinks a change or new program is very easy to do, it is really a very hard project.
* If a business person thinks the change or new program us hard to do, usually it is a trivial project.
For me, this has been true for well over 40 years. I never use any kind AI for my work, it did not exist before I retired.
If it's easy and the business thinks it's easy it gets done. If it's hard and the business thinks it's hard it doesn't.
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.
Read the full thread on Hacker News →
Related stories
- The Verge · 0 points · 2 days ago
- Lobsters · 86 points · about 1 year ago
- Hacker News · 1 points · 7 days ago
- Hacker News · 2 points · 4 days ago
- Hacker News · 293 points · 5 days ago
- Hacker News · 1 points · 7 days ago