Our organization has adopted AI engineering as its normal approach to software development. As that work has progressed, I have found myself increasingly trusting the quality of AI’s output over the work and recommendations of people I would previously have deferred to. That applies across software engineering, security operations, development operations, financial operations, and quality engineering. It is an uncomfortable observation to make about colleagues and professional disciplines, but it has become central to how I think about organizing technical work.

My confidence in people has become more selective. The people whose opinions I value most can explain why a proposed solution is sound, identify where an argument fails, and recognize when an apparently convincing answer is wrong. AI has increased the responsibility I believe those people can carry. At the same time, it has made me less willing to distribute decisions among specialists simply because their titles suggest that their involvement should improve the result.

This changes the argument about the software development lifecycle. Faster implementation is part of the story, but the more consequential question is who adds judgment that improves on what AI can already produce. If that contribution is concentrated in fewer people than we previously assumed, there is a reason to reconsider the handoffs and review functions through which we distribute responsibility.

How implementation shaped the traditional lifecycle

In many software organizations, implementation has historically consumed the largest portion of a project’s time and budget. Product management, business requirements documents, and discovery established an initial direction, after which engineering began the longer task of translating that direction into working software. Because implementation was expected to take months, there was a practical incentive to start it before every requirement had been resolved. Teams proceeded with enough information to begin and addressed uncertainty as development continued.

Viewed as a rough distribution of effort, this resembled a bell curve. Requirements occupied the left side, implementation formed the peak, and testing occupied the right. The long implementation period also allowed engineers to fill gaps in the specification, clarify business rules, and reconcile expectations as they worked. We relied on that capacity to compensate for decisions the organization had not made before development began.

Testing generally received a smaller allocation of time, and that allocation was vulnerable when development ran late. By then, the organization had already made a substantial investment and faced pressure to begin realizing a return. Shortening testing offered a way to preserve a delivery date without reducing the feature set. The resulting schedule reflected financial and organizational pressure as much as an assessment of how thoroughly the software needed to be tested. Problems left undiscovered would eventually emerge through production use.

The separation of development and quality engineering also reflected these conditions. Testing required expertise distinct from implementation, and assigning it to a separate group allowed developers to concentrate on difficult technical work. Developers could move to the next feature while quality engineers evaluated the previous one. That arrangement helped allocate scarce engineering capacity, although it also introduced handoffs, delays, and repeated transfers of context when defects were returned for correction.

The changing distribution of effort

Our experience with AI has challenged the assumption that implementation must remain the dominant activity. In an earlier post, I described a project estimated at 14 weeks that three engineers completed in 34 wall-clock hours, along with a 23-sprint project delivered in three and a half weeks. These examples do not establish a universal rate of improvement, but they have been significant enough to change how I evaluate our delivery process. When implementation can proceed at that pace, the cost of unresolved requirements becomes much more visible.

An agent can produce a plausible implementation before stakeholders have agreed on the behavior they actually need. If a business rule is ambiguous, faster code generation may simply produce the wrong result sooner. Requirements therefore need more deliberate attention to expected behavior, exceptions, dependencies, and acceptance criteria. This does not necessarily require longer documents or an attempt to eliminate all uncertainty before development begins. It requires resolving the decisions that would otherwise force engineers or agents to guess about the intended outcome.

Verification becomes more important for a related reason. As the cost of producing code declines, the ability to establish whether that code satisfies the requirement accounts for a greater share of the engineering task. AI can assist with test generation, regression coverage, and the exploration of failure cases, making broader verification more practical. However, the value of those checks depends on their relationship to the intended behavior. Tests that reproduce an incorrect assumption in the implementation can pass without demonstrating that the software is suitable for use.

The inverted curve describes this change in relative emphasis. Implementation occupies a smaller share of the work, while defining the outcome and establishing that it has been achieved become more prominent. It is a conceptual picture, not a measured distribution, and it does not imply that verification should become a longer phase after development. It suggests that the people directing and evaluating the work need to exercise better judgment at both ends of the process.

What AI reveals about expertise

The more difficult change concerns the basis on which we trust technical advice. Organizations often use specialization, seniority, and participation in review processes as evidence of competence. Those are understandable shortcuts when a leader cannot personally evaluate every recommendation. However, they can also allow someone to acquire authority through familiarity with a process or vocabulary without demonstrating an equivalent ability to solve the underlying problem.

AI gives me another way to examine those recommendations. I can compare explanations, investigate alternatives, and ask what evidence supports an objection. In that comparison, some human contributions become more valuable, while others offer less than I had assumed. A specialist who cannot explain why a recommendation is better than the AI’s proposal no longer receives the same presumption of authority from me. The same applies to a reviewer who identifies a concern but cannot connect it to a credible failure, cost, or constraint.

Put plainly, I think AI is exposing people who have been able to pass as experts without consistently demonstrating expert judgment. That is a strong claim, and I mean it as an account of what I am observing rather than a conclusion about every practitioner in these disciplines. I increasingly favor AI’s answer when it is better supported than a person’s answer. Professional courtesy cannot be the basis for accepting weaker technical work.

Part of my own value to peers and senior leaders has always been the ability to recognize when a technical argument does not hold up. I need to explain what is wrong, why it matters, and what would make the conclusion defensible. AI has made it clearer to me which other people can do that reliably, including when the flawed argument comes from AI itself. Those are the people whose opinions I increasingly seek out. Their value grows because they can direct and assess a much larger volume of work than they could previously produce themselves.

Integrating quality, architecture, and security

I believe quality engineering should be part of the engineering process, with responsibility for testing retained by the team producing the software. The expertise of quality engineers remains valuable, particularly in challenging assumptions and identifying failure conditions that a feature’s author may overlook. That expertise can inform requirements, test design, and the checks performed during implementation. A separate queue for testing is not a necessary consequence of having people with specialized testing skills.

This distinction matters because a handoff carries costs beyond the time spent executing tests. Another team must understand the feature, interpret its requirements, investigate findings, and return defects to people who may already be working on something else. That additional involvement is worthwhile when it contributes judgment or evidence the work would otherwise lack. The existence of another team does not establish that it does. Incorporating verification into engineering makes responsibility clearer: the people producing the software must establish that it meets its acceptance criteria before considering it finished.

The same reasoning applies to proposals within our organization for architecture and security agents to review work after development is complete. These agents can contribute useful expertise, but placing them at the end preserves the sequence we should be reconsidering. Architectural constraints should influence design before implementation commits the team to a particular structure. Security requirements should inform behavior and testing while changes are being made. Both types of agents can participate throughout this work, with their findings addressed as part of engineering rather than becoming another team’s subsequent assignment.

Our specification-driven workflows, agent skills, and Model Context Protocol tooling provide ways to make relevant standards available during development. Their presence alone does not establish compliance; engineering must also verify that the implementation follows them. The objective is a process in which architecture, security, and functional checks contribute to the decision that work is complete. A separate review stage should not be needed to perform checks that could already have been incorporated into that process.

Concentrating responsibility where judgment is strongest

The organizational implication is that I would place more responsibility with fewer people whose judgment has proved reliable. Previously, even an exceptionally capable engineer had limited time to implement features, investigate operational concerns, examine costs, and evaluate security decisions. Distributing that work was partly a response to the amount of effort involved. AI changes how much of it a capable person can undertake, although that person still needs to recognize the limits of their understanding and seek expertise where it is genuinely needed.

Broader responsibility should depend on demonstrated ability to evaluate results. Someone who accepts every AI answer is not exercising more judgment than someone who repeats a policy without understanding its purpose. The people I would trust with wider ownership can distinguish a useful answer from a plausible one, pursue an uncertainty until it is resolved, and take responsibility for the consequences. AI allows those people to act on their judgment across more of the lifecycle, reducing the need to spread decisions across functions that may contribute less insight.

This approach also changes how specialists support engineering. In my earlier criticism of shift left, I argued that security and infrastructure teams too often transferred their responsibilities to developers without providing adequate tools. Integrating their expertise into AI-assisted engineering should address that problem. Specialists can develop approved patterns, maintain agent guidance, and build checks that make their standards usable during development. They remain responsible for the quality of that guidance and for improving it when experience reveals gaps.

Engineering, in turn, remains accountable for the delivered software. That accountability includes evaluating the evidence produced by tests and other checks, rather than relying on an agent’s assurance that it followed instructions. Agreement between two agents may still reflect a shared mistaken assumption. Useful verification must be grounded in explicit requirements, observable behavior, and relevant technical controls. Incorporating this work into engineering preserves its importance while reducing the need to transfer ownership between stages.

The lifecycle I favor can therefore be described as requirements, engineering, and delivery. Requirements establish the intended outcome and the basis for acceptance. Engineering includes implementation, testing, architectural conformance, and security verification, with findings resolved before the work is considered complete. Delivery places the result in use and provides feedback that can inform subsequent requirements. The people accountable for this work should be selected for the quality of their judgment and supported by AI, with specialist involvement determined by what the problem requires.

My growing trust in AI has made me more demanding about the human contribution to that process. I still place considerable value on expertise, but I am less willing to infer it from a role, a title, or a place in an approval chain. Where people demonstrate sound judgment, I want to give them greater responsibility and the tools to exercise it. Where an additional handoff produces weaker reasoning than the AI already provides, I no longer see a reason to preserve it. That is the deeper organizational change behind the inverted curve, and it requires more than accelerating implementation within the structure we already have.