Discussion summary

Discussions centered around the relevance of AI and work distinctions, with some criticizing the use of certain terminology and others defending the value of AI-related articles.

What the discussion says

  • Some believe the distinction between use-cases is still relevant.
  • Critics argue some commentators are not worth engaging with.
  • Others see value in AI articles despite occasional irrelevance.
It could be that this person has something profound to say, but ... it's about AI.
wodenokoto
Some commentators are unknown for good reason, or otherwise not worth the effort.
SideburnsOfDoom

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • Does this read a bit incoherent and hard to follow for anyone else? This pluralistic website itself seems a bit chaotic..
    by rzz3
  • Yes, the way the URLs are interspersed between short passages makes reading it difficult. It's like reading an article on a news site without an adblocker.
  • When one cannot determine right or wrong its easy to ride the fence and try to please everyone and rationalize motivations and outcomes.

    If vibe code is not production code than you are just "reading" your fathers playboy magazines "for the articles" and creating tech debt you or nobody else can maintain.

    If you read between the lines there I think vibe coding is a very "generous gesture" towards the folks "doing this"

    Also the article bugs me referring to programming paradigms like visual basic as "equivalent to" vibe coding. That is factually incorrect and should be stricken from the record.

  • > the capital was raised for AI requires that it produce as many reverse centaurs as possible, because the only way to recoup the farcical sums associated with AI production is to fire millions of workers and replace them

    I'm not sure that this is the only way, just the way that selfish, sloppy, or impatient actors within business often work. If more wealth is created, more efficiencies found, more problems fixed, new jobs created, these would also bring the returns desired.

  • Corey laid out this line of thinking on a July 1 episode of the Galaxy Brain podcast. It was a good listen and I generally think he has some interesting points, but I also can't help but think that he does himself a disservice by having such a consistently negative bias toward AI and tech in general.

    Most of the time he comes off as an objective thinker, but those are really discounted by moments where his own dogma leads him down a path of making weakly supported points that seem like they come more from a place of anger.

  • He doesn't have a negative bias towards tech if you pay attention. He often talks about how he personally uses AI.

    He has a negative take on a lot of the business practices around AI and tech. While he is consistently harsh on that front, I don't find it to be weakly supported at all, especially when you realize his criticism is focused on business and implementation, not the tech.

  • > By canonization, I mean the process of taking a local, one-off formalization and turning it into library mathematics: general, reusable, coherent, efficient, and compatible with the rest

    I think this kind of work is constantly misunderstood and undervalued. I don't really see it as a binary thing, more like a complex skill that most people are terrible at, some are good at, and a handful of giants use to be just ridiculously productive in their field.

    It reminds me of hedgehogs and foxes - foxes tend to be bad at making one off progress on their own, but are critical for accretive work.

    Also I was reading a textbook the other day and thinking wow, it is absurd how much more valuable these things can be than other resources, and it's exactly because they canonize. It would be a massive loss if they stop getting written.

  • This article ended waaaay too abruptly. Reverse Centaurs and Canonization would seem to be orthogonal dynamics, and there was synthesis to be had between them.

    Centaur + no Canonization -> personal infrastructure, MVPs. probably ever-accruing tech debt, but the scale is limited so it probably doesn't matter

    Centaur + Canonization -> libre software, companies with empowered employees. The Canonization process is going to have some differences now that the goal now includes consumption by an LLM.

    Reverse Centaur + no Canonization -> Ever accruing tech debt, eventually leading to a situation where nobody understands how the "magic box" works and everyone is powerless to fix it when it breaks down (tech debt accrues to a level where an LLM can no longer achieve the desired results)

    Reverse Centaur + Canonization -> It's certainly possible to have an automated process that distills and compresses knowledge at one stage into a succinct representation that can be used down the line. The open question is whether a company could arrive at this with disempowered reverse centaurs, or whether they're doomed to the previous option

    Enumerating those 4 quadrants, I don't think I'm even doing a good job capturing where I had thought the article was going to go. But I'm having a hard time getting it back now.

  • AI makes it cheaper to create working fragments. It does not automatically make those fragments part of a maintainable system. In practice it may make the canonization step more important not less
  • Realistically speaking, most programs, no, 90% of them are terrible. Including mine. I write terrible code too, so I'm in no position to judge.

    The programs I've taken apart and looked at, even ones running in real industrial settings and large corporate factories, 90% of them are terrible.

    Most code is just 'Today's Task.' The people who deny this are probably those working at IT service companies, because they build around maintainability and scalability.

    But as you go down into hardware, there's an additional pressure: 'We don't know when this hardware will reach end-of-life.' The centaur metaphor is a simplified dichotomy. 'Centaur is good, reverse-centaur is bad.' But in reality, the vast majority of programs end up as disposable one-off code.

    These days, AI related articles just seem to amplify whatever values people want to believe, turning into tribal warfare posts. Realistically speaking, you can write maintainable code with AI too. In fact, the 'Canonization' mentioned in this post is essentially pattern-templating, which AI does better.

    The fundamental problem with AI code is that as the input prompt gets deeper, it introduces enterprise level complexity rather than the depth the program actually needs. I don't think that's the core issue here.

    The advantage of human written code is that it can be complex when it needs to be and simple when it doesn't, but AI code tries to apply the same level of complexity everywhere. Honestly, the most widely used things in the world are CRUD, and I don't think they require that much complexity.

    A good programmer applies the right level of complexity to the situation.

    Even human written code leaks abstractions depending on requirements.

    Take ORM as an example. Can you see the query count? Is there a rule to prevent N+1? Conditions like these keep getting added. It's just a matter of explicitly adding a layer to handle them.

    These days, I see a lot of AI articles filled with nostalgia about how things were different in the past, and it catches me off guard. I'm not sure if that's really how Western programming culture was, or if where I am, the vast majority of work has always been just 'get it done.'

    In my opinion, good programming is about choosing the right level of complexity based on the code's expected lifespan, likelihood of change, cost of failure, and transferability. I don't think everything needs to be maintainable.

  • Isn’t this a question of how much the “terrorised survivors” spend on tokens to make the output “canonised”?

    I think the main argument that the billions spent are not going to be recouped is accurate, but I strongly suspect the cost of producing high quality code will remain the same -just being produced faster (speed, cost, quality - you still only get to pick two)

    If one Steve Yegge can burn tokens in “Gas Town” that cost as much as me and ten others then you have saved my salary but spent it on Steve’s token use for roughly the same code quality as me steve and ten others would have produced in three months - just it took steve three days

    Same price, faster delivery. Is that a win ? I suspect that facebooks recent announcement (“we cannot think of enough things to do with software so who wants our GPUs?” Might suggest that it’s a business model problem more than a software probkem

  • Good analysis. Infact, there's collaboration cost in AI when it comes to quality, but a much smaller team can put out same quality things in a shorter time. As such it's same quality for cheaper, for sure.
  • I suspect "same price, three days instead of three months" is a very real win for plenty of businesses
  • There's a 'joke' that goes around occasionally that has some truth to it: "Excel is the world's most popular programming language." Occasionally it's 'Excel macros' or 'VBA' instead of just Excel.[1]

    The core truth of it is that a massive amount, possibly most, of the world's software is not a carefully hand-crafted application in that lives in Github written by expert software developers. It's a heap of Excel functions in an XSLX file, with no tests, no source control, no PRs, and no real planning behind it. And it works for that one specific task that the person who built it needed at the time.

    AI vibe-coding is probably filling in the middle-ground between that stuff and 'real' code - it does more than just building somehting to complete today's task, and it is accretive in the sense that someone can build on top of it, but it doesn't really look that way to someone used to working on 'proper' software.

    [1] Further reading if you're interested - https://news.ycombinator.com/item?id=27048672

  • I'll take that one step further and claim that Excel is the world's most popular VISUAL programming language.

    https://news.ycombinator.com/item?id=26668885

    >Spreadsheet certainly are visual programming languages: by any measure, by far one of the most common most widely used types of visual programming languages in the world.

  • > AI vibe-coding is probably filling in the middle-ground [..] and it is accretive in the sense that someone can build on top of it

    To me 'accretive work' means something you do at a lower level than your task at hand which by itself doesn't count progress, but rather lay the groundwork for it so it's compounding from there on. AI has nothing to do with this.

  • I cannot overstate just how much I love working on stuff in Excel and Google Sheets. It's the most popular programming language because it's incredibly intuitive to people at all levels of programming experience (especially the "none" level), it offers instant feedback, and in many cases, the results are trivially verifiable.

    It does have its flaws, that you've pointed out - there's no good way to write tests, I'm not aware of any good way to have any sort of source control, and modularity is basically non-existent.

    But, damn - if I have a bunch of data I need to go through and/or present, Sheets is usually my go-to. I genuinely love it when my spouse asks me to troubleshoot some Sheets stuff for her.

  • "There's plenty of space for "disposable and single use software." Sure, to a trained software engineer, this might be "bad code" but doing today's task has value, even if the code that performs that task isn't "accretive.""

    Grant me the serenity to accept the bad code i shouldn't fix, the courage to change the code I can, and the wisdom to know the difference.

  • We used to keep it in it's own separate thing: Microsoft Excel.
  • Part of why I like "tech debt" as a term. Much like actual financial debts, some tech debt has a low enough interest rate or is easy enough to declare bankruptcy on that it's not worth paying off.
  • >>> Grant me the serenity to accept the bad code i shouldn't fix, the courage to change the code I can, and the wisdom to know the difference.

    Fantastic

  • The real trick is recognizing when "disposable" code has quietly become infrastructure
  • That quote also resonated with me. It reminded me of "Perl, the write-only language"-meme of yore.

    And I think there is a place for perl, just like there is a place for bash one-liners.

    The authors example is personal software. The things we write to scratch our own little itches, that do not need to be shared or developed together with other people.

  • > Grant me the serenity to accept the bad code i shouldn't fix, the courage to change the code I can, and the wisdom to know the difference.

    Well, It's really early in the morning and I've got the quote of the day already

    by gota