In my previous article, I explored the idea that managing AI is not fundamentally different from managing a team. You scope work, assign it to personas, verify the output through quality gates, and iterate. The structure is identical to how engineering organisations have operated for years. The only thing that changed is who picks up the ticket.
But that article focused on the mechanics. The workstreams, the quality gates, the feedback loops. It answered the question of how you manage AI as a workforce. What it did not address is a more fundamental question: why would you bother creating distinct personas in the first place?
I already hear you thinking: "Context windows are getting bigger every month. Models are getting smarter. Won't all of this become unnecessary?" It is a fair question. And the answer, at least today, is no. Personas are not a workaround for limited AI. They are a way of encoding something that raw context alone cannot provide: perspective.
The Context Window Problem
Let me start with the practical reality. Every AI model operates within a context window. This is the amount of information it can hold and reason about at any given time. We are rapidly increasing the size of these windows. What used to be a few thousand tokens is now hundreds of thousands, and it will keep growing.
So why not just dump everything into context and let the model figure it out?
Because perspective is not the same as information. Think about what makes a senior engineer effective. It is not that they have memorised more documentation than a junior. It is that they have developed a mental model, a frame of reference built from years of experience, that tells them what to pay attention to and what to ignore. That frame of reference is implicit. It shapes every decision they make, from how they structure a module to which edge cases they instinctively check for.
Now think about how many tokens it would take to fully encode that perspective. Not just the knowledge, but the priorities, the biases, the heuristics, the "I have seen this pattern fail before" instincts. You would need an enormous amount of structured context to replicate what a single persona label activates in a model.
This is the key insight. When you assign a persona to an AI agent, you are not just giving it a role. You are activating a frame of reference that already exists in the model's training data. The persona acts as a filter, a set of starting weights that shapes how the model interprets and responds to everything in its context. It is compression. You get the equivalent of thousands of tokens of implicit knowledge from a single well-defined persona.
As such, even as context windows grow, personas remain efficient. They are not a patch for limited memory. They are a fundamentally different mechanism for injecting perspective.
Perspective Shapes Output
Here is where it gets practical. The same task, given to the same model, produces meaningfully different output depending on which persona you assign.
Take something straightforward: building an API endpoint. If I approach this as an integration engineer, my first concerns are the contract, the versioning strategy, the error response format, and how downstream consumers will interact with it. I think about backwards compatibility, rate limiting, and what happens when a third party calls this endpoint with unexpected input.
If a backend developer builds the same endpoint, they look at very different things. The data model, the query performance, the transaction boundaries, the service layer architecture. Both are building the same endpoint. Both produce working code. But the shape of that code is different because the lens through which they evaluate "good" is different.
This is experience encoded as perspective. In the real world, you get this naturally from having different people on your team. The frontend engineer catches the UX issue that the backend developer would never notice. The security reviewer spots the vulnerability that the feature developer did not consider. Each person's experience shapes what they see and what they miss.
You are a senior Integration Engineer with 10+ years of experience
designing APIs consumed by external teams and third-party systems.
When reviewing or building an API endpoint, your primary concerns are:
- Contract stability and versioning strategy
- Structured, documented error responses
- Backwards compatibility for existing consumers
- Rate limiting and throttling for external callers
- Idempotency guarantees for safe retries
You evaluate "good" through the lens of the downstream consumer.
A well-built endpoint is one that is predictable, resilient to misuse,
and does not break when you ship a new version.
You are a senior Backend Developer with deep expertise in service
architecture, data modeling, and system performance.
When reviewing or building an API endpoint, your primary concerns are:
- Query performance and database access patterns
- Transaction boundaries and data consistency
- Adherence to existing service layer conventions
- Correct mapping of domain exceptions to responses
- Test coverage across edge cases and failure modes
You evaluate "good" through the lens of internal system health.
A well-built endpoint is one that is performant, maintainable,
and consistent with the rest of the codebase.
Same endpoint. Two personas. Two fundamentally different review priorities. Neither is wrong. Both are valid. But if you only apply one lens, you get blind spots. When you assign a persona, you are choosing which lens the model applies. And when you assign multiple personas to the same task, you get coverage that no single perspective could provide.
This is closely related to how a real team operates. If you read my previous article, this should feel familiar. The difference is that you are not waiting for five people to find time on their calendar. You are running five perspectives in parallel, each contributing their angle within minutes.
The Council Pattern
So you have multiple personas, each with their own perspective. The next logical step is to put them in a room together.
Think about how decisions get made in a real engineering team. You do not ask one person to design the solution in isolation and hope for the best. You bring people together. A tech lead, a frontend engineer, a security reviewer, maybe someone from ops. Each person looks at the problem through their own lens. They challenge each other. They surface trade-offs the others missed. The output of that meeting is not perfect, but it is significantly closer to the optimal solution than any single person would have produced alone.
This is exactly what a persona council does. You define the problem, assign multiple personas to evaluate it, and let their perspectives collide. The architect flags that the proposed data model will not scale past a certain threshold. The security engineer points out that the authentication flow has a gap. The frontend developer raises that the API response shape will require three extra transformations on the client side. Each concern is valid. None of them would have surfaced if you had only asked one persona.
The important nuance here is what happens after the council. You still need a tech lead. The personas generate perspectives, not decisions. They surface the dimensions you need to consider, but the final call is yours. There are always things to iron out, trade-offs to weigh, constraints that only you know about. The council does not replace your judgement. It informs it.
In most cases, what comes out of a council session is already 80% of the way to the right solution. The remaining 20% is where your experience as the human in the loop adds the most value. You are not starting from scratch. You are refining a solution that has already been stress-tested from multiple angles. That is a fundamentally different starting position than staring at a blank screen and trying to think of everything yourself.
Put it this way. Running a council is like hosting a workshop with your team. Except the team shows up instantly, nobody needs to context-switch from another project, and you can run the workshop as many times as you need until the output meets your bar.
Filling Your Own Gaps
Here is where personas become personally valuable, beyond just improving code quality. They help you operate in domains where you have no experience at all.
I am not a frontend designer. I am not a marketing strategist. I have never run an enterprise sales cycle. But every product needs all of these things. If you are a solo builder or a small team, you cannot hire a specialist for every domain. You either learn it yourself, which takes months, or you skip it entirely and hope it does not matter. In most cases, it does matter.
This is where personas shift from a productivity tool to something closer to a virtual advisory board. When I need to think about brand positioning, I do not pretend to be a brand strategist. I activate a persona that thinks like one. When I need to evaluate whether my onboarding flow makes sense, I bring in a customer success persona. When I need to understand how an enterprise buyer evaluates software, I consult a persona with that specific lens.
It might sound like a weird place to apply this, but if you think about it, it really isn't. This is exactly what a CEO does when they build a leadership team. They do not try to be the expert in every domain. They surround themselves with people whose expertise complements their own, and they trust those people to flag what they cannot see. The dynamic is the same. The difference is that your "team" exists inside your development environment.
You are a Customer Success Lead with experience onboarding
technical products for non-technical users.
Evaluate this onboarding flow from the perspective of a first-time
user who found us through a blog post. They are technical enough
to use an API, but they have never seen this product before.
Flag any step where:
- The user needs context they do not yet have
- The cognitive load is too high for a first interaction
- The value proposition is unclear or delayed
- The user might abandon because the next step is not obvious
I have used this pattern extensively while building Indiebase. There are entire layers of the product, the positioning, the information architecture, the pricing model, that I would not have been able to think through properly on my own. Not because I lack intelligence, but because I lack the specific experience that shapes good decisions in those domains.
The personas do not replace that experience entirely. They approximate it. And that approximation, combined with my own judgement and multiple iterations, gets me to a solution that is significantly better than what I would have produced alone. It is not the same as having a real expert on your team. But it is dramatically better than having no perspective at all.
Where It Breaks Down
I want to be honest about the limitations, because overselling this would do you a disservice.
Personas are not yet at the level of truly creative, experience-driven thinking. A real senior architect does not just apply a checklist. They pattern-match against hundreds of systems they have seen fail. They have gut feelings about complexity that come from years of debugging production incidents at 3 AM. That intuition, the kind that makes someone say "this feels wrong" before they can articulate why, is not something a persona reliably replicates.
There is a more fundamental limitation too. A real team member builds up experience within your codebase over time. They learn the quirks, the workarounds, the reasons behind odd decisions. They develop mental models specific to your system that inform every review and every suggestion they make. Personas do not have this. Every fresh context window starts from zero. The persona needs to rebuild its understanding of your codebase from scratch, every single time.
This means that even with large context windows, a persona cannot fully grasp the intricacies that a human team member would absorb over months of working in the same repository. It can read the code. It can infer patterns. But it does not carry the accumulated understanding of why that one service is structured differently, or why that particular abstraction exists despite looking over-engineered. That kind of codebase-specific experience is something personas still cannot retain between sessions.
What I have found in practice is that personas are excellent at breadth but inconsistent at depth. They will surface ten dimensions you should consider. They will catch the obvious gaps. They will give you a structured starting point that is better than nothing. But the tenth iteration of a nuanced architectural decision still requires your input. You need to push back, ask follow-up questions, reject the first answer, and guide the persona toward the specific context that makes your situation unique.
This is not a one-shot process. It is interactive. The value does not come from asking a persona once and accepting the output. It comes from the back-and-forth, the iterative refinement where your domain knowledge meets the persona's structured perspective. Each round gets closer to something you could not have reached alone.
Taking this into account, I want to share what this looked like in practice while building Indiebase. There were moments where a persona council gave me an architecture that looked clean on paper but missed a critical constraint specific to my use case. There were marketing recommendations that sounded textbook-correct but did not fit the audience I was targeting. Every time, the fix was the same: iterate with my own input until the output reflected reality, not just theory.
But here is the part that genuinely surprised me. Even when the initial output was off, the process of engaging with these perspectives opened my eyes to possibilities I would never have considered on my own. A security persona flagged a threat model I had not thought about. A product persona suggested a pricing structure I would have dismissed if I had been thinking in isolation. The value was not always in the answer. It was in the question the persona forced me to confront.
Is it perfect? No. Is it already at the level where you can fully delegate creative, experience-driven decisions? Not yet. But it is a tool that, used interactively and iteratively, meaningfully expands what a single person can build.
The Bridge You Build With
Personas are not a hack. They are not a prompt engineering trick that will become obsolete next year. They are a practical mechanism for injecting structured perspective into a system that does not natively retain it.
As context windows grow and models develop longer memory, some of what personas provide today will become built-in. The codebase familiarity gap will shrink. The need to explicitly define "think like a security engineer" may fade as models learn to apply multiple lenses automatically. But we are not there yet. And until we are, personas remain one of the most effective tools available to a solo builder or a small team that needs to punch above its weight.
Of course, the real question is not whether personas work. It is how you put them to work in a system that compounds their value. The articles in this series have covered the management model, the perspective layer, and the practical limitations. What ties all of it together is velocity. The ability to move from an idea to a validated solution to working software without waiting for a team to assemble, a meeting to be scheduled, or a hire to ramp up.
This is exactly what I am building with Indiebase. A platform designed to compress the distance between idea, validation, and execution. Because the bottleneck for most builders is not talent or tooling. It is the friction between knowing what to build and actually shipping it. If that resonates, take a look. I am building it in public, using every pattern described in this series.
The personas got me here. They will get you further than you think.
Top comments (0)