Discussion
Thoughts on slowing the fuck down
0xbadcafebee: [delayed]
ex-aws-dude: Eh I think its self-correcting problemCompanies will face the maintenance and availability consequences of these tools but it may take a while to learn those lessons
apical_dendrite: 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: True but there is a limit, there are still levels of quality
markus_zhang: 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.
abletonlive: > 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.
latchkey: > 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 termPull the bandaid off quickly, it hurts less.
jaffee: > 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"?
badlibrarian: 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: > People answered this wrong in the Ruby era, they answered it wrong in the PHP eraAren't you conveniently ignoring the fact that there were people saw through that and didn't go down those routes?
sjkoelle: i just wish someone would explain why i prefer cline to claude code so much
ketzo: 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.
bluGill: 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 unless - I do most of my coding with an agent, but I don't trust it until I verify every line.
pixl97: We live in a world where every line of code written by a human should be reviewed by another human. We can't even do that! Nothing should go straight to prod ever, ever ever, ever.
latchkey: > Nothing should go straight to prod ever, ever ever, ever.I'm one-shotting AI code for my website without even looking at it. Straight to prod (well, github->cf worker). It is glorious.
bikelang: Were people reviewing your hobby projects previously? Were you on-call for your hobby website? If not - then it sounds like nothing changed?
kemiller2002: Maybe back in the beginning, but I don't think it's an engineering discipline now. I don't think that's bad though. I always thought we tagged on the word "engineer" so that we could make more money. I'm ok with not being one. The engineers I've known are very strict in their approach which is good since I don't want my deck to fall down. Most of us are too risky with our approach. We love to try new things and patterns, not just used established ones over time. This is fine with me, and when we apply the term "engineer" to work, I get a little uneasy, because I think it implies us doing something that most of us really don't want to do. That is, absolutely prove our approach works and will work for years to come. Just my opinion though.
QuantumNomad_: I’ve had jobs where my title was “software engineer”, but I never refer to myself as such outside of work. When I tell others what I do, I say I am a software developer. It may seem a pointless distinction, but to me there is a distinction.Neither myself nor the vast majority of other “software engineers” in our field are living up to what it should mean to be an “engineer”.The people that make bridges and buildings, those are the engineers. Software engineers, for the very very most part, are not.
SpicyLemonZest: It's a conversation I've had many times in my career and I'm sure I'll have many more. We've got code that seems plausible on a surface level, at a glance it solves the problem it's meant to solve - why can't we just send it to prod and address whatever problems we find with it later?The answer is that it's very easy for bad code to cause more problems than it solves. This:> Then one day you turn around and want to add a new feature. But the architecture, which is largely booboos at this point, doesn't allow your army of agents to make the change in a functioning way.is not a hypothetical, but a common failure mode which routinely happens today to teams who don't think carefully enough about what they're merging. I know a team of a half-dozen people who's been working for years to dig themselves out of that hole; because of bad code they shipped in the past, changes that should have taken a couple hours without agentic support take days or weeks even with agentic support.
badlibrarian: 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 is what we do. It's what makes us us.
ontouchstart: 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/d43591213e0d3087369298f...(Note: pi was written by the author of the post.)Now it is time to read them carefully without AI.
ontouchstart: 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.
travmiller: Exactly. The amount of bs bloatwork anywhere I've ever worked is insane and growing. We need to move on.
pixl97: 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.
simonw: 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: ... people like that have a way of writing articles that don't seem to say anything at all.
guzfip: > 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: 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.
guzfip: > Name a single time doomers were right about anything.- NFTs- Surveillance schizos- Global Pedophile Cabal schizos- Anyone who didn’t believe we were a year out from Star Trek living when LLMs first started picking up steam- People who predicted the flood of people entering Software via bootcamps, etc. would never cause any problems because their god of software is consuming the world too quickly for supply and demand to ever be a real concern.- Anyone amongst the sea of delusional democrats who did indeed believe Trump could win a second term.All of those doomers were vindicated, and that’s just recently.
api: I was thinking the other day about why a "global pedophile cabal" would be a thing. I still think that phrase overstates it a bit, but not that much.Committing a crime with someone bonds you to them.First, it's a kind of shared social behavior, and it's one that is exclusive to you and your friends who commit the same kinds of crimes. Any shared experience bonds people, crimes included. Having a shared secret also bonds people.Second, it creates an implied pact of mutually assured destruction. Everyone knows the skeletons in everyone else's closet, so it creates a web of trust. Anyone defecting could possibly be punished by selectively revealing their crimes, and vice versa. Game theoretically it overcomes tit-for-tat and enables all-cooperate interactions, at least to some extent, and even among people who otherwise don't like each other or don't have a lot in common.Third, it separates the serious from the unserious. If you want to be a member of the club, do the bad thing. It's a form of high cost membership gating.This works for other kinds of crimes too. It's not that unusual for criminal gangs to demand that initiates commit a crime and provide evidence, or commit a crime in front of existing members. These can be things like robbery, murder, and so on. Anyone not willing to do this probably isn't serious and can't be trusted. Once someone does do it, you know they're really in.It naturally creates cabals. The crime comes first, the cabal second, but then the cabal can realize this and start using the crime as a gateway to admission.
no_shadowban_3: > I'm not even sure building software is an engineering discipline at this point. Maybe it never was.Just another reason we should cut software jobs and replace them with A(G)I.If the human "engineers" were never doing anything precisely, why would the robot engineers need to?
ge96: I'm similar except for me reason is no degree. So some jobs eng others just developer... although my current job I'm a "technology specialist" which is funny. But I'm getting paid so whatever.Most recently I wrote cloudformation templates to bring up infra for AWS-based agents. I don't use ai-assisted coding except googling which I acknowledge is an ai summary.A friend of mine is in a toxic company where everyone has to use AI and they're looked down upon if they don't use it. Every minute of their day has to be logged doing something. They're also going to lay off a bunch of people soon since "AI has replaced them" this is in the context of an agency.
SoftTalker: > I'm not even sure building software is an engineering discipline at this point. Maybe it never was.It isn't. Show me the licensing requirements to be a "software engineer." There are none. A 12 year old can call himself a software engineer and there are probably some who have managed to get remote work on major projects.
JoshTriplett: > It isn't. Show me the licensing requirementsThat's assuming the axiom that "engineer" must require licensing requirements. That may be true in some jurisdictions, but it's not axiomatically or definitionally true.Some kinds of building software may be "engineering", some kinds may not be, but anyone seeking to argue that "licensing requirements" should come into play will have to actually argue that rather than treat it as an unstated axiom.
PaulHoule: There's this interesting issue that we've never had occupational licensing for software developers despite the sheer incompetence that we see all the time.On one hand there's an approach to computing where it is a branch of mathematics that is universal. There are some creatures that live under the ice on a moon circling a gas giant around another star and if they have computers they are going to understand the halting problem (even if they formulate it differently) and know bubble sort is O(N^2) and about algorithms that sort O(N log N).On the other hand we are divided by communities of practice that don't like one another. For instance there is the "OO sux" brigade which thinks I suck because I like Java. There still are shops where everything is done in a stored procedure (oddly like the fashionable architecture where you build an API server just because... you have to have an API) and other shops where people would think you were brain damaged to go anywhere near stored procs, triggers or any of that. It used to be Linux enthusiasts thought anybody involved in Windows was stupid and you'd meet Windows admins who were click-click-click-click-clicking over and over again to get IIS somewhat working who thought IIS was the only web server good enough for "the enterprise"Now apart for the instinctual hate for the tools there really are those chronic conceptual problems for which datetime is the poster child. I think every major language has been through multiple datetime libraries in and out of the standard lib in the last 20 years because dates and times just aren't the simple things that we wish they would be and the school of hard knocks keeps knocking us to accept a complicated reality.
latchkey: > There's this interesting issue that we've never had occupational licensing for software developers despite the sheer incompetence that we see all the time.I'm laughing over the current Delve/SOC2 situation right now. Everyone pulls for 'licenses' as the first card, but we all know that is equally fraught with trauma. https://xkcd.com/927/
SoftTalker: > 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, crashesOne 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: 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 fact is that now, because of the ease of pushing your fix to everything without requiring anything 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.
bensyverson: 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.
MisterTea: > 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.
postexitus: You sound like you are working on unimportant stuff. Sure, go ahead, push.
bikelang: Were you not reviewing every line when a human wrote it before it went to prod? I think the output of these tools is about as good as a human would write - which means it needs thorough review if I’m going to be on the hook to resolve its issues at 2AM.
alecbz: Yeah in many places we had two humans with context on every line, and now we're advocating going to zero?
AnimalMuppet: Depends on the country. In some countries, it is a legal axiom (or at least identity).For the other countries, though, arguing "some countries do it that way" is as persuasive as "some countries drive on the other side of the road." It's true, but so what? Why should we change to do it their way?
ehsanu1: That a personal website? Prod means different things in different contexts. Even then, I'd be a bit worried about prompt injection unless you control your context closely (no web access etc).
latchkey: Prompt injection?! Give me an example.
