Where you start is where you'll stay
I ran a workshop with six developers recently. Same task: design an audit log component for a real customer codebase. Same brief, same materials, same week to work on it before we reconvened.
When we met again, six radically different things had been built.
One developer had a working RabbitMQ publisher/consumer with a polished UI. One had four parallel logging methods designed in detail but no code yet. One had a dual-store architecture with OpenSearch and a complete read interface. One had a full PRD, software requirements spec, and architecture document — and not a single line of code. One had a framework focused entirely on who would use the audit log and what indicators they'd need. One had not started.
For a few minutes I thought the team had failed to converge. Then I realized the diversity was the data.
The starting point encodes a bias
Every developer chose where to begin. That choice — usually unconscious — determined everything that followed.
The one with the working RabbitMQ system started by asking "what should it track?" That's a data-model question. A backend engineer's default. He built downstream from data.
The one with four parallel methods started from "how should this integrate with the existing codebase?" That's an optionality bias. He designed multiple paths so the team could pick later. Methodical. Risk-averse.
The one with the full OpenSearch implementation started from "what are my architectural options?" Research-driven. He'd recently read about dual-store designs and chose the differentiator deliberately. His starting move was to ask Codex for three alternatives before touching code.
The one with the full spec and no code started from "what does the system actually need to be?" Specification bias. He was the CTO. He wrote the guidelines the team works from. His default is rigorous top-down design.
The one focused on the user started from "who is this for, and what conclusions will they draw?" That's a product/end-user bias. He was the VD. The audit log to him was a decision-support tool, not a record.
The one who didn't start at all — well, that's a different question. But his admission set the tone for the whole room.
Where you start is where you'll always start
Here's the thing nobody told these developers when they got the task: their starting point isn't a property of the task. It's a property of them.
The same person will repeat the same starting move on the next task. And the one after that. Backend engineers will start from data even when the task is fundamentally about user flow. CTOs will start from spec even when the task is small enough to just write. Product-minded people will start from "who is this for" even when the audience is obvious. We don't pick starting points — we recognize them after the fact, or we don't recognize them at all.
That's not a failure. The bias is usually correct for the kind of work the person normally does. The backend engineer's data-first instinct is what makes him good at backend. The CTO's spec-first instinct is what makes his guidelines coherent. The product person's user-first instinct is what makes him a useful product person.
But when the task at hand isn't the task they're optimized for, the bias misfires. And because the bias is unconscious, the misfire is invisible.
The first lever is noticing
You can't change your default starting move by trying harder. You change it by noticing it.
This is the single most useful exercise I've found for teams that work with AI: ask each person, after they've finished something, where did you start? Not what did you build. Not what model did you use. Where did you begin?
The answers cluster. Backend engineers describe the data first. Frontend engineers describe the user interaction. Architects describe the contracts and boundaries. Operations people describe the deploy and the monitoring. PMs describe the user story.
Make the starting points visible to the team. Suddenly everyone sees: ah, that's what we always do. I always start from there. The bias is in the room.
"Det första jag brukar göra med varje projekt är att läsa strukturen av loggfilerna." (The first thing I usually do with every project is read the structure of the log files.)
That was one developer describing his approach. Not wrong. Not right. Just his default. Once he named it, he had a choice the next time.
Why this matters more with AI
In pre-AI software development, your starting bias mattered less. Code took long enough to write that you'd run into the bias's failure modes and correct mid-flight. The grind of typing protected you.
With AI assistance, the grind is gone. You can produce a complete first draft of almost anything in 30 minutes. The bias now scales: whatever you started thinking about, you've now built. The wrong starting point doesn't slow you down — it just produces more wrong output faster.
The result is that AI-assisted teams either:
- Develop strong self-awareness about starting points and choose deliberately, or
- Build six different things and discover after the fact that nobody was solving the same problem
The first group has a workflow superpower. The second has expensive churn.
What to do about it
If you're a developer working with AI:
- Notice your default starting move. Write it down. "When I get a new task, the first thing I reach for is ___." Be specific.
- Ask whether this task matches your default. A data-modeling task fits a data-first developer. A user-flow task does not, even if it eventually has data in it.
- If there's a mismatch, deliberately start somewhere else. Read the spec, then start from the user. Read the code, then start from the integration surface. Force a different first move.
If you're leading a team:
- Make starting points a recurring question. After every shipped feature, ask each contributor where they started.
- Map the team's defaults. You'll find clusters and gaps. The gaps are where you have blind spots.
- Pair people with opposite defaults on tasks where the work needs to span both biases. A backend engineer + a product-minded engineer often produces more than two backend engineers, even when the task is technically backend-heavy.
If you're a facilitator running a workshop or training:
- Don't ask "what did you build?" Ask "where did you start?" The first question produces self-congratulation. The second produces self-awareness.
- Surface the diversity of starting points as the lesson — not as a coordination failure. The lesson is the spread.
- Let the team draw the conclusion themselves. They'll see it. Don't lecture about it.
The deeper claim
The methodology pieces in Mindtastic — foundation pillars, the work loop, voice methodology, the three approaches — are all attempts to make implicit thinking explicit. Where-you-start is the most upstream of these. Everything else happens after.
You can run the work loop perfectly and still end up with the wrong thing built, if you started from the wrong place. The work loop is downstream of the starting point. So is the prompt. So is the model selection. So is the review depth.
Knowing where you start is the cheapest, most reliable productivity intervention I know of in AI-assisted development. It costs nothing. It takes thirty seconds. Most teams have never done it.
Start there.
Based on observations from a recent Mindtastic Sprint engagement with a senior development team, May 2026. Six developers, one task, six legitimate starting points. Customer identity withheld.