5 ms·
There is a split between people who think of labor as an end in itself and people who think of a labor as a means of achieving some other end and people in the
by empath75 1y ago
There is a split between people who think of labor as an end in itself and people who think of a labor as a means of achieving some other end and people in the former category are going to always dislike any kind of automation.
Even though I've written a bunch of code, I don't really enjoy writing code. I enjoy building systems and solving problems. If I never have to write another line of code to do that, I couldn't be happier.
Other people have invested a lot of their time and their self image in becoming a good "computer programmer", and they are going to have a really hard time interacting with AI programmers or really any other kind of automation that removes the part of the job that they actually enjoy doing.
Really, it's not much difference between that and musicians that got mad at djs for just playing other people's music, who then got mad at djs that use ableton live instead of learning to beat match. Do you think the _process_ of making music is the important part, or the final sounds that are produced?
Just like DJ's and collage artists can be inventive and express ideas using work created by other people, people who use AI to code can still express creative ideas through how they use it and combine it and manipulate it.
- seadan83 1y ago> Do you think the _process_ of making music is the important part, or the final sounds that are produced? It is both, for different reasons. Not caring for the process is the path of the mid-wit.
- thoroughburro 1y agoUltimately, you’re arguing for generalism over specialism. Any specialist must be ignoring part of the larger process. “All specialists are midwits” is obviously false. Alternatively, even “most expert musicians are their own luthiers”… maybe more obviously false?
- seadan83 1y agoI'm interested for you to elaborate a bit more! I'd like to see more clearly the connection of my statements and the argument for generalist over specialist. Overall, I think I'm arguing that you cannot become an expert without continually improving the process; and to do that you need to continually understand and study the process at progressively deeper levels. If a person cares nothing for the process, just the outcome - they therefore cannot achieve mastery (I'm like 85% convinced this is true). If we assume a specialist is also an expert, then by definition specialists are not midwits - I agree. An expert musician I would suspect should know how the different qualities of the instrument they play affect the outcome. Whether they can actually construct an instrument is a different question, but they ought to know the differences. Can you also be an expert musician and not know, nor care about the differences in instrument construction quality and material? Can you be an expert on a piano and not know what makes for a good piano? I think the most exact analogy would be a musician who does not care about how an instrument is played - they don't study it, they don't care, just do something that makes for a nice sound, and that is all they desire. I don't think a person can achieve mastery in that manner, to achieve mastery - the 'how' does matter; the master should know everything about the different 'hows' and the trade-offs; and that is what makes them a master.
- jdefr89 1y agoThe issue is, though ChatGPT and the likes definitely speed up development in one respect, they create a bottleneck in various other places.. “vibe coders” have essentially no idea what the code their LLM cranked out even does and are unaware the code they generated is often riddled with bugs yet still looks plausible. Not only that, they are often trying to develop things, that for the most part you could have just googled. Of course an LlM can write your CRUD app to a pint but then try to add a novel aspect and you see it pretending to reason and make progress when in reality you’re just spinning your wheels. I do research at MIT, my day to day involves developing systems/solutions/technologies that did not previously exist. When the bulk of your work lies in novel things such as R&D the limits of LLMs become very apparent and they offer no further help. Every single day friends of mine ( many who aren’t programmers just wanna be CEOs of the next trend) tell me about these “project” of theirs. At the beginning it amazed them. They got a GUI up displaying some numbers up in Python with just a few queries! So cool! To them this probably looks like black magic. As the project grows to anything beyond the trivial, they cannot push it further along. They can’t look at the code themselves to fix the minor issue any human would immediately see because they have no clue/haven’t read the bulk of generated code (often trash quality riddled with vulnerabilities)… They often resort to trying a million different tools and platforms, spinning in circles, praying another model can fix their abomination… You get the idea. Sorry for poor grammar typing on small phone on bus.
- kubb 1y ago> When the bulk of your work lies in novel things such as R&D the limits of LLMs become very apparent and they offer no further help. Yes, but most people here do CRUD websites, so they’re extatic.
- tuckerman 1y agoI know they are very visible on Twitter and the like but how many people are truly "vibe coding" versus just being a SWE that uses an LLM to summarize documentation, scaffold some test cases, implement some tedious data transformations, and still implement the truly interesting bits on their own? I'm not sure how to actually figure that out but it would be very interesting to know. I know IRL none of the former but am myself/know plenty of engineers who are the latter. It very well could be I'm the one with the biased sample but my experience is that I only hear about vibe coding from "influencers" and articles/comments decrying it.
- asdff 1y agoThe main issue with AI I think is that it is exposing slop in the process people have handwaved away for some time. If the issue is you ask an AI for a prompt and it issues a function that doesn't work as expected, and this breaks your workflow, then the issue is your workflow. A junior dev or anyone else really could write a function that doesn't work as expected. Your workflow shouldn't go down to its knees in response, it should have tests and other debugging surrounding the putative function call to ensure that its output is as expected and it is not causing downstream issues in the stack. This is why a stack overflow copy paster and a gen ai cruch wielder are both the same kind of bad. Both don't understand the context of the code hence grasping for "please solve this for me someone/thing" tooling instead of the underlying documentation that explains every thing for someone with knowledge to apply. Both require the same care to either not hire or to disempower such that one stupid bug pushed on friday isn't going to bring down the stack on the weekend, that it can be reviewed by people with an understanding of what is happening.
- dmm 1y ago> Do you think the _process_ of making music is the important part, or the final sounds that are produced? Pharmaceuticals are regulated not just by testing the end product but by regulating the entire production process[1]. How this came to be has an interesting story but I believe that it's essentially the correct way to do things. Saying that process is irrelevant, that only the end product matters is a very persuasive idea but the problem comes when it's time to validate the end product. Any test you can perform on a black box can only show the presence or absence of a specific problem, never the absence of problems. “Program testing can be used to show the presence of bugs, but never to show their absence!” - Dijkstra [1] If you're interested in how this regulatory structure has failed to regulate international drug manufacturers, check out "Bottle of Lies" by Katherine Eban.