12 ms·

This March 2025 post from Aral Balkan stuck with me: https://mastodon.ar.al/@aral/114160190826192080 https://mastodon.ar.al/@aral/114160190826192080 "Coding i

• anonymous344 9mo ago
  yes, this is maybe it's my preference to jump directly to coding, instead of canva to draw the gui and stuff. i would not know what to draw because the involvemt is not so deep ...or something
• helloplanets 9mo ago
  And when programming with agentic tools, you need to actively push for the idea to not regress to the most obvious/average version. The amount of effort you need to expend on pushing the idea that deviates from the 'norm' (because it's novel), is actually comparable to the effort it takes to type something out by hand. Just two completely different types of effort. There's an upside to this sort of effort too, though. You actually need to make it crystal clear what your idea is and what it is not, because of the continuous pushback from the agentic programming tool. The moment you stop pushing back, is the moment the LLM rolls over your project and more than likely destroys what was unique about your thing in the first place.
  • fallous 9mo ago
    You just described the burden of outsourcing programming.
    • deleted 9mo ago
      [deleted]
    • tomrod 9mo ago
      100%! There is significant analogy between the two!
      • salawat 9mo ago
        There is a reason management types are drawn to it like flies to shit.
        • theshrike79 9mo ago
          Working with and communicating with offshored teams is a specific skill too. There are tips and tricks on how to manage them and not knowing them will bite you later on. Like the basic thing of never asking yes or no questions, because in some cultures saying "no" isn't a thing. They'll rather just default to yes and effectively lie than admit failure.
    • darkwater 9mo ago
      With the basic and enormous difference that the feedback loop is 100 or even 1000x faster. Which changes the type of game completely, although other issues will probably arise as we try this new path.
      • Terr_ 9mo ago
        That embeds an assumption that the outsourced human workers are incapable of thought, and experience/create zero feedback loops of their own. Frustrated rants about deliverables aside, I don't think that's the case.
• boredtofears 9mo ago
  I dunno, when you've made about 10,000 clay pots its kinda nice to skip to the end result, you're probably not going to learn a ton with clay pot #10,001. You can probably come up with some pretty interesting ideas for what you want the end result to look like from the onset. I find myself being able to reach for the things that my normal pragmatist code monkey self would consider out of scope - these are often not user facing things at all but things that absolutely improve code maintenance, scalability, testing/testability, or reduce side effects.
  • belZaah 9mo ago
    Depends on the problem. If the complexity of what you are solving is in the business logic or, generally low, you are absolutely right. Manually coding a signup flow #875 is not my idea of fun either. But if the complexity is in the implementation, it’s different. Doing complex cryptography, doing performance optimization or near-hardware stuff is just a different class of problems.
    • boredtofears 9mo ago
      In my experience AI is pretty good at performance optimizations as long as you know what to ask for. Can't speak to firmware code or complex cryptography but my hunch is if it's in it's training dataset and you know enough to guide it, it's generally pretty useful.
      • kranner 9mo ago
        > my hunch is if it's in it's training dataset and you know enough to guide it, it's generally pretty useful. Presumably humanity still has room to grow and not everything is already in the training set.
      • aleph_minus_one 9mo ago
        > In my experience AI is pretty good at performance optimizations as long as you know what to ask for. This rather tells that the kind of performance optimizations that you ask for are very "standard".
• CamperBob2 9mo ago
  Eloquent, moving, and more-or-less exactly what people said when cameras first hit the scene.
  • vermilingua 9mo ago
    Source?
    • CamperBob2 9mo ago
      Art history. It's how we ended up with Impressionism, for instance. People felt (wrongly) that traditional representational forms like portraiture were threatened by photography. Happily, instead of killing any existing genres, we got some interesting new ones.
  • AdieuToLogic 9mo ago
    > Eloquent, moving, and more-or-less exactly what people said when cameras first hit the scene. This is a non sequitur. Cameras have not replaced paintings, assuming this is the inference. Instead, they serve only to be an additional medium for the same concerns quoted: The process, which is an iterative one, is what leads you towards understanding what you actually want to make, whether you were aware of it or not at the beginning. Just as this is applicable to refining a software solution captured in code, just as a painter discards unsatisfactory paintings and tries again, so too is it when people say, "that picture didn't come out the way I like, let's take another one."
    • CamperBob2 9mo ago
      Cameras have not replaced paintings, assuming this is the inference. You wouldn't have known that, going by all the bellyaching and whining from the artists of the day. Guess what, they got over it. You will too.
      • kranner 9mo ago
        > Guess what, they got over it. You will too. Prediction is difficult, especially of the future.
• abhgh 9mo ago
  This is an amazing quote - thank you. This is also my argument for why I can't use LLMs for writing (proofreading is OK) - what I write is not produced as a side-effect of thinking through a problem, writing is how I think through a problem.
  • Cthulhu_ 9mo ago
    Counterpoint (more devil's advocate), I'd argue it's better than an LLM writes something (e.g. the solution or thinking through of a problem) than nothing at all. Counterpoint to my own counterpoint, will anyone actually (want to) read it? counterpoint to the third degree, to loop it back around, an LLM might and I'd even argue an LLM is better at reading and ingesting long text (I'm thinking architectural documentation etc) than humans are. Speaking for myself, I struggle to read attentively through e.g. a document, I quickly lose interest and scan read or just focus on what I need instead.
    • yurishimo 9mo ago
      I kinda saw this happen in realtime on reddit yesterday. Someone asked for advice on how to deal with a team that was in over their heads shipping slop. The crux of their question was fair, but they used a different LLM to translate their original thoughts from their native language into English. The prompt was "translate this to english for a reddit post" - nothing else. The LLM adding a bunch of extra formatting to add emphasis and structure to what might have originally been a bit of a ramble, but obviously human written. The comments absolutely lambasted this OP for being a hypocrite complaining about their team using AI, but then seeing little problem with posting what is obviously an AI generated question because the OP didn't deem their English skills good enough to ask the question directly. I'm not going to pass judgement on this scenario, but I did think the entire encounter was a "fun" anecdote in addition to your comments. Edit: wrods
      • vict7 9mo ago
        I saw the same post and was a bit saddened that all the comments seemed to be focused on the implied hypocrisy of the OP instead of addressing the original concern. As someone that’s a bit of a fence-sitter on the matter of AI, I feel that using it in the way that OP did is one of the less harmful or intrusive uses.
• oceanplexian 9mo ago
  Coding is not at all like working a lump of clay unless you’re still writing assembly. You’re taking a bunch of pre-built abstractions written by other people on top of what the computer is actually doing and plugging them together like LEGOs. The artificial syntax that you use to move the bricks around is the thing you call coding. The human element of discovery is still there if a robot stacks the bricks based on a different set of syntax (Natural Language), nothing about that precludes authenticity or the human element of creation.
  • satvikpendem 9mo ago
    Exactly, and that's why I find AI coding solving this well, because I find it tedious to put the bricks together for the umpteenth time when I can just have an AI do it (which I will of course verify the code when it's done, not advocating for vibe coding here). This actually leaves me with a lot more time to think, about what I want the UI to look like, how I'll market my software, and so on.
  • lsy 9mo ago
    I think the analogy to high level programming languages misunderstands the value of abstraction and notation. You can’t reason about the behavior of an English prompt because English is underspecified. The value of code is that it has a fairly strong semantic correlation to machine operations, and reasoning about high level code is equivalent to reasoning about machine code. That’s why even with all this advancement we continue to check in code to our repositories and leave the sloppy English in our chat history.
    • skydhash 9mo ago
      Yep. Any statement in python or others can be mapped to something that the machine will do. And it will be the same thing every single time (concurrency and race issue aside). There’s no english sentence that can be as clear. We’ve created formal notation to shorten writing. And computation is formal notation that is actually useful. Why write pages of specs when I could write a few lines of code?
• isolli 9mo ago
  This is very insightful, thanks. I had a similar thought regarding data science in particular. Writing those pandas expressions by hand during exploration means you get to know the data intimately. Getting AI to write them for you limits you to a superficial knowledge of said data (at least in my case).
• nielsbot 9mo ago
  While there is still a market for artisanal furniture, dishes and clothes most people buy mass-produced dishes, clothes and furniture. I wonder if software creation will be in a similar place. There still might be a small market for handmade software but the majority of it will be mass produced. (That is, by LLM or even software itself will mostly go away and people will get their work done via LLM instead of "apps")
  • pinkgolem 9mo ago
    I would argue the opposite.. What you get right now is mass replicated software, just another copy of sap/office/Spotify/whatever That software is not made individually for you, you get a copy like millions of other people and there is nearly no market anymore for individual software. Llms might change that, we have a bunch of internal apps now for small annoying things.. They all have there quirks, but are only accessible internally and make life a little bit easier for people working for us. Most of them are one shot llms things, throw away if you do not need it anymore or just one shoot again
    • Cthulhu_ 9mo ago
      The question is whether that's a good thing or not; software adages like "Not Invented Here" aren't going to go away. For personal tools / experiments it's probably fine, just like hacking together something in your spare time, but it can become a risk if you, others, or a business start to depend on it (just like spare time hacked tools). I'd argue that in most cases it's better to do some research and find out if a tool already exists, and if it isn't exactly how you want it... to get used to it, like one did with all other tools they used.
      • williamcotton 9mo ago
        > it can become a risk if you, others, or a business start to depend on it (just like spare time hacked tools). So that Excel spreadsheet that manages the entire sales funnel?
  • Cthulhu_ 9mo ago
• socalgal2 9mo ago
  To me it's all abstraction. I didn't write my own OS. I didn't write my own compiler. I didn't write the standard library. I just use them. I could write them but I'm happy to work on the new thing that uses what's already there. This is no different than many things. I could grow a tree and cut it into wood but I don't. I could buy wood and nails and brackets and make furniture but I don't. I instead just fill my house/apartment with stuff already made and still feel like it's mine. I made it. I decided what's in it. I didn't have to make it all from scratch. For me, lots of programming is the same. I just want to assemble the pieces > When you skip the process of creation you trade the thing you could have learned to make for the simulacrum of the thing you thought you wanted to make No, your favorite movie is not crap because the creators didn't grind their own lens. Popular and highly acclaimed games not at crap because they didn't write their own physics engine (Zelda uses Havok) or their own game engine (Plenty of great games use Unreal or Unity)
  • Krssst 9mo ago
    OS and compilers have a deterministic public interface. They obey a specification developers know, so you they can be relied on to write correct software that depends on them even without knowing the internal behavior. Generative AI does not have those properties.
    • refactor_master 9mo ago
      But the code you’re writing is guard railed by your oversight, the tests you decide on and the type checking. So whether you’re writing the spec code out by hand or ask an LLM to do it is besides the point if the code is considered a means to an end, which is what the post above yours was getting at.
      • skydhash 9mo ago
        Tests and type checking are often highway-wide guardrails when the path you want to take is like a tightrope. Also the code is not a means to an end. It’s going to be run somewhere doing stuff someone wants to do reliably and precisely. The overall goal was ever to invest some programmer time and salary in order to free more time for others. Not for everyone to start babysitting stuff.
• bodge5000 9mo ago
  "The muse visits during the act of creation, not before. Start alone." That has actually been a major problem for me in the past where my core idea is too simple, and I don't give "the muse" enough time to visit because it doesn't take me long enough to build it. Anytime I have given the muse time to visit, they always have.
• ibestvina 9mo ago
  This makes no sense to me. There are plenty of artists out there (e.g. El Anatsui), not to mention whole professions such as architects, who do not interact directly with what they are building, and yet can have profound relationship with the final product. Discovering the right problem to solve is not necessarily coupled to being "hands on" with the "materials you're shaping".
  • darepublic 9mo ago
    you think El Anatsui would concur that they didn't interact directly with what they were building? "hands on", "material you're shaping" is a metaphor
    • ibestvina 9mo ago
      I don't see why his involvement, explaining to his team how exactly to build a piece, is any different from a developer explaining to an LLM how to build a certain feature, when it comes to the level of "being hands on". Obviously I am not comparing his final product with my code, I am simply pointing out how this metaphor is flawed. Having "workers" shape the material according to your plans does not reduce your agency.
      • skydhash 9mo ago
        > I don't see why his involvement, explaining to his team how exactly to build a piece, is any different from a developer explaining to an LLM Because everyone under him knows that a mistake big enough is a quick way to unemployment or legal actions. So the whole team is pretty much aligned. A developer using an LLM may as well try to herd cats.
        • ibestvina 9mo ago
          First, that's quite a sad view of incentives structures. Second, you can't be serious in thinking that "worker worried they might be fired" puts the person in charge closer to the "materials" and more "hands on" with the project.
• darepublic 9mo ago
  Thanks for the quote, it definitely resonates. Distressing to see many people who can't relate to this, taking it literally and arguing that there is nothing lost the more removed they are from the process.
• Bengalilol 9mo ago
  I love Aral, he is so invested.
• Cuervo_ 9mo ago
  I personally have found success with an approach that's the inverse of how agents are being used generally. I don't allow my agent to write any code. I ask it for guidance on algorithms, and to supply the domain knowledge that I might be missing. When using it for game dev for example, I ask it to explain in general terms how to apply noise algorithms for procedural generation, how to do UV mapping etc, but the actual implementation in my language of choice is all by hand. Honestly, I think this is a sweet spot. The amount of time I save getting explanations of concepts that would otherwise get a bit of digging to get is huge, but I'm still entirely in control of my codebase.
  • shsksj 9mo ago
    Yep, this is the sweet spot. Though I still let it type code a lot - boilerplate stuff I’d be bored out of my mind typing. And I’ve found it has an extremely high success rate typing that code on top of its very easy for me to review that code. No friction at all. Granted this is often no larger than 100 lines or so (across various files). If it takes you more than a few seconds or so to understand code an agent generated you’re going to make mistakes. You should know exactly what it’s going to produce before it produces it.
• CraigJPerry 9mo ago
  >> Coding is like That description is NOT coding, coding is a subset of that. Coding comes once you know what you need to build, coding is the process of you expressing that in a programming language and as you do so you apply all your knowledge, experience and crucially your taste, to arrive at an implementation which does what's required (functionally and non-functionally) AND is open to the possibility of change in future. Someone else here wrote a great comment about this the other day and it was along the lines of if you take that week of work described in the GP's comment, and on the friday afternoon you delete all the code checked in. Coding is the part to recreate the check in, which would take a lot less than a week! All the other time was spent turning you into the developer who could understand why to write that code in the first place. These tools do not allow you to skip the process of creation. They allow you to skip aspects of coding - if you choose to, they can also elide your tastes but that's not a requirement of using them, they do respond well to examples of code and other directions to guide them in your tastes. The functional and non-functional parts they're pretty good at without much steering now but i always steer for my tastes because, e.g. opus 4.5 defaults to a more verbose style than i care for.
  • pikzel 9mo ago
    It's all individual. That's like saying writing only happens when you know exactly the story to tell. I love open a blank project with a vague idea of what I want to do, and then just start exploring while I'm coding.
    • pixl97 9mo ago
      I'm sure some coding works this way, but I'd be surprised if it's more than a small percentage of it.
• moron4hire 9mo ago
  I have no idea who this guy is (I guess he's a fantasy novelist?) but this video came up in my YouTube feed recently and feels like it matches closely with the themes you're expressing. https://youtu.be/mb3uK-_QkOo?si=FK9YnawwxHLdfATv https://youtu.be/mb3uK-_QkOo?si=FK9YnawwxHLdfATv
• jstanley 9mo ago
  But you can move a layer up. Instead of pouring all of your efforts into making one single static object with no moving parts, you can simply specify the individual parts, have the machine make them for you, and pour your heart and soul into making a machine that is composed of thousands of parts, that you could never hope to make if you had to craft each one by hand from clay. We used to have a way to do this before LLMs, of course: we had companies that employed many people, so that the top level of the company could simply specify what they wanted, and the lower levels only had to focus on making individual parts. Even the person making an object from clay is (probably) not refining his own clay or making his own oven.
  • amelius 9mo ago
    Yes, but bad ingredients do not make a yummy pudding. Or, it's like trying to make a MacBook Pro by buying electronics boards from AliExpress and wiring them together.
    • jstanley 9mo ago
      I'd rather have a laptop made from AliExpress components than only have a single artisanal hand-crafted resistor.
      • deleted 9mo ago
        [deleted]
      • amelius 9mo ago
        Yes, the point is that only if you're willing to accept crappy results then you can use AI to build bigger things.
        • sdoering 9mo ago
          To me that seems like a spurious (maybe even false) dichotomy. You can have crappy results without AI. And you can have great results with AI. Your contrast is an either or, that - in the real world - does not exist. Take content written by AI, prompted by a human. A lot of it is slop and crap. And there will be more slop and crap with AI than before. But that was the case, when the medium changed from hand writen to printed books. And when paper and printing became cheap, we had slop like those 10 Cent Western or Romance novellas. We also still had Goethe, still had Kleist, still had Grass (sorry, very German centric here). We also have Inception vs. the latest sequel of any Marvel franchise. I have seen AI writen, but human prompted short stories, that made people well up and find ideas presented in a light not seen before. And I have seen AI generated stories that one wants to purge from my brain. It isn't the tool - it is the one yielding it. Question: Did photoshop kill photography? Because honestly, this AI discussion to me sounds very much like the discussion back then.
• leftbehinds 9mo ago
  reminds of arguments for - hosting a server vs running stuff in cloud - vps vs containers
• logicprog 9mo ago
  This is beautifully written, but as a point against agentic AI coding, I just don't really get it. It seems to assume that vibe coding or like whatever you call the Gas Town model of programming is the only option, but you don't have to do that. You don't have to specify upfront what you want and then never change or develop that as you go through the process of building it, and you don't have to accept whatever the AI gives you on the other end as final. You can explore the affordances of the technologies you're using, modify your design and vision for what you're building as you go; if anything, I've found AI coding mix far easier to change and evolve my direction because it can update all the various parts of the code that need to be updated when I want to change direction as well as keeping the tests and specification and documentation in sync, easily and quickly. You also don't need to take the final product as a given, a "simulacrum delivered from a vending machine": build, and then once you've gotten something working, look at it and decide that it's not really what you want, and then continue to iterate and change and develop it. Again, with AI coding, I've found this easier than ever because it's easier to iterate on things. The process is a bit faster for not having to move the text around and looking up API documentation myself, even though I'm directly dictating the architecture and organization and algorithms and even where code should go most of the time. And with the method I'm describing, where you're in the code just as much as the AI is, just using it to do the text/API/code munging, you can even let the affordances of not just the technologies, but the source code and programming language itself effect how you do this: if you care about the code quality and clarity and organization of the code that the AI is generating, you'll see when it's trying to brute force its way past technical limitations and instead redirect it to follow the grain. It just becomes easier and more fluid to do that. If anything, AI coding in general makes it easier to have a conversation with the machine and its affordances and your design vision and so on, then before because it becomes easier to update everything and move everything around as your ideas change. And nothing about it means that you need to be ignorant of what's going on; ostensibly you're reviewing literally every line of code it creates and deciding what libraries and languages as well as the architecture, organization and algorithms it's using. You are aren't you? So you should know everything you need to know. In fact, I've learned several libraries and a language just from watching it work, enough that I can work with them without looking anything up, even new syntax and constructs that would have been very unfamiliar prior on my manual coding days.
• koliber 9mo ago
  Sometimes you want an artistic vase that captures some essential element of beauty, culture, or emotion. Sometimes you want a utilitarian teapot to reliably pour a cup of tea. The materials and rough process for each can be very similar. One takes a master craftsman and a lot of time to make and costs a lot of money. The other can be made on a production line and the cost is tiny. Both have are desirable, for different people, for different purposes. With software, it's similar. A true master knows when to get it done quick and dirty and when to take the time to ponder and think.
  • bayindirh 9mo ago
    > Sometimes you want a utilitarian teapot to reliably pour a cup of tea. If you pardon the analogy, watch how Japanese make a utilitarian teapot which reliably pours a cup of tea. It's more complicated and skill-intensive than it looks. In both realms, making an artistic vase can be simpler than a simple utilitarian tool. AI is good at making (poor quality, arguably) artistic vases via its stochastic output, not highly refined, reliable tools. Tolerances on these are tighter.
    • koliber 9mo ago
      There is a whole range of variants in between those two "artistic vs utilitarian" points. Additionally, there is a ton of variance around "artistic" vs "utilitarian". Artisans in Japan might go to incredible lengths to create utilitarian teapots. Artisans who graduated last week from a 4-week pottery workshop will produce a different kind quality, albeit artisan. $5.00 teapots from an East Asian mass production factory will be very different than high quality mass-produced upmarket teapots at a higher price. I have things in my house that fall into each of those categories (not all teapots, but different kinds of wares). Sometimes commercial manufacturing produces worse tolerances than hand-crafting. Sometimes, commercial manufacturing is the only way to get humanly unachievable tolerances. You can't simplify it into "always" and "never" absolutes. Artisan is not always nicer than commercial. Commercial is not always cheaper than artisan. _____ is not always _____ than ____. If we bring it back to AI, I've seen it produce crap, and I've also seen it produce code that honestly impressed me (my opinion is based on 24 years of coding and engineering management experience). I am reluctant to make a call where it falls on that axis that we've sketched out in this message thread.
• spacecadet 9mo ago
  This is cute, but this is true for ALL activities in life. I have to constantly remind my brother that his job is not unique and if he took a few moments, he might realize, flipping burgers is also molding lumps of clay. I think the biggest beef I have with Engineers is that for decades they more or less reduced the value of other lumps of clay and now want to throw up arms when its theirs.
• raw_anon_1111 9mo ago
  In 30 years across 10 jobs, the companies I’ve worked for have not paid me to “code”. They’ve paid me to use my experience to add more business value than the total cost of employing me. I’m no less proud of what I built in the last three weeks using three terminal sessions - one with codex, one with Claude, and one testing everything from carefully designed specs - than I was when I first booted a computer, did “call -151” to get to the assembly language prompt on my Apple //e in 1986. The goal then was to see my ideas come to life. The goal now is to keep my customers happy, get projects done on time, on budget and meets requirements and continue to have my employer put cash in my account twice a month - and formerly put AMZN stock in my brokerage account at vesting.
• resters 9mo ago
  It's very similar now, you have to surf a swell of selective ignorance that is (feels?) less reliable than the ignorance that one adopts when using a dependency one hasn't read and understood the source code for. One must be conversant in abstractions that are themselves ephemeral and half hallucinated. It's a question of what to cling to, what to elevate beyond possible hallucinated rubbish. At some level it's a much faster version of the meastspace process and it can be extermely emotionally uncomfortable and anarchic to many.
• jatora 9mo ago
  Yeah? And then you continue prompting and developing, and go through a very similar iterative process, except now it's faster and you get to tackle more abstract, higher level problems. "Most developers don't know the assembly code of what they're creating. When you skip assembly you trade the very thing you could have learned to fully understand the application you were trying to make. The end result is a sad simulacrum of the memory efficiency you could have had." This level of purity-testing is shallow and boring.
  • wtetzner 9mo ago
    I don't think this comparison holds up. With a higher-level language, the material you're building with is a formal description of the software, which can be fed back into a compiler to get a deterministic outcome. With an LLM, you put in a high-level description, and then check in the "machine code" (generated code).
• anymouse123456 9mo ago
  Having a background in fine art (and also knew Aral many years ago!), this prose resonates heavily with me. Most of the OP article also resonated with me as I bounce back and forth between learning (consuming, thinking, pulling, integrating new information) to building (creating, planning, doing) every few weeks or months. I find that when I'm feeling distressed or unhappy, I've lingered in one mode or the other a little too long. Unlike the OP, I haven't found these modes to be disrupted by AI at all, in fact it feels like AI is supporting both in ways that I find exhilarating. I'm not sure OP is missing anything because of AI per se, it might just be that they are ready to move their focus to broader or different problem domains that are separate from typing code into an IDE? For me, AI has allowed me to probe into areas that I would have shied away from in the past. I feel like I'm being pulled upward into domains that were previously inaccessible. I use Claude on a daily basis, but still find myself frequently hand-writing code as Claude just doesn't deliver the same results when creating out of whole cloth. Claude does tend to make my coarse implementations tighter and more robust. I admittedly did make the transition from software only to robotics ~6 years ago, so the breadth of my ignorance is still quite thrilling.
• dwaite 9mo ago
  Supposedly when Michelangelo was asked about how he created the statue of David, he said "I just chipped away everything that wasn’t David.” Your work is influenced by the medium by which you work. I used to be able to tell very quickly if a website was developed in Ruby on Rails, because some approaches to solve a problem are easy and some contain dragons. If you are coding in clay, the problem is getting turned into a problem solvable in clay. The challenge if you are directing others (people or agents) to do the work is that you don't know if they are taking into account the properties of the clay. That may be the difference between clean code - and something which barely works and is unmaintainable. I'd say in both cases of delegation, you are responsible for making sure the work is done correctly. And, in both cases, if you do not have personal experiences in the medium you may not be prepared to judge the work.
• nindalf 9mo ago
  For me it’s a related but different worry. If I’m no longer thinking deeply, then maybe my thinking skills will simply atrophy and die. Then when I really need it, I won’t have it. I’ll be reduced to yanking the lever on the AI slot machine, hoping it comes up with something that’s good enough. But at that point, will I even have the ability to distinguish a good solution from a bad one? How would I know, if I’ve been relying on AI to evaluate if ideas are good or not? I’d just be pushing mediocre solutions off as my own, without even realising that they’re mediocre.
• tcgv 9mo ago
  I get what he's pointing at: building teaches you things the spec can't, and iteration often reveals the real problem. That said, the framing feels a bit too poetic for engineering. Software isn't only craft, it's also operations, risk, time, budget, compliance, incident response, and maintenance by people who weren't in the room for the "lump of clay" moment. Those constraints don't make the work less human; they just mean "authentic creation" isn't the goal by itself. For me the takeaway is: pursue excellence, but treat learning as a means to reliability and outcomes. Tools (including LLMs) are fine with guardrails, clear constraints up front and rigorous review/testing after, so we ship systems we can reason about, operate, and evolve (not just artefacts that feel handcrafted).
  • rsyring 9mo ago
    > That said, the framing feels a bit too poetic for engineering. I wholeheartedly disagree but I tend to believe that's going to be highly dependent on what type of developer a person is. One who leans towards the craftsmanship side or one who leans towards the deliverables side. It will also be impacted by the type of development they are exposed to. Are they in an environment where they can even have a "lump of clay" moment or is all their time spent on systems that are too old/archaic/complex/whatever to ever really absorb the essence of the problem the code is addressing? The OP's quote is exactly how I feel about software. I often don't know exactly what I'm going to build. I start with a general idea and it morphs towards excellence by the iteration. My idea changes, and is sharpened, as it repeatedly runs into reality. And by that I mean, it's sharpened as I write and refactor the code. I personally don't have the same ability to do that with code review because the amount of time I spend reviewing/absorbing the solution isn't sufficient to really get to know the problem space or the code.
• giancarlostoro 9mo ago
  The best analogy I think is, if you just take Stack Overflow code solutions, smoosh over your code and hit compile / build, and move on without ever looking at "why it works" you're really not using your skills to the best of your ability, and it could introduce bugs you didn't expect, or completely unnecessary dependencies. With Stack Overflow you can have other people pointing out the issues with the accepted answer and giving you better options.
  • sodapopcan 9mo ago
    This keeps coming up again and again and again, but like how many times were you able to copy paste SO solution wholesale and just have it work? Other than for THE most simple cases (usually CSS) there would always have to be some understanding involved. Of course you don't always learn deeply every time, but the whole "copy paste off of stackoverflow" was always an exaggeration that is being used in seeming earnest.
• 4er_transform 9mo ago
  Honestly this sounds like a Luddite mindset (and I mean that descriptively, not to be insulting). This mindset holds us back. You can imagine the artisans who made shirts saying the exact same thing as the first textile factories became operational. Humans have been coders in the sense we mean for a matter of decades at most - a blip in our existence. We’re capable of far more, and this is yet another task we should cast into the machine of automation and let physical laws do the work for us. We’re capable of manipulating the universe into doing our bidding, including making rocks we’ve converted into silicones think on our behalf. Making shirts and making code: we’re capable of so much more.
• steveBK123 9mo ago
  > Being handed a baked and glazed artefact that approximates what you thought you wanted to make Isn't this also an overstatement, and the problem is worse. That is - the code being handed back is a great prototype, needs polishing/finishing, and is ignorant of obvious implicit edge cases unless you explicitly innumerate all of them in your prompts?? For me, the state of things reminds me of a bad job I had years ago. Worked with a well-regarded long tenured but truculent senior engineer who was immune to feedback due to his seniority. He committed code that either didn't run, didn't past tests, or implemented only the most obvious happy path robotically literal interpretation of requirements. He was however, very very fast... underbidding teammates on time estimates by 10x. He would hand back the broken prototype and we'd then spend the 10x time making his code actually something you can run in production. Management kept pushing this because he had a great reputation, promised great things, and every once in a while did actually deliver stuff fast. It took years for management to come around to the fact that this was not working.
• dekhn 9mo ago
  That quote sounds like special pleading for artisans.
• sanderjd 9mo ago
  I relate to this. But also, isn't it just that every human endeavor goes through an evolution from craft to commodity, which is sad for the craftsmen but good for everyone else, and that we happen to be the ones living through that for software? For instance, I think about the pervasive interstate overpass bridge. There was a time long ago when building bridges was a craft. But now I see like ten of these bridges every day, each of which is better - in the sense of how much load they can support and durability and reliability - than the best that those craftsmen of yore could make. This doesn't mean I'm in any way immune to nostalgia. But I try to keep perspective, that things can be both sad and ultimately good.
  • convolvatron 9mo ago
    there is a presumption that the models we are using today are 'good enough'. by models I mean thinks like linkers and package managers, micro services and cluster management tools. I personally think that we're not done evolving really, and to call it quits today would leave alot of efficiency and productivity on the table
  • wtetzner 9mo ago
    If you're only building things that have been built before, then sure, though I'd argue we already had solutions for that before LLMs.
• deleted 9mo ago
  [deleted]
• 7402 9mo ago
  "... software is not a product, but rather a medium for the storage of knowledge" Phillip G. Armour The Five Orders of Ignorance https://www.researchgate.net/publication/27293624_The_Five_Orders_of_Ignorance https://www.researchgate.net/publication/27293624_The_Five_O...