[dead]
Developers are attached to tools because tools encode trust
31–40 of 148 posts
Re: Developers are attached to tools because tools encode trust
#32Earlier quoted context omitted.
MCP is the answer to not using bash, right? Bash is a great control surface anyway for LLMs as it is wordy and powerful.
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.
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.
Re: Developers are attached to tools because tools encode trust
#33Earlier quoted context omitted.
> 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…
You can't just call everyone you don't like a Nazi.
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.
Re: Developers are attached to tools because tools encode trust
#34There'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...
Re: Developers are attached to tools because tools encode trust
#35I 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…
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.
Re: Developers are attached to tools because tools encode trust
#36I 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 bound…
I was surprised to see you say you have automated tests. To me this makes most of the difference, but you have you actually have a good test suite, like one that actually proves the code does what you want it to do. Unit tests, property tests, e2e tests. The other part that makes all difference, is you have to be all up in the model's business about architecture. Pick something that wants to testable and isolation fr…
Wait; So you say you outsource development to a LLM fully knowing that it will not write sound/deterministic code and your quality requirement are your test cases, right?
I further suppose you are not writing the test cases in its whole by hand. But you try to specify them before you hand out the development task to the LLM, right?
It sounds like you just introduces a new team member which is not trustworthy yet. Normally you would review each change of him and explain how to improve hisself and the code. But that's not possible to a fixed-state LLM. That sounds exhausting.
If your Markdown Files should aim at improving the LLM contributions, you are again stuck with the fact that it did not follow in the first place.
So I conclude: You pay for an Intern who is not trustworthy and pay additional input token on Markdown Files to still no be certain about future contributions.
I just don't grasp how we as engineers are accepting this and integrate it into our craft. And: Everybody using External LLM Services, possibly providing the entire project as context, is allowed to let the source code of your company be leaked to some third party. I hope that party is trustworthy and does not have a track record of copyright infridgement. Because this would be fairly naive and reason to be fired. So we as Engineers knowing the implications should therefore point to these issues at the correct management level.
At least that's what I am doing shrugs
Re: Developers are attached to tools because tools encode trust
#37There'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 sys…
> 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.
Re: Developers are attached to tools because tools encode trust
#38This 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.
Re: Developers are attached to tools because tools encode trust
#39Stack 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.
Re: Developers are attached to tools because tools encode trust
#40Earlier quoted context omitted.
I was surprised to see you say you have automated tests. To me this makes most of the difference, but you have you actually have a good test suite, like one that actually proves the code does what you want it to do. Unit tests, property tests, e2e tests. The other part that makes all difference, is you have to be all up in the model's business about architecture. Pick something that wants to testable and isolation fr…
I think testing is really important (even without LLMs). Currently I have 2247 unit tests across 132 files in a ~150K LOC codebase (test code included in that count). It takes about 50s to run. There could be more, but it's not nothing. There is playwright for it to test drive the UI, although if I'm being perfectly honest even before LLMs I thought that kind of test tends to be brittle and annoying to write (I guess…
Isn't being brittle kinda the point of playwright tests? Because each test uses the whole app those tests can catch errors that happen at many places in the code. But that means lots of things can cause a test failure.