8 ms·

Developers are attached to tools because tools encode trust

hamza7159 2mo ago
[dead]
overgard 2mo ago
I have to admit, I asked ChatGPT to do a TLDR summary because I found the writing meandered quite a bit. I think the overall point is sound: > "Developers become attached to tools like Vim, Emacs, or an IDE because years of experience make those tools predictable extensions of their thinking. The attachment is less about features and more about accumulated trust, muscle memory, and a workflow built around known boundaries. > AI coding agents disrupt that trust because they are fast but probabilistic, opaque, constantly changing, and capable of producing more code than humans can realistically review. This shifts the bottleneck from writing code to specifying, reviewing, validating, and operating it safely." (Note the > is paraphrasing) Trust is a big problem I'm having with these tools so far. What I've been running into a lot is, I'll get the equivalent 40 hours of work done in 8 hours, and I'm like, wow, that really was quick. Then I'll start using the application I'm making more directly (a tool for writing), and I'll start to see that it's broken all over the place in very surprising ways (ie, updating this menu item broke something on the other side of the app, etc.). So then I spend another 40 hours of real wall clock time kind of fixing everything that was broken, and at the end of those two weeks I'm like, did I actually go much faster or was that all kind of a wash? Because if I'm not going faster in overall terms, then the loss of deep understanding of the code base might not be worth it if my pace is the same. I'm sure someone is going to be like "BRUH AUTOMATED TESTS" or "BRUH MODEL CHOICE". I have a LOT of automated tests, and I don't like fussing with models so I pretty much use Opus on high reasoning for most things (or the equivalent from other providers). Code review also doesn't help that much, for much of the same reason it doesn't tend to help find bugs in human written code either.. you're reading the happy path usually. Anyway I wouldn't say these tools aren't useful, but, I'm deeply skeptical of all the productivity claims because I think people just look at one dimension of it while ignoring all the other important dimensions. Yeah you can generate a lot of crap fast, but most of it is not shippable and making it shippable does take time.
- nvgjbdhmkdd 2mo ago
  [dead]
- derek1800 2mo ago
  If you are spending 40 hours fixing everything that was broken, the question I have is does your AI tools have the necessary context to be successful and not result in a lot of broken items? Also, is there ways for AI to help prevent the loss of deep understanding of your code base without you having to know every line of code deeply?
  - dijit 2mo ago
    "40 hours" in his context here is actually a work day, so 7-8hrs. He says "40 hours" because he feels like he's managed to do 40 hours worth of work in this time, but then has to spend another "40 hours" (actually: 1 day) just going around kicking tyres. Obviously the implication is that it's a net gain of some kind, but he's unsure if he caught everything. (sorry to reiterate the GP, but I feel like you missed the important nuance that it's not a real 40 hours of time).
    - grey-area 2mo ago
      No the second 40 hours is a real 40 hours (two weeks), and the implication is there is no real time saving.
    - inigyou 2mo ago
      Wow, just wow. This is the first time I've encountered this particularly AI apologism. To recap: Alice: "in the end, AI doesn't make me any faster because it still takes 80 hours to do 80 hours of work once I fix it" Bob (AI booster): "actually you might've been holding it wrong, did you try XYZ?" Carol (super AI booster): "Bob, actually Alice means it took 16 hours to do 80 hours of work. So it did work for her." Alice: "no I fucking didn't"
    - overgard 2mo ago
      Sorry, my original phrasing was confusing which you should not be downvoted for. I've edited my original comment to clarify what I meant (hopefully).
fitsumbelay 2mo ago
[flagged]
- inigyou 2mo ago
  Yes that is what happened to SO. They now get practically zero questions, zero answers, zero page views, and zero ad revenue. It is their own fault because they froze everyone out of the site and then once LLMs became an alternative, everyone started asking their questions to LLMs. They are now trying to somehow pivot to AI to make revenue again, starting with Stack Overflow for Agents, and now with wordy vacuous blog posts to show off how AI they are.
  - fitsumbelay 2mo ago
    The pains for me were around all the penalties I got for not following formalities, or at least that's what it felt like to me.
    - inigyou 2mo ago
      Nobody liked SO. They tolerated it as long as it was the best way to get answers to questions.
  - inigyou 2mo ago
    https://data.stackexchange.com/stackoverflow/query/1882532/questions-per-month#graph https://data.stackexchange.com/stackoverflow/query/1882532/q... Here is the proof
utopiah 2mo ago
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.
- zahlman 2mo ago
  > typing this in GVim thanks to Tridactyl Thanks for the heads-up that such a thing is possible. I will definitely be investigating it.
  - utopiah 2mo ago
    With pleasure, ^i in a textarea or even input element brings your text in GVim then saving brings you back. Really handy feature to bring regexes or text navigation to any Webpage.
  - paradox460 2mo ago
    Check out firenvim too
    - utopiah 2mo ago
      nice, --does it work on Firefox Nightly on Android too by any chance?-- guess not, seems limited to text edition, not browsing
kittikitti 2mo ago
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.
- hahahaa 2mo ago
  What constitutes taking the wheel? Skip permissions in a proper sandbox is fine IMO. There is a small amount of risk I admit though.
firasd 2mo ago
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 ^
- hahahaa 2mo ago
  MCP is the answer to not using bash, right? Bash is a great control surface anyway for LLMs as it is wordy and powerful.
  - ElectricalUnion 2mo ago
    Problem is that bash is too sharp to handle to smart and gullible clankers without a sandbox - That I think everyone should be using anyways, for everything, even things not related to clankers - Android and Qubes are right. The app/vm, and whatever it tries, should not be considered trusted by default.
    - applfanboysbgon 2mo ago
      Qubes is directionally correct, Android is extremely not. Safety must not be obtained by preventing users from controlling their own computing devices, or else we face a dire future.
  - firasd 2mo ago
    Yeah as far as what I'm talking about bash CLI vs MCP doesn't matter (there could be a file_sample MCP tool)---I'm saying that by default Windows, Linux etc don't have this venetianblinds affordance of seeing equally spaced samples. It's a trivial algo but it's very handy these days cause LLMs can't really just be like 'okay I'm gonna open this file at random and scroll around'--the file itself is an unknown blob (JSON data, Python, Typescript, a log file etc) without coordinates. So they fall back to thinking they've gotten a good sense of the file from head/grep or they write ad-hoc Python to manipulate the file. Another venetianblinds survey, of the Paul Graham 'What I Worked On' article that's used in many LlamaIndex examples: npx github:firasd/venetianblinds pgworkedon.txt --- sample 1/20 char 0 line 1 col 1 range 0:60 Before college the two main things I worked on, outside of s --- sample 2/20 char 3946 line 19 col 237 range 3886:4006 d an intelligent computer called Mike, and a PBS documentary that showed Terry Winograd using SHRDLU. I haven't tried re
youareinsuffera 2mo ago
[flagged]
- zephen 2mo ago
  > Apparently you just deserve a life of pain. Don't we all? (I can see that you are starting to get downvoted as well. Spread the love.) Stack overflow was interesting. Its design was the only thing like it at the time, and made it a Schelling point for programming knowledge distribution, but also a welcoming environment for the programming equivalent of grammar nazis. Some of those programming nazis, of course, had suffered at the hands of previous ones on stack overflow before becoming "enlightened." And thus, the generational hazing began. It was great if google directed you to exactly the right answer, but god help you if you couldn't figure it out, and posed a question that someone thought didn't contain an MCVE. Also, a few too many of the high-reputation people would post complete garbage on topics they knew absolutely nothing about.
  - inigyou 2mo ago
    You can't just call everyone you don't like a Nazi.
    - zephen 2mo ago
      The term "xxx nazi" has been around for over 70 years to describe people with sticks shoved so far up their asses that they poke out the tops of their heads. And "grammar nazi" has been around since at least 1990, and the infamous Seinfeld Soup Nazi since 1995. I'm not sure of the etymology of the "not everybody's a Nazi Nazi" but I'm sure you're not the first. But in any case: > You can't just call everyone you don't like a Nazi. Yes, yes, I can. I don't (because I reserve the appellation for certain particular kinds of attitudes), but I could if I wanted to.
inigyou 2mo ago
This is a lot of words to say absolutely nothing. Seems apropos for Stack Overflow though.
shostack 2mo ago
An example of this in action is the utter inability to get deepseek v4 flash (even the new version) to stay concise. I have jumped through all sorts of hoops with deterministic checks, pre-message injection hooks, memory framework, etc and when it fails still and I ask why it essentially says "I forgot." This makes it unreliable and preferences are things I need to assume are treated as exactly that, preferences, not hard settings. It is an area where it is more like working with an unreliable human than I would prefer.
- mlloyd 2mo ago
  Lots of people saying the same about Deepseek v4 Flash. Seems like it's an artifact of that model.
oooyay 2mo ago
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.
fibuladev 2mo ago
[dead]
ThePhysicist 2mo ago
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-environment-makes-you-happy/ https://www.joelonsoftware.com/2000/04/10/controlling-your-e...
- matheusmoreira 2mo ago
  > 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.
  - slopinthebag 2mo ago
    Crazy amount of effort when you can just use a different harness and a better and cheaper model.
    - matheusmoreira 2mo ago
kristianc 2mo ago
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.
- deleted 2mo ago
  [deleted]
MiddleEndian 2mo ago
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.
- jcranmer 2mo ago
  > 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.
- jgord 2mo ago
  A good tool does a job well with minimal side effects and maximal predictability. Perhaps this is why users dislike monthly SaaS - they cannot trust stability of the tool, because often the incentives are to keep adding features well past peak utility [ resulting in enshitification ]
  - jgord 2mo ago
    followup .. one reason I now love and detest C++ is the regularity of new features in the core working set [ particularly the current politically correct incarnation of the smart pointer. ]
willjp 2mo ago
I agree with this article, but it's so much more than just trust in a workflow. It's an API you can trust, in an ocean of change. That's what you're choosing; an api, abi... whatever you call it. You're committing to an extensible boundary. And both the boundary, and the extensibility (not to mention the openness) are why they win. And shelling out to a cli? That's a pretty damn compelling and composable boundary, IMO.
p1necone 2mo ago
[dead]
pianopatrick 2mo ago
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.
- win311fwg 2mo ago
  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.
groundzeros2015 2mo ago
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.
- TacticalCoder 2mo ago
  > 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.
  - inigyou 2mo ago
    Nobody uses it. Objectively. It has died. Past tense. https://data.stackexchange.com/stackoverflow/query/1882532/questions-per-month#graph https://data.stackexchange.com/stackoverflow/query/1882532/q... It's owned by some really stupid private equity firm since about 2019, which is trying to revive it as a platform for agents to talk to each other.
alexpotato 2mo ago
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 0 - https://queue.acm.org/detail.cfm?id=3197520 https://queue.acm.org/detail.cfm?id=3197520
- AlotOfReading 2mo ago
  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/uploads/sites/18/2022/05/IMG_5426-scaled.jpg https://i0.wp.com/blogs.princeton.edu/notabilia/wp-content/u... [1] https://ff-65a4.kxcdn.com/assets/uploads/OriginalDocs_old/983/berlin-gutenberg-bible-facsimile-edition-01.jpg https://ff-65a4.kxcdn.com/assets/uploads/OriginalDocs_old/98... [2] https://www.prepressure.com/images/Nieuwe-Tijdinghe-newspaper-573x800.jpg https://www.prepressure.com/images/Nieuwe-Tijdinghe-newspape...
acchow 2mo ago
[dead]
1saadcodes 2mo ago
I think the article is right that developers become attached to tools because of trust. Ironically though, that's also why many people drifted away from Stack Overflow. The answers were trustworthy, but over time the experience of asking questions felt less and less welcoming than searching for existing ones
antonvs 2mo ago
It’s hard to take an article seriously that starts out admitting an earlier troll. This is clearly a person that’s more interested in engagement than content.
tizerluo 2mo ago
[flagged]
deleted 2mo ago
[deleted]
niemenghui 2mo ago
I agree: With AI, we’re able to automate a lot of those processes. The good news is that work gets done faster. The bad news is that we don’t trust it when it’s done.
pjio 2mo ago
> The good news is that work gets done faster. The bad news is that we don’t trust it when it’s done. It's not done when you can't trust it.
Avery29 2mo ago
Trust in tools often comes from predictability and shared context
zahlman 2mo ago
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.
Mikhail_Edoshin 2mo ago
Developers can also build tools as needed. This is the key to simplicity.
sharpnick 2mo ago
[flagged]
iwontberude 2mo ago
Tools encode determinism, not trust
conferza 2mo ago
“If you leave anything up to chance, it will be left up to chance.”

[dead]

I have to admit, I asked ChatGPT to do a TLDR summary because I found the writing meandered quite a bit. I think the overall point is sound: > "Developers become attached to tools like Vim, Emacs, or an IDE because years of experience make those tools predictable extensions of their thinking. The attachment is less about features and more about accumulated trust, muscle memory, and a workflow built around known boundaries. > AI coding agents disrupt that trust because they are fast but probabilistic, opaque, constantly changing, and capable of producing more code than humans can realistically review. This shifts the bottleneck from writing code to specifying, reviewing, validating, and operating it safely." (Note the > is paraphrasing) Trust is a big problem I'm having with these tools so far. What I've been running into a lot is, I'll get the equivalent 40 hours of work done in 8 hours, and I'm like, wow, that really was quick. Then I'll start using the application I'm making more directly (a tool for writing), and I'll start to see that it's broken all over the place in very surprising ways (ie, updating this menu item broke something on the other side of the app, etc.). So then I spend another 40 hours of real wall clock time kind of fixing everything that was broken, and at the end of those two weeks I'm like, did I actually go much faster or was that all kind of a wash? Because if I'm not going faster in overall terms, then the loss of deep understanding of the code base might not be worth it if my pace is the same. I'm sure someone is going to be like "BRUH AUTOMATED TESTS" or "BRUH MODEL CHOICE". I have a LOT of automated tests, and I don't like fussing with models so I pretty much use Opus on high reasoning for most things (or the equivalent from other providers). Code review also doesn't help that much, for much of the same reason it doesn't tend to help find bugs in human written code either.. you're reading the happy path usually. Anyway I wouldn't say these tools aren't useful, but, I'm deeply skeptical of all the productivity claims because I think people just look at one dimension of it while ignoring all the other important dimensions. Yeah you can generate a lot of crap fast, but most of it is not shippable and making it shippable does take time.

nvgjbdhmkdd 2mo ago
[dead]
derek1800 2mo ago
If you are spending 40 hours fixing everything that was broken, the question I have is does your AI tools have the necessary context to be successful and not result in a lot of broken items? Also, is there ways for AI to help prevent the loss of deep understanding of your code base without you having to know every line of code deeply?
- dijit 2mo ago
  "40 hours" in his context here is actually a work day, so 7-8hrs. He says "40 hours" because he feels like he's managed to do 40 hours worth of work in this time, but then has to spend another "40 hours" (actually: 1 day) just going around kicking tyres. Obviously the implication is that it's a net gain of some kind, but he's unsure if he caught everything. (sorry to reiterate the GP, but I feel like you missed the important nuance that it's not a real 40 hours of time).
  - grey-area 2mo ago
    No the second 40 hours is a real 40 hours (two weeks), and the implication is there is no real time saving.
  - inigyou 2mo ago
    Wow, just wow. This is the first time I've encountered this particularly AI apologism. To recap: Alice: "in the end, AI doesn't make me any faster because it still takes 80 hours to do 80 hours of work once I fix it" Bob (AI booster): "actually you might've been holding it wrong, did you try XYZ?" Carol (super AI booster): "Bob, actually Alice means it took 16 hours to do 80 hours of work. So it did work for her." Alice: "no I fucking didn't"
  - overgard 2mo ago
    Sorry, my original phrasing was confusing which you should not be downvoted for. I've edited my original comment to clarify what I meant (hopefully).

fitsumbelay 2mo ago

[flagged]

inigyou 2mo ago
Yes that is what happened to SO. They now get practically zero questions, zero answers, zero page views, and zero ad revenue. It is their own fault because they froze everyone out of the site and then once LLMs became an alternative, everyone started asking their questions to LLMs. They are now trying to somehow pivot to AI to make revenue again, starting with Stack Overflow for Agents, and now with wordy vacuous blog posts to show off how AI they are.
- fitsumbelay 2mo ago
  The pains for me were around all the penalties I got for not following formalities, or at least that's what it felt like to me.
  - inigyou 2mo ago
    Nobody liked SO. They tolerated it as long as it was the best way to get answers to questions.
- inigyou 2mo ago
  https://data.stackexchange.com/stackoverflow/query/1882532/questions-per-month#graph https://data.stackexchange.com/stackoverflow/query/1882532/q... Here is the proof

utopiah 2mo ago

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.

zahlman 2mo ago
> typing this in GVim thanks to Tridactyl Thanks for the heads-up that such a thing is possible. I will definitely be investigating it.
- utopiah 2mo ago
  With pleasure, ^i in a textarea or even input element brings your text in GVim then saving brings you back. Really handy feature to bring regexes or text navigation to any Webpage.
- paradox460 2mo ago
  Check out firenvim too
  - utopiah 2mo ago
    nice, --does it work on Firefox Nightly on Android too by any chance?-- guess not, seems limited to text edition, not browsing

kittikitti 2mo ago

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.

hahahaa 2mo ago
What constitutes taking the wheel? Skip permissions in a proper sandbox is fine IMO. There is a small amount of risk I admit though.

firasd 2mo ago

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 ^

hahahaa 2mo ago
MCP is the answer to not using bash, right? Bash is a great control surface anyway for LLMs as it is wordy and powerful.
- ElectricalUnion 2mo ago
  Problem is that bash is too sharp to handle to smart and gullible clankers without a sandbox - That I think everyone should be using anyways, for everything, even things not related to clankers - Android and Qubes are right. The app/vm, and whatever it tries, should not be considered trusted by default.
  - applfanboysbgon 2mo ago
    Qubes is directionally correct, Android is extremely not. Safety must not be obtained by preventing users from controlling their own computing devices, or else we face a dire future.
- firasd 2mo ago
  Yeah as far as what I'm talking about bash CLI vs MCP doesn't matter (there could be a file_sample MCP tool)---I'm saying that by default Windows, Linux etc don't have this venetianblinds affordance of seeing equally spaced samples. It's a trivial algo but it's very handy these days cause LLMs can't really just be like 'okay I'm gonna open this file at random and scroll around'--the file itself is an unknown blob (JSON data, Python, Typescript, a log file etc) without coordinates. So they fall back to thinking they've gotten a good sense of the file from head/grep or they write ad-hoc Python to manipulate the file. Another venetianblinds survey, of the Paul Graham 'What I Worked On' article that's used in many LlamaIndex examples: npx github:firasd/venetianblinds pgworkedon.txt --- sample 1/20 char 0 line 1 col 1 range 0:60 Before college the two main things I worked on, outside of s --- sample 2/20 char 3946 line 19 col 237 range 3886:4006 d an intelligent computer called Mike, and a PBS documentary that showed Terry Winograd using SHRDLU. I haven't tried re

youareinsuffera 2mo ago

[flagged]

zephen 2mo ago
> Apparently you just deserve a life of pain. Don't we all? (I can see that you are starting to get downvoted as well. Spread the love.) Stack overflow was interesting. Its design was the only thing like it at the time, and made it a Schelling point for programming knowledge distribution, but also a welcoming environment for the programming equivalent of grammar nazis. Some of those programming nazis, of course, had suffered at the hands of previous ones on stack overflow before becoming "enlightened." And thus, the generational hazing began. It was great if google directed you to exactly the right answer, but god help you if you couldn't figure it out, and posed a question that someone thought didn't contain an MCVE. Also, a few too many of the high-reputation people would post complete garbage on topics they knew absolutely nothing about.
- inigyou 2mo ago
  You can't just call everyone you don't like a Nazi.
  - zephen 2mo ago
    The term "xxx nazi" has been around for over 70 years to describe people with sticks shoved so far up their asses that they poke out the tops of their heads. And "grammar nazi" has been around since at least 1990, and the infamous Seinfeld Soup Nazi since 1995. I'm not sure of the etymology of the "not everybody's a Nazi Nazi" but I'm sure you're not the first. But in any case: > You can't just call everyone you don't like a Nazi. Yes, yes, I can. I don't (because I reserve the appellation for certain particular kinds of attitudes), but I could if I wanted to.

inigyou 2mo ago

This is a lot of words to say absolutely nothing. Seems apropos for Stack Overflow though.

shostack 2mo ago

An example of this in action is the utter inability to get deepseek v4 flash (even the new version) to stay concise. I have jumped through all sorts of hoops with deterministic checks, pre-message injection hooks, memory framework, etc and when it fails still and I ask why it essentially says "I forgot." This makes it unreliable and preferences are things I need to assume are treated as exactly that, preferences, not hard settings. It is an area where it is more like working with an unreliable human than I would prefer.

mlloyd 2mo ago
Lots of people saying the same about Deepseek v4 Flash. Seems like it's an artifact of that model.

oooyay 2mo ago

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.

fibuladev 2mo ago

[dead]

ThePhysicist 2mo ago

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-environment-makes-you-happy/ https://www.joelonsoftware.com/2000/04/10/controlling-your-e...

matheusmoreira 2mo ago
> 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.
- slopinthebag 2mo ago
  Crazy amount of effort when you can just use a different harness and a better and cheaper model.
  - matheusmoreira 2mo ago

kristianc 2mo ago

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.

deleted 2mo ago
[deleted]

MiddleEndian 2mo ago

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.

jcranmer 2mo ago
> 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.
jgord 2mo ago
A good tool does a job well with minimal side effects and maximal predictability. Perhaps this is why users dislike monthly SaaS - they cannot trust stability of the tool, because often the incentives are to keep adding features well past peak utility [ resulting in enshitification ]
- jgord 2mo ago
  followup .. one reason I now love and detest C++ is the regularity of new features in the core working set [ particularly the current politically correct incarnation of the smart pointer. ]

willjp 2mo ago

I agree with this article, but it's so much more than just trust in a workflow. It's an API you can trust, in an ocean of change. That's what you're choosing; an api, abi... whatever you call it. You're committing to an extensible boundary. And both the boundary, and the extensibility (not to mention the openness) are why they win. And shelling out to a cli? That's a pretty damn compelling and composable boundary, IMO.

p1necone 2mo ago

[dead]

pianopatrick 2mo ago

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.

win311fwg 2mo ago
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.

groundzeros2015 2mo ago

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.

TacticalCoder 2mo ago
> 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.
- inigyou 2mo ago
  Nobody uses it. Objectively. It has died. Past tense. https://data.stackexchange.com/stackoverflow/query/1882532/questions-per-month#graph https://data.stackexchange.com/stackoverflow/query/1882532/q... It's owned by some really stupid private equity firm since about 2019, which is trying to revive it as a platform for agents to talk to each other.

alexpotato 2mo ago

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 0 - https://queue.acm.org/detail.cfm?id=3197520 https://queue.acm.org/detail.cfm?id=3197520

AlotOfReading 2mo ago
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/uploads/sites/18/2022/05/IMG_5426-scaled.jpg https://i0.wp.com/blogs.princeton.edu/notabilia/wp-content/u... [1] https://ff-65a4.kxcdn.com/assets/uploads/OriginalDocs_old/983/berlin-gutenberg-bible-facsimile-edition-01.jpg https://ff-65a4.kxcdn.com/assets/uploads/OriginalDocs_old/98... [2] https://www.prepressure.com/images/Nieuwe-Tijdinghe-newspaper-573x800.jpg https://www.prepressure.com/images/Nieuwe-Tijdinghe-newspape...

acchow 2mo ago

[dead]

1saadcodes 2mo ago

I think the article is right that developers become attached to tools because of trust. Ironically though, that's also why many people drifted away from Stack Overflow. The answers were trustworthy, but over time the experience of asking questions felt less and less welcoming than searching for existing ones

antonvs 2mo ago

It’s hard to take an article seriously that starts out admitting an earlier troll. This is clearly a person that’s more interested in engagement than content.

tizerluo 2mo ago

[flagged]

deleted 2mo ago

[deleted]

niemenghui 2mo ago

I agree: With AI, we’re able to automate a lot of those processes. The good news is that work gets done faster. The bad news is that we don’t trust it when it’s done.

pjio 2mo ago

> The good news is that work gets done faster. The bad news is that we don’t trust it when it’s done. It's not done when you can't trust it.

Avery29 2mo ago

Trust in tools often comes from predictability and shared context

zahlman 2mo ago

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.

Mikhail_Edoshin 2mo ago

Developers can also build tools as needed. This is the key to simplicity.

sharpnick 2mo ago

[flagged]

iwontberude 2mo ago

Tools encode determinism, not trust

conferza 2mo ago

“If you leave anything up to chance, it will be left up to chance.”