Most people working with AI treat it like a souped-up search bar. You type in a question, you get an answer, you move on. Some have progressed to the "fancy autocomplete" stage, letting it fill in code while they hover over the accept button. Both are valid use cases, but they barely scratch the surface of what becomes possible when you shift your mental model entirely.
The better way to think about AI, particularly in a software engineering context, is as a team of personas. Not a single assistant, but a set of specialists you assign to workstreams and manage through quality gates. A developer persona, an architect persona, a QA persona, a security reviewer. Each scoped to a concern, each operating within boundaries you define.
If that sounds familiar, it should. It is how most engineering organisations already work.
The Forcing Problem
Let me start with the most common mistake I see people make when working with AI in a development context. They try to force their opinions onto the code. Line by line, function by function, they dictate exactly what the output should look like. The AI becomes a transcription machine for thoughts you already had.
I already hear you thinking: "But, I know the codebase better than the AI does." Of course you do. But knowing the codebase does not mean you need to write every line yourself. Think about how you work with a colleague. You would not sit behind their shoulder and dictate every variable name. You would describe the problem, point them to the relevant context, and let them figure out the implementation details.
The same principle applies to AI. When you micromanage the output, you are essentially paying the cost of writing the code yourself, with the added overhead of translating your intent into prompts. You are operating at the wrong abstraction level. The value of AI is not that it types faster than you. The value is that it can handle the lower level abstractions of the code while you focus on the decisions that actually matter: architecture, constraints, and quality.
The research also does not lie. An AI agent can already tackle work that a normal person would take 8 to 16 hours. That's about 2 working days of output while you are looking at the friendly "Frolicking..." prompt your Claude outputs for a couple of minutes. This is a different packet of work than we normally think about.
Put it this way. If you find yourself rewriting most of what the AI produces, the problem is not the AI. The problem is that you are trying to control the wrong layer.
Horizontal Scaling
Once you stop thinking of AI as a single assistant and start thinking of it as a workforce, something interesting happens. You realise you are not limited to one agent doing one thing at a time.
In a traditional team, you would not assign your entire engineering department to a single ticket. You would spread the work across parallel workstreams. One person handles the implementation, another writes tests, a third reviews the architecture. The same model applies to AI. You can run multiple personas in parallel, each scoped to a specific concern, each producing output that feeds into the next.
The key insight here is not just that you can parallelise. It is that you should start by automating the lowest complexity tasks first. The boilerplate. The test scaffolding. The documentation updates. The linting fixes. These are the tasks where AI produces reliable output with minimal oversight, and where the time savings compound the fastest.
It shouldn't come as a surprise that this is exactly how you would onboard a new team member. You would not hand them the most critical architectural decision on day one. You would give them well-scoped, lower-risk tasks with clear acceptance criteria, and gradually increase the scope as trust builds.
The difference with AI is that you can run ten of these "new team members" simultaneously. The horizontal scaling is practically free. What is not free is the management layer on top, and that is where your role shifts.
Workstreams, Not Prompts
So if the goal is to manage AI rather than dictate to it, what does that look like in practice? The abstraction shift is this: you stop writing code and start defining workstreams.
A workstream is a scoped unit of work with clear inputs, constraints, and expected outputs. It is not a prompt. A prompt says "write me a function that does X." A workstream says "here is the problem, here are the files involved, here are the acceptance criteria, and here is how I will verify the result."
If that sounds like a well-written Jira ticket, that is because it is. The tooling and processes we have been building for years to coordinate human developers turn out to be exactly what AI agents need. User stories, scoped tickets with acceptance criteria, definition of done. None of this is new. The only thing that changed is who picks up the ticket.
Let me give you a concrete example. Say you need to add input validation to all your API routes. The prompting approach would be to open each file, paste the code, and ask the AI to add Zod schemas. You would do this thirty times, reviewing each output manually.
The workstream approach looks different. You define the task once:
task: backfill-zod-validation
scope: all POST/PATCH routes in src/app/api/
constraints:
- use Zod for schema definitions
- validate request body before any business logic
- return 400 with structured error on validation failure
- do not modify response types or business logic
acceptance_criteria:
- every mutation route has a Zod schema
- all schemas are co-located with their route file
- existing tests still pass
verify: run lint, type check, and test suite
This is not a hypothetical. This is how I run my own projects. The task definition becomes the management artifact. The AI handles the implementation across all thirty files. Your job is to verify the output against the criteria you defined, not to review every line of generated code.
As such, the skill shifts from "how do I implement this" to "how do I specify this clearly enough that someone else can implement it." If you have ever written a good Jira ticket, you already know how to do this.
The AI Workforce Model
To make this more tangible, here is how the model looks when you put it all together. You, as the tech lead, sit at the top. Below you are the personas, each operating in their own swim lane. The quality gates sit between the work and the merge.
You (Tech Lead) define workstreams for each persona:
- Developer Persona produces code changes
- QA Persona produces test coverage
- Security Persona produces security reviews
- Architect Persona produces design reviews
All output flows through Quality Gates (lint, type check, test suite, acceptance criteria) into a Verification step:
- Pass → Merge
- Fail → Feedback Loop → retry with context → back to the Developer Persona
The important thing to notice is that this diagram would look exactly the same if you replaced the personas with human engineers. The structure is identical. The rituals are the same: scope the work, assign it, verify the output, iterate on failures. The only difference is the speed at which the cycle runs.
In most cases, the feedback loop between a failed quality gate and the next attempt takes seconds instead of hours. The cycle that used to take a full review round now completes almost instantly. This is where the real productivity gain lives. Not in writing code faster, but in shortening the iteration loop between "here is my attempt" and "does it meet the criteria."
Quality Gates as Management
If AI handles the implementation and you handle the workstream definition, then what sits in between? Quality gates. This is where you as a human add the most value.
A quality gate is any automated or manual check that decides whether output is good enough to move forward. In most cases, you already have these in place. Your linter, your type checker, your test suite, your CI pipeline. These are not just developer tools anymore. They are your management layer.
Think about what a good engineering manager actually does. They do not write every line of code. They define what "good" looks like, create the systems to verify it, and step in when the output does not meet the bar. Taking this into account, your role when managing AI personas is the same. You define the acceptance criteria. You build the verification pipeline. You review the edge cases where automated checks are not sufficient.
Let me name a definitely non-exhaustive list of quality gates that work well in this model:
- Linting and formatting to catch style violations before you even look at the code
- Type checking to verify structural correctness across the codebase
- Automated test suites to validate behaviour against specifications
- Security scans to flag common vulnerabilities before they reach review
- Acceptance criteria checks where you verify the output matches the original ticket
The interesting thing is that the more robust your quality gates are, the more you can delegate. If your test coverage is high and your CI pipeline is strict, you can trust AI output with less manual review. If your quality gates are weak, you will spend most of your time reviewing code manually, which defeats the purpose.
As such, investing in your verification infrastructure is not just good engineering practice. It is a direct multiplier on how effectively you can manage your AI workforce.
One quality gate that deserves special attention is documentation. AI agents go down. Services have outages. Models change behaviour between versions. When that happens, a human developer needs to step in and understand what was built, why it was built that way, and how to modify it. If your AI-generated code has no documentation, no architectural context, and no inline reasoning, that fire drill becomes significantly more expensive. Documentation is not a nice-to-have in this model. It is a quality gate that ensures your codebase remains maintainable regardless of who or what wrote it.
Thinking at a Higher Abstraction
Everything we have discussed so far points in one direction: the abstraction level at which you operate is moving up. You are spending less time thinking about how to implement a function and more time thinking about what the function should achieve, how to verify it, and where it fits in the larger system.
This is not a new phenomenon in software engineering. We have been moving up the abstraction ladder for decades. Assembly gave way to C, C gave way to higher level languages, manual deployments gave way to CI/CD pipelines. Every step reduced the amount of low level detail a developer needed to hold in their head and allowed them to focus on higher order concerns.
AI is the next step on that ladder. The questions you ask yourself change. Instead of "how do I parse this JSON payload," you ask "what are the validation rules for this endpoint and how do I verify they are enforced." Instead of "how do I write this migration," you ask "what are the data integrity constraints and what does the rollback path look like."
The skill shift is real, but it is less dramatic than people think. You are still an engineer. You still need to understand the domain, the architecture, and the trade-offs. What changes is where you spend your attention. Less time in the implementation details, more time in the specification and verification layers. Less time writing code, more time reading it critically and deciding whether it meets the bar.
And here is one thing every developer can relate to. How many hours have you spent staring at an error message in your terminal, tracing it back through five layers of abstraction to find the one line that broke? By moving up the abstraction layer, you spend less time in that debugging loop. The AI persona handles the implementation, your quality gates catch the failures, and the feedback loop resolves them. You get to focus on the parts of engineering that you actually enjoy, the problem solving and the architecture, and less on the parts that drain your energy.
What This Means for Jobs
So will AI reshape jobs in software engineering? Yes, it will. But the skills it requires are not as foreign as the headlines suggest.
If you have ever managed a team, you know how to scope work and define expectations. If you have ever written a user story with clear acceptance criteria, you know how to instruct an AI persona. If you have ever set up a CI pipeline or a code review process, you know how to build quality gates. If you have ever run a sprint retro and adjusted your process based on what went wrong, you know how to iterate on your AI management layer.
The abstraction level moved up. The skills did not fundamentally change. They just apply to a different layer now.
Of course, this raises an even bigger question. If AI can handle the implementation layer of software development, what happens when you zoom out further? Past the code, past the architecture, into the strategic layer. What happens when you apply the same model of personas, workstreams, and quality gates to idea validation, market analysis, and product strategy?
That is what I will explore in the next article. Because the same principles that let you manage a virtual engineering team also let you validate ideas faster than ever before.
I am currently building multiple projects using this exact model, and they will launch soon. If you want to stay in the loop and see how this plays out in practice, keep an eye on my socials.
Top comments (0)