It's fine to have preferences. The biggest problem with bikeshedding is the time spent (wasted) debating. But you don't have to debate the AI, you just tell it your preferences, and ideally encode them so that they are repeatable.
Of course it's fine to have preferences. I think you missed the nuance. Bikeshedding implies the time is wasted because the topic wasn't important in the first place. The color of the bike shed, as it were, has nothing to do with the storing of the bikes.
I am equating the nerve that develops in people that get lost bikeshedding (wasting time on inconsequential parts of the problem) with fighting an llm on inconsequential implementation details.
We most certainly agree: what matters should always be the actual requirements (functional, security, performance, etc.) You can't bikeshed an important topic. Everything else is implementers decision. In my experience an experienced engineer understands the difference and trusts implementers to make the decisions that they do own.
No I understand the nuance. But it's only bad to have preferences about things that barely matter if you waste time on them. You don't have to fight the llm, you just tell it what you prefer and it does that, that's what's great about them. (If it is not listening to your directives, then you have other problems.)
You use the intentionally vague word "implementers" to abstract whether you're delegating to a human or to an AI. But the key point is that these are not the same thing. If I'm delegating to a person, that person is the "implementer". If I'm using an AI to generate an implementation, I am still the "implementer", it is merely a computer program working on my behalf.
Directing an AI's work is not "fighting it". You keep characterizing it that way, but it's the wrong characterization. "Implementer" is not blurry at all. Humans are responsible for the things they implement, whether or not they use AI tooling to do that implementation.
Is that my characterization? This subthread is about how it’s so time consuming fixing every little thing the AI does to be just like you would have done. My challenge to that sentiment is “give it some freedom, don’t micromanage it.” That’s all.
I understand the boundaries of ownership and responsibility. That’s why I can tell you if you are spending inordinate amounts of time correcting AI code then you’re doing something wrong. Either write the code yourself or reassess your ownership boundaries. You’re acting as a manager of a team of agents in an agentic coding paradigm. Managers don’t tell me how to write code.
Without going and re reading the whole thread, I'm pretty sure that both of your comments that I replied to included this "fighting the AI" characterization. It's certainly fair that you didn't start the thread about it but were just taking the premise of the sub thread. But I just disagree with that whole premise. I think what's nice about these tools is that I can just write a document that says things like "prefer immutability" and then I neither need to micromanage nor accept code I don't like, and there is no long slack thread about whether I'm right about any of the things I've written into those rules, the AIs are happy to do as I've asked.
I think this entire analogy about being a manager of a team of agents that is in vogue is completely misguided. Have I always been the manager of a team of bash scripts? No. These tools are way more capable, but they are still just tools that I'm using to do my own work, they are not people that I'm delegating responsibility to.
> I think what's nice about these tools is that I can just write a document that says things like "prefer immutability" and then I neither need to micromanage nor accept code I don't like
Why are we even arguing then? You and I agree. Did I ever say "don't share a single preference with the AI"? You set the guardrails and preferences and the AI follows them. This is how it's always worked so it's reasonable for me to assume that people "fighting the AI" have already done this and are being overly pedantic about the output. Otherwise it wouldn't be eating up inordinate amounts of time...
> Have I always been the manager of a team of bash scripts? No.
No. You're not even remotely close here. Let's revisit this once you've figure out how to have a team of bash scripts implement 100k lines of code and build entire systems in 2 weeks based on high level instructions and requirements shared in context and prompts. You have responsibility at a different level and scale in an AI native workflow.
I don't know why we're arguing about the first thing :)
But I think we have a real disagreement about the second thing. You don't "have responsibility at a different level and scale in an AI native workflow", you're still using tools. I understand that what you're saying is that it's such a difference in scale that it is a difference in kind. But I don't agree. I'm fundamentally at odds with this entire framing of ai agents as a team that is being managed. I don't like any of the anthropomorphizing of ai tools. It's fine if it's just an analogy, but people take it way too seriously as a real thing IMO. I fully recognize that I'm out of step with the prevailing discourse on this, but it's a genuine disagreement, I'm not confused about what other people think.
"Hey look I got this brand new tool it can do everything my old tools did and more but I'm scared to use it to do more--might shoot myself in the foot."
I think most people have felt that way before. Only way forward is to practice with the new tool (=
