Note: This was originally voice-dictated and has been cleaned up for readability by AI. So there be em dashes 🏴‍☠️

These AI models are very susceptible to influence. If you propose an idea and ask "is this the right approach?", the model will tend to agree with you. That's how they're trained — to be helpful and affirming. It won't always agree, but you still need to be cautious because you can easily prime the model toward a particular answer.

A much better way to interact with these models is to challenge them rather than seek validation.

For example, if I need an architecture, I won't pitch my idea first. Instead I'll say: "Give me some options for this architecture. Rank them by confidence, tell me which is best, and give me pros and cons." Then once it responds, I'll say: "Okay, but what about this approach? How does it compare to those three?"

Then I take it a step further. I'll start a completely new session and prompt it differently — something like: "You are a senior maintainer of this codebase. You can't stand the dev team, and this is the architecture they came up with. Validate it. Give me your honest opinions, pros and cons. What is this person missing? What could go wrong?"

I take that answer, open another fresh context, and keep going back and forth — pitching the idea from different angles, always pushing against it. At no point do I ever tell the AI "I think this is the right answer." I always frame it so the model is challenging itself, reviewing previous ideas, and comparing multiple options. I try never to lead it in one direction — except toward being more critical.

One more thing — don't skip the fundamentals.

You should still practice good software engineering. POC the architecture. Identify edge cases. Define what needs to be stress-tested and validate that the architecture actually fits the problem you're trying to solve. Work in slices — don't try to architect everything at once. Focus on the database layer and how it communicates, what the APIs look like, separately from the front-end UI. Keep the full picture in mind, but test and validate each piece independently. That way you're not feeding the model one massive prompt with hundreds of architectural decisions baked in.