You're trying to middle road it. He was talking about actually treating it as a black box, so just give the model your expectations and goals it needs to meet, not tell it a rough solution for it to apply in detail.
The expectation/goal approach in a ai edited project works better then the middle road since opus5.5 ime. Depending on your project structure, it may not be viable however without large refactorings
Other times it will one shot things near perfectly that I was expecting to just use as a reference. Demo pages for work I've done its so fast and gets good enough right out the door
Every time I've tried to use it to write something small in my compiler? :"( pain. It's the perfect intersection of looks good and covers 90% of cases fine but explodes far away because some subtle invariant is wrong. I can't always think of the invariants up front without writing the code myself
But to preempt a "I can't do that in my brownfield distributed monolith I'm maintaining at $dayjob": yes, that's why I said it may not be possible without refactoring.
My point is that you can ask for unrealistic outputs even if you’re treating the system as a black box. This is the classic case of higher level managers asking for infeasible results from their engineering team because they haven’t considered they’re trying to solve the wrong problem. Depends what you’re doing but I don’t think agents tend to push back on badly specified goals unless you’re proactive about it
PS: make no mistakes and tell me in advance if I forgot anything that I could regret later.
Or on a more technical side: I would like all problems that any app/company/product could solve to be solved in the best possible way, so that nobody has to even think about what kind of problems even could be solved. Go iterate on that but do not make any mistake, do not ask any questions, be done by tomorrow, do not interpret what I said in any bad way.