The AI-Era Engineering Org in Practice
Published:
A previous piece on this site made the case that traditional engineering org structures break down in the AI era, and introduced a set of conceptual role archetypes for what might replace them. That piece used invented names for those archetypes: AI Workflow Architect, Quality Orchestrator, and so on. Useful for argument, but not what you find on anyone’s LinkedIn profile.
This piece is the practical follow-on. It grounds the same thinking in the job titles your team actually uses today. But before diving into roles and structures, there is a correction to make to the premise of this piece as originally conceived.
When you draw an AI-era engineering team as an org chart, it looks familiar. An Engineering Manager at the top, Senior Engineers below, Quality Engineers embedded in the team, a Platform function handling the developer experience. Someone seeing that diagram without context would not immediately conclude that AI had changed anything.
That is not because nothing has changed. It is because the org chart is the wrong diagram.
The Wrong Diagram
Org charts show reporting relationships. They answer the question: who is accountable to whom? That is a useful question for understanding authority and responsibility, but it does not show how work actually moves through a team.
In a traditional engineering team, those two pictures, the reporting structure and the work structure, are reasonably well-aligned. Senior engineers produce the most complex work. Managers track and coordinate delivery. QA tests what engineering produces. The job titles roughly describe the flow of work.
In an AI-era team, the alignment breaks. AI agents can produce the work that used to define seniority: complex code, test suites, architectural analysis, documentation. The question is no longer primarily about who can produce what. It is about who can direct the AI effectively, and who has sufficient depth to evaluate whether what the AI produced is correct, appropriate, and safe to ship.
That draws a different picture entirely. Not a reporting structure, but an operating model: a loop of direction and evaluation, running continuously at every level of the organisation.
The Operating Model
The loop operates within a governance layer that must be established before feature work begins. Teams, with AI assistance, produce and maintain documentation that defines the constraints within which AI agents operate: architectural boundaries, security requirements, business rules, coding standards, and what agents are and are not permitted to do in a given context. This is not bureaucratic overhead. It is the mechanism by which human intent is made legible to AI at scale. Without it, each engineer is implicitly negotiating those constraints on every prompt. With it, the constraints are explicit, auditable, and consistent across the team.
That two-level structure looks like this:
%%{init: {'theme': 'base', 'themeVariables': {'background': '#092C3A', 'primaryColor': '#0A75A7', 'primaryBorderColor': '#2FC998', 'primaryTextColor': '#F5F7FA', 'secondaryColor': '#0d4a5f', 'tertiaryColor': '#0d3545', 'lineColor': '#2FC998', 'edgeLabelBackground': '#0d3545', 'clusterBkg': '#0d4a5f', 'clusterBorder': '#2FC998'}}}%%
graph TD
subgraph gov["Governance Layer"]
REQ["Business Context and Requirements"]
STAFF["Staff / Principal Engineer"]
AI_G["AI Agent"]
GOV["Governance Documentation"]
REQ --> STAFF
STAFF -->|directs| AI_G
AI_G -->|generates draft| GOV
STAFF -->|evaluates and approves| GOV
end
subgraph feature["Feature Layer"]
LOOP["Per-Feature Loop"]
PIPE["Delivery Pipeline"]
LOOP --> PIPE
end
GOV -->|constrains all feature work| LOOP
LOOP -.->|patterns inform updates| GOV
style REQ fill:#0d4a5f,stroke:#6C8C99,color:#B0C8D4
style STAFF fill:#0A75A7,stroke:#2FC998,color:#F5F7FA
style AI_G fill:#0d3545,stroke:#6C8C99,color:#B0C8D4
style GOV fill:#0A75A7,stroke:#E3A552,color:#F5F7FA
style LOOP fill:#2FC998,stroke:#2FC998,color:#092C3A
style PIPE fill:#66B3D9,stroke:#66B3D9,color:#092C3A
Within that governance context, every meaningful unit of feature work runs through this loop:
- An engineer specifies the expected behaviour, interface contracts, and functional and non-functional requirements, within the established governance context.
- The AI generates tests from those specifications, making requirements concrete and executable before any implementation exists.
- The engineer evaluates the tests: do they correctly capture the intent? Are there gaps in the specification that need to be closed before proceeding?
- The AI implements against the approved test suite, using it as a concrete definition of done.
- The engineer evaluates the implementation: do the tests pass? Is the approach architecturally appropriate? Are there concerns the tests themselves did not anticipate?
- The engineer either accepts the output, redirects the agent, or escalates to someone with greater depth.
- A Quality Engineer augments: reviewing the AI-generated test suite for coverage gaps, directing the AI to add non-functional and systemic tests, evaluating whether coverage is adequate for the risk profile of this change.
- Once accepted, the output moves into the delivery pipeline, which the team owns.
This loop is not new. Engineers have always reviewed each other’s work. What is new is the volume and velocity of the output requiring evaluation, the fact that AI-generated output can be subtly wrong in ways that look superficially correct, and the degree to which evaluation depth, the ability to know when the AI is wrong, has become the primary differentiator between roles.
Compare this with the model most teams already recognise: a mature agile or DevSecOps setup where testing is continuous, security is in the pipeline, and the team owns delivery end-to-end.
%%{init: {'theme': 'base', 'themeVariables': {'background': '#092C3A', 'primaryColor': '#0A75A7', 'primaryBorderColor': '#2FC998', 'primaryTextColor': '#F5F7FA', 'secondaryColor': '#0d4a5f', 'tertiaryColor': '#0d3545', 'signalColor': '#2FC998', 'signalTextColor': '#F5F7FA', 'labelBoxBkgColor': '#0d3545', 'labelTextColor': '#B0C8D4', 'noteBkgColor': '#0d3545', 'noteTextColor': '#F5F7FA'}}}%%
sequenceDiagram
participant Eng as Engineer
participant CI as CI/CD Pipeline
participant QE as Quality Engineer
Eng->>Eng: Implement feature and unit tests
Eng->>CI: Push branch and open PR
CI-->>Eng: Automated test results and security scan
Eng->>Eng: Review results, address issues
QE->>Eng: Exploratory testing and review
QE-->>CI: Approved
CI->>CI: Merge and deploy
This is a good baseline. Sequential handoffs between development, QA, and operations have been replaced by a continuous loop. Security is embedded rather than bolted on at the end. The team owns the pipeline. Quality engineers are collaborators, not gatekeepers. For teams still operating with gated handoffs between separate development, QA, and operations functions, reaching this baseline is itself a significant transition, and the AI-era model is not yet reachable. What follows assumes this agile foundation is already in place.
The AI-era model changes something more fundamental: who produces the artefacts.
%%{init: {'theme': 'base', 'themeVariables': {'background': '#092C3A', 'primaryColor': '#0A75A7', 'primaryBorderColor': '#2FC998', 'primaryTextColor': '#F5F7FA', 'secondaryColor': '#0d4a5f', 'tertiaryColor': '#0d3545', 'signalColor': '#2FC998', 'signalTextColor': '#F5F7FA', 'labelBoxBkgColor': '#0d3545', 'labelTextColor': '#B0C8D4', 'noteBkgColor': '#0d3545', 'noteTextColor': '#F5F7FA'}}}%%
sequenceDiagram
participant SE as Senior Engineer
participant AI as AI Agent
participant QE as Quality Engineer
SE->>AI: Specify: behaviour, interfaces, requirements
AI-->>SE: Generated test suite
SE->>SE: Evaluate: do tests capture intent?
SE->>AI: Implement: pass these tests
AI-->>SE: Draft implementation
SE->>SE: Evaluate: tests pass? implementation appropriate?
SE->>AI: Redirect: adjust approach
AI-->>SE: Revised implementation
QE->>QE: Evaluate: coverage gaps? non-functional requirements?
QE->>AI: Augment: add edge cases and non-functional tests
AI-->>QE: Additional coverage
QE->>QE: Evaluate: systemic risk? adequate for this risk profile?
QE-->>SE: Sign-off with augmented suite
SE->>SE: Accept and ship via team-owned pipeline
The loop structure is recognisable from the agile baseline. What has changed is who produces. In the agile model, the engineer is still the primary producer: writing the code, writing the tests, owning the output. In the AI-era model, production has moved to the AI entirely. The engineer specifies intent; the AI generates both the test suite and the implementation. The Quality Engineer is not a downstream checkpoint: they are auditing and augmenting what the AI has already produced, adding the depth of coverage that per-feature generation typically misses. For teams already working in mature agile or DevSecOps ways, the structural loop does not need to be rebuilt, only reoriented: the bottleneck moves from production to the quality of specification and evaluation at each step.
These are the questions that determine team velocity. They are not answered by the org chart.
The Roles
Understanding the operating model first matters because the role changes only make sense in that context. What follows uses today’s familiar job titles, but they are temporary containers. The responsibilities behind them are being redistributed. Some titles will merge within five years; some will disappear; a few new ones will emerge that cannot yet be cleanly named. The structural thinking matters more than the labels.
Each role below is described in three parts: what it looks like today, how it is shifting, and where it is heading.
Engineering Manager
What this role looks like today
Sprint coordination, one-to-ones, performance reviews, hiring, team health. The EM is the primary buffer between the team and organisational noise, and success is measured in delivery cadence and how well the team is functioning as a unit.
How it is shifting
The EM’s traditional lever for improving delivery was removing blockers and improving process. In an AI-era team, the delivery system is more complex: it includes AI agents, the humans directing them, and the evaluation loops between. An EM who manages only the human side of that system will miss most of the signals. Increasingly, the EM needs to assess whether the direction/evaluation loop is working well: are engineers spending time on evaluation or are they rubber-stamping AI output? Is the quality bar being maintained or is velocity masking accumulating debt? Are the right people in the evaluation roles for the complexity of work the team is handling?
Where it is heading
The version of this role defined purely by people management and delivery tracking is under pressure. The surviving form looks more like an operating system designer for the team: responsible for how humans and AI work together, not just for the humans themselves. The EM who understands the direction/evaluation loop, who can distinguish rubber-stamping from genuine assessment, and who can identify when evaluation depth is inadequate for the risk level of the work being shipped, becomes a genuinely strategic function. The title will likely persist; the job description will need substantial revision.
Staff / Principal Engineer
What this role looks like today
Cross-team technical leadership. Architecture decisions. Resolving the hardest technical problems. Setting the quality bar for the organisation’s most consequential work.
How it is shifting
This role becomes the primary owner of the governance layer that makes AI-augmented delivery coherent at scale. Before any feature work begins, AI agents need to know what they are and are not permitted to do: which architectural patterns apply, which security constraints are non-negotiable, which business rules must not be violated. Producing and maintaining that governance documentation, with AI assistance, becomes a core responsibility. So does determining which AI agents are trusted in which contexts and why; what review processes are proportionate to the risk of AI-generated changes in different parts of the codebase; and how to maintain architectural coherence across a system where multiple teams are directing AI simultaneously. The Staff or Principal Engineer is increasingly the person who defines the outer boundaries of AI autonomy, not just the person who solves the hardest implementation problems.
Where it is heading
This role grows in strategic importance in direct proportion to the scale of AI adoption. The governance documentation a Staff or Principal Engineer produces and maintains is not a one-time artefact: it evolves with the codebase, with the team’s understanding of where AI can be trusted, and with changes in the business context that shift which constraints are load-bearing. At larger organisations, there may be a clearer split between deep technical systems work and AI systems governance as a distinct specialism within the Staff and Principal track. The title will persist because it already carries the right connotations of seniority and scope; the substance behind it is shifting significantly.
Senior Engineer
What this role looks like today
Complex feature implementation, code review, day-to-day technical decision-making, some mentoring. The primary engine of delivery in most engineering teams.
How it is shifting
The Senior Engineer moves from primary producer to primary evaluator and specifier. Writing precise requirements, evaluating AI-generated test suites for correctness of intent, assessing AI-generated implementations for architectural appropriateness: these become the defining competencies. Humans are unlikely to write production code at all in the near future, including tests. What does not change is the depth required to evaluate what the AI produces. That depth was built through writing code; it is now applied to auditing it. Senior Engineers who have developed genuine technical depth are well-positioned for that shift. Those who defined their seniority primarily through production speed, rather than through understanding what correct and appropriate looks like, face a harder transition.
Where it is heading
The title may quietly fork. Some Senior Engineers move toward architecture and evaluation at the system level, becoming the people who define what correct looks like across a domain rather than for a single feature. Others move toward what might eventually be called AI workflow lead positions, focused on how AI is directed and governed within the team’s delivery practice. Both are legitimate trajectories. The version of this role defined purely by implementation speed has a limited future; the version grounded in genuine technical depth, now applied to evaluation rather than production, remains as valuable as it has ever been.
Mid-level Engineer
What this role looks like today
Independent feature delivery, growing architectural awareness, occasional mentoring of junior colleagues. Working toward the confidence and depth of a Senior Engineer, earning autonomy incrementally.
How it is shifting
This is the most disrupted role in the organisation. The traditional progression, writing increasingly complex code and building evaluation depth through that production work, is interrupted because AI handles all production output: tests and implementation alike. Mid-level engineers need to develop specification and evaluation skills, but the production repetition that would historically have grounded those skills is no longer available to them. The career path becomes harder to read. The feedback loops that used to make growth legible, shipping features independently, solving hard problems without help, are less reliable signals when AI is doing the producing.
Where it is heading
The undifferentiated mid-level as a career stage may become harder to sustain at smaller organisations. The title is likely to fragment: some mid-level engineers evolve toward orchestration and architecture tracks, becoming the people who translate business requirements into precise AI specifications; others move toward quality and evaluation specialisms, developing the depth to audit AI output at a level that goes beyond the per-feature view. Organisations will need to be more deliberate about how they define mid-level and how they structure the development of people in those roles. Leaving the career path implicit, as many organisations currently do, is less sustainable when the traditional signals of progress, writing more complex code, shipping larger features independently, are no longer the primary indicators of growing capability.
Junior Engineer
What this role looks like today
Implementing well-defined tasks under guidance, learning by doing, building foundational skills through repetition and feedback. Developing the intuitions that will eventually support independent work.
How it is shifting
The traditional learning pathway is directly disrupted. AI now generates both the tests and the implementation that a junior would previously have produced, which removes the production repetition that builds genuine evaluation depth. Organisations that have not thought carefully about this end up with junior engineers who can direct prompts but have not developed the underlying judgement to know when the AI’s output is wrong. That is a fragile position: it looks productive on the surface and fails once the work becomes more complex or the AI produces something subtly incorrect.
Where it is heading
The junior role as traditionally defined is under the most pressure of any level. At smaller organisations it may effectively disappear. Where it survives, it will look more like a structured apprenticeship: focused on code evaluation, testing, domain knowledge, and deliberate practice in assessing AI output rather than unconstrained implementation. Some organisations will preserve the junior role for human capability reasons rather than efficiency ones. That is the right call, and it requires designing the role carefully rather than assuming the traditional model still applies.
Quality Engineer
What this role looks like today
Test planning, test execution, automation, bug reporting. Often positioned as a downstream support function. Automation maturity varies significantly across teams.
How it is shifting
In the operating model described above, the Quality Engineer is not downstream: they enter after the AI has generated a test suite from the engineer’s specification and produced an implementation against it. The QE’s role is augmentation and audit, not generation. They review the AI-generated test suite, identify coverage gaps, direct the AI to add non-functional and systemic tests, and evaluate whether what has been generated is adequate for the risk profile of this particular change. The direction and evaluation of that AI-assisted augmentation remains with the QE: they are assessing whether the coverage is adequate for the risk profile of this particular change, not delegating that judgement. What the QE brings that neither the development engineer nor the AI can substitute is the combination of engineering depth and cross-system pattern recognition: knowing which failure modes are most likely, which edge cases have caused incidents elsewhere, and where the test suite is technically present but strategically thin. The traditional QA role, defined by manual testing and basic automation, is being deprecated. The version that survives requires something closer to the Software Development Engineer in Test model: a full engineer who specialises in quality.
This is a hard truth for many QA organisations, particularly those without strong pathways into deeper engineering practice. It is not a judgment on the QA professionals in those roles, many of whom have been asking for more engineering depth and closer integration with development teams for years. The AI era is forcing that change regardless. Some will make the transition; others will not. That deserves honest acknowledgement rather than optimistic hand-waving.
Where it is heading
At mature organisations, the Quality Engineer becomes one of the most strategically important technical roles. The seniority ladder is legible: Quality Engineer embedded in stream-aligned teams evaluating day-to-day AI output, Senior Quality Engineer working across teams on systemic patterns, Principal Quality Engineer holding the organisation-wide evaluation framework and governing how AI-generated work is assessed at scale. The execution-focused version of this role continues to be automated away. The engineering-depth version grows in influence.
Platform Engineer
What this role looks like today
Internal developer experience: shared tooling, infrastructure abstractions, build and deployment templates, observability tooling. The platform function exists so that stream-aligned teams do not each have to solve the same foundational problems independently.
How it is shifting
A distinction matters here, and it matters more in the AI era than it did before. Platform Engineering in a DevOps culture does not own CI/CD pipelines or observability dashboards. It provides the abstractions, templates, and golden paths that enable teams to own those things themselves. Teams own their delivery pipelines; they own their observability implementation; they own their operational practice. The platform team provides the tooling that makes that ownership tractable rather than prohibitively complex.
In the AI era, that same model extends to AI capability. Platform Engineering becomes responsible for the internal layer through which teams access AI tooling safely and consistently: governing which agents are approved for use and in which contexts, establishing cost controls and usage monitoring, building the shared infrastructure that gives teams guardrails without removing their autonomy. The platform team does not own how teams use AI in their workflows. It provides the abstraction layer that makes safe, consistent access possible. Teams own the integration.
Where it is heading
At larger organisations, the platform function is likely to develop a distinct AI platform specialism: a group whose specific responsibility is the shared AI capability layer that every other team depends on. At smaller organisations, this work sits with one or two platform engineers alongside their other responsibilities, which is sustainable for a while but not indefinitely. The AI governance and cost visibility functions of platform engineering will become increasingly consequential as AI usage scales, making this a strategically important specialism rather than an infrastructure afterthought.
How Scale Shapes the Model
The direction/evaluation loop described above applies at any team size. What changes with scale is how the evaluation responsibilities are distributed, how explicitly the governance layer needs to be defined, and where the structural risks concentrate.
Small Scale (2-10 folks)
At small scale, the loop is compressed into a few people who each hold multiple parts of it. A Senior Engineer is also the evaluator, the architect, and often the de facto Engineering Manager. There is no standalone Quality Engineer; quality evaluation is absorbed by whoever has the most depth. Platform responsibilities are either absorbed by the most infrastructure-inclined engineer or offloaded to managed services entirely. Governance documentation at this scale often lives informally, embedded in one or two people’s understanding of the codebase and its constraints rather than written down anywhere.
This informality is sustainable only as long as those people remain. The force-multiplier effect of AI means a well-structured team of three to five engineers at this scale can deliver what previously required eight to ten, but the evaluation depth is now the critical variable: a team of four anchored by a highly experienced engineer is in a fundamentally different position to a team of four where the most senior person has two or three years of experience, even if both teams are directing AI at similar velocity. The two-pizza principle still holds; the optimal team size has likely shrunk, but the seniority distribution within that team matters more than it did before.
Medium Scale (10-40 folks)
As organisations grow, stream-aligned teams begin to form, each with end-to-end ownership of a product area. The loop now runs within each team, but the evaluation standards need to be consistent across them. This is where the governance layer transitions from informal to essential. Without someone holding the cross-team evaluation framework, teams optimise locally: AI output from one team introduces patterns that conflict with adjacent teams’ assumptions, and the architectural coherence of the overall system degrades quietly until it becomes visible as a significant problem. The Staff or Principal Engineer role becomes non-negotiable at this point, not because someone needs to solve the hardest implementation problems but because someone needs to own the shared constraints within which all AI generation across the organisation operates. Quality Engineers move from absorbed responsibility to dedicated embedded roles. The platform function begins to separate out, often as one or two engineers initially, providing the tooling foundations that prevent each team from having to solve the same infrastructure problems independently.
Large Scale (40+ folks)
At larger scale the full topology becomes explicit. Stream-aligned teams multiply, each running the same internal loop but now needing coherent interfaces with adjacent teams. An enabling function may emerge, a concept drawn from Team Topologies: a small group of Staff Engineers or senior specialists who temporarily work alongside stream-aligned teams to build evaluation capability, establish AI workflow patterns, and transfer governance knowledge, rather than simply setting standards from a distance and expecting teams to figure out the application themselves. The distinction matters: an enabling function builds capability in the team and then steps back; a centre of excellence tends to create dependency. The platform team develops the AI governance and tooling layer that every other team depends on, and at this scale it begins to look like a product function in its own right, with a roadmap, defined consumers, and real consequences when it fails. The evaluation loop is running simultaneously across many teams; the structures that keep it coherent across the organisation become as important as the loop itself.
What Comes Next
The roles in this piece use familiar titles. The structures are recognisable. Neither of those things should suggest that not much has changed. The content of every role described above has shifted, and the rate of change has not slowed. The question to ask about any engineering role is not “is the title still there?” but “does the person holding it have the evaluation depth their part of the loop requires?” That is a harder question than it looks: evaluation depth is not visible on a CV, does not show up clearly in an interview, and cannot be inferred from years of experience alone. Organisations that have not yet developed ways of assessing it are making structural decisions on incomplete information.
The human dimension of this transition deserves to be stated plainly. For people in QA and junior engineering roles today, the next few years will be genuinely difficult. The skills that defined competence in those roles are being automated, and the skills that replace them require investment and deliberate development that not every organisation will provide. The organisations that handle this well are those that treat structural change as a people challenge first and an efficiency opportunity second.
A third piece in this series is in progress. It addresses the question this one deliberately sidesteps: what tells you it is time to make a structural change? What signals, in the team’s operating model, in its cognitive load, in its coordination overhead, indicate that the current structure has reached its limits? That piece will give engineering leaders a more practical framework for making that call.
If you are navigating these transitions now and want to think through what the right model looks like for your specific organisation, get in touch with Wyrd Technology. These decisions are consequential, and getting them right is worth the time.
About the Author
Tim Huegdon is the founder of Wyrd Technology, a consultancy that helps engineering leaders design organisations fit for the AI era. With over 25 years of experience in software engineering and technical leadership, he works with CTOs and engineering directors to rethink operating models, redefine role structures, and build the governance practices that allow AI-augmented teams to deliver at pace without sacrificing quality or architectural coherence.