11 ms·
In 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
by davnicwil 9mo ago
In 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 saves you from this, because the last level is simply things happening in the world in the way you want them to, and it's really really complicated to engineer that to happen.
I think this is evident by looking at the extreme case. There are plenty of companies with software engineers who truly can turn instructions articulated in plain language into software. But you see lots of these not being successful for the simple reason that those providing the instructions are not sufficiently engaged with the detail, or have the detail wrong. Conversely, for the most successful companies the opposite is true.
- lazypenguin 9mo agoYes! I love this framing and it’s spot on. The successful projects that I’ve been involved in someone either cares deeply and resolves the details in real time or we figured out the details before we started. I’ve seen it outside software as well, someone says “I want a new kitchen” but unless you know exactly where you want your outlets, counter depths, size of fridge, type of cabinets, location of lighting, etc. ad infinitum your project is going to balloon in time and cost and likely frustration.
- cwmoore 9mo agoA kitchen is a great metaphor. Details or doom.
- fragmede 9mo agoIs your kitchen contractor an unthinking robot with no opinions or thoughts of their own that has never used a kitchen? Obviously if you want a specific cabinet to go in a specific place in the room, you're going to have to give the kitchen contractor specifics. But assuming your kitchen contractor isn't an utter moron, they can come up with something reasonable if they know it's supposed to be the kitchen. A sink, a stove, dishwasher, refrigerator. Plumbing and power for the above. Countertops, drawers, cabinets. If you're a control freak (which is your perogative, it's your kitchen after all), that's not going to work for you. Same too for generated code. If you absolutely must touch every line of code, code generation isn't going to suit you. If you just want a login screen with parameters you define, there are so many login pages the AI can crib from that nondeterminism isn't even a problem.
- mkleczek 9mo agoAt least in case of the kitchen contractor, you can trust all the electrical equipment, plumbing etc. is going to be connected in such a way that disasters won't happen. And if it is not, at least you can sue the contractor. The problem with LLMs is that it is not only the "irrelevant details" that are hallucinated. It is also "very relevant details" which either make the whole system inconsistent or full of security vulnerabilities.
- fc417fc802 9mo agoThe login page example was actually perfect for illustrating this. Meshing polygons? Centering a div? Go ahead and turn the LLM loose. If you miss any bugs you can just fix them when they get reported. But if it's security critical? You'd better be touching every single line of code and you'd better fully understand what each one does, what could go wrong in the wild, how the approach taken compares to best practices, and how an attacker might go about trying to exploit what you've authored. Anything less is negligence on your part.
- gtowey 9mo agoYou kitchen contractor will never cook in your kitchen. If you leave the decisions to them, you'll get something that's quick and easy to build, but it for sure won't have all the details that make a great kitchen. It will be average. Which seems like an apt analogy for software. I see people all the time who build systems and they don't care about the details. The results are always mediocre.
- AstroBen 9mo agoDo all details matter equally? Maybe only 3/10 of them you really care about and you can leave the rest up to the contractor
- sehansen 9mo agoThat still requires you to evaluate all the details in order to figure out which you care about. And if you haven't built a kitchen before you, won't know what the details even are ahead of time. Which means you need to be involved in the process, constantly evaluating whether what is currently happening and if you need to care about it.
- libraryofbabel 9mo agoThis rings true and reminds me of the classic blog post “Reality Has A Surprising Amount Of Detail”[0] that occasionally gets reposted here. Going back and forth on the detail in requirements and mapping it to the details of technical implementation (and then dealing with the endless emergent details of actually running the thing in production on real hardware on the real internet with real messy users actually using it) is 90% of what’s hard about professional software engineering. It’s also what separates professional engineering from things like the toy leetcode problems on a whiteboard that many of us love to hate. Those are hard in a different way, but LLMs can do them on their own better than humans now. Not so for the other stuff. [0] http://johnsalvatier.org/blog/2017/reality-has-a-surprising-amount-of-detail http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...
- fragmede 9mo agoCan you give an example of an "other stuff"?
- christophilus 9mo agoI once wrote software that had to manage the traffic coming into a major shipping terminal- OCR, gate arms, signage, cameras for inspecting chassis and containers, SIP audio comms, RFID readers, all of which needed to be reasoned about in a state machine, none of which were reliable. It required a lot of on the ground testing and observation and tweaking along with human interventions when things went wrong. I’d guess LLMs would have been good at subsets of that project, but the entire thing would still require a team of humans to build again today.
- corysama 9mo ago“Writing is nature's way of letting you know how sloppy your thinking is.” — Richard Guindon This is certainly true of writing software. That said, I am assuredly enjoying trying out artificial writing and research assistants.
- TeMPOraL 9mo agoCounterpoint: perhaps it's not about escaping all the details, just the irrelevant ones, and the need to have them figured out up front. Making the process more iterative, an exploration of medium under supervision or assistance of domain expert, turns it more into a journey of creation and discovery, in which you learn what you need (and learn what you need to learn) just-in-time. I see no reason why this wouldn't be achievable. Having lived most of my life in the land of details, country of software development, I'm acutely aware 90% of effort goes into giving precise answers to irrelevant questions. In almost all problems I've worked on, whether at tactical or strategic scale, there's either a single family of answers, or a broad class of different ones. However, no programming language supports the notion of "just do the usual" or "I don't care, pick whatever, we can revisit the topic once the choice matters". Either way, I'm forced to pick and spell out a concrete answer myself, by hand. Fortunately, LLMs are slowly starting to help with that.
- mkleczek 9mo agoFrom my experience the issue really is, unfortunately, that it is impossible to tell if a particular detail is irrelevant until after you have analyzed and answered all of them. In other words, it all looks easy in hindsight only.
- cyber_kinetist 9mo agoI think the the most coveted ability of a skilled senior developer, is precisely this "uncanny" ability to predict beforehand if some particular detail is important or irrelevant. This ability can only be obtained through years of experience and hubris.
- FridgeSeal 9mo agoWoah woah woah, that sounds like a skill set we might have to _pay_ someone for??? Can’t we just prompt the model to do that??
- mathgeek 9mo ago
- kvirani 9mo agoYou write so well that I'm convinced by your words, even if you are wrong. Do you write professionally?
- onenite 9mo agomanifest-driven development.
- bitwize 9mo agoJust put the intention out there in the universe and the universe will answer!
- threethirtytwo 9mo agoThe 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 either direction. Speech recognition was a joke for half a century until it wasn’t. Machine translation was mocked for decades until it quietly became infrastructure. Autopilot existed forever before it crossed the threshold where it actually mattered. Voice assistants were novelty toys until they weren’t. At the same time, some technologies still haven’t crossed the line. Full self driving. General robotics. Fusion. History does not point one way. It fans out. That is why invoking history as a veto is lazy. It is a crutch people reach for when it’s convenient. “This happened before, therefore that’s what’s happening now,” while conveniently ignoring that the opposite also happened many times. Either outcome is possible. History alone does not privilege the comforting one. If you want to argue seriously, you have to start with ground truth. What is happening now. What the trendlines look like. What follows if those trendlines continue. Output per developer is rising. Time from idea to implementation is collapsing. Junior and mid level work is disappearing first. Teams are shipping with fewer people. These are not hypotheticals. The slope matters more than anecdotes. The relevant question is not whether this resembles CASE tools. It’s what the world looks like if this curve runs for five more years. The conclusion is not subtle. The reason this argument keeps reappearing has little to do with tools and everything to do with identity. People do not merely program. They are programmers. “Software engineer” is a marker of intelligence, competence, and earned status. It is modern social rank. When that rank is threatened, the debate stops being about productivity and becomes about self preservation. Once identity is on the line, logic degrades fast. Humans are not wired to update beliefs when status is threatened. They are wired to defend narratives. Evidence is filtered. Uncertainty is inflated selectively. Weak counterexamples are treated as decisive. Strong signals are waved away as hype. Arguments that sound empirical are adopted because they function as armor. “This happened before” is appealing precisely because it avoids engaging with present reality. This is how self delusion works. People do not say “this scares me.” They say “it’s impossible.” They do not say “this threatens my role.” They say “the hard part is still understanding requirements.” They do not say “I don’t want this to be true.” They say “history proves it won’t happen.” Rationality becomes a costume worn by fear. Evolution optimized us for social survival, not for calmly accepting trendlines that imply loss of status. That psychology leaks straight into the title. Calling this a “recurring dream” is projection. For developers, this is not a dream. It is a nightmare. And nightmares are easier to cope with if you pretend they belong to someone else. Reframe the threat as another person’s delusion, then congratulate yourself for being clear eyed. But the delusion runs the other way. The people insisting nothing fundamental is changing are the ones trying to sleep through the alarm. The uncomfortable truth is that many people do not stand to benefit from this transition. Pretending otherwise does not make it false. Dismissing it as a dream does not make it disappear. If you want to engage honestly, you stop citing the past and start following the numbers. You accept where the trendlines lead, even when the destination is not one you want to visit.
- bodegajed 9mo agoWell said. This dream is probably for someone who have experienced the hardship, felt frustrated and gave up. Then see others who effortless did it, even felt fun for them. The manifestation of the dream feels like revenge to them.
- mattgreenrocks 9mo agoThis framing neatly explains the hubris of the influencer-wannabes on social media who have time to post endlessly about how AI is changing software dev forever while also having never shipped anything themselves. They want to be seen as competent without the pound of flesh that mastery entails. But AI doesn’t level one’s internal playing field.
- utopiah 9mo ago> the dream underneath this dream is about being able to manifest things into reality without having to get into the details. Yes, it has nothing to do with dev specifically, dev "just" happens to be how to do so while being text based, which is the medium of LLMs. What also "just" happens to be convenient is that dev is expensive, so if a new technology might help to make something possible and/or make it unexpensive, it's potentially a market. Now pesky details like actual implementation, who got time for that, it's just few more trillions away.
- bandrami 9mo agoIt's a cliché that the first 90% of a software project takes 90% of the time and the last 10% also takes 90% of the time, but it's cliché because it's true. So we've managed to invent a giant plausibility engine that automates the 90% of the process people enjoy leaving just the 90% that people universally hate.
- geon 9mo agoAnd since the developers who have to do the last 90 % were not involved in the first 90 %, they will have no clue how to do it.
- Jensson 9mo agoSo now the last 90% is the last 99%.
- bryanrasmussen 9mo ago>So we've managed to invent a giant plausibility engine that automates the 90% of the process people enjoy leaving just the 90% that people universally hate. OK, for me it is the last 10% that is of any interest whatsoever. And I think that has been the case with any developer I've ever worked with I consider to be a good developer. OK the first 90% can have spots of enjoyment, like a nice gentle Sunday drive stopping off at Dairy Queen, but it's not normally what one would call "interesting".
- bandrami 9mo agoSorry, I don't buy it. I'm an ops guy, and devs who say they like the integration stage mean they like making ops play a guessing game and clean up the mess they left us.
- Imustaskforhelp 9mo agoI am an AI hater (atleast in some of its current context precisely used for this) and you have worded some things I like to say in a manner I hadn't thought of and I agree with all you said and appreciate what you said man! Now, I do agree with you and this is why I feel like AI can be good at just prototyping or for internal use cases, want to try out something no idea, sure use it or I have a website which sucks and I can quickly spin up an alternative for person use case, go for it, maybe even publish it to web with open source. Take feedback from people if they give any and run with it. So in essense, prototyping's pretty cool. But whenever I wish to monetize or the idea of monetize, I feel like we can take some design ideas or experimentation and then just write them ourselves. My ideology is simple in that I don't want to pay for some service which was written by AI slop, I mean at that point, just share us the prompt. So at this point, just rewrite the code and actually learn what you are talking about (like I will give an example, I recently prototyped some simple firecracker ssh thing using gliderlabs/ssh golang package, I don't know how the AI code works, its just I built for my own use case, but If I wish to ever (someday) try to monetize it in any sense, rest assured I will try to learn how gliderlabs/ssh works to its core and build it all by my hands) TLDR: AI's good for prototyping but then once you got the idea/more ideas on top of it, try to rewrite it in your understanding because as others have said the AI code you won't understand and you would spend 99% time on that 1% which AI can't but at that point, why not just rewrite? Also if you rewrite, I feel like most people will be chill then buying even Anti AI people. Like sure, use AI for prototypes but give me code which I can verify and you wrote/ you understand to its core with 100% pinning of this fact. If you are really into software projects for sustainability, you are gonna anger a crowd for no reason & have nothing beneficial come out of it. So I think kind of everybody knows this but still AI gets to production because sustainability isn't the concern. This is the cause. sustainability just straight up isn't the concern. if you have VC's which want you to add 100's of features or want you to use AI or have AI integration or something (something I don't think every company should or their creators should be interested in unless necessary) and those VC's are in it only for 3-5 years who might want to dump you or enshitten you short term for their own gains. I can see why sustainability stops being a concern and we get to where we are. Or another group of people most interested are the startup entrepreneur hustle culture people who have a VC like culture as well where sustainability just doesn't matter I do hope that I am not blanket naming these groups because sure some might be exceptions but I am just sharing how the incentives aren't aligned and how they would likely end up using AI 90% slop and that's what we end up seeing in evidence for most companies. I do feel like we need to boost more companies who are in it for the long run/sustainable practices & people/indie businesses who are in it because they are passionate about some project (usually that happens when they face the problem themselves or curiosity in many cases), because we as consumers have an incentive stick as well. Hope some movement can spawn up which can capture this nuance because i am not anti AI completely but not exactly pro either
- cuteeaglet 9mo ago[dead]
- acron0 9mo agoTo put an economic spin on this (that no one asked for), this is also the capitalist nirvana. I don't have an immediate citation but from my experience software engineer salary is usually one of the biggest items on a P&L which prevents the capitalist approaching the singularity: limitless profit margin. Obviously this is unachievable but one of the major obstacles to this is in the process of being destablised and disrupted.
- cudgy 9mo agoin the most profitable / high margin software industry, what other major costs are there?
- mattgreenrocks 9mo agoSam Altman’s real job is pushing AI hopium on execs who will believe anything in pursuit of that nirvana.
- TheOtherHobbes 9mo agoWhich is hilarious, because AI is making it easier and easier to bring a good idea to market with much less external financing than usual. You can argue about security, reliability, and edge cases, but it's not as if human devs have a perfect record there. Or even a particularly good one. What are those execs bringing to the table, beyond entitlement and self-belief?
- mattgreenrocks 9mo ago> What are those execs bringing to the table, beyond entitlement and self-belief? The status quo, which always require an order of magnitude more effort to overcome. There's also a substantial portion of the population that needs well-defined power hierarchies to feel psychologically secure.
- michaelsalim 9mo agoFor me what supports this are things outside of software. If a company or regime wants to build something, they can't just say what they want and get exactly what they envision. If human minds can't figure out what other human wants, how could a computer do it?
- ninjagoo 9mo ago> In 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. Since the author was speaking to business folk, I would argue that their dream is cheaper labor, or really just managing a line item in the summary budget. As evidenced by outsourcing efforts. I don't think they really care about how it happens - whether it is manifesting things into reality without having to get into the details, or just a cheaper human. It seems to me that the corporate fever around AI is simply the prospect of a "cheaper than human" opportunity. Although, to your point, we must await AGI, or get very close to it, to be able to manifest things into reality without having to get into the details :-)
- njhnjh 9mo ago[dead]
- yoquan 9mo agoYes. On an analogy level you can also examine whether you are in a dream or in reality by looking exactly to such details :)
- bananaflag 9mo ago> 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. Of course you can. The way the manager ignores the details when they ask the developer to do something, the same way they can when they ask the machine to do it.
- sanderjd 9mo agoYeah this is a thought provoking framing. Maybe the way in which those of us who really enjoy programming are weird is that we relish meticulously figuring out those details.
- MarceliusK 9mo agoI don't think the recurring failure is that we haven't found the right abstraction yet. It's that abstraction is often mistaken for understanding
- yomismoaqui 9mo agoMy mantra as an engineer is "Devil is in the details". For 2 almost identical problems, having a little diference between them, the solutions can be radically different in complexity, price & time to deliver.
- brabel 9mo ago> Conversely, for the most successful companies the opposite is true. While I agree with this, I think that it’s important to acknowledge that even if you did everything well and thought of everything in detail, you can still fail for reasons that are outside of your control. For example, a big company buying from your competitor who didn’t do a better job than you simply because they were mates with the people making the decision… that influences everyone else and they start, with good reason, to choose your competitor just because it’s now the “standard” solution, which itself has value and changes the picture for potential buyers. In other words, being the best is not guarantee for success.
- dexdal 9mo agoThis matches what keeps repeating. Tools change where the work happens, but they don’t remove the need for controlled decisions about inputs, edge cases, and outcomes. When that workflow isn’t explicit, every new abstraction feels like noise.
- SftwrSvior81 9mo ago> The recurring dream of replacing developers > In 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. It's basically this: "I'm hungry. I want to eat." "Ok. What do you want?" "I don't know. Read my mind and give me the food I will love."
- taneq 9mo agoThis, 100%. Semicolons and curly brackets aren’t the hard part of developing software. The hard part is figuring out what you want in the first place.
- hintymad 9mo agoIt looks there's a difference this time: copying the details of other people's work has become exceedingly easy and reliable, at least for commonly tried use cases. Say I want to vibe code a dashboard, and AI codes it out. It works. In fact, it works so much better than I could ever build, because the AI was trained with the best dashboard code out there. Yes, I can't think of all the details of a world-class dashboard, but hey, someone else did and AI correctly responds to my prompt with those details. Such "copying" used to be really hard among humans. Without AI, I would have to learn so much first even if I can use the open-source code as the starting point: the APIs of the libraries, the basic concepts of web programming, and etc. Yet, the AI doesn't care. It's just a gigantic Bayesian machine that emits code that nearly probability 1 for common use cases. So it is not that details don't matter, but that now people can easily transfer certain know-how from other great minds. Unfortunately (or fortunately?), most people's jobs are learning and replicating know-hows from others.
- sublinear 9mo agoI don't think anyone's job is copying "know-how". Knowing how goes a lot deeper than writing the code. Especially in web, boilerplate/starters/generators that do exactly what you want with little to no code or familiarity has been the norm for at least a decade. This is the lifeblood of repos like npm. What we have is better search for all this code and documentation that was already freely available and ready to go.
- drcxd 9mo agoBut the dashboard is not important at all, because everyone can have the same dashboard the same way you have it. It's like you are generating a static website using Hugo and apply a theme provided on it. The end product you get is something built by a streamline. No taste, no soul, no effort. (Of course, the effort is behind the design and produce of the streamline, but not the product produced by the streamline.) Now, if you want to use the dashboard do something else really brilliant, it is good enough for means. Just make sure the dashboard is not the end.
- hintymad 9mo ago
- broast 9mo agoIt's essentially the same as an engineering lead writing a good jira ticket
- gonational 9mo agoThis is the most correct comment I've ever come across.