Earlier quoted context omitted.
But they get to live in Europe
And Europe is a sh*thole
The recurring dream of replacing developers
521–530 of 535 posts
Re: The recurring dream of replacing developers
#522Re: The recurring dream of replacing developers
#523In the end, I think the dream underneath this dream is about being able to manifest things into reality without having to get into the details. The details are what stops it from working in every form it's been tried. You cannot escape the details. You must engage with them and solve them directly, meticulously. It's messy, it's extremely complicated and it's just plain hard. There is no level of abstraction that sav…
The argument is empty because it relies on a trope rather than evidence. “We’ve seen this before and it didn’t happen” is not analysis. It’s selective pattern matching used when the conclusion feels safe. History is full of technologies that tried to replace human labor and failed, and just as full of technologies that failed repeatedly and then abruptly succeeded. The existence of earlier failures proves nothing in…
Another lesson history has taught us though, is that people don't defend narratives, they defend status. Not always successfully. They might not update beliefs, but they act effectively, decisively and sometimes brutally to protect status. You're making an evolutionary biology argument (which is always shady!) but people see loss of status as an existential threat, and they react with anger, not just denial.
Re: The recurring dream of replacing developers
#524Re: The recurring dream of replacing developers
#525Earlier quoted context omitted.
That depends a bit on whether you view and use unit-tests for a) Testing that the spec is implemented correctly, OR b) As the Spec itself, or part of it. I know people have different views on this, but if unit-tests are not the spec, or part of it, then we must formalize the spec in some other way. If the Spec is not written in some formal way then I don't think we can automatically verify whether the implementation…
> then we must formalize the spec in some other way. For most projects, the spec is formalized in formal natural language (like any other spec in other professions) and that is mostly fine. If you want your unit tests to be the spec, as I wrote in https://news.ycombinator.com/item?id=46667964 , there would be quite A LOT of them needed. I rather learn to write proofs, then try to exhaustively list all possible combin…
Re: The recurring dream of replacing developers
#526Earlier quoted context omitted.
Don’t you understand? That’s why all these AI companies are praying for humanoid robots to /just work/ - so we can replace humans mentally and physically ASAP!
I'm sure those will help. But that doesn't solve the problem the parent stated. Those robots can't solve those real world problems until they can reason, till they can hypothesize, till they can experiment, till they can abstract all on their own. The problem is you can't replace the humans (unilaterally) until you can create AGI. But that has problem of its own, as you now have to contend with previously creating a…
> until they can reason, till they can hypothesize, till they can experiment, till they can abstract all on their own
at that point we will have to let them vote...Re: The recurring dream of replacing developers
#527Earlier quoted context omitted.
Which is why quiet quitting is the logical thing. Managers and business owners shouldn't take it personally that I do as little as possible and minimize the amount of labor I provide for the money I receive. Hey, it's just business.
Which is why I fire the quiet quitters on the spot
Re: The recurring dream of replacing developers
#528Earlier quoted context omitted.
I think it's like super insane people think that anyone can just "code" an app with AI and that can replace actual paid or established open-source software, especially if they are not a programmer or know how to think like one. It might seem super obvious if you work in tech but most people don't even know what an HTTP server is or what is pytho, let alone understanding best practices or any kind of high-level thinki…
I think this comment will not age well. I understand where you are coming from. You are missing the idea that infrastructure will come along to support vibe coding. You are assuming vibe coding as it stands today will not be improved. It will get to the point where the vibe coder needs to know less and less about the underlying construction of software.
Re: The recurring dream of replacing developers
#529Earlier quoted context omitted.
> we won't know if LLM's might save a life I had friend who was in crisis while the rest of us were asleep. Talking with ChatGPT kept her alive. So we know the number is at least one. If you go to the Dr ChatGPT thread, you'll find multiple reports of people who figured out debilitating medical conditions via ChatGPT in conjunction with a licensed human doctor, so we can be sure the numbers greater than zero. It does…
Great for her, I hope she's doing okay now. (I do think we humans can take each other for granted) If talking to chatgpt helps anyone mentally, then sure great. I can see as to why but I am a bit concerned that if we remove a human from the loop then we can probably get way too easily disillusioned as well which is what is happening. These are still black boxes but in the context of traffic lights code (even partiall…
As far as traffic lights go, this predates ChatGPT, but IBM's Watson, which is also rather much a black box where you stuff data in, and instructions come out; they've been doing traffic light optimization for years. IBM's got some patents on it, even. Of course that's machine learning, but as they say, ML is just AI that works.
Re: The recurring dream of replacing developers
#530To understand how business views developers, reread Tim Bryce's Theory P: The Philosophy of Managing Programmers (which is old enough to drink in the USA today): https://web.archive.org/web/20160407111718fw_/http://phmains... Tim Bryce was kind of the anti Scott Adams: he felt that programmers were people of mediocre intelligence at best that thought they were so damn smart, when really if they were so smart, they'd…
In my experience translating requirements into a formal language (programming language) is where a lot of the important details are actually worked out. The process of taking the "squishy" thoughts/ideas and translating them into code is a forcing function for actually clarifying and correcting those ideas.
Bryce: "Mental laziness can also be found in planning and documenting software. Instead of carefully thinking through the logic of a program using graphics and text, most programmers prefer to dive into source code without much thinking."