14 ms·

Thoughts on slowing the fuck down

• 0xbadcafebee 7mo ago
  > it sure feels like software has become a brittle mess, with 98% uptime becoming the norm instead of the exception, including for big services As somebody who has been running systems like these for two decades: the software has not changed. What's changed is that before, nobody trusted anything, so a human had to manually do everything. That slowed down the process, which made flaws happen less frequently. But it was all still crap. Just very slow moving crap, with more manual testing and visual validation. Still plenty of failures, but it doesn't feel like it fails a lot of they're spaced far apart on the status page. The "uptime" is time-driven, not bugs-per-lines-of-code driven. DevOps' purpose is to teach you that you can move quickly without breaking stuff, but it requires a particular way of working, that emphasizes building trust. You can't just ship random stuff 100x faster and assume it will work. This is what the "move fast and break stuff" people learned the hard way years ago. And breaking stuff isn't inherently bad - if you learn from your mistakes and make the system better afterward. The problem is, that's extra work that people don't want to do. If you don't have an adult in the room forcing people to improve, you get the disasters of the past month. An example: Google SREs give teams error budgets; the SREs are acting as the adult in the room, forcing the team to stop shipping and fix their quality issues. One way to deal with this in DevOps/Lean/TPS is the Andon cord. Famously a cord introduced at Toyota that allows any assembly worker to stop the production line until a problem is identified and a fix worked on (not just the immediate defect, but the root cause). This is insane to most business people because nobody wants to stop everything to fix one problem, they want to quickly patch it up and keep working, or ignore it and fix it later. But as Ford/GM found out, that just leads to a mountain of backlogged problems that makes everything worse. Toyota discovered that if you take the long, painful time to fix it immediately, that has the opposite effect, creating more and more efficiency, better quality, fewer defects, and faster shipping. The difference is cultural. This is real DevOps. If you want your AI work to be both high quality and fast, I recommend following its suggestions. Keep in mind, none of this is a technical issue; it's a business process isssue.
  • pixl97 7mo ago
    It also seems like massive consolidation has caused issues too. Everyone is on Github. Everyone is on AWS. Everyone is behind cloudflare. Whenever an issue happens here it effects everyone and everyone sees it. In the past with smaller services those services did break all the time, but the outage was limited to a much smaller area. Also systems were typically less integrated with each other so one service being down rarely took out everything.
    • 0xbadcafebee 7mo ago
      The power company is massively consolidated, as is the water supply, telephone service. These are monolithic, monopolistic entities. But they are also very reliable (failures are usually isolated by region, or a result of natural disaster). What leads to more failure is when you don't engineer those consolidated entities to be reliable. Tech companies have none of the legal requirements or incentives to be reliable, the way physical infrastructure companies do. I agree that the tighter integration is an issue, but the root cause is tech companies have no incentive other than profits. If they're making profits, everything's fine.
      • pixl97 7mo ago
        I mean recommend professional software engineering licenses here on HN and it goes over like a turd in a punch bowl. Everyone knows where the search for more profit was going, no one wanted to get off the ride though.
  • hackertyper69 7mo ago
    It's a systems engineering job. You need to provide context, acceptable failure modes, and test at each level for validation. Identify false coupling, poor interfaces, things that don't match business context during agent planning phase. Then communicate / translate to others so their decisions improve instead of destroying the system by optimizing only for their local situation.
  • _doctor_love 7mo ago
    Super good take - the Andon cord is needed everywhere.
• gchamonlive 7mo ago
  I think before even being able to entertain the thought of slowing the fuck down, we need to seriously consider divorcing productivity. Or at least asking a break, so you can go for a walk in the park, meet some friends and reflect on how you are approaching development. I think this is very good take on AI adoption: https://mitchellh.com/writing/my-ai-adoption-journey https://mitchellh.com/writing/my-ai-adoption-journey. I've had tremendous success with roughly following the ideas there. > The point is: let the agent do the boring stuff, the stuff that won't teach you anything new, or try out different things you'd otherwise not have time for. Then you evaluate what it came up with, take the ideas that are actually reasonable and correct, and finalize the implementation. That's partially true. I've also had instances where I could have very well done a simple change by myself, but by running it through an agent first I became aware of complexities I wasn't considering and I gained documentation updates for free. Oh and the best part, if in three months I'm asked to compile a list of things I did, I can just look at my session history, cross with my development history on my repositories and paint a very good picture of what I've achieved. I can even rebuild the decision process with designing the solution. It's always a win to run things through an agent.
  • kitsune1 7mo ago
    [dead]
• ex-aws-dude 7mo ago
  Eh I think its self-correcting problem Companies will face the maintenance and availability consequences of these tools but it may take a while for the feedback loop to close
  • apical_dendrite 7mo ago
    Unfortunately, I think the lesson from recent history seems to be that outside of highly-regulated industries, customers and businesses will accept terrible quality as long as it's cheap.
    • ex-aws-dude 7mo ago
      True but there is a limit, there are still levels of quality
      • layer8 7mo ago
        Levels of enshittification, more often than not.
    • bonoboTP 7mo ago
      Yes, every slack is optimized out of systems. If something has an ounce more quality than would suffice to obtain the same profit, it must be cut out. It's an inefficiency. A quality overhang. If people buy it even if it's crap, then the conclusion is that it has to be crap, else money is left on the table. It's a large scale coordination issue. This gives us a world where everything balances exactly near the border where it just barely works, for just barely enough time.
    • slopinthebag 7mo ago
      Nah, there is a quality floor that consumers are willing to accept. Once you get below that, where it's actually affecting their lives in a meaningful way, it will self-correct as companies will exploit the new market created for quality products.
  • the_mitsuhiko 7mo ago
• badlibrarian 7mo ago
  I suppose everyone on HN reaches a certain point with these kind of thought pieces and I just reached mine. What are you building? Does the tool help or hurt? People answered this wrong in the Ruby era, they answered it wrong in the PHP era, they answered it wrong in the Lotus Notes and Visual BASIC era. After five or six cycles it does become a bit fatiguing. Use the tool sanely. Work at a pace where your understanding of what you are building does not exceed the reality of the mess you and your team are actually building if budgets allow. This seldom happens, even in solo hobby projects once you cost everything in. It's not about agile or waterfall or "functional" or abstracting your dependencies via Podman or Docker or VMware or whatever that nix crap is. Or using an agent to catch the bugs in the agent that's talking to an LLM you have next to no control over that's deleting your production database while you slept, then asking it to make illustrations for the postmortem blog post you ask it to write that you think elevates your status in the community but probably doesn't. I'm not even sure building software is an engineering discipline at this point. Maybe it never was.
  • latchkey 7mo ago
    > People answered this wrong in the Ruby era, they answered it wrong in the PHP era Aren't you conveniently ignoring the fact that there were people saw through that and didn't go down those routes?
    • badlibrarian 7mo ago
      Change it to "Some people" if your pedanticism won't let you follow the flow. Or better yet point out the better paths they chose instead. Were they wrestling with Java and "Joda Time"? Talking to AWS via a Python library named after a dolphin? Running .NET code on Linux servers under Mono that never actually worked? Jamming apps into a browser via JQuery? Abstracting it up a level and making 1,400 database calls via ActiveRecord to render a ten item to-do list and writing blog posts about the N+1 problem? Rewriting grep in Rust to keep the ruskies out of our precious LLCs? Asking the wrong questions, using the wrong tools, then writing dumb blog posts about it is what we do. It's what makes us us.
• ketzo 7mo ago
  I think the core idea here is a good one. But in many agent-skeptical pieces, I keep seeing this specific sentiment that “agent-written code is not production-ready,” and that just feels… wrong! It’s just completely insane to me to look at the output of Claude code or Codex with frontier models and say “no, nothing that comes out of this can go straight to prod — I need to review every line.” Yes, there are still issues, and yes, keeping mental context of your codebase’s architecture is critical, but I’m sorry, it just feels borderline archaic to pretend we’re gonna live in a world where these agents have to have a human poring over every single line they commit.
  • movedx01 7mo ago
    Not having a code review process is archaic engineering practice at this point(at any point in history, really), be it for human written or AI written code.
  • bluGill 7mo ago
    Maybe in the future humans won't need to pour over every line. However I quickly learn which interns I can trust and which I need to pour over their code - I don't trust AI because it has been wrong too often. I'm not saying AI is useless - I do most of my coding with an agent, but I don't trust it until I verify every line.
    • bensyverson 7mo ago
      I did this for a while… and until Opus 4.5, I couldn't fully trust the model. But at this point, while it does make the occasional mistake, I don't need to scrutinize every line. Unit and integration tests catch the bugs we can imagine, and the bugs we can't imagine take us by surprise, which is how it has always been.
      • bluGill 7mo ago
        Even with 4.6 I find there are a lot of mistakes it makes that I won't allow. Though it is also really good at finding complex thread issues that would take me forever...
• ontouchstart 7mo ago
  I am "playing" with both pi and Claude (in docker containers) with local llama.cpp and as an exercise, I asked both the same question and the results are in this gist: https://gist.github.com/ontouchstart/d43591213e0d3087369298f159785c7b https://gist.github.com/ontouchstart/d43591213e0d3087369298f... (Note: pi was written by the author of the post.) Now it is time to read them carefully without AI.
  • ontouchstart 7mo ago
    What I have leaned from the exercise above is that we paid more attention and spent more resources on "metadata" than real data. They are the rabbit holes that lead us to more metadata and forget what we really want. We are all rabbits.
• bluGill 7mo ago
  I only have so long on earth. (I have no idea how long) I need things to be faster for me. Sometimes that means I need to take extra time now so they don't come back to me later.
• markus_zhang 7mo ago
  If there is anyone who absolutely should slow down, it's the folks who are actively integrating company data with an agent -- you are literally helping removing as many jobs as possible, from your colleagues, and from yourselves, not in the long term, but in the short term. Integration is the key to the agents. Individual usages don't help AI much because it is confined within the domain of that individual.
  • latchkey 7mo ago
    > you are literally helping removing as many jobs as possible, from your colleagues, and from yourselves, not in the long term, but in the short term Pull the bandaid off quickly, it hurts less.
  • abletonlive 7mo ago
    > If there is anyone who absolutely should slow down, it's the folks who are actively integrating company data with an agent -- you are literally helping removing as many jobs as possible, from your colleagues, and from yourselves, not in the long term, but in the short term. I'm one of those people and I'm not going to slow down. I want to move on from bullshit jobs. The only people that fear what is coming are those that lack imagination and think we are going to run out of things to do, or run out of problems to create and solve.
    • guzfip 7mo ago
      > I want to move on from bullshit jobs. So are you aiming for death poverty? Once those bullshit jobs go, we’re going to find a lot of people incapable of producing anything of value while still costing quite a bit to upkeep. These people will have to be gotten rid of somehow. > and think we are going to run out of things to do, or run out of problems to create and solve. There will be plenty of problems to solve. Like who will wipe the ass of the very people that hate you and want to subjugate you.
      • abletonlive 7mo ago
        Name a single time doomers were right about anything. Doomers consistently overstate their expected outcome in every single domain and consistently fail to predict how society evolves and adapts. Again: The only people that fear what is coming are those that lack imagination and think we are going to run out of things to do, or run out of problems to create and solve.
• sjkoelle 7mo ago
  i just wish someone would explain why i prefer cline to claude code so much
• jaffee 7mo ago
  > You installed Beads, completely oblivious to the fact that it's basically uninstallable malware. Did I miss something? I haven't used it in a minute, but why is the author claiming that it's "uninstallable malware"?
  • vardalab 7mo ago
    It's not really malware, but it's a mess. It installed so much shit and it interfered with your git hooks and stuff. It was kind of messy. I kind of gave up on it. I just went back to using built-in claude code todowrite tasks.
    • the_mitsuhiko 7mo ago
      It managed to throw itself into a global file for me that Claude used which caused beads to appear in random projects on my machine. Because of how it was there the agent attempted to re-install beads after I already removed it because the guy hook errored.
    • skybrian 7mo ago
      Haven't tried it, but this rewrite might be better? https://github.com/Dicklesworthstone/beads_rust https://github.com/Dicklesworthstone/beads_rust
    • moeffju 7mo ago
      Try https://github.com/hmans/beans https://github.com/hmans/beans - I find it a refreshingly pragmatic take that works great with my agents use.
  • michaelbarton 7mo ago
    Malware might be a bit of stretch but could refer to this issue? https://github.com/steveyegge/beads/issues/1857 https://github.com/steveyegge/beads/issues/1857
  • dwaltrip 7mo ago
    Maybe they meant un-uninstallable?
• gedy 7mo ago
  It's not even the complexity which, you have to realize: many managers and business types think it's just fine to have code no one understands because AI will do it. I don't agree, but bigger issue to me is many/most companies don't even know what they want or think about what the purpose is. So whereas in past devs coding something gave some throttle or sanity checks, now we'd just throw shit over wall even faster. I'm seeing some LinkedIn lunatics brag about "my idea to production in an hour" and all I can think is: that is probably a terrible feature. No one I've worked with is that good or visionary where that speed even matters.
• simonw 7mo ago
  Useful context here is that the author wrote Pi, which is the coding agent framework used by OpenClaw and is one of the most popular open source coding agent frameworks generally.
  • PaulHoule 7mo ago
    ... people like that have a way of writing articles that don't seem to say anything at all.
  • sehugg 7mo ago
    That's hilarious. I've been following Mario since his work on libGDX and RoboVM. His blog post on pi is here: https://mariozechner.at/posts/2025-11-30-pi-coding-agent/ https://mariozechner.at/posts/2025-11-30-pi-coding-agent/
  • slopinthebag 7mo ago
    That's a great shout because I'm sure a lot of people would otherwise just discredit this take as just another anti-ai skeptic. But he probably has more experience working with LLM's and agents than most of us on this site, so his opinion holds more weight than most.
    • bigstrat2003 7mo ago
      If you were going to dismiss an argument because of who it comes from rather than its content, that is a flaw in your thinking. The argument is correct, or it isn't, no matter who said it.
      • roughly 7mo ago
        Your ability to evaluate whether the argument is correct is limited. In theory, the author and the correctness of the argument are unrelated; in practice, the degree of experience the author has with the topic they’re making an argument on does indeed have some correlation with the argument and should influence the attention you give to arguments, especially counterintuitive ones.
• shevy-java 7mo ago
  > While all of this is anecdotal, it sure feels like software has become a brittle mess That may be the case where AI leaks into, but not every software developer uses or depends on AI. So not all software has become more brittle. Personally I try to avoid any contact with software developers using AI. This may not be possible, but I don't want to waste my own time "interacting" with people who aren't really the ones writing code anymore.
• SoftTalker 7mo ago
  > Companies claiming 100% of their product's code is now written by AI consistently put out the worst garbage you can imagine. Not pointing fingers, but memory leaks in the gigabytes, UI glitches, broken-ass features, crashes One thing about the old days of DOS and original MacOS: you couldn't get away with nearly as much of this. The whole computer would crash hard and need to be rebooted, all unsaved work lost. You also could not easily push out an update or patch --- stuff had to work out of the box. Modern OSes with virtual memory and multitasking and user isolation are a lot more tolerant of shit code, so we are getting more of it. Not that I want to go back to DOS but Wordperfect 5.1 was pretty damn rock solid as I recall.
  • windowliker 7mo ago
    Another factor at work is the use of rolling updates to fix things that should better have been caught with rigorous testing before release. Before the days of 'always on' internet it was far too costly to fix something shipped on physical media. Not that everything was always perfect, but on the whole it was pretty well stress-tested before shipping. The sad truth is that now, because of the ease of pushing your fix to everything while requiring little more from the user than that their machine be more or less permanently connected to a network, even an OS is dealt with as casually as an application or game.
  • MisterTea 7mo ago
    > Modern OSes with virtual memory and multitasking and user isolation are a lot more tolerant of shit code, so we are getting more of it. It's not the glut of compute resources, we've already accepted bloat in modern software. The new crutch is treating every device as "always online" paired with mantra of "ship now! push fixes later." Its easier to setup a big complex CI pipeline you push fixes into and it OTA patches the users system. This way you can justify pushing broken unfinished products to beat your competitors doing the same.
  • skybrian 7mo ago
    I think you're just recalling the few software products that were actually good. There was plenty of crap software that would crash and lose your work in the old days.
• gmuslera 7mo ago
  This assumes that only (AI/Agentic) stupidity comes into play, with no malice on sight. But if things go wrong because you didn't noticed the stupidity, malice will pass through too. And there is a a big profit opportunity, and a broad vulnerable market for malice. Is not just correctness or uptime what comes into play, but bigger risks for vulnerabilities or other malicious injected content.
• caldis_chen 7mo ago
  hope my boss can see this
• rglover 7mo ago
  Nature will handle this in time. Just expect to see a "Bear Stearns moment" in the software world if this spirals completely out of control (and companies don't take a hint from recent outages).
  • michaelbarton 7mo ago
    I’m worried we end up with an AIG moment, and we all end up on the hook.
    • rglover 7mo ago
      That's a valid fear imo.
  • jafitc 7mo ago
    subprime mortgages sprinkled on top of prime ones, treated as prime ones. because they were printing money. subprime code sprinkled on the backbone of software we use everyday. because they are printing code. reckoning
• profdevloper 7mo ago
  It's 2026, the "fuck" modifier for post titles by "thought leaders" has been done already ad nauseam. Time to retire it and give us all a break.
  • niam 7mo ago
    If we're on the subject of tropes: https://theonion.com/report-stating-current-year-still-leading-argument-for-1819576151/ https://theonion.com/report-stating-current-year-still-leadi...
• jschrf 7mo ago
  I for one look forward to rewriting the entirety of software after the chatbot era
• mpajares 7mo ago
  [dead]
• trinsic2 7mo ago
  > And I would like to suggest that slowing the fuck down is the way to go. Give yourself time to think about what you're actually building and why. Give yourself an opportunity to say, fuck no, we don't need this. Set yourself limits on how much code you let the clanker generate per day, in line with your ability to actually review the code. This is a great point. I have been avoiding LLM's for awhile now, but realized that I might want to try working on a small PDF book to Markdown conversion project[0]. I like the Claude code because command line. I'm realizing you really need to architect with good very precise language to avoid mistakes. I didn't try to have a prompt do everything at once. I prompted Claude Code to do the conversion process section by section of the document. That seemed to reduce the mistake the agent would make [0]: https://www.scottrlarson.com/publications/publication-my-first-llm-experiment/ https://www.scottrlarson.com/publications/publication-my-fir...
• edwardsrobbie 7mo ago
  [dead]
• BloondAndDoom 7mo ago
  This aligns with my observation from product design point as well. Product design has a slightly different problem than engineering, because the speed of development is so high we cannot dogfood and play with new product decisions, features. By the time I’ve realized we made a stupid design choice and it doesn’t really work in real world, we already built 4 features on top of it. Everyone makes bad product decisions but it was easy and natural to back out of them. It’s all about how we utilize these things, if we focus on sheer speed it just doesn’t work. You need own architecture and product decisions. You need to use and test your products with humans (and automate those as regression testing). You need to able to hold all of the product or architecture in your mind and help agents to make the right decisions with all the best practice you’ve learned.
  • angrydev 7mo ago
    Agree. The issue was never, how can we get our engineers to squirt out more lines of code in a day? It has always been, how can we effectively iterate using customer feedback to deliver the highest quality product. That type of thing needs time to bake.
• Towaway69 7mo ago
  What the article doesn't touch on is the vendor lock-in that is currently underway. Many corps are now moving to an AI-based development process that is reliant on the big AI providers. Once the codebase has become fully agentic, i.e., only agents fundamentally understand it and can modify it, the prices will start rising. After all, these loss making AI companies will eventually need to recoup on their investments. Sure it will be - perhaps - possible to interchange the underlying AI for the development of the codebase but will they be significantly cheaper? Of course, the invisible hand of the market will solve that problem. Something that OPEC has successfully done for the oil market. Another issue here is once the codebase is agentic and the price for developers falls sufficiently that it will significant cheaper to hire humans again, will these be able to understand the agentic codebase? Is this a one-way transition? I'm sure the pro-AIs will explain that technology will only get cheaper and better and that fundamentally it ain't an issue. Just like oil prices and the global economy, fundamentally everything is getting better.
  • fantasizr 7mo ago
    this is a good point. Some of the ai companies are trying to hook cs students so they'll only know "dev" as a function of their products. First one's free as they say (the drug dealers).
    • Towaway69 7mo ago
      I agree, that is the great danger that CS students aren't even taught the fundamentals of "computer science" any longer. It would be the equivalent of physics students not learning Newtons laws or e-m-c-squared. Probably there is an issue with how much there is in CS - each programming language basically represents a different fundamental approach to coding machines. Each paradigm has its application, even COBOL ;) Perhaps CS has not - yet - found its fundamental rules and approaches. Unlike other sciences that have hard rules and well trodden approaches - the speed of light is fixed but not the speed of a bit.
  • SaucyWrong 7mo ago
    This is a great point, and I routinely use it as an argument for why seasoned professionals should work hard to keep their skills and why new professionals should build them in the first place. I would never be comfortable leasing my ability to perform detailed knowledge work from one of these companies. Sometimes the argument lands, very often it doesn't. As you said, a common refrain is, "but prices won't go up, cost to serve is the highest it will ever be." Or, "inference is already massively profitable and will become more so in the future--I read so on a news site." And that remark, for me, is unfortunately a discussion-ender. I just haven't ever had a productive conversation with somebody about this after they make these remarks. Somebody saying these things has placed their bets already and are about to throw the dice.
• Plutarco_ink 7mo ago
  [dead]
• deleted 7mo ago
  [deleted]
• impulser_ 7mo ago
  I think this post should be directed to every Typescript developer. I think a lot of this is just Typescript developers. I bet if you removed them from the equation most of the problem he's writing about go away. Typescript developers didn't even understand what React was doing without agent, now they are just one-shot prompting features, web apps, clis, desktop apps and spitting it out to the world. The prime example of this is literally Anthropic. They are pumping out features, apps, clis and EVERY single one of them release broken.
• bigstrat2003 7mo ago
  I really don't get the author's conclusion here. I agree with his premises: organizations using LLMs to churn out software are turning out terrible quality software. But the conclusion from that shouldn't be "slow down", it should be "this tool isn't currently fit for use, don't use it". It feels like the author starts from the premise of "I want to use AI" and is trying to figure out how to make that work, rather than "I want to make good software" and trying to figure out how to do that.
• saadn92 7mo ago
  i like the article and what it says, but not sure why cursing was necessary
• atemerev 7mo ago
  I expected this to be yet another anti-AI rant, but the guy is actually right. You should guide the agents, and this is a full-time job where you have to think hard.
• sayYayToLife 7mo ago
  Oh look another anti AI article. Oh they even swore in the title. Oh and of course it's anti-economics and is probably going to hurt whoever actually follows it. Three for three. It's not logical it's emotional.
• deleted 7mo ago
  [deleted]
• andai 7mo ago
  It occurred to me on my walk today that a program is not the only output of programming. The other, arguably far more important output, is the programmer. The mental model that you, the programmer, build by writing the program. And -- here's the million dollar question -- can we get away with removing our hands from the equation? You may know that knowledge lives deeper than "thought-level" -- much of it lives in muscle memory. You can't glance at a paragraph of a textbook, say "yeah that makes sense" and expect to do well on the exam. You need to be able to produce it. (Many of you will remember the experience of having forgotten a phone number, i.e. not being able to speak or write it, but finding that you are able to punch it into the dialpad, because the muscle memory was still there!) The recent trend is to increase the output called programs, but decrease the output called programmers. That doesn't exactly bode well. See also: Preventing the Collapse of Civilization / Jonathan Blow (Thekla, Inc) https://www.youtube.com/watch?v=ZSRHeXYDLko https://www.youtube.com/watch?v=ZSRHeXYDLko
  • Munksgaard 7mo ago
    Peter Naur had that realization back in 1985: https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf
  • tau5210 7mo ago
    > The recent trend is to increase the output called programs, but decrease the output called programmers. That doesn't exactly bode well. Perhaps on a related note, I've noticed that a lot of the positive talks about AI are about quantity. On the other hand, there is disproportionately very little deep discussion about quality. And I mean not just short term, local quality, but more long term and holistic quality (e.g. managing complexity under evolving requirements in a complex system with multiple connected parts) at real production scale, where there is much less tolerance for failure. In all the places I've worked in throughout my career, I've felt that there have always been a tension between those who cared more about things like the mental model and holistic quality, and those who seemed to care less or were even oblivious about it. I think one contribution of the current AI hype is that it gave a more concrete shape to this split...
    • 7mo ago
• riazrizvi 7mo ago
  This is what I call content based on 'garbage'. Because garbage is the random collection of peoples' stuff. You can try and make sense and commentary on a society through the garbage dump, but it's pretty superficial. It doesn't tell you a lot about any real person's motivations. So it's not a great basis for commenting on real people. OPs comments are on the collection of things that they happen to come across through news and social media. Sure it looks like a lot is happening, but look at any one person's or business's approach and it will make a lot more sense. Yes, I realize people are producing content that appeals to the 'garbage' mindset, but it's obviously theater. A system that writes 10,000 lines of code for you a week, is headline theater.
• commandlinefan 7mo ago
  It's always been this way - the people that rise to the top are the people who never had to deeply understand something, so they can't even comprehend what that would look like or why it should be important. They're trying to automate the "understanding" part, with predictably disastrous consequences that those of us who aren't the "rise to the top" type could see coming. Agentic AI is just another symptom.
• Bulaien 7mo ago
  [dead]
• Vektorceraptor 7mo ago
  Fine to read a fellow countryman on HN :) "Dere!" I have disabled my coding agent by default. I first try to think, plan, code something myself and only when I get stuck or the code gets repetitive, only then I tell him to do the stuff. But I get what you are saying, and I agree ... I am clearly pro human on this debate, and the low bloat trash everywhere is annoying. I have come to the conclusion - if you find docs on something, and it is plain HTML - it will be probably of high quality. If you find docs with a flashy, dynamic, effectful and unnecessary 100mb js booboo, then you what you are about to read ...
• aerhardt 7mo ago
  I'm capturing videos of all the bugs I am seeing as of late. The folder is filling fast. I'll write a compilation post but I'm thinking a techno remix video could be fitting too. If there are any common apps which are unhinged please do share your experiences. LinkedIn was never great quality but it's off the charts. Also catching some on Spotify.
• 6510 7mo ago
  I keep returning to this thought: Assuming our abstraction architecture is missing something fundamental, what is it? My gut says something simple is missing that makes all of the difference. One thought I had was that our problem lives between all the things taking something in and spitting something out. Perhaps 90% of the work writing a "function" should be to formally register it as taking in data type foo 1.54.32 and bar 4.5.2 then returning baz 42.0 The register will then tell you all the things you can make from baz 42.0 and the other data you have. A comment(?) above the function has a checksum that prevents anyone from changing it. But perhaps the solution is something entirely different. Maybe we just need a good set of opcodes and have abstractions represent small groups of instructions that can be combined into larger groups until you have decent higher languages. With the only difference being that one can read what the abstraction actually does. The compiler can figure lots of things out but it wont do architecture.
  • marcosdumay 7mo ago
    You seem to be describing a type system.
    • 6510 7mo ago
      walking away from the keyboard I thought I did a pretty poor job describing that one. Ill try an example, those always have the potential to describe things even worse. Imagine a type that is an outdoor datetimetemperature in utcc or a first name form value or a solitaire terms of service checkbox value. Have both the chewing gum balls in dispenser and a total weight of chewing gum balls in dispenser as well as a min-max weight per chewing gum ball in dispenser. Make it just as ridiculous as it sounds. If you can quantify it a type must be registered. If there is a pair of quantifications to be had register that too. The vision just expanded! Make for everything an xml implementation then do a ram drive and make all variables into files. The idea sounds so ridiculous it might actually work. Think of the employment opportunities!
  • Hackbraten 7mo ago
    There's more to a function than just types. It's not sufficient to know that the function outputs a baz 42.0. You have to understand which one. The oldest? The latest? The one that matches the foo and bar input parameters? I think that's the part where it remains difficult. Someone has to convey clearly what the semantics and side effects of the function are. Consumers have to read and understand it. Failing that, you get breakage.
• _doctor_love 7mo ago
  Great take, spot on. Very similar to Armin's post the other day about things taking time. The need for speed and its ill effects are being rediscovered (again). Reminds me of Carson Gross' very thoughtful post on AI also: https://htmx.org/essays/yes-and/ https://htmx.org/essays/yes-and/ [Y]ou are going to fall into The Sorcerer’s Apprentice Trap, creating systems you don’t understand and can’t control.
• leonardoe 7mo ago
  Just yesterday I was discussing many of the ideas presented here with a coworker. I had just walked out of a workshop led by $BIGTECHCOMPANY where someone presented the following toy example: A service goes down. He tells the agent to debug it and fix it. The agent pulls some logs from $CLOUDPROVIDER, inspects the logs, produces a fix and then automatically updates a shared document with the postmortem. This got me thinking that it's very hard to internalize both issue and solution -updating your model of the system involved- because there is not enough friction for you to spend time dealing with the problem (coming up with hypotheses, modifying the code, writing the doc). I thought about my very human limitation of having to write things down in paper so that I can better recall them. Then I recalled something I read years ago: "Cars have brakes so they can go fast." Even assuming it is now feasible to produce thousands of lines of quality code, there is a limitation on how much a human can absorb and internalize about the changes introduced to a system. This is why we will need brakes -- so we can go faster.
  • chatmasta 7mo ago
    The gap in your example is that a human had to realize the system is broken so that he could nudge the agent into fixing it. He can fix that gap by updating the agent to recognize when the system breaks. This now becomes the level at which he debugs… did the agent recognize the failure and self-heal, or not? And at that point, if the autonomous system breaks, realized it’s broken, and fixes itself before you even notice… then do you need to care whether you learn from it? I suppose this could obfuscate some shared root cause that gets worse and worse, but if your system is robust and fault-tolerant _and_ self-heals, then what is there to complain about? Probably plenty, but now you can complain about one higher level of abstraction.
• Hackbraten 7mo ago
  > There were precursors like Aider and early Cursor, but they were more assistant than agent. I use Aider on my private computers and Copilot at work. Both feel equally powerful when configured with a decent frontier model. Are they really generations apart? What am I missing?
• RodMiller 7mo ago
  [dead]
• jbs789 7mo ago
  > You realize you can no longer trust the codebase. This cuts to the problem and is excellent framing. A rogue employee can achieve the same, but probably less quickly, and we've designed systems to help catch them early.
• criscros 7mo ago
  Just looking at the LiteLLM disaster from yesterday and so much slop flowing around, I couldn’t agree more. It’s time to slow the fuck down!
• adamtaylor_13 7mo ago
  Once again I appeal: who is shipping code they don't understand? Those who do so are creating the problem, not the coding agent. I use agents all day, every single day. But I also push back, understand what was written, and ensure I read and understand everything I ship. Does it slow me down? Uh, yup. You bet. Yes, this article literally advocates for slowing the fuck down, but it also makes the coding agents out to be the problem, but they're not.
  • kermatt 7mo ago
    The problem is not the AI users who frequent this board and are shipping code they don't understand. It is the moronic MBA trained executives who can only think about speed, more speed, more revenue for less cost. Quality is an optional expense. A race where the finish line is the current fiscal quarter, to hell with everything after that. The "we can fix it later" Band-Aid over a tumor. Sensible engineers who look AI as another (potentially powerful) tool in the toolbox "aren't forward looking enough". I watched this happen in real time at my previous company, where every discussion about quality was interpreted as slowing down progress, and the only thing that was looked on favorably was the idea of replacing developers with machines - because they are "cheaper and faster". The logical minds here on HN are less prone to believing in magic and AI fairies, but they are often not the ones setting the rules. And the number of companies being run by people with critical thinking skills is getting smaller by the day.
  • the_snooze 7mo ago
    It's a matter of affordances. The path of least resistance with agents is to let it commit whatever it wants. That's a natural outcome of the design and implementation of agents. Yes, humans are accountable for the ultimate output. But so are the people who design and build these automation tools. As the saying goes, the purpose of a system is what it does.
  • badlogic 7mo ago
    i wrote the blog post and i also wrote pi.dev. i haven't written much code myself in the past 12 months. i'm not making coding agents out to be the problem. the entire last section keeps is basically "use a clanker for this and that". i'm making specific usage pattersn out to be the problem, and explain why those patterns can't work due to the way agents work.
• youknownothing 7mo ago
  I understand your pain, we're just a peak hype, I think people will learn to backtrack and use the tool in a more sensible way. It always happens. I remember when MongoDB and other NoSql databases came out, people went as far as to say that "SQL is dead" and refuse to use a normal SQL database for anything. Not even for the most obvious relational application. People would store everything as key-value pairs with no schema and do all the joins in the application layer. Fast forward 10 years and we're back to using SQL for most of our applications. NoSql hasn't disappeared, it has just been reduced to the nice where it's useful.
  • tau5210 7mo ago
    Also reminded me of Kafka (Kafka as a database!) and microservices (monoliths are evil, microservices are the future). I'm sure we can dig up similar hypes on various scales throughout the history of this industry... Perhaps so-called AI is slightly different from hypes like NoSql and microservices in that these reduced to usages that practically apply to only a fraction of the engineering population (albeit, it's still good for anyone to know about them even if we never use them), whereas AI will probably still affect us all even after the dust settles. Just in much less spectacular ways than is being trumpeted currently by some groups. Reminded me of No Silver Bullet: "There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity. "
    • pm90 7mo ago
      Technology moves fast and is prone to hype. While NoSQL and Kafka were certainly oversold, almost every mid-large scale tech company has at least one nosql system and kafka-like system in use. The proponents weren’t wrong, they oversold the impact. There is other tech that did completely change how we do things. CI/CD, Containers, Kubernetes, distributed tracing etc. are considered standard now (but weren’t not that long ago).
      • youknownothing 7mo ago
        Containers and Kubernetes are not as standard as we'd like to think. They're standard for things of certain size, but for small-to-medium there are a good amount of serverless options. For a moderately sized website, it's easier to just stick the thing in Vercel than having to deal with the complexity of Kubernetes. Of course, once you grow then you do need that complexity, but I'm willing to bet that many people who got onboard into it don't actually need it, they just did it because everyone else is doing it.
• Zachzhao 7mo ago
  > Coding agents are sirens, luring you in with their speed of code generation and jagged intelligence, often completing a simple task with high quality at breakneck velocity. Things start falling apart when you think: "Oh golly, this thing is great. Computer, do my work!". But the rough edges are temporary. Coding agents are becoming superhuman along certain dimensions; the progress is staggering. As Andrej Karpathy put it, anything measurable or legible can be optimized by AI. The gaps will close fast. The harder question is HCI. How do you expose this kind of intelligence in interfaces that actually align with human values? That's the design problem worth obsessing over.
• convexly 7mo ago
  I started writing down any of the technical decisions I needed to make before implementing them, usually just a sentence or two on what I'm choosing and why. I I looked back after 6 months and the pattern was embarrassing. I spent days agonizing over choices that turned out to be totally reversible and made quick decisions on things that actually mattered.
  • codybontecou 7mo ago
    How did you find patterns between these sentences?
    • convexly 7mo ago
      [dead]
  • driftnode 7mo ago
    The pattern you found between reversible and irreversible decisions is interesting. Did writing them down change how you made decisions going forward or did you just keep making the same mistakes with better documentation? Asking because I have tried something similar and found that knowing my pattern did not actually fix it. I still agonize over the wrong things.
    • convexly 7mo ago
      [dead]
• alvivar 7mo ago
  I was reading the article, but I don't think it's possible to slow the fuck down, honestly. There are too many people who need to discover for themselves what the limits of these AI models are when they push them far. Maybe some people have already reached that point after so much AI coding and are now warning us; they pushed so hard that they understand the limits. But this is the kind of thing you need to experience on your own. You need to experiment, learn, test the limits, think for yourself, take as many steps back as you need.
  • alt227 7mo ago
    > There are too many people who need to discover for themselves what the limits of these AI models are when they push them far Why? Next week a new version of Claude and GPT will come out and the limits will change again. Are you really fully testing every new version of every LLM agant to see where its limits are? Those of us old enough to have seen this cycle before know its a fools game trying to keep up with development pace in the initial bubble. Its much better to wait for development and progress to start plateuing and then its easier to see the wood for the trees.
    • alvivar 7mo ago
      Just curious, what have you seen before that was like AI?
      • alt227 6mo ago
        ai in the sense of a new and immature techology which is constantly evolving and changing? How about anything on the web? HTML boon in the 90s. Wordpress and PHP frameworks in the 00's, Javascript frontend shadow doms which require hydration in the 10's, node.js and javascript on the server etc etc. All techonologies which were not worth jumping in during the initial boom becasue it changed so rapidly and it meant relearning concepts with every new release. Its the same with ai, some prompt which gave amazing results last year might not now, and you need to be aware of what has changed and the better way to do it now. I prefer to jump in later when things are more mature and I can learn the most stable and liked way of doing something, instead of having to relearn the same thing multiple times as it changes.
• magicmicah85 7mo ago
  This entire article is basically saying "What are we doing? What's going on?" and I could not agree more. My own experience with coding agents has been FOMO cause if I don't have fifteen claude tabs running with OpenClaw, I'm not going to make it. I much prefer keeping myself in the loop and being active with the process than handing it off to deus ex machina and seeing the eventual results that may be what I like and maybe not what I like. I do like the tips on how to work with agents for delegation. Let it do boring things. The deterministic things where you know what the result should look like each time.
• gurachek 7mo ago
  The compounding booboos bit is the key insight here. Humans are a bottleneck and that bottleneck is actually load-bearing. You feel the pain of bad decisions slowly enough to course correct. I've been building the same AI product for months - a coaching loop that persists across sessions. Every few weeks someone ships a "competitor" in a weekend. Feature list looks similar. The difference is everything that breaks when a real user comes back for session 3 or 4. Context drifts, scores stop calibrating, plans don't adapt. None of that shows up in a demo. You only find it after sitting in the same codebase for weeks, running real sessions, getting confused by your own data. That's the friction the post is talking about and I don't think you can skip it.
  • dgb23 7mo ago
    I like the framing of „context drift“. It describes the problem in LLM/agent terms. Similar how „tech debt“ describes the same mechanism in business terms.
• cobbzilla 7mo ago
  articles like these make me think that coding with AI is a little bit like writing Perl code: if you know what you’re doing, you can do brilliant things very quickly, but if you don’t, you can make spaghetti very quickly.
  • Aldipower 7mo ago
    That's a great analogy and is something I experience every second day. Once a week I do a full second pass of a manual review on the generate AI code. Very often I find myself in a situation were I do not really understand the recently AI generated code anymore or find it hard to read, so I either rewrite it manually or tell the LLM to make it more readable. And this is just one part. If you really would like to get a long-term maintainable software product, AI code suddenly isn't that much of a speed boost anymore. Maybe a little bit, but the initial wow effect is very ephemeral.
• anishgupta 7mo ago
  building because its always the dopamine from the coding agents than the problem getting solved. Github contribution graph is rigged because higher number of commits doesnt make you a better engineer. We needed this blog, ty
• memolife23 7mo ago
  [dead]
• emmitska 7mo ago
  "Do me a SOLID, YAGNI, give me a DRY KISS" — that's been my coding philosophy for 20 years. So when I came back to building after a long detour, I couldn't stomach watching agents confidently generate 400 lines where 40 would do. What I found is that the discipline was the feature, not the obstacle. I ended up pair programming closely — not because I distrusted the agent, but because I couldn't let go of the architecture. The internet kept telling me to stop going into the weeds. Your article explained why that instinct was right. Everyone else is happy grinding in third the whole race. I went 1, 2, 3 — and because I didn't bury myself getting out of the driveway, I still get to shift into fourth.
  • chr15m 7mo ago
    As well as pair programming with the AI, you can explicitly put those principles in AGENTS.md and the stochastic code generator will pay attention and be less verbose.
    • jillesvangurp 7mo ago
      Exactly. There's a difference between vibe coding and agentic software engineering. One is just prompting and hoping for the best. It works surprisingly well, up to a point. And then it doesn't. If that's happening to you, you might be doing it wrong. The other is forcing agents to do it right. Working in a TDD way, cleaning up code that needs cleaning up, following processes with checklists, etc. You need to be diligent about what you put in there and there's a lot of experience that translates into knowing what to ask for and how. But it boils down to being a bit strict and intervening when it goes off the rails and then correcting it via skills such that it won't happen again. I've been working on an Ansible code base in the past few weeks. I manually put that together a few years ago and unleashed codex on it to modernize it and adapt it to a new deployment. It's been great. I have a lot of skills in that repository that explain how to do stuff. I'm also letting codex run the provisioning and do diagnostics. You can't do that unless you have good guard rails. It's actually a bit annoying because it will refuse to take short cuts (where I would maybe consider) and sticks to the process. I actually don't write the skills directly. I generate them. Usually at the end of a session where I stumbled on something that works. I just tell it to update the repo local skills with what we just did. Works great and makes stuff repeatable. I'm at this point comfortable generating code in languages I don't really use myself. I currently have two Go projects that I'm working on, for example. I'm not going to review a lot of that code ever. But I am going to make sure it has tests that prove it implements detailed specifications. I work at the specification level for this. I think a lot of the industry is going to be transitioning that direction.
• casey2 7mo ago
  People always talk about velocity and speed debating slowing down and speeding up. But the wider tech industry hasn't solved any real problems in a decades, even in mobile things are pretty much the same. We are well into the optimization stage. AI is the only growth industry of the last decade, and it's the only thing people talk about, we've been so long without growth that people are scared of it now.
• voidUpdate 7mo ago
  I feel like people are getting too comfortable saying "clanker". It's a word that was literally conceived as a slur against a group, but I guess people feel ok using it because its not aimed at humans?
  • bayindirh 7mo ago
    What's the problem with using it in the context of AI? Will it get offended, too? Will it track people down and refuse orders, or give poisoned output?
    • voidUpdate 7mo ago
      No, but I just feel like calling something by a word that is designed to offend doesn't reflect particularly well on the person saying it, no matter if the target has the ability to comprehend it?
      • bayindirh 7mo ago
        Yeah, that's a good point. I feel the same about the person who talks that way, too. I personally refrain from offending people on purpose, but not being a native English speaker sometimes betrays me in judging how offensive a word is perceived by the natives.
        • voidUpdate 7mo ago
          From what I've seen, the natives don't generally perceive the word as offensive, as it was originally used in star wars (I believe) against fictional robots, and it has since been used against LLMs and such like. But it just seems a bit distasteful, like using a word for someone to try and offend someone, when they dont understand that word in their native language
  • dgb23 7mo ago
    That’s a very deliberate style in the specific article. It’s a polemic, so the choice of words is provokative.
• ChrisMarshallNY 7mo ago
  I am not [yet] comfortable, working with agents. I work interactively, with a chat interface. It’s definitely made a significant difference, for me. But the LLM regularly makes lots of mistakes (sometimes, due to me, giving it bogus information). I can’t imagine just letting it do the whole thing, as a “black box.” I’m old enough to remember the advent of ATMs. When they first came out, they were universally free, for years. Once people got hooked, the fees began to appear.
• puttycat 7mo ago
  > Companies claiming 100% of their product's code is now written by AI consistently put out the worst garbage you can imagine. Not pointing fingers, but memory leaks in the gigabytes, UI glitches, broken-ass features, crashes. Spotify's CEO recently bragged about the app's code being written almost entirely by AI. Just saying.
• chrsw 7mo ago
  That's a tortoise, not a turtle.
• drzaiusx11 7mo ago
  The article touches on this but I think the key takeaway is that humans need to properly manage the _scope of work_ for their agentic teams in order to have any chance of a successful outcome. Current gen agents need to be provided with small, actionable units of work that can _easily_ be reviewed by a human. A code deliverable is made easy to review if the scope of change is small and aligned with a specific feature or task, not sprawled across multiple concerns. The changes must be ONLY related to the task at hand. If a PR is generated that does two very different things like fix linting errors in preexisting code AND implement feature X, you're doing it wrong. Or rather, you're simply gambling. I'd rather not leave things up to chance that I may miss something in that new 10000LOC PR. It's better that a 10000LOC never existed at all. YOLOing out massive, sweeping changes with agents exceed our own (human) "context windows" and as this article points out, we're then left with an inevitable "mess." The untangling of which will take an inordinate amount of time to fix.
  • codyb 7mo ago
    At which point you've gained very little efficiency in most large organizations given that by the time you're actually doing development work at the ticket level 90% of the project timeline (identifying issues, prioritizing, creating requirements, architecture, ticket breakdowns, coordination, etc) has already passed. If AI can enable engineers to move through the organization more effectively, say by allowing them to work through the service mesh as a whole, that could reduce time. But in order to evaluate code contributions to any space well, as far as I can tell, you still have to put in leg work even if you are an experienced engineer and write some features which exposes you to the libraries, quirks, logging/monitoring, language, etc that make up that specific codebase. (And also to build trust with the people who own that codebase and will be gatekeeping your changes, unless you prefer the Amazon method of having junior engineers YOLO changes onto production codebases without review apparently... holy moly, how did they get to that point in the first place...) So the gains seem marginal at best in large organizations. I've seen some small organizations move quicker with it, they have less overhead, less complexity, and smaller tasks. Although I've yet to see much besides very small projects/POCs/MVPs from anyone non-technical. Maybe it'll get to the point where it can handle more complexity, I kind of think we're leveling off on this particular phase of AI, and some headlines seem to confirm that... - MS starting to make CoPilot a bit less prominent in its products and marketing - Sora shutting down - Lots of murky, weird, circular deals to fund a money pit with no profits - Observations at work It's really kind of crazy how much our entire society can be hijacked by these hype machines. My company did slow roll AI deployment a bit, but it very much feels like the Wild West, and the amount of money spent! I'm sure it's astronomical. Pretty sure we could have hired contractors to create the Chrome plugin and Kafka topic dashboard we've deployed for far cheaper
• aswegs8 7mo ago
  I love the use of the term clanker. There is just no one there that can be offended by this.
• bustah 7mo ago
  [flagged]
• boxerbk 7mo ago
  The cognitive surrender study from UPenn highlights the risks of agents producing all of the code - eventually you give up verifying the result. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6097646 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6097646 There’s going to be a bottleneck on what is verified because over time we will realize how much tail risk we are creating by simply surrendering our own agency to the agents - https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6298838 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6298838
• ramon156 7mo ago
  Now that the pop media is finally letting go a bit of the topic "AI is the new X!", I'm starting to notice a few more high quality posts seeping through. This is one of them. I really want to read people's perspectives on LLM's, it was just impossible to find quality when everyone wanted to give their opinion. This is the worst on LinkedIn, where mentioning AI gives you free "brownie points" (I have yet to figure out what Managers gained from this). I don't care what you use it for, unless you have a new perspective I can ponder over. Regardless, nothing is black and white, and most things are a shade of grey. LLM's have been more positive leaning, making the CTA for working on something a lot simpler. Although, I end up refactoring my day away (which I am fine with, I quite enjoy putting the dots on the i's).
• ramesh31 7mo ago
  Why is it that every single one of these think pieces feel terminally 3 months behind on the times?
• yrashk 7mo ago
  I've been working on some parts of this problem, specifically capturing and retaining other semantically useful layers of the systems we build as we build and maintain them. By introducing progressive semantically enriching layers (starting with prose, reasoning and terminology and going all the way into specifying interaction surfaces), we can reduce the dark matter between spec and code, make code more disposable – if your semantics live in the spec layer rather than the implementation, you can throw away and regenerate the implementation without losing understanding – and, critically, give LLMs a way to navigate a graph of knowledge instead of gobbling up walls of text. https://clayers.com https://clayers.com -- https://github.com/CognitiveLayers/clayers https://github.com/CognitiveLayers/clayers
• chrisweekly 7mo ago
  > "The point is: let the agent do the boring stuff, the stuff that won't teach you anything new, or try out different things you'd otherwise not have time for. Then you evaluate what it came up with, take the ideas that are actually reasonable and correct, and finalize the implementation. Yes, sure, you can also use an agent for that final step." Agreed w this TLDR. TFA has some good observations, but the repeated use of the word "booboos" (dozens of times) made it almost unreadable.
• xivzgrev 7mo ago
  There's currently a billboard up in San Francisco that basically says "use AI to reduce your saas costs". And I'm thinking - has anyone actually done that for something meaningful? Replacing salesforce as your crm or replacing Shopify as your e-commerce platform? I get the hype but AI doesn't remove accountability, it just moves it up. Oh you can do with 1 person what 3 people used to do? Great, that 1 person is now accountable for 3 person's jobs. And people are naturally uncomfortable with that - you need to understand what's going on and be able to investigate / fix. It's different than say, weaving machines replacing jobs because weaving machines were consistent. 1 person could confidently produce what x weavers could before. But AI is not, and that variability in output & quality introduces massive friction. So as of now, in both software and people, there's a real limit to how much AI can replace because the remaining people still are equally accountable.
  • 52-6F-62 7mo ago
    tick tock tick tock...
  • hbarka 7mo ago
    Vendor lock-in is real and it’s scary. You are helpless to the constant price increases and each passing renewal you get deeper and deeper into the lock-in. Here’s to the day when someone clever with AI can disintermediate this situation. You don’t have to vibecode your own CRM but imagine a deterministic harness that lets you lego-block CRM functions like lead management, opportunity tracking, contact list, campaigns. There shouldn’t be a moat anymore.
    • crisnoble 7mo ago
      Moving the vendor lock-in to the AI provider and exponentially increasing the pain of migration by locking all teams and all services in at once.
      • deleted 7mo ago
        [deleted]
      • 7mo ago
• Anamon 7mo ago
  > Because the simple act of having to write the thing or seeing it being built up step by step introduces friction that allows you to better understand what you want to build [...] I would go further and remove that second option. If the code is important, LLM support or not, write it yourself. At least for me, there is a clear qualitative difference in thinking between typing the code and watching it being typed, even if I follow along with every line. If I type it, my brain is constantly questioning whether what I'm doing is correct. What are the edge cases here? Is this introducing a vulnerability? Am I getting the right data from the right place? By watching an agent or someone else code, the mindset is different. I'm checking someone else's work under the implicit assumption that they have some idea of what they're doing and I'm just reviewing mostly for superficial stuff. I can force myself to ask those other questions, but it takes conscious effort and isn't sustainable over long sessions. I play around with agentic coding, but I'm always shocked at how much worse the result is compared to working in a separate chat and typing (not pasting!) the suggestions. In the direct comparison, it's easy to see how agentic code turns so incredibly shit so ridiculously fast.
• Cherlyn2 6mo ago
  [dead]