35 ms·

Code is cheap. Show me the talk

287 points by ghostfoxgod 8mo ago

pton_xd 8mo ago
Code, talk, who cares. Show me the product. If it works and is useful I will incorporate it into my life. Ultimately no one cares how the sausage is made.
- ares623 8mo ago
  Uhh I kinda care? And some people do too? People have given software social permission so far. I have a feeling that it’s about to change. Engineers are thinking too narrowly about the effects of LLM assisted coding. They only see the shiny bits that benefit them.
- lifetimerubyist 8mo ago
  > Ultimately no one cares how the sausage is made. Yeah...now that prompt injection is a fact of life and basically unsolvable - we can't really afford this luxury anymore.
  - deleted 8mo ago
    [deleted]
- habinero 8mo ago
  As for me, I'm looking forward to the Golden Age of Everyone Relearns Computer Security Is Important.
deleted 8mo ago
[deleted]
w10-1 8mo ago
It might be a mistake to think in terms of production costs. The real "cost" of software is reliance: what risk do your API clients or customers take in relying on you? This is just as true for free-as-in-beer software as for SaaS with enterprise SLA's. In software and in professions, providers have some combination of method and qualifications or authority which justifies reliance by their clients. Both education and software have reduced the reliance on naked authority, but a good track record remains the gold standard. So providers (individuals and companies) have to ask how much of their reputation do they want to risk on any new method (AI, agile, ...)? Initially, it's always a promising boost in productivity. But then... So the real question is what "Show me" means - for a quick meet, an enterprise sale, an enduring human-scale consumer dependence... So, prediction: AI companies and people that can "show me" will be the winners. (Unfortunately, we've also seen competitive advantage accrue to dystopian hiding of truth and risk, which would have the same transaction-positive effect but shift and defer the burden of risk. Let's hope...)
datatrashfire 8mo ago
premise is wrong. have seen a number of claude/codex disasters that never make it to production with clients, yet consumed an enormous amount of human time and bandwidth. expertise and effort is and will continue to be for the forseeable future essential. talk, like this, still cheap.
whatever1 8mo ago
If you have a solid test environment that would allow for an agent to check if it is right or wrong, I encourage you to do the experiment. Put the agent on the wheel and observe it as it tries ruthlessly to pass the test. These days, likely it will manage to pass the tests after 3-5 loops, which I find fascinating. Close the loop, and try an LLM. You will be surprised.
SLWW 8mo ago
I would like articles like this to have a quick "who" and "what experience" is talking. I can usually tell the conclusions based on experience/skill level regardless, but it would be nice. Also, that projects page on his website is atrocious; hate to be "that guy" but I don't trust the author's insight since "personal projects" seems to include a lot more than just his work; the first several PRs I looked at where all vibed. I'm not interested in re-implementations of the same wheel over and over again telling me and people who know how to write real software (have been doing it since I was 12) that we are becoming unnecessary bc you can bully an extremely complex machine built on a base theory of heuristics abstracted out endlessly (perceptually) to re-invent the same specs in slightly different flavors. > 100% human written, including emdashes. Sigh. If you can't write without emdashes, maybe you spend too much time with LLMs and not enough time reading and learning on your own. Also people can lie on the Internet, they do it all the time, and if not then I'm doing it right now. The hubris on display is fascinating.
overgard 8mo ago
I asked Codex to write some unit tests for Redux today. At first glance it looked fine, and I continued on. I then went back to add a test by hand, and after looking more closely at the output there were like 50 wtf worthy things scattered in there. Sure they ran, but it was bad in all sorts of ways. And this was just writing something very basic. This has been my experience almost every time I use AI: superficially it seems fine, once I go to extend the code I realize it's a disaster and I have to clean it up. The problem with "code is cheap" is that, it's not. GENERATING code is now cheap (while the LLMs are subsidized by endless VC dollars, anyway), but the cost of owning that code is not. Every line of code is a liability, and generating thousands of lines a day is like running up a few thousand dollars of debt on a credit card thinking you're getting free stuff and then being surprised when it gets declined.
- acedTrex 8mo ago
  I've always said every line is a liability, its our job to limit liabilities. That has largely gone out the window these days.
  - nomel 8mo ago
    The only people I've known that share this perspective are those that hate abstraction. Going back to their code, to extend it in some way, almost always requires a rewrite, because they wrote it with the goal of minimum viable complexity rather than understanding the realities of the real world problem they're solving, like "we all know we need these other features, but we have a deadline!" For one off, this is fine. For anything maintainable, that needs to survive the realities of time, this is truly terrible. Related, my friend works in a performance critical space. He can't use abstractions, because the direct, bare metal, "exact fit" implementation will perform best. They can't really add features, because it'll throw the timing of others things off to much, so usually have to re-architect. But, that's the reality of their problem space.
    - johnmwilkinson 8mo ago
      I believe this is conflating abstraction with encapsulation. The former is about semantic levels, the later about information hiding.
tikhonj 8mo ago
> crystal clear software development plan and the exact know-how to implement it This is simply not how expert programmers work. Programming is planning, and programming languages are surprisingly good planning tools. But, of course, becoming an expert is hard and requires not only some general aptitude but also substantial time, experience and effort. My theory is that this is a source of diverging views on LLMs for programming: people who see programming languages as tools for thought compared to people who see programming languages as, exclusively, tools to make computers do stuff. It's no surprise that the former would see more value in programming qua programming, while the latter are happy to sweep code under the rug. The fundamental problem, of course, is that anything worth doing in code is going to involve pinning down a massive amount of small details. Programming languages are formal systems with nice (well, somewhat nice) UX, and formal systems are great for, well, specifying details. Human text is not. Then again, while there might be a lot of details, there are also a lot of applications where the details barely matter. So why not let a black box make all the little decisions? The question boils down to where you want to spend more energy: developing and articulating a good conceptual model up-front, or debugging a messy system later on. And here, too, I've found programmers fall into two distinct camps, probably for the same reasons they differ in their views on LLMs. In principle, LLM capabilities could be reasonably well-suited to the up-front thinking-oriented programming paradigm. But, in practice, none of the tools or approaches popular today—certainly none of the ones I'm familiar with—are oriented in that direction. We have a real tooling gap.
- rrook 8mo ago
  > My theory is that this is a source of diverging views on LLMs for programming: people who see programming languages as tools for thought compared to people who see programming languages as, exclusively, tools to make computers do stuff. It's no surprise that the former would see more value in programming qua programming, while the latter are happy to sweep code under the rug. i'd postulate this: most people see llms as tools for thought. programmers also see llms as tools for programming. some programmers, right now, are getting very good at both, and are binding the two together.
  - jaredcwhite 8mo ago
pico303 8mo ago
Anyone who says with LLMs coding is over wasn’t that good at coding to begin with.
jaredcwhite 8mo ago
Just because a bunch of people tell you the practice of performing the art form of producing software via handwriting code is over doesn't mean it's over. This form of hyperbole is intended to overwhelm your reason, get you to forget your own expertise, and trick you into engaging with the topic in a fearful manner (literally FOMO). Don't fall for this cheap stunt.
- doug_durham 8mo ago
  There will always be a niche for any form of expression. However technologies change practice. It is your responsibility to be able to solve problems that balance performance, cost, schedule, and quality. Use the right tool for the job.
  - ares623 8mo ago
    One of the tools require constant use to justify its existence though.
jongjong 8mo ago
My perspective is that AI is a multiplier if existing skill (both positive and negative aspects). A bad developer can now produce bad code at 10x the rate and a good developer can produce good code at 10x the rate. There is a net positive gain on the automated testing side of things but I think a bad developer, even with AI will not be able to out-compete a good 10x developer without AI. The costs of incorrect abstractions is just too high and LLMs don't really help avoid those. You have to ask the right questions. It's a bit like in Hitchhiker's Guide to the Galaxy... Where a super-intelligent computer took millions of years to calculate the meaning of life as the number 42. The wrong question will always waste computation.
deleted 8mo ago
[deleted]
- funnyfoobar 8mo ago
  I have replied to a comment adjacent to yours, for my parent comment. Please check i think if you follow the "process", it is avoidable.
Sophira 8mo ago
Completely disagree that "software development, as it has been done for decades, is over". AI is a useful tool, agreed - but it will always be reliant upon humans writing code. Let's take a very simple example to prove my point. Let's say that everybody is now using AI to write code, and someone develops a new programming language with it. Cool! We have a new language now. What we don't have, however, are any examples of how that programming language is used. Nothing that the AI can learn from. How well do you think AI is going to handle being able to code in this new language which doesn't appear at all in its training data?
- draven 8mo ago
  I was thinking about this and wonder if a LLM trained exclusively on the language spec and API docs would be able to generate code in it?
dmitrygr 8mo ago
> One can no longer know whether such a repository was “vibe” coded by a non-technical person who has never written a single line of code, or an experienced developer, who may or may not have used LLM assistance Usually one can tell quite easily, actually...
galaxyLogic 8mo ago
"Smalltalk is cheap". Sorry, couldn't resist, this was my slogan decades ago when I was advocating Smalltalk.
bicepjai 8mo ago
I used to have the original quote as the first cell in my every Jupyter notebook. This is an amazing title for the current era.
athrowaway3z 8mo ago
> there is no universal measure of what makes a codebase good or great. We practically found one thought. The measure is: how well can an AI operate in/with your codebase. I regularly find myself wondering if skeptics throwing around their empirical failure are obscuring their bad code/docs/setup.
stego-tech 8mo ago
Finally, someone articulates the middle better than I have: > Thus, the extreme proponents of manic “agentic” vibe coding,[19] and the outright denouncers of LLMs, are both missing the forest for the trees. That there is a pragmatic middle path, where people who have the experience, expertise, competence, and the ability to articulate can use these tools to get the outcomes they desire with the right sets of trade-offs. LLMs are tools. They are not gods to replace man, nor are they exclusively means of harm. It is entirely possible to denounce the blatant attempt of rent extraction in the form of OpenAI, Google Gemini, Microsoft CoPilot, Anthropic, and others, while still running Qwen and Ministral and their like on local hardware. You can, in fact, have it “both ways”. As fun as it is to poke at cloud services to see their new features and advancements, I (in IT terms) personally could never recommend them in any serious enterprise context for the very reason that they’re fundamentally insecure; you will never, ever have full E2EE with these services because it would nullify their ability to evolve, improve, monetize, and exploit. That said? I can truly be a one dinosaur army in an enterprise now, as a generalist with a modest Mac Mini (or Studio) and a local LLM to fill in edge cases as needed. I can query these local tools for questions on database schemas or build a one-off API integration for me, so I can focus on the substance of work in safeguarding and accelerating the enterprise. I don’t need fleets of specialists unless I’m running a huge conglomerate or have specific needs - and even then, it’s going to be cheaper to retain one or two seniors to direct the larger army of generalists when needed. The landscape has changed, and it’s why I target leadership and management roles accordingly with my sales pitch (“One senior generalist can do the work of three mid-level specialists”). Don’t get me wrong, I still have immense grievances regarding theft of work, reductions in force, rent extraction, and the seeming attempt at destroying local general compute, but local LLMs as a tool have been in my kit for years, and that’s not going away.
toddmorrow 8mo ago
for a group of people as smart as developers, it sure took us long enough to realize billionaires were liquidating our code integrity to become trillionaires
hellolio 8mo ago
Ok imho this _blog’s_ words looks like stitching of some fancy words. Is this a thing for rich execs to write like this? Doesn't even convey the message easily.
ekidd 8mo ago
In January 2026, prototype code is cheap. Shitty production code is cheap. If that's all you need—which is sometimes the case—then go for it. But actually good code, with a consistent global model for what is going on, still won't come from Opus 4.5 or a Markdown plan. It still comes from a human fighting entropy. Getting eyes on the code still matters, whether it's plain old AI slop, or fancy new Opus 4.5 "premium slop." Opus is quite smart, and it does its best. But I've tried seriously using a number of high-profile, vibe-coded projects in the last few weeks. And good grief what unbelievable piles of shit most of them are. I spend 5% of the time using the vibe-coded tool, and 95% of the time trying to uncorrupt my data. I spend plenty of time having Opus try to look at the source to figure out what went wrong in 200,000 lines of vibe-coded Go. And even Opus is like, "This never worked! It's broken! You see, there's a race condition in the daemonization code that causes the daemon to auto-kill itself!" And at that point, I stop caring. If someone can't be bothered to even read the code Opus generates, I can't be bothered to debug their awful software.
giancarlostoro 8mo ago
AI was never the problem we have been having a downgrade in software in general AI just amplifies how badly you can build software. The real problem is people who just dont care about the craft just pushing out human slop, whether it be because the business goes “we can come back to that dont worry” or what have you. At least with AI me coming back to something is right here and right now, not never or when it causes a production grade issue.
rewilder12 8mo ago
The original phrase "talk is cheap" is generally used to mean "it's easy to say a whole lot of shit and that talk often has no real value." So this cleaver headline is telling me the code has even less value than the talk. That alone betrays a level of ignorance I would expect from the author's work. I go to read the article and it confirmed my suspicion.
- xnorswap 8mo ago
  It's directly an inversion of https://www.goodreads.com/quotes/437173-talk-is-cheap-show-me-the-code https://www.goodreads.com/quotes/437173-talk-is-cheap-show-m...
- joenot443 8mo ago
  Did you get very far in? They're referring to a pretty specific contextual usage of the phrase (Linus, back in 2000), not the adage as a whole.
  - wiseowise 8mo ago
    I read the whole thing, and GP is right. Code is important, whether it is generated or handwritten. At least until true AGI is here.
  - rewilder12 8mo ago
    I think I made it to about here haha > One can no longer know whether such a repository was “vibe” coded by a non-technical person who has never written a single line of code, or an experienced developer, who may or may not have used LLM assistance. I am talking about what it means to invert that phrase.
- quadrifoliate 8mo ago
  I think you are hyper-focusing on the headline, which is just a joke. The underlying article does not indicate to me that the author is ignorant of code, and if you care to look, they seem to have a substantial body of public open source contributions that proves this quite conclusively. The underlying point is just that while it was very cognitively expensive to back up a good design with good code back in 2000, it's much cheaper now. And therefore, making sure the design is good is the more important part. That's it really.
gipp 8mo ago
I see a lot of the same (well thought out) pushback on here whenever these kinds of blind hype articles pop up. But my biggest objection to this "engineering is over" take is one that I don't see much. Maybe this is just my Big Tech glasses, but I feel like for a large, mature product, if you break down the time and effort required to bring a change to production, the actual writing of code is like... ten, maybe twenty percent of it? Sure, you can bring "agents" to bear on other parts of the process to some degree or another. But their value to the design and specification process, or to live experiment, analysis, and iteration, is just dramatically less than in the coding process (which is already overstated). And that's without even getting into communication and coordination across the company, which is typically the real limiting factor, and in which heavy LLM usage almost exclusively makes things worse. Takes like this seem to just have a completely different understanding of what "software development" even means than I do, and I'm not sure how to reconcile it. To be clear, I think these tools absolutely have a place, and I use them where appropriate and often get value out of them. They're part of the field for good, no question. But this take that it's a replacement for engineering, rather than an engineering power tool, consistently feels like it's coming from a perspective that has never worked on supporting a real product with real users.
- jatins 8mo ago
  Did you read the article? Author is one of the more thoughtful and least hype guys you'll find when it comes to these things
- mupuff1234 8mo ago
  They're also great for writing design docs, which is another significant time sink for SWEs.
- techblueberry 8mo ago
  Yeah in a lot of ways, my assertion is that @ “Code is cheap” actually means the opposite of what everyone thinks it does. Software Engineer is even more about the practices we’ve been developing over the past 20 or so years, not less Like Linus’ observation still stands. Show me that the code you provided does exactly what you think it should. It’s easy to prompt a few lines into an LLM, it’s another thing to know exactly the way to safely and effectively change low level code. Liz Fong-Jones told a story on LinkedIn about this at HoneyComb, she got called out for dropping a bad set of PR’s in a repo, because she didn’t really think about the way the change was presented.
karmasimida 8mo ago
Regardless, knowing syntax of programming language or remember some library API, is a dead business.
- pmg101 8mo ago
  I for one am quite happy to outsource this kind of simply memorisation to a machine. Maybe it's the thin end of the slippery slope? It doesn't FEEL like it is but...
  - habinero 8mo ago
    Why even learn how to read when you can just yell at the computers?
negamax 8mo ago
I keep on wondering how much of the AI embrace is marketing driven. Yes, it can produce value and cut corners. But it seems like self driving by 2016 Musk prediction. Which never happened. With IPO/Stock valuations closely tied to hype, I wonder if we are all witnessing a giant bubble in the making How much of this is mass financial engineering than real value. Reading a lot of nudges how everyone should have Google or other AI stock in their portfolio/retirement accounts
- Cthulhu_ 8mo ago
  No need to wonder, just look at the numbers - investments versus revenue are hugely disparate, growth is plateauing.
- dbtablesorrows 8mo ago
  I realize many are disappointed (especially by technical churn, star-based-development JS projects on github without technical rigour). I don't trust any claim on the open web if I don't know the technical background of the person making it. However I think - Nadh, ronacher, the redis bro - these are people who can be trusted. I find Nadh's article (OP) quite balanced.
  - sjsizjhaha 8mo ago
    > ronacher I think he’s soured a bit on the 10x claim echoing many of the quality concerns expressed by others in this thread: https://lucumr.pocoo.org/2026/1/18/agent-psychosis/ https://lucumr.pocoo.org/2026/1/18/agent-psychosis/
  - Imustaskforhelp 8mo ago
    When you mention Redis bro, I think you are talking about Antirez correct?
    - dbtablesorrows 8mo ago
      yeah, forgot his name.
- 8mo ago
leecommamichael 8mo ago
> Ignoring outright bad code, in a world where functional code is so abundant that “good” and “bad” are indistinguishable, ultimately, what makes functional AI code slop or non-slop? I'm sorry, but this is an indicator for me that the author hasn't had a critical eye for quality in some time. There is massive overlap between "bad" and "functional." More than ever. The barrier-to-entry to programming got irresponsibly low for a time there, and it's going to get worse. The toolchains are not in a good way. Windows and macOS are degrading both in performance and usability, LLVM still takes 90% of a compiler's CPU time in unoptimized builds, Notepad has AI (and crashes,) simple social (mobile) apps are >300 MB download/installs when eight years ago they were hovering around a tenth of that, a site like Reddit only works on hardware which is only "cheap" in the top 3 GDP nations in the world... The list goes on. Whatever we're doing, it is not scaling.
- atomicnature 8mo ago
  This is the "artisanal clothing argument". I'd think there'll be a dip in code quality (compared to human) initially due to "AI machinery" due to its immaturity. But over-time on a mass-scale - we are going to see an improvement in the quality of software artifacts. It is easier to 'discipline' the top 5 AI agents in the planet - rather than try to get a million distributed devs ("artisans") to produce high quality results. It's like in the clothing or manufacturing industry I think. Artisans were able to produce better individual results than the average industry machinery, at least initially. But overtime - industry machinery could match the average artisan or even beat the average, while decisively beating in scale, speed, energy efficiency and so on.
  - noosphr 8mo ago
    The issue is that code isn't clothing. It's the clothing factory. We aren't artisans sewing clothing. We're production engineers deciding on layouts for robots to make clothes most efficiently. I see this type error of thinking all the time. Engineers don't make objects of type A, we make functions of type A -> B or higher order.
    - 8mo ago
wiseowise 8mo ago
>> Remember the old adage, “programming is 90% thinking and 10% typing”? It is now, for real. > Proceeds to write literal books of markdown to get something meaningful >> It requires no special training, no new language or framework to learn, and has practically no entry barriers—just good old critical thinking and foundational human skills, and competence to run the machinery. > Wrote a paragraph about how it is important to have serious experience to understand the generated code prior to that >> For the first time ever, good talk is exponentially more valuable than good code. The ramifications of this are significant and disruptive. This time, it is different. > This time is different bro I swear, just one more model, just one more scale-up, just one more trillion parameters, bro we’re basically at AGI
ctrlmeta 8mo ago
This "Code is cheap. Show me the talk." punchline gets overused as a bait these days. It is an alright article but that's a lot of words to tell us something we already know. There's nothing here that we don't already know. It's not just greedy companies riding the AI wave. Bloggers and influencers are also riding the AI wave. They know if you say anything positive or negative about AI with a catchy title it will trend on HN, Reddit, etc. Also credit where credit is due. Origin of this punchline: https://nitter.net/jason_young1231/status/1935180703416897895 https://nitter.net/jason_young1231/status/193518070341689789... https://programmerhumor.io/ai-memes/code-is-cheap-show-me-the-talk-wafz https://programmerhumor.io/ai-memes/code-is-cheap-show-me-th...
vb-8448 8mo ago
> Software development, as it has been done for decades, is over. I'm pretty sure the way I was doing things in 2005 was completely different compared to 2015. Same for 2015 and 2025. I'm not old enough to know how they were doing things in 1995, but I'm pretty sure there very different compared to 2005. For sure, we are going through some big changes, but there is no "as it has been done for decades".
- awesan 8mo ago
  I don't think things have changed that much in the time I've been doing it (roughly 20 years). Tools have evolved and new things were added but the core workflow of a developer has more or less stayed the same.
  - mobiuscog 8mo ago
    I don't think that's true, at least for everywhere I've worked. Agile has completely changed things, for better or for worse. Being a SWE today is nothing like 30 years ago, for me. I much preferred the earlier days as well, as it felt far more engineered and considered as opposed to much of the MVP 'productivity' of today.
    - lo_zamoyski 8mo ago
      MVP is not necessarily opposed to engineered and considered. It's just that many people who throw that term around have little regard for engineering, which they hide behind buzzwords like "agile".
  - seszett 8mo ago
    I also wonder what those people have been doing all this time... I also have been mostly working as a developer for about 20 years and I don't think much has changed at all. I also don't feel less productive or lacking in anything compared to the newer developers I know (including some LLM users) so I don't think I am obsolete either.
    - 8mo ago
dist-epoch 8mo ago
Long blog posts are cheap. Show me the prompt.
- lioeters 8mo ago
  Prompts are cheap. Show me the spark of consciousness that brings the whole thing to life, that which makes all of it worthwhile and meaningful.
dbtablesorrows 8mo ago
OK, fuck it, show me the demo (without staging it). show me the result.
ojr 8mo ago
talk is even cheaper, still show me the code, people claim 10x productivity that translates to 10x of work done in a month, even with Opus 4.5 out since November 2025 I haven't seen signs of this. AI makes the level of complexity with modern systems bearable, it was getting pretty bad before and AI kinda saved us. A non-trivial React app is still a pain to write. Also creating a harness for a non-deterministic api that AI provides is also pain. At least we don't have to fight through typing errors or search through relevant examples before copying and pasting. AI is good at automating typing, the lack of reasoning and the knowledge cutoff still makes coding very tedious though.
- program_whiz 8mo ago
  Best example of this is Claude's own terminal program. Apparently renders react at 60fps and then translates it into ANSI chars that then diff the content of the terminal and do an overwrite... All to basically mimic what curses can do very easily.
  - tokioyoyo 8mo ago
    This is the fun part of whole AI-built things that a lot of people don’t want to accept - it really, really, really does not matter if the code “nice, maintainable and etc.”. Does it work? Is it somewhat extendable with AI? Are users generally happy and adoption rate is high? That’s it.
    - chr15m 8mo ago
      If you have high time preference yes. Over longer time horizons I think the issues with vibe coded software will reveal themselves in the same way badly written software does.
    - esafak 8mo ago
      In this case, no, it does not work. CC is full of reported rendering issues, including some that affect me.
      - 8mo ago
v3ss0n 8mo ago
code is cheap, show me the prompt
Waterluvian 8mo ago
I think if your job is to assemble a segment of a car based on a spec using provided tools and pre-trained processes, it makes sense if you worry that giant robot arms might be installed to replace you. But if your job is to assemble a car in order to explore what modifications to make to the design, experiment with a single prototype, and determine how to program those robot arms, you’re probably not thinking about the risk of being automated. I know a lot of counter arguments are a form of, “but AI is automating that second class of job!” But I just really haven’t seen that at all. What I have seen is a misclassification of the former as the latter.
- mips_avatar 8mo ago
  Well a lot of managers view their employees as doing the former, but they’re really doing the latter
- HorizonXP 8mo ago
  This is actually a really good description of the situation. But I will say, as someone that prided myself on being the second one you described, I am becoming very concerned about how much of my work was misclassified. It does feel like a lot of work I did in the second class is being automated where maybe previously it overinflated my ego.
  - skydhash 8mo ago
    SWE is more like formula 1 where each race presents a unique combination of track, car, driver, conditions. You may have tools to build the thing, but designing the thing is the main issue. Code editor, linter, test runner, build tools are for building the thing. Understanding the requirements and the technical challenges is designing the thing.
    - Waterluvian 8mo ago
      The other day I said something along the lines of, "be interested in the class, not the instance" and I meant to try to articulate a sense of metaprogramming and metaanalysis of a problem. Y is causing Z and we should fix that. But if we stop and study the problem, we might discover that X causes the class of Y problem so we can fix the entire class, not just the instance. And perhaps W causes the class of X issue. I find my job more and more being about how far up this causality tree can I reason, how confident am I about my findings, and how far up does it make business sense to address right now, later, or ever?
keybored 8mo ago
Lots of words to say that “now” communicating in regular human language is important. What soft-skill buzzword will be the next one as the capital owners take more of the supposed productivity profits?
raincole 8mo ago
Talk is never cheap. Communicating your thoughts to people without the exact same kind of expertise as you is the most important skill. This quote is from Torvalds, and I'm quite sure that if he weren't able to write eloquent English no one would know Linux today. Code is important when it's the best medium to express the essence of your thoughts. Just like a composer cannot express the music in his head with English words.
- CuriouslyC 8mo ago
  You want a real mind bender? Imagine a universe where Linus's original usenet post didn't go viral.
- Imustaskforhelp 8mo ago
  I don't think Linus is a people person. This is something which he talks about himself in the famous ted-ed video. I just re-watched the video (currently halfway) & I feel like the point of Linux is something which you are forgetting but it was never intended to grow so much and Linux himself in the video when asked says that he never had a moment where he went like oh this went big. In fact he talks about when the project was little. On how he had gratitude when the project had 10 people maybe 100 people working on it and then things only grow over a very large time frame (more than 25-30years? maybe now 35 just searched 34) He talks about how he got other people's idea which he couldn't have thought of things themselves and when he first created the project he just wanted to show off to the world to look at what I did (and he did it mainly for both the end result of the project and programming itself too) and then he got introduced to open source (free software) by his friend and he just decided to have it open source. My point is it was neither the code nor the talk. Linus is the best person to maintain Linux, why? Because he has been passionate over it for 25 years. I feel like Linux would be just as interested in talking about the code and any improvements now with maybe the same vigour as 34 years ago. He loves his creation & we love Linux too :) Another small point I wish to add is that if talk was the only thing, then you are missing the point because Linux was created because hurd was getting delayed (so all talks no code) Linux himself says that if the hurd kernel would've been released earlier, Linux wouldn't have been created. So all talk no code Hurd project (which from what I hear right now is still a bit limbo as now everyone [rightfully?] uses linux) is what led to creation of linux project. Everyone who hasn't watched Linus's ted ed should definitely watch it. The Mind Behind Linux | Linus Torvalds | TED : https://www.youtube.com/watch?v=o8NPllzkFhE https://www.youtube.com/watch?v=o8NPllzkFhE
z0r 8mo ago
From the article: Historically, it would take a reasonably long period of consistent effort and many iterations of refinement for a good developer to produce 10,000 lines of quality code that not only delivered meaningful results, but was easily readable and maintainable. While the number of lines of code is not a measure of code quality—it is often the inverse—a codebase with good quality 10,000 lines of code indicated significant time, effort, focus, patience, expertise, and often, skills like project management that went into it. Human traits. Now, LLMs can not only one-shot generate that in seconds, Evidence please. Ascribing many qualities to LLM code that I haven't (personally) seen at that scale. I think if you want to get an 'easily readable and maintainable' codebase of 10k lines with an LLM you need somebody to review its contributions very closely, and it probably isn't going to be generated with a 1 shot prompt.
- sjsizjhaha 8mo ago
  It’s like the google claim. There was a years worth of work up front, but AI took the typing from a few days to a day.
Imustaskforhelp 8mo ago
Okay I was writing a comment to simon (and I have elaborated some there but I wanted this to be something catchy to show how I feel and something people might discuss with too) Both Code and talk are cheap. Show me the trust. Show me how I can trust you. Show me your authenticity. Show me your passion. Code used to be the sign of authenticity. This is whats changing. You can no longer guarantee that large amounts of code let's say are now authentic, something which previously used to be the case (for the most part) I have been shouting into the void many times about it but Trust seems to be the most important factor. Essentially, I am speaking it from a consumer perspective but suppose that you write AI generated code and deploy it. Suppose you talked to AI or around it. Now I can do the same too and create a project sometimes (mostly?) more customizable to my needs for free/very-cheap. So you have to justify why you are charging me. I do feel like that's only possible if there is something additional added to value. Trust, I trust the decision that you make and personally I trust people/decisions who feel like they take me or my ideas into account. So, essentially not ripping me off while actively helping. I don't know how to explain this but the most thing which I hate is the feeling of getting ripped off. So justifiable sustainable business who is open/transparent about the whole deal and what he gets and I get just gets my respect and my trust and quite frankly, I am not seeing many people do that but hopefully this changes. I am curious now what you guys of HN think about this & what trust means to you in this (new?) ever-changing world. Like y'know I feel like everything changes all the time but at the same time nothing changes at the same time too. We are still humans & we will always be humans & we are driven by our human instincts. Perhaps the community I envision is a more tight knit community online not complete mega-sellers. Thoughts?
deleted 8mo ago
[deleted]
api 8mo ago
Uhh... how about show me both? I think that's always been true. The ideas and reasoning process matter. So does the end product. If you produced it with an LLM and it sucks, it still sucks.
heliumtera 8mo ago
Please no. Talk is cheap. I hate this trend of using adjectives to describe systems. Fast Secure Sandboxed Minimal Reliable Robust Production grade AI ready Let's you _____ Enables you to _____ But somewhat I agree, code is essentially free, you can shit out infinite amounts of code. Unless it's good, then show the code instead. If your code is shit, show the program. If your program is shit, your code is worse, but you still pursing an interesting idea (in your eyes), show the prompt instead of the slop generated. Or even better communicate an elaborate version of the prompt. >One can no longer know whether such a repository was “vibe” This is absurd. Simply false, people can spot INSTANTLY when the code is good, see: https://news.ycombinator.com/item?id=46753708 https://news.ycombinator.com/item?id=46753708
bambax 8mo ago
> Code was always a means to an end. Unlike poetry or prose, end users don’t read or care about code. Yes and no. Code is not art, but software is art. What is art, then? Not something that's "beautiful", as beauty is of course mostly subjective. Not even something that works well. I think art is a thing that was made with great care. It doesn't matter if some piece of software was vibe-coded in part or in full, if it was edited, tested, retried enough times for its maker to consider it "perfect". Trash is something that's done in a careless way. If you truly love and use what you made, it's likely someone else will. If not, well... why would anyone?
- chrisvalleybay 8mo ago
  The best definition of art I've read is the one from "What is Art?" by Tolstoy. I haven't read it myself, but came across it in a Van Neistat video recently. Tolstoy argued that art is essentially the transmission of feeling from the artist to the audience. He claimed that when an artist experiences an emotion and then, through their work, evokes that same emotion in others, that is art.
- jll29 8mo ago
  Well, why do humans read code: 1. To maintain it (to refactor or extend it). 2. To test it. 3. To debug it (to detect and fix flaws in it). 4. To learn (to get better by absorbing how the pros do it). 5. To verify and improve it (code review, pair programming). 6. To grade it (because a student wrote it). 7. To enjoy its beauty. These are all I can think of right now, and they are ordered from most common to most rare case. Personally, I have certainly read and re-read SICP code to enjoy its beauty (7), perhaps mixed in with a desire to learn (4) how to write equally beautiful code.
- jdjeeee 8mo ago
  Art is expression. What the software provides (an experience) for which the artist (software engineer) expresses in code.
captain5123 8mo ago
> The real concern is for generations of learners who are being robbed of the opportunity to acquire the expertise to objectively discern what is slop and what is not. How do new developers build the skills that seniors generated through time? I see my seniors having higher success in vibe-coding than me. How can I short-circuit the time they put through for myself?
monster_truck 8mo ago
Feels like this website is yelling at me with its massive text size. Had to drop down to -50% to get it readable. Classical indicators of good software are still very relevant and valid! Building something substantial and material (ie not an api wrapper+gui, to-do list) that is undeniably well made, while being faster and easier than it used to be, still takes a _lot_ of work. Even though you don't have to write a line of code, it moves so fast that you are now spending 3.5-4 days of your work week reading code, using the project, running benchmarks and experimental test lanes, reviewing specs and plans, drafting specs, defining features and tests. The level of granularity needed to get earnestly good results is more than most people are used to. It's directly centered at the intersection between spec heavy engineering work and writing requirements for a large, high quality offshore dev team that is endearingly literal in how they interpret instructions. Depending on the work, I've found that I average around one 'task' per 22-35 lines of code. You'll discover a new sense of profound respect for the better PMs, QA Leads, Eng Directors you have worked with. Months of progress happen each week. You'll know you're doing it right when you ask an Agent to evaluate the work since last week and it assumes it is reviewing the output of a medium sized business and offers to make Jira tickets.
optymizer 8mo ago
> because one is hooked on and dependent on the genie, the natural circumstances that otherwise would allow for foundational and fundamental skills and understanding to develop, never arise, to the point of cognitive decline. After using AI to code, I came to the same conclusion myself. Interns and juniors are fully cooked: - Companies will replace them with AI, telling seniors to use AI instead of juniors - As a junior, AI is a click away, so why would you spend sleepless nights painstakingly acquiring those fundamentals? Their only hope is to use AI to accelerate their own _learning_, not their performance. Performance will come after the learning phase. If you're young, use AI as a personal TA, don't use it to write the code for you.
- furyofantares 8mo ago
  Young folks are gonna figure out how to use this stuff way better than us older folks. We just start with a big advantage.
- polytely 8mo ago
  as someone who is sort of a medior programmer it is very hard to balance, trying to keep up with the advancements in AI while not shooting myself in the foot by robbing myself of learning experiences
  - passivegains 8mo ago
    if it helps, that kind of thoughtfulness is how to learn the things that matter most. you're already on the right track.
deleted 8mo ago
[deleted]
MyHonestOpinon 8mo ago
My latest take on AI assisted coding is that AI tools are an amplifier of the developer. - A good and experienced developer who knows how to organize and structure systems will become more productive. - An inexperienced developer will also be able to produce more code but not necessarily systems that are maintainable. - A sloppy developer will produce more slop.

287 points by ghostfoxgod 8mo ago

Code, talk, who cares. Show me the product. If it works and is useful I will incorporate it into my life. Ultimately no one cares how the sausage is made.

ares623 8mo ago
Uhh I kinda care? And some people do too? People have given software social permission so far. I have a feeling that it’s about to change. Engineers are thinking too narrowly about the effects of LLM assisted coding. They only see the shiny bits that benefit them.
lifetimerubyist 8mo ago
> Ultimately no one cares how the sausage is made. Yeah...now that prompt injection is a fact of life and basically unsolvable - we can't really afford this luxury anymore.
- deleted 8mo ago
  [deleted]
habinero 8mo ago
As for me, I'm looking forward to the Golden Age of Everyone Relearns Computer Security Is Important.

deleted 8mo ago

[deleted]

w10-1 8mo ago

It might be a mistake to think in terms of production costs. The real "cost" of software is reliance: what risk do your API clients or customers take in relying on you? This is just as true for free-as-in-beer software as for SaaS with enterprise SLA's. In software and in professions, providers have some combination of method and qualifications or authority which justifies reliance by their clients. Both education and software have reduced the reliance on naked authority, but a good track record remains the gold standard. So providers (individuals and companies) have to ask how much of their reputation do they want to risk on any new method (AI, agile, ...)? Initially, it's always a promising boost in productivity. But then... So the real question is what "Show me" means - for a quick meet, an enterprise sale, an enduring human-scale consumer dependence... So, prediction: AI companies and people that can "show me" will be the winners. (Unfortunately, we've also seen competitive advantage accrue to dystopian hiding of truth and risk, which would have the same transaction-positive effect but shift and defer the burden of risk. Let's hope...)

datatrashfire 8mo ago

premise is wrong. have seen a number of claude/codex disasters that never make it to production with clients, yet consumed an enormous amount of human time and bandwidth. expertise and effort is and will continue to be for the forseeable future essential. talk, like this, still cheap.

whatever1 8mo ago

If you have a solid test environment that would allow for an agent to check if it is right or wrong, I encourage you to do the experiment. Put the agent on the wheel and observe it as it tries ruthlessly to pass the test. These days, likely it will manage to pass the tests after 3-5 loops, which I find fascinating. Close the loop, and try an LLM. You will be surprised.

SLWW 8mo ago

I would like articles like this to have a quick "who" and "what experience" is talking. I can usually tell the conclusions based on experience/skill level regardless, but it would be nice. Also, that projects page on his website is atrocious; hate to be "that guy" but I don't trust the author's insight since "personal projects" seems to include a lot more than just his work; the first several PRs I looked at where all vibed. I'm not interested in re-implementations of the same wheel over and over again telling me and people who know how to write real software (have been doing it since I was 12) that we are becoming unnecessary bc you can bully an extremely complex machine built on a base theory of heuristics abstracted out endlessly (perceptually) to re-invent the same specs in slightly different flavors. > 100% human written, including emdashes. Sigh. If you can't write without emdashes, maybe you spend too much time with LLMs and not enough time reading and learning on your own. Also people can lie on the Internet, they do it all the time, and if not then I'm doing it right now. The hubris on display is fascinating.

overgard 8mo ago

I asked Codex to write some unit tests for Redux today. At first glance it looked fine, and I continued on. I then went back to add a test by hand, and after looking more closely at the output there were like 50 wtf worthy things scattered in there. Sure they ran, but it was bad in all sorts of ways. And this was just writing something very basic. This has been my experience almost every time I use AI: superficially it seems fine, once I go to extend the code I realize it's a disaster and I have to clean it up. The problem with "code is cheap" is that, it's not. GENERATING code is now cheap (while the LLMs are subsidized by endless VC dollars, anyway), but the cost of owning that code is not. Every line of code is a liability, and generating thousands of lines a day is like running up a few thousand dollars of debt on a credit card thinking you're getting free stuff and then being surprised when it gets declined.

acedTrex 8mo ago
I've always said every line is a liability, its our job to limit liabilities. That has largely gone out the window these days.
- nomel 8mo ago
  The only people I've known that share this perspective are those that hate abstraction. Going back to their code, to extend it in some way, almost always requires a rewrite, because they wrote it with the goal of minimum viable complexity rather than understanding the realities of the real world problem they're solving, like "we all know we need these other features, but we have a deadline!" For one off, this is fine. For anything maintainable, that needs to survive the realities of time, this is truly terrible. Related, my friend works in a performance critical space. He can't use abstractions, because the direct, bare metal, "exact fit" implementation will perform best. They can't really add features, because it'll throw the timing of others things off to much, so usually have to re-architect. But, that's the reality of their problem space.
  - johnmwilkinson 8mo ago
    I believe this is conflating abstraction with encapsulation. The former is about semantic levels, the later about information hiding.

tikhonj 8mo ago

> crystal clear software development plan and the exact know-how to implement it This is simply not how expert programmers work. Programming is planning, and programming languages are surprisingly good planning tools. But, of course, becoming an expert is hard and requires not only some general aptitude but also substantial time, experience and effort. My theory is that this is a source of diverging views on LLMs for programming: people who see programming languages as tools for thought compared to people who see programming languages as, exclusively, tools to make computers do stuff. It's no surprise that the former would see more value in programming qua programming, while the latter are happy to sweep code under the rug. The fundamental problem, of course, is that anything worth doing in code is going to involve pinning down a massive amount of small details. Programming languages are formal systems with nice (well, somewhat nice) UX, and formal systems are great for, well, specifying details. Human text is not. Then again, while there might be a lot of details, there are also a lot of applications where the details barely matter. So why not let a black box make all the little decisions? The question boils down to where you want to spend more energy: developing and articulating a good conceptual model up-front, or debugging a messy system later on. And here, too, I've found programmers fall into two distinct camps, probably for the same reasons they differ in their views on LLMs. In principle, LLM capabilities could be reasonably well-suited to the up-front thinking-oriented programming paradigm. But, in practice, none of the tools or approaches popular today—certainly none of the ones I'm familiar with—are oriented in that direction. We have a real tooling gap.

rrook 8mo ago
> My theory is that this is a source of diverging views on LLMs for programming: people who see programming languages as tools for thought compared to people who see programming languages as, exclusively, tools to make computers do stuff. It's no surprise that the former would see more value in programming qua programming, while the latter are happy to sweep code under the rug. i'd postulate this: most people see llms as tools for thought. programmers also see llms as tools for programming. some programmers, right now, are getting very good at both, and are binding the two together.
- jaredcwhite 8mo ago

pico303 8mo ago

Anyone who says with LLMs coding is over wasn’t that good at coding to begin with.

jaredcwhite 8mo ago

Just because a bunch of people tell you the practice of performing the art form of producing software via handwriting code is over doesn't mean it's over. This form of hyperbole is intended to overwhelm your reason, get you to forget your own expertise, and trick you into engaging with the topic in a fearful manner (literally FOMO). Don't fall for this cheap stunt.

doug_durham 8mo ago
There will always be a niche for any form of expression. However technologies change practice. It is your responsibility to be able to solve problems that balance performance, cost, schedule, and quality. Use the right tool for the job.
- ares623 8mo ago
  One of the tools require constant use to justify its existence though.

jongjong 8mo ago

My perspective is that AI is a multiplier if existing skill (both positive and negative aspects). A bad developer can now produce bad code at 10x the rate and a good developer can produce good code at 10x the rate. There is a net positive gain on the automated testing side of things but I think a bad developer, even with AI will not be able to out-compete a good 10x developer without AI. The costs of incorrect abstractions is just too high and LLMs don't really help avoid those. You have to ask the right questions. It's a bit like in Hitchhiker's Guide to the Galaxy... Where a super-intelligent computer took millions of years to calculate the meaning of life as the number 42. The wrong question will always waste computation.

deleted 8mo ago

[deleted]

funnyfoobar 8mo ago
I have replied to a comment adjacent to yours, for my parent comment. Please check i think if you follow the "process", it is avoidable.

Sophira 8mo ago

Completely disagree that "software development, as it has been done for decades, is over". AI is a useful tool, agreed - but it will always be reliant upon humans writing code. Let's take a very simple example to prove my point. Let's say that everybody is now using AI to write code, and someone develops a new programming language with it. Cool! We have a new language now. What we don't have, however, are any examples of how that programming language is used. Nothing that the AI can learn from. How well do you think AI is going to handle being able to code in this new language which doesn't appear at all in its training data?

draven 8mo ago
I was thinking about this and wonder if a LLM trained exclusively on the language spec and API docs would be able to generate code in it?

dmitrygr 8mo ago

> One can no longer know whether such a repository was “vibe” coded by a non-technical person who has never written a single line of code, or an experienced developer, who may or may not have used LLM assistance Usually one can tell quite easily, actually...

galaxyLogic 8mo ago

"Smalltalk is cheap". Sorry, couldn't resist, this was my slogan decades ago when I was advocating Smalltalk.

bicepjai 8mo ago

I used to have the original quote as the first cell in my every Jupyter notebook. This is an amazing title for the current era.

athrowaway3z 8mo ago

> there is no universal measure of what makes a codebase good or great. We practically found one thought. The measure is: how well can an AI operate in/with your codebase. I regularly find myself wondering if skeptics throwing around their empirical failure are obscuring their bad code/docs/setup.

stego-tech 8mo ago

Finally, someone articulates the middle better than I have: > Thus, the extreme proponents of manic “agentic” vibe coding,[19] and the outright denouncers of LLMs, are both missing the forest for the trees. That there is a pragmatic middle path, where people who have the experience, expertise, competence, and the ability to articulate can use these tools to get the outcomes they desire with the right sets of trade-offs. LLMs are tools. They are not gods to replace man, nor are they exclusively means of harm. It is entirely possible to denounce the blatant attempt of rent extraction in the form of OpenAI, Google Gemini, Microsoft CoPilot, Anthropic, and others, while still running Qwen and Ministral and their like on local hardware. You can, in fact, have it “both ways”. As fun as it is to poke at cloud services to see their new features and advancements, I (in IT terms) personally could never recommend them in any serious enterprise context for the very reason that they’re fundamentally insecure; you will never, ever have full E2EE with these services because it would nullify their ability to evolve, improve, monetize, and exploit. That said? I can truly be a one dinosaur army in an enterprise now, as a generalist with a modest Mac Mini (or Studio) and a local LLM to fill in edge cases as needed. I can query these local tools for questions on database schemas or build a one-off API integration for me, so I can focus on the substance of work in safeguarding and accelerating the enterprise. I don’t need fleets of specialists unless I’m running a huge conglomerate or have specific needs - and even then, it’s going to be cheaper to retain one or two seniors to direct the larger army of generalists when needed. The landscape has changed, and it’s why I target leadership and management roles accordingly with my sales pitch (“One senior generalist can do the work of three mid-level specialists”). Don’t get me wrong, I still have immense grievances regarding theft of work, reductions in force, rent extraction, and the seeming attempt at destroying local general compute, but local LLMs as a tool have been in my kit for years, and that’s not going away.

toddmorrow 8mo ago

for a group of people as smart as developers, it sure took us long enough to realize billionaires were liquidating our code integrity to become trillionaires

hellolio 8mo ago

Ok imho this _blog’s_ words looks like stitching of some fancy words. Is this a thing for rich execs to write like this? Doesn't even convey the message easily.

ekidd 8mo ago

In January 2026, prototype code is cheap. Shitty production code is cheap. If that's all you need—which is sometimes the case—then go for it. But actually good code, with a consistent global model for what is going on, still won't come from Opus 4.5 or a Markdown plan. It still comes from a human fighting entropy. Getting eyes on the code still matters, whether it's plain old AI slop, or fancy new Opus 4.5 "premium slop." Opus is quite smart, and it does its best. But I've tried seriously using a number of high-profile, vibe-coded projects in the last few weeks. And good grief what unbelievable piles of shit most of them are. I spend 5% of the time using the vibe-coded tool, and 95% of the time trying to uncorrupt my data. I spend plenty of time having Opus try to look at the source to figure out what went wrong in 200,000 lines of vibe-coded Go. And even Opus is like, "This never worked! It's broken! You see, there's a race condition in the daemonization code that causes the daemon to auto-kill itself!" And at that point, I stop caring. If someone can't be bothered to even read the code Opus generates, I can't be bothered to debug their awful software.

giancarlostoro 8mo ago

AI was never the problem we have been having a downgrade in software in general AI just amplifies how badly you can build software. The real problem is people who just dont care about the craft just pushing out human slop, whether it be because the business goes “we can come back to that dont worry” or what have you. At least with AI me coming back to something is right here and right now, not never or when it causes a production grade issue.

rewilder12 8mo ago

The original phrase "talk is cheap" is generally used to mean "it's easy to say a whole lot of shit and that talk often has no real value." So this cleaver headline is telling me the code has even less value than the talk. That alone betrays a level of ignorance I would expect from the author's work. I go to read the article and it confirmed my suspicion.

xnorswap 8mo ago
It's directly an inversion of https://www.goodreads.com/quotes/437173-talk-is-cheap-show-me-the-code https://www.goodreads.com/quotes/437173-talk-is-cheap-show-m...
joenot443 8mo ago
Did you get very far in? They're referring to a pretty specific contextual usage of the phrase (Linus, back in 2000), not the adage as a whole.
- wiseowise 8mo ago
  I read the whole thing, and GP is right. Code is important, whether it is generated or handwritten. At least until true AGI is here.
- rewilder12 8mo ago
  I think I made it to about here haha > One can no longer know whether such a repository was “vibe” coded by a non-technical person who has never written a single line of code, or an experienced developer, who may or may not have used LLM assistance. I am talking about what it means to invert that phrase.
quadrifoliate 8mo ago
I think you are hyper-focusing on the headline, which is just a joke. The underlying article does not indicate to me that the author is ignorant of code, and if you care to look, they seem to have a substantial body of public open source contributions that proves this quite conclusively. The underlying point is just that while it was very cognitively expensive to back up a good design with good code back in 2000, it's much cheaper now. And therefore, making sure the design is good is the more important part. That's it really.

gipp 8mo ago

I see a lot of the same (well thought out) pushback on here whenever these kinds of blind hype articles pop up. But my biggest objection to this "engineering is over" take is one that I don't see much. Maybe this is just my Big Tech glasses, but I feel like for a large, mature product, if you break down the time and effort required to bring a change to production, the actual writing of code is like... ten, maybe twenty percent of it? Sure, you can bring "agents" to bear on other parts of the process to some degree or another. But their value to the design and specification process, or to live experiment, analysis, and iteration, is just dramatically less than in the coding process (which is already overstated). And that's without even getting into communication and coordination across the company, which is typically the real limiting factor, and in which heavy LLM usage almost exclusively makes things worse. Takes like this seem to just have a completely different understanding of what "software development" even means than I do, and I'm not sure how to reconcile it. To be clear, I think these tools absolutely have a place, and I use them where appropriate and often get value out of them. They're part of the field for good, no question. But this take that it's a replacement for engineering, rather than an engineering power tool, consistently feels like it's coming from a perspective that has never worked on supporting a real product with real users.

jatins 8mo ago
Did you read the article? Author is one of the more thoughtful and least hype guys you'll find when it comes to these things
mupuff1234 8mo ago
They're also great for writing design docs, which is another significant time sink for SWEs.
techblueberry 8mo ago
Yeah in a lot of ways, my assertion is that @ “Code is cheap” actually means the opposite of what everyone thinks it does. Software Engineer is even more about the practices we’ve been developing over the past 20 or so years, not less Like Linus’ observation still stands. Show me that the code you provided does exactly what you think it should. It’s easy to prompt a few lines into an LLM, it’s another thing to know exactly the way to safely and effectively change low level code. Liz Fong-Jones told a story on LinkedIn about this at HoneyComb, she got called out for dropping a bad set of PR’s in a repo, because she didn’t really think about the way the change was presented.

karmasimida 8mo ago

Regardless, knowing syntax of programming language or remember some library API, is a dead business.

pmg101 8mo ago
I for one am quite happy to outsource this kind of simply memorisation to a machine. Maybe it's the thin end of the slippery slope? It doesn't FEEL like it is but...
- habinero 8mo ago
  Why even learn how to read when you can just yell at the computers?

negamax 8mo ago

I keep on wondering how much of the AI embrace is marketing driven. Yes, it can produce value and cut corners. But it seems like self driving by 2016 Musk prediction. Which never happened. With IPO/Stock valuations closely tied to hype, I wonder if we are all witnessing a giant bubble in the making How much of this is mass financial engineering than real value. Reading a lot of nudges how everyone should have Google or other AI stock in their portfolio/retirement accounts

Cthulhu_ 8mo ago
No need to wonder, just look at the numbers - investments versus revenue are hugely disparate, growth is plateauing.
dbtablesorrows 8mo ago
I realize many are disappointed (especially by technical churn, star-based-development JS projects on github without technical rigour). I don't trust any claim on the open web if I don't know the technical background of the person making it. However I think - Nadh, ronacher, the redis bro - these are people who can be trusted. I find Nadh's article (OP) quite balanced.
- sjsizjhaha 8mo ago
  > ronacher I think he’s soured a bit on the 10x claim echoing many of the quality concerns expressed by others in this thread: https://lucumr.pocoo.org/2026/1/18/agent-psychosis/ https://lucumr.pocoo.org/2026/1/18/agent-psychosis/
- Imustaskforhelp 8mo ago
  When you mention Redis bro, I think you are talking about Antirez correct?
  - dbtablesorrows 8mo ago
    yeah, forgot his name.
8mo ago

leecommamichael 8mo ago

> Ignoring outright bad code, in a world where functional code is so abundant that “good” and “bad” are indistinguishable, ultimately, what makes functional AI code slop or non-slop? I'm sorry, but this is an indicator for me that the author hasn't had a critical eye for quality in some time. There is massive overlap between "bad" and "functional." More than ever. The barrier-to-entry to programming got irresponsibly low for a time there, and it's going to get worse. The toolchains are not in a good way. Windows and macOS are degrading both in performance and usability, LLVM still takes 90% of a compiler's CPU time in unoptimized builds, Notepad has AI (and crashes,) simple social (mobile) apps are >300 MB download/installs when eight years ago they were hovering around a tenth of that, a site like Reddit only works on hardware which is only "cheap" in the top 3 GDP nations in the world... The list goes on. Whatever we're doing, it is not scaling.

atomicnature 8mo ago
This is the "artisanal clothing argument". I'd think there'll be a dip in code quality (compared to human) initially due to "AI machinery" due to its immaturity. But over-time on a mass-scale - we are going to see an improvement in the quality of software artifacts. It is easier to 'discipline' the top 5 AI agents in the planet - rather than try to get a million distributed devs ("artisans") to produce high quality results. It's like in the clothing or manufacturing industry I think. Artisans were able to produce better individual results than the average industry machinery, at least initially. But overtime - industry machinery could match the average artisan or even beat the average, while decisively beating in scale, speed, energy efficiency and so on.
- noosphr 8mo ago
  The issue is that code isn't clothing. It's the clothing factory. We aren't artisans sewing clothing. We're production engineers deciding on layouts for robots to make clothes most efficiently. I see this type error of thinking all the time. Engineers don't make objects of type A, we make functions of type A -> B or higher order.
  - 8mo ago

wiseowise 8mo ago

>> Remember the old adage, “programming is 90% thinking and 10% typing”? It is now, for real. > Proceeds to write literal books of markdown to get something meaningful >> It requires no special training, no new language or framework to learn, and has practically no entry barriers—just good old critical thinking and foundational human skills, and competence to run the machinery. > Wrote a paragraph about how it is important to have serious experience to understand the generated code prior to that >> For the first time ever, good talk is exponentially more valuable than good code. The ramifications of this are significant and disruptive. This time, it is different. > This time is different bro I swear, just one more model, just one more scale-up, just one more trillion parameters, bro we’re basically at AGI

ctrlmeta 8mo ago

This "Code is cheap. Show me the talk." punchline gets overused as a bait these days. It is an alright article but that's a lot of words to tell us something we already know. There's nothing here that we don't already know. It's not just greedy companies riding the AI wave. Bloggers and influencers are also riding the AI wave. They know if you say anything positive or negative about AI with a catchy title it will trend on HN, Reddit, etc. Also credit where credit is due. Origin of this punchline: https://nitter.net/jason_young1231/status/1935180703416897895 https://nitter.net/jason_young1231/status/193518070341689789... https://programmerhumor.io/ai-memes/code-is-cheap-show-me-the-talk-wafz https://programmerhumor.io/ai-memes/code-is-cheap-show-me-th...

vb-8448 8mo ago

> Software development, as it has been done for decades, is over. I'm pretty sure the way I was doing things in 2005 was completely different compared to 2015. Same for 2015 and 2025. I'm not old enough to know how they were doing things in 1995, but I'm pretty sure there very different compared to 2005. For sure, we are going through some big changes, but there is no "as it has been done for decades".

awesan 8mo ago
I don't think things have changed that much in the time I've been doing it (roughly 20 years). Tools have evolved and new things were added but the core workflow of a developer has more or less stayed the same.
- mobiuscog 8mo ago
  I don't think that's true, at least for everywhere I've worked. Agile has completely changed things, for better or for worse. Being a SWE today is nothing like 30 years ago, for me. I much preferred the earlier days as well, as it felt far more engineered and considered as opposed to much of the MVP 'productivity' of today.
  - lo_zamoyski 8mo ago
    MVP is not necessarily opposed to engineered and considered. It's just that many people who throw that term around have little regard for engineering, which they hide behind buzzwords like "agile".
- seszett 8mo ago
  I also wonder what those people have been doing all this time... I also have been mostly working as a developer for about 20 years and I don't think much has changed at all. I also don't feel less productive or lacking in anything compared to the newer developers I know (including some LLM users) so I don't think I am obsolete either.
  - 8mo ago

dist-epoch 8mo ago

Long blog posts are cheap. Show me the prompt.

lioeters 8mo ago
Prompts are cheap. Show me the spark of consciousness that brings the whole thing to life, that which makes all of it worthwhile and meaningful.

dbtablesorrows 8mo ago

OK, fuck it, show me the demo (without staging it). show me the result.

ojr 8mo ago

talk is even cheaper, still show me the code, people claim 10x productivity that translates to 10x of work done in a month, even with Opus 4.5 out since November 2025 I haven't seen signs of this. AI makes the level of complexity with modern systems bearable, it was getting pretty bad before and AI kinda saved us. A non-trivial React app is still a pain to write. Also creating a harness for a non-deterministic api that AI provides is also pain. At least we don't have to fight through typing errors or search through relevant examples before copying and pasting. AI is good at automating typing, the lack of reasoning and the knowledge cutoff still makes coding very tedious though.

program_whiz 8mo ago
Best example of this is Claude's own terminal program. Apparently renders react at 60fps and then translates it into ANSI chars that then diff the content of the terminal and do an overwrite... All to basically mimic what curses can do very easily.
- tokioyoyo 8mo ago
  This is the fun part of whole AI-built things that a lot of people don’t want to accept - it really, really, really does not matter if the code “nice, maintainable and etc.”. Does it work? Is it somewhat extendable with AI? Are users generally happy and adoption rate is high? That’s it.
  - chr15m 8mo ago
    If you have high time preference yes. Over longer time horizons I think the issues with vibe coded software will reveal themselves in the same way badly written software does.
  - esafak 8mo ago
    In this case, no, it does not work. CC is full of reported rendering issues, including some that affect me.
    - 8mo ago

v3ss0n 8mo ago

code is cheap, show me the prompt

Waterluvian 8mo ago

I think if your job is to assemble a segment of a car based on a spec using provided tools and pre-trained processes, it makes sense if you worry that giant robot arms might be installed to replace you. But if your job is to assemble a car in order to explore what modifications to make to the design, experiment with a single prototype, and determine how to program those robot arms, you’re probably not thinking about the risk of being automated. I know a lot of counter arguments are a form of, “but AI is automating that second class of job!” But I just really haven’t seen that at all. What I have seen is a misclassification of the former as the latter.

mips_avatar 8mo ago
Well a lot of managers view their employees as doing the former, but they’re really doing the latter
HorizonXP 8mo ago
This is actually a really good description of the situation. But I will say, as someone that prided myself on being the second one you described, I am becoming very concerned about how much of my work was misclassified. It does feel like a lot of work I did in the second class is being automated where maybe previously it overinflated my ego.
- skydhash 8mo ago
  SWE is more like formula 1 where each race presents a unique combination of track, car, driver, conditions. You may have tools to build the thing, but designing the thing is the main issue. Code editor, linter, test runner, build tools are for building the thing. Understanding the requirements and the technical challenges is designing the thing.
  - Waterluvian 8mo ago
    The other day I said something along the lines of, "be interested in the class, not the instance" and I meant to try to articulate a sense of metaprogramming and metaanalysis of a problem. Y is causing Z and we should fix that. But if we stop and study the problem, we might discover that X causes the class of Y problem so we can fix the entire class, not just the instance. And perhaps W causes the class of X issue. I find my job more and more being about how far up this causality tree can I reason, how confident am I about my findings, and how far up does it make business sense to address right now, later, or ever?

keybored 8mo ago

Lots of words to say that “now” communicating in regular human language is important. What soft-skill buzzword will be the next one as the capital owners take more of the supposed productivity profits?

raincole 8mo ago

Talk is never cheap. Communicating your thoughts to people without the exact same kind of expertise as you is the most important skill. This quote is from Torvalds, and I'm quite sure that if he weren't able to write eloquent English no one would know Linux today. Code is important when it's the best medium to express the essence of your thoughts. Just like a composer cannot express the music in his head with English words.

CuriouslyC 8mo ago
You want a real mind bender? Imagine a universe where Linus's original usenet post didn't go viral.
Imustaskforhelp 8mo ago
I don't think Linus is a people person. This is something which he talks about himself in the famous ted-ed video. I just re-watched the video (currently halfway) & I feel like the point of Linux is something which you are forgetting but it was never intended to grow so much and Linux himself in the video when asked says that he never had a moment where he went like oh this went big. In fact he talks about when the project was little. On how he had gratitude when the project had 10 people maybe 100 people working on it and then things only grow over a very large time frame (more than 25-30years? maybe now 35 just searched 34) He talks about how he got other people's idea which he couldn't have thought of things themselves and when he first created the project he just wanted to show off to the world to look at what I did (and he did it mainly for both the end result of the project and programming itself too) and then he got introduced to open source (free software) by his friend and he just decided to have it open source. My point is it was neither the code nor the talk. Linus is the best person to maintain Linux, why? Because he has been passionate over it for 25 years. I feel like Linux would be just as interested in talking about the code and any improvements now with maybe the same vigour as 34 years ago. He loves his creation & we love Linux too :) Another small point I wish to add is that if talk was the only thing, then you are missing the point because Linux was created because hurd was getting delayed (so all talks no code) Linux himself says that if the hurd kernel would've been released earlier, Linux wouldn't have been created. So all talk no code Hurd project (which from what I hear right now is still a bit limbo as now everyone [rightfully?] uses linux) is what led to creation of linux project. Everyone who hasn't watched Linus's ted ed should definitely watch it. The Mind Behind Linux | Linus Torvalds | TED : https://www.youtube.com/watch?v=o8NPllzkFhE https://www.youtube.com/watch?v=o8NPllzkFhE

z0r 8mo ago

From the article: Historically, it would take a reasonably long period of consistent effort and many iterations of refinement for a good developer to produce 10,000 lines of quality code that not only delivered meaningful results, but was easily readable and maintainable. While the number of lines of code is not a measure of code quality—it is often the inverse—a codebase with good quality 10,000 lines of code indicated significant time, effort, focus, patience, expertise, and often, skills like project management that went into it. Human traits. Now, LLMs can not only one-shot generate that in seconds, Evidence please. Ascribing many qualities to LLM code that I haven't (personally) seen at that scale. I think if you want to get an 'easily readable and maintainable' codebase of 10k lines with an LLM you need somebody to review its contributions very closely, and it probably isn't going to be generated with a 1 shot prompt.

sjsizjhaha 8mo ago
It’s like the google claim. There was a years worth of work up front, but AI took the typing from a few days to a day.

Imustaskforhelp 8mo ago

Okay I was writing a comment to simon (and I have elaborated some there but I wanted this to be something catchy to show how I feel and something people might discuss with too) Both Code and talk are cheap. Show me the trust. Show me how I can trust you. Show me your authenticity. Show me your passion. Code used to be the sign of authenticity. This is whats changing. You can no longer guarantee that large amounts of code let's say are now authentic, something which previously used to be the case (for the most part) I have been shouting into the void many times about it but Trust seems to be the most important factor. Essentially, I am speaking it from a consumer perspective but suppose that you write AI generated code and deploy it. Suppose you talked to AI or around it. Now I can do the same too and create a project sometimes (mostly?) more customizable to my needs for free/very-cheap. So you have to justify why you are charging me. I do feel like that's only possible if there is something additional added to value. Trust, I trust the decision that you make and personally I trust people/decisions who feel like they take me or my ideas into account. So, essentially not ripping me off while actively helping. I don't know how to explain this but the most thing which I hate is the feeling of getting ripped off. So justifiable sustainable business who is open/transparent about the whole deal and what he gets and I get just gets my respect and my trust and quite frankly, I am not seeing many people do that but hopefully this changes. I am curious now what you guys of HN think about this & what trust means to you in this (new?) ever-changing world. Like y'know I feel like everything changes all the time but at the same time nothing changes at the same time too. We are still humans & we will always be humans & we are driven by our human instincts. Perhaps the community I envision is a more tight knit community online not complete mega-sellers. Thoughts?

deleted 8mo ago

[deleted]

api 8mo ago

Uhh... how about show me both? I think that's always been true. The ideas and reasoning process matter. So does the end product. If you produced it with an LLM and it sucks, it still sucks.

heliumtera 8mo ago

Please no. Talk is cheap. I hate this trend of using adjectives to describe systems. Fast Secure Sandboxed Minimal Reliable Robust Production grade AI ready Let's you _____ Enables you to _____ But somewhat I agree, code is essentially free, you can shit out infinite amounts of code. Unless it's good, then show the code instead. If your code is shit, show the program. If your program is shit, your code is worse, but you still pursing an interesting idea (in your eyes), show the prompt instead of the slop generated. Or even better communicate an elaborate version of the prompt. >One can no longer know whether such a repository was “vibe” This is absurd. Simply false, people can spot INSTANTLY when the code is good, see: https://news.ycombinator.com/item?id=46753708 https://news.ycombinator.com/item?id=46753708

bambax 8mo ago

> Code was always a means to an end. Unlike poetry or prose, end users don’t read or care about code. Yes and no. Code is not art, but software is art. What is art, then? Not something that's "beautiful", as beauty is of course mostly subjective. Not even something that works well. I think art is a thing that was made with great care. It doesn't matter if some piece of software was vibe-coded in part or in full, if it was edited, tested, retried enough times for its maker to consider it "perfect". Trash is something that's done in a careless way. If you truly love and use what you made, it's likely someone else will. If not, well... why would anyone?

chrisvalleybay 8mo ago
The best definition of art I've read is the one from "What is Art?" by Tolstoy. I haven't read it myself, but came across it in a Van Neistat video recently. Tolstoy argued that art is essentially the transmission of feeling from the artist to the audience. He claimed that when an artist experiences an emotion and then, through their work, evokes that same emotion in others, that is art.
jll29 8mo ago
Well, why do humans read code: 1. To maintain it (to refactor or extend it). 2. To test it. 3. To debug it (to detect and fix flaws in it). 4. To learn (to get better by absorbing how the pros do it). 5. To verify and improve it (code review, pair programming). 6. To grade it (because a student wrote it). 7. To enjoy its beauty. These are all I can think of right now, and they are ordered from most common to most rare case. Personally, I have certainly read and re-read SICP code to enjoy its beauty (7), perhaps mixed in with a desire to learn (4) how to write equally beautiful code.
jdjeeee 8mo ago
Art is expression. What the software provides (an experience) for which the artist (software engineer) expresses in code.

captain5123 8mo ago

> The real concern is for generations of learners who are being robbed of the opportunity to acquire the expertise to objectively discern what is slop and what is not. How do new developers build the skills that seniors generated through time? I see my seniors having higher success in vibe-coding than me. How can I short-circuit the time they put through for myself?

monster_truck 8mo ago

Feels like this website is yelling at me with its massive text size. Had to drop down to -50% to get it readable. Classical indicators of good software are still very relevant and valid! Building something substantial and material (ie not an api wrapper+gui, to-do list) that is undeniably well made, while being faster and easier than it used to be, still takes a _lot_ of work. Even though you don't have to write a line of code, it moves so fast that you are now spending 3.5-4 days of your work week reading code, using the project, running benchmarks and experimental test lanes, reviewing specs and plans, drafting specs, defining features and tests. The level of granularity needed to get earnestly good results is more than most people are used to. It's directly centered at the intersection between spec heavy engineering work and writing requirements for a large, high quality offshore dev team that is endearingly literal in how they interpret instructions. Depending on the work, I've found that I average around one 'task' per 22-35 lines of code. You'll discover a new sense of profound respect for the better PMs, QA Leads, Eng Directors you have worked with. Months of progress happen each week. You'll know you're doing it right when you ask an Agent to evaluate the work since last week and it assumes it is reviewing the output of a medium sized business and offers to make Jira tickets.

optymizer 8mo ago

> because one is hooked on and dependent on the genie, the natural circumstances that otherwise would allow for foundational and fundamental skills and understanding to develop, never arise, to the point of cognitive decline. After using AI to code, I came to the same conclusion myself. Interns and juniors are fully cooked: - Companies will replace them with AI, telling seniors to use AI instead of juniors - As a junior, AI is a click away, so why would you spend sleepless nights painstakingly acquiring those fundamentals? Their only hope is to use AI to accelerate their own _learning_, not their performance. Performance will come after the learning phase. If you're young, use AI as a personal TA, don't use it to write the code for you.

furyofantares 8mo ago
Young folks are gonna figure out how to use this stuff way better than us older folks. We just start with a big advantage.
polytely 8mo ago
as someone who is sort of a medior programmer it is very hard to balance, trying to keep up with the advancements in AI while not shooting myself in the foot by robbing myself of learning experiences
- passivegains 8mo ago
  if it helps, that kind of thoughtfulness is how to learn the things that matter most. you're already on the right track.

deleted 8mo ago

[deleted]

MyHonestOpinon 8mo ago

My latest take on AI assisted coding is that AI tools are an amplifier of the developer. - A good and experienced developer who knows how to organize and structure systems will become more productive. - An inexperienced developer will also be able to produce more code but not necessarily systems that are maintainable. - A sloppy developer will produce more slop.