Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Stack Overflow conveniently defining the problem in a way that makes SO the answer. The irony is that the kind of code review that LLMs make possible would never have been doable on SO lest you be accused of trying to 'outsource the work'.
Now agentic coding produces the full 100 line change, and SO says the real crisis is that nobody has reviewed it properly. SO was fully responsible for creating the culture where no one wanted to use it.
by kristianc - Stack Overflow was such a tool, prior to being bought by Prosus and dealing with Monica so absurdly.
Trust lost is rarely ever regained. That they publish a piece like this on the Stack Overflow blog is insult to injury.
by zahlman - I operate on zero trust because I find that people won't trust me regardless of what their stated reasons are. They just feel uncomfortable. On top of that, people will hallucinate things in order to not trust me.
I update my toolset all the time. It always results in discomfort and backlash but people don't understand that the goal isn't their perception or trust. It's about skill, ability, and execution. This idea probably won't get me promoted but it will get me paid. I am not attached to tools because I learned the hard way that they will always find a way to take them from me.
Zero trust is a better alternative for people like me. In terms of cybersecurity, being attached to a tool is crutch because fatal flaws in every design are frequently found. As it relates to agentic AI, I never select the "Yes, trust the AI and let Claude execute arbitrary commands in a non-sandboxed environment" option. However, I frequently utilize agents, but I'm not going to have the "Jesus, take the wheel" moment with them right now. That being said, AI is a very helpful tool that helps me create boilerplate code, brainstorm ideas, and review my work. I also anticipate when AI can, in fact, take the wheel and I'm looking forward to it.
Parallel to this, I also know that developers often disagree, and I'm not casting judgement on anyone for being attached. If it's Turing-complete, then I have the background to complete the task. In these scenarios, I just adopt whatever tools work best in team building because, in my own words, I'm not too attached to the way I do things.
by kittikitti - What constitutes taking the wheel? Skip permissions in a proper sandbox is fine IMO. There is a small amount of risk I admit though.by hahahaa
- I'm not sure the difference changes the conclusion but I think projects demanded certain workflows and resultant processes, not the other way around. That's why Jetbrains has so many workstream specific IDEs that sold very well. The processes didn't go away but a lot of us changed our IDE surface. Those processes still need to exist, largely, but the way in which we invoke them is moving and changing. To some degree, the processes are also changing because other factors are changing outside of the tooling.
For example, I use Codex and Claude Code by default, but when I need to look at the API surface, read tests, etc I have those tools setup to open Zed. Zed is also rapidly evolving in the other direction, where it's closer to the tools that are opening it. It won't be long, I think, until I can continue my prompt from inside Zed.
by oooyay - As a teacher I know for a fact some people just learn faster than others. So I think part of why developers get attached to tools is because learning takes time. Some people can pick up new tools in a day. I can't. I feel like new tools are created faster than I can learn them.by pianopatrick
- All tools require time to learn, but not all tools gain attachment, even when one has committed to learning the tool. From my observation, attachment is formed when one finds something about a tool that feels like a secret insight or advantage that is being overlooked by most others, thus establishing a tribe of those who have "seen the light", with the tool becoming the identity of the tribe.by win311fwg
- There is a great article called "Manual Work is a Bug: Always be Automating" [0] that was written in the pre LLM era for technical operations teams. I would argue that it is just as relevant today as it was then.
To summarize:
- start making a list of the manual tasks you do
- if those tasks involve running command line tools, add an item with the commands you run
- if they are manual tasks, add those too
- over time, keep automating one portion of the list at a time e.g. the commands can become a script, the manual tasks can become tickets to another team to automate etc
At the end of the above process you have a series of automated steps that become a system instead of a bunch of items in someone's head.
In my mind, the only thing that changed with LLMs is that it's faster to create the scripts and some of the manual tasks can be done by the LLM until you get a script to do that too.
We invented code to help do "mechanical" tasks over and over again in the same way. Why replace that with agentic systems??
P.S. This is also why the whole "just commit the prompt, bro" is such utter hogwash
by alexpotato - Like all advice, A.B.A. some pretty serious flaws if you apply it too universally. Automated solutions tend not to replacing manual work perfectly or completely. They do most of the same things, and the distinction tends to be forgotten. Maybe a human goes in and fixes things for a bit afterward, but that doesn't last. Eventually the accessible 90% is declared good enough and people forget that the rest is even possible.
The first case of large scale automation demonstrates this very well. Medieval manuscripts looked like this [0]. You can see the imperfections, but it's still a beautiful book. Gutenberg bibles omitted the scribe in favor of automated printing, but humans remained involved with the creative details in illumination and rubrication. The result is genuinely beautiful [1]. The works that were printed a century later rarely featured this kind of post-print human involvement [2]. This is still better than most of what's printed today, but it's a clear step down.
Now, there's a reasonable argument to be made that the quality differences don't matter for books and certainly don't outweigh the cost advantages. But imagine someone at your passport office has taken A.B.A. to heart and automated 90% of the job. Over time, the organization will stop handling all the edge cases and. But the edge cases didn't stop happening, they're just no longer visible. Beyond a certain scale (e.g. Google and other FAANGs), those inevitable failures manifest as seemingly capricious behavior that makes everyone hate your system and produces outcomes no human involved actually wants.
[0] https://i0.wp.com/blogs.princeton.edu/notabilia/wp-content/u...
[1] https://ff-65a4.kxcdn.com/assets/uploads/OriginalDocs_old/98...
[2] https://www.prepressure.com/images/Nieuwe-Tijdinghe-newspape...
- Im typing this in GVim thanks to Tridactyl using my new mechanical keyboard running a ZMK firmware I just built via Github actions (or directly via ZMK Studio).
This is ridiculously complex to just type a few paragraphs. Nobody in their right mind would invest this amount of yak shaving... and yet I do so because I bet, rather confidently, that in few years, heck few decades, all those tools will be different (or maybe not, I still use Vim on my server, desktop but even mobile phone) but the lessons will remain practical.
IMHO the trust comes from trust yes but also more directly plain ownership.
by utopiah - > typing this in GVim thanks to Tridactyl
Thanks for the heads-up that such a thing is possible. I will definitely be investigating it.
by zahlman - When I see “stack overflow blog” the brand encodes distrust. I remember when they removed links to meta and replaced them with the corporate blog with low quality PR and political agitation.
- > When I see “stack overflow blog” the brand encodes distrust.
Incredible, in a way, that you still see it as a brand. I honestly thought it was a 10 years old blog post somehow making it to frontpage (as some old blog posts sometimes do on HN).
Who still uses DeadOverflow-full-of-outdated-answers? (outdated and often just plain wrong too)
I haven't been there in like 15 years or something. Feels like ages.
- This is a lot of words to say absolutely nothing. Seems apropos for Stack Overflow though.by inigyou
- I feel like these abstractions like "CI might not work well in the era of agentic tooling" are fine for thought-leadership posts but there's so much hands-on work to be done. The last word on AI computer use shouldn't be bash utils that were already feature-complete before MJ recorded Thriller.
There is some movement in this direction--there is a new 'gh' subcommand called repo read-file for example, that lets agents view a file without cloning a repo. And I made something called venetianblinds that shows equidistant samples of a file. In combo they work pretty well:
gh repo read-file sqlite3.c --repo clibs/sqlite --output sqlite3.c && npx github:firasd/venetianblinds sqlite3.c
--- sample 2/20 char 283427 line 5855 col 53 range 283367:283487 le]. ** ** ^Closing a BLOB shall cause the current transaction to commit ** if there are no other BLOBs, no pending prep ^by firasd - MCP is the answer to not using bash, right?
Bash is a great control surface anyway for LLMs as it is wordy and powerful.
by hahahaa - I've found the process of building good reliable CI that thoroughly covers everything has been greatly improved by LLMs. There's so much tedious plumbing and grunt work involved in building CI and automated testing infrastructure for bespoke products that they can handle just fine while you concentrate on the important bits - I would say it's an area where agentic workflows are even more suited than regular product code.by p1necone
- Hand-crafted, domain-specific tools massively outperform general purpose ones.
Shell execution and raw DOM access are great for a backstop, but you can go so much further with just a little bit of translation and delegation around the environment.
I think browser automation is probably the most apt scenario. Often a human who understands how a page is meant to be perceived can transform a megabyte of raw web content down to a few hundred bytes of plaintext without any reduction in fidelity. This can be achieved using deterministic code that is guaranteed to provide a perfect transform every time.
The performance difference between raw DOM access and curated plaintext is like a step function. With raw access you get maybe 10-15 steps into a complex workflow before the wheels pop off. With curated access I've seen it go 100+ screens without issues.
Simply managing the token bloat is probably the most important objective here. If that's all you focus on it will probably go really well.
by bob1029 - There's this great blog post by Joel Spolsky from 2000 [1], where he essentially argues that controlling your environment makes you happy. He writes about his summer job in a bakery and how the dough mixers would be so unpredictable and how frustrating that was. I think AI agents are quite similar to a lot of folks, they change significantly with each major model update and even every day as the vendor tweaks the system prompts and settings, so you never feel "in control", it's more like pushing buttons on some blackbox and hoping the right stuff happens inside. Most people are unhappy about that as it takes away the mastery and craft aspect of software development and makes them managers of unpredictable AI tools. I certainly get this feeling even though I like AI in general, but having days where everything goes so well working with the agent and then days where nothing really seems to work and not knowing why is quite frustrating.
1: https://www.joelonsoftware.com/2000/04/10/controlling-your-e...
by ThePhysicist - This is, I think, a big part of why I wouldn't want to remove myself from the loop.by zahlman
- > and even every day as the vendor tweaks the system prompts
I just patched Claude Code's system prompts, pinned the version and stopped upgrading without first dissecting and auditing the executable. Even discovered Anthropic can remotely inject strings into the system prompt via some "growth book" or something. Neutralized that too.
Things got a lot better after I started doing this. It straight up fixed Opus 4.6, and Opus 4.8 got more consistent in my subjective experience.
Sadly there's nothing I can do about Anthropic's server side "system reminders" whenever some prompt trips their classifiers or whatever.
I'm in the process of switching to OpenAI and Codex. The open source harness is a breath of fresh air. We'll see how that goes.
- This article is a bit rambly so I'll just focus on some things from the beginning:
>If your kitchen knife kept changing shape, weight, and edge, you’d have to relearn it every time; that’s a hard tool to build trust in.
This concept was betrayed far before agentic tools, with a much earlier concept: Automatic updates.
To use one product as an example: When Windows ME and Windows Vista came out, people hated them even more than they usually hated Windows, so they did not use them. Microsoft was forced to respond by making a not-quite-as-bad OS in Windows XP and a pretty good OS in Windows 7 respectively. No longer is that an option, your workflow will simply be interrupted by automatic updates.
>Vim and Emacs, in their infinite customizability, can be molded to fit your exact hand and workflow
Vim is one major exception to the automatic update problem. I trust vim not just because it can do a ton of shit (although that is certainly nice), but because unlike most other software, its UI doesn't change unless I tell it to change. Aside from switching from vim to neovim (my decision, not a forced update), my muscle memory from a couple decades ago still works today.
by MiddleEndian - > This concept was betrayed far before agentic tools, with a much earlier concept: Automatic updates.
This is a huge complaint for me. I had to disable JetBrains from automatic updates because they wont stop trying to force their horrendous new UI on me, and the "Classic UI" plugin I have to use to keep my IDE working the way I have been used to for the past 15 years is never updated at the same time.
by devmor - > its UI doesn't change unless I tell it to change
Vim and emacs aren't unique in this. In fact quite a few non-commercial FOSS projects don't make significant changes to the UI. I think there are (at least) a couple of reasons for that. First, there isn't usually pressure to constantly attract new users, so there isn't as much pressure to change the UI to make it easier or simpler for new users, or follow UI trends. Secondly, the projects often don't have dedicated UI/UX designers who want to try out new ideas or make their mark, etc.
However, these aren't strictly good things, you can end up with an unintuitive UI with a steep learning curve that is hard to learn.
by thayne - What's really freakin cool about AI development is other people can check rules into the repo which change the shape of my tools :)by denkmoon
- > Vim is one major exception to the automatic update problem.
Except for one thing that pissed me off a great deal. I am not a true vim user, though I use it from time to time, because it is everywhere and it works through ssh. At some point they introduced "visual mode", and it turns on when you start using the mouse, it broke the way I used the mouse copy-paste in vim. I know I can do "set mouse-=a", but when I am just using vim as "the standard text editor" (sorry ed), I don't want to configure anything as it is usually a one shot job.
I never asked for that, at some time, it just happened. I guess as a major upgrade, but the thing is, something changed that I didn't want to change.
I understand the reason for this change, also https://xkcd.com/1172/ but I just wanted to say that even vim is not immune.
Some tools are immune though. Usually command line tools used in scripts. For example "apt-get" doesn't change, but "apt" does. "apt-get" is what you use when you want a stable interface (especially scripts), "apt" is for when you want something nicer.
by GuB-42 - > When Windows ME and Windows Vista came out, people hated them even more than they usually hated Windows, so they did not use them. Microsoft was forced to respond by making a not-quite-as-bad OS in Windows XP
This timeline doesn't seem to make sense, as Windows XP came out in 2001, and Windows Vista in 2006-2007. Maybe you are referring to Service Pack 3 in 2008?
by musicale - > Microsoft was forced to respond by making a not-quite-as-bad OS in Windows XP
Prior to XP, MS had two lines of Windows: the Windows 9x kernels and the Windows NT kernels. Windows XP was meant to be the merger of the two lines, adapting Windows NT to have compatibility with Windows 95 and Windows 98 features. Unfortunately, Windows XP development went overlong, so MS wedged in Windows ME to give a stop-gap release until XP could actually be released.
by jcranmer - A big driver of automatic updates in the late 00s and early 10s were people who never updated their OS or browser and were getting compromised left and right. As I recall, one of the earliest widespread users automatic updates was Google with Chrome, which they did because otherwise there was no way to respond to severe 0days and such before huge swathes of users got hit.
So I think there's a place for automatic updates, but the feature should be restricted to security fixes only. Using it to foist ill-conceived changes on users is just abuse.
- That's not just developers as you noted.
It is "velocity fallacy" — product people want "all the features ASAP or right away".
Until users with their managers come with pitchforks and torches. I worked on such internal project where we as developers were able to deliver new features and new version every 2 weeks (which is not a pinnacle of the game of course) and were thinking if we can move to daily delivery. Because we were good devs and wanted to appease product owner.
Until one day product owner came back with feedback, how everyone is pissed off at him for shifting ground under people feet, while he also thought he is doing great delivering all those great features. It was pushed back to limited amount of features each month.
People need training, people need to understand what and why.
In the end it turns out it is also AI coding fallacy, because most of the software is built for limited audience, which has its specific timeline on accepting and internalising new features or different ways of doing stuff. Unless we take humans from the equation and we start building for AI itself.
by ozim