It says "of course you're right" and may or may not refactor/fix/rewrite the issue correctly. More often than not it doesn't or misses some detail.
So you tell it again, "of course you are right", and the cycle repeats.
And then the context window gets exhausted. Compaction loses most of the details and degrades quality. You start a new session, but the new session has to re-learn the entire world from scratch and may or may not fix the issue.
You can control some simple things that way. But the subtle stylistic choices that many teams agree on are difficult to articulate clearly. Plus they don’t always do everything you tell them to in the prompts or rule files. Even when it’s extremely clear sometimes they just don’t. And often the thing you want isn’t clear.
For plain Linux, chmod, chmod's sticky bit and setfacl provide extensive ad hoc permissions restricting. Your comment is 4 hours old, I'm surprised I'm the first person to help correct its inaccuracy.
This doesn't meet the requirement. It doesn't restrict a certain subprocess to only write in a certain directory. You are just saying these things to quickly shut down the uncomfortable thought that Linux can't do something.
Or perhaps you need to go read my original comment again as you missed the premise. But if you feel you have perfect memory then perhaps look at something like firejail or read more about systemd.
But your premise of Linux "can't" do something is rather absurd. It's Linux, you can do anything, even if no one has done that thing before.
The reason people didn't respond earlier is because they probably assumed it a waste of their time. I know I have wasted mine
You chose to respond to a question I posed, with an extremely poor answer. I was very specific about restricting a certain subprocess to only write to a certain directory. Your answer does not do that. I pointed that out. Now you are defending that answer by claiming you were actually answering something else entirely. This is nonsensical.
> I'm going to try and be honest with you because I'm where you were at 3 months ago
> I honestly don't think there's anything I can say to convince you
> The value I've personally been getting which I've been valuing
> And that's not to say that the output is good
> My personal evidence for this is that after several years of tilting those windmills
It sounds to me like you're rationalizing and your opening sentences embed your awareness of the fallibility of what you say and clearly believe about your situation later.
I feel there are two types of programmers who use AI:
Type A who aren't very good but AI makes them feel better about themselves.
Type B who are good with or without AI and probably slightly better with it but at a productivity cost due to fixing AI all the way through, rather than a boost; leading to their somewhat negative but valid view of AI.
It's great when the terrain is unfamiliar to the user but extremely familiar to the LLM. And it's useless in the opposite.
The best programmers are going to be extremely familiar with terrains that are unfamiliar to the LLMs, which is why their views are so negative. These are people working on core parts of complex high performing highly scalable systems, and people with extreme appreciation for the craft of programming and code quality.
But the most productive developers focused on higher level user value and functionality (e.g pumping out full stack apps or features), are more likely to be working with commonly used technologies while also jumping around between technologies as a means to a functionality or UX objective rather than an end of skill development, elegant code, or satisfying curiosity.
I think this explains a lot of the difference in perspectives. LLMs offer value in the latter but not the former.
It's a shame that so many of the people in one context can't empathize with the people in the other.
What? Bash is the best scripting language available for CI flows.
reply