With AI, the answer you get depends on the question you ask

Our team recently had one of those debates that every development shop eventually runs into: where should a particular piece of logic live?

The scenario was straightforward. We have a web application with a frontend built in Angular and a backend API. There are places in the app where we need to show or hide certain fields — maybe columns in a table, maybe inputs on an edit form. The question was simple: should the frontend handle that, or should the backend?

Two developers had two different opinions, which isn't unusual. So someone decided to ask AI for a tiebreaker.

Here's where it gets interesting.

Round One: The Narrow Question

The first question was framed pretty tightly. It essentially asked: "Is it okay to pass a configuration object to an Angular component that tells it which fields to show or hide?" No mention of why a field might be hidden. No mention of what drives that decision. Just: can we pass display instructions to the frontend and let it handle the rendering?

AI's answer? Absolutely. That's a perfectly reasonable pattern. Pass a config object to your component and let it toggle field visibility.

Fair enough. That is a valid pattern, and if that's all you're doing, the frontend is a fine place for it.

Round Two: The Full Picture

Then someone added context. They took the original question — word for word — and appended a bit more detail. Specifically, they explained that the decision about whether a field should be visible or required isn't arbitrary. It depends on things like user permissions, role-based access, and the current state of the data being viewed. Think business rules, not just layout preferences.

Same AI. Same original prompt. Just a few extra sentences of context.

This time the answer was completely different: That logic belongs in your API. Let the backend evaluate the rules and pass the results down to the frontend. The Angular side should just render what it's told.

The Takeaway

Neither answer was wrong. Both were perfectly valid responses — to the question that was asked. The AI wasn't inconsistent. It simply answered what was in front of it.

And that's the real lesson here. AI doesn't know what you didn't tell it. It can't infer the business rules hiding behind your question. It responds to what you give it, and if you give it a narrow, implementation-focused question, you'll get a narrow, implementation-focused answer. Add the why behind the question — the constraints, the business logic, the broader architecture — and you'll get something much more useful.

This isn't a flaw in AI. It's a mirror. The quality of the answer is directly tied to the quality of the question.

So the next time you're asking AI to weigh in on a technical decision, don't just ask how to do something. Tell it why you need to do it, what drives the decision, and what else is in play. You might be surprised how much the answer changes — and how much better it gets.