Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developers are attached to tools because tools encode trust

stackoverflow.blog

Post reply on HN
Print view View original

11–20 of 148 posts

Re: Developers are attached to tools because tools encode trust

#11

Post by kittikitti »

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.

Re: Developers are attached to tools because tools encode trust

#12

Post by firasd »

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
                                                    ^

Re: Developers are attached to tools because tools encode trust

#15

Post by hahahaa »

firasd wrote: post #12

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…

MCP is the answer to not using bash, right?

Bash is a great control surface anyway for LLMs as it is wordy and powerful.

Re: Developers are attached to tools because tools encode trust

#16

Post by hahahaa »

kittikitti wrote: post #11

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…

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

Re: Developers are attached to tools because tools encode trust

#18

Post by zephen »

youareinsuffera wrote: post #14

[flagged]

> 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.

Re: Developers are attached to tools because tools encode trust

#19

Post by shostack »

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.

Re: Developers are attached to tools because tools encode trust

#20

Post by inigyou »

dijit wrote: post #8
derek1800 wrote: post #4

Earlier quoted context omitted.

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?

"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 i…

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"

Post reply on HN