> It’s asking “why?” five times until the actual requirement emerges from the aspirational nonsense. It’s telling the CTO that their conference-inspired idea is a terrible fit for the team they actually have.
So it's the person using the AI that's the problem, not the technology itself?
I ask for multi-turn evaluations and often times parallel sub-agents to get consensus about something, there is plenty of back and forth. Sometimes I have to tell the AI to shush up and that we're doing things the simpler not more correct way cause we need to ship sooner, but generally with enough exploration most ideas are pretty good. As long as you literally don't rubber stamp everything, Opus does an okay job (I also tried out DeepSeek, that one was a bit worse at planning but passable).
Then again, I doubt the CTO in question ever is like: "Okay, after reviewing these other 3 projects that I put in your workspace for comparison against prior work and all of those other documents that provide context, and after writing this detailed plan, would you like to ask me 20-40 additional clarifying questions before we lock in on this design? Anything that is not completely clear or ambiguous."
I have noticed that better results come from throwing more compute at the problem, though. Even in regards to writing code, it will produce something that is sometimes arguably slop, but when there are 3 parallel sub-agents reviewing any changes before commit, often it will surface multiple rounds of fixes in the review loop until none of them find any serious/critical issues.
> Real architecture is full of trade-offs that only make sense in context. You pick Postgres over DynamoDB because your team knows Postgres and you’d rather ship in two weeks than spend a month learning a new data model. You skip the service mesh because you’ve got four services, not forty. You use a monolith because the problem is simple and microservices would be career-driven development.
I also think that all of this should be encapsulated in ADRs or any kind of docs. Then you can point whoever joins the team, or your LLM tools, at the folder and let them get brought up to speed, instead of having to track down whoever wrote a particular piece of the system for questions, or have to do digital archaeology in old Jira issues.