The results you get from an AI tool are, roughly speaking, the average of the data it was trained on. The more I use these tools, the more I see it play out.
When you ask an AI a question or give it a task without much context, it does what it knows best: it gives you the most common answer. The default. The thing most people do. And sometimes that’s fine. But often, it’s not what I actually need or want.
User Stories: “As a” vs. “In Order To”
If I prompt an AI tool with a problem statement and ask it to write user stories, it will default to the classic format:
As a [role], I want to [action], so that [benefit].
That’s the average. That’s what most people use, so that’s what the model learned.
I happen to prefer a different format:
In order to [benefit], as a [role], I want to [action].
It’s a subtle shift, but it puts the why front and center. That matters to me. The AI doesn’t know that unless I tell it.
Automated Tests: AAA vs. Given-When-Then
The same thing happens with automated tests. Ask an AI to write tests, and it will reach for the Arrange-Act-Assert (AAA) pattern. Again — the average. The most common approach.
I prefer writing tests using the Given-When-Then format. It reads more like a specification. It aligns better with how I think about behavior. But the AI has no way of knowing that unless I bring that context into the conversation.
Where Does the Logic Go?
I ran into this one recently. I gave an AI tool a user story that involved some decision logic — rules for displaying something on the UI based on specific data and context.
The result? All of that logic landed on the front end.
Why? Because that’s the average. That’s what most codebases out there do. Many developers put a lot of logic in the UI layer, and the training data reflects that.
I’m in the camp that says much of the logic people put on the front end should live on the back end. Keeping the UI thin and pushing decisions to the server side has served me well over the years — especially when change comes knocking. And in this industry, change is the only constant.
It’s Not About Being Right
These aren’t opinions I hold because I think they’re universally better. They’re better for me, based on my track record — the successes, the failures, the challenges, the lessons learned the hard way. Years of seeing what holds up when requirements shift, when teams grow, and when a “quick fix” turns into long-term maintenance.
That experience shapes how I work. And when I bring it into my AI interactions, the results improve.
How I Work With It
Sometimes I’ll just give the AI an assignment and see what comes back without steering it. I want to see the default. Occasionally, I actually like the result—and I appreciate that I didn’t influence it.
But many times, I don’t like what I get. So I make the request again, this time layering in my opinions, my thought process, my intent, and the desired outcome. Then I see what comes back and refine from there.
That’s why I’ve built my own AI instructions, workflows, and skills — for writing user stories, acceptance criteria, automated tests, and deciding where logic should live. These aren’t static. They keep evolving as I learn more about how to collaborate with these tools.
The Takeaway
AI gives you the average. That’s its starting point. Your job is to bring what makes your work yours — the experience, the patterns, the lessons, the intent. That’s what turns a generic output into something you can actually stand behind.
Leave a Reply