AI has made it possible for people to build working software in areas where they have relatively little prior experience. While the possibilities introduced by this new variety of AI-enabled or agentic engineering are vast and exciting, the hype can also obscure an important but subtle distinction: getting something to work with AI isn’t necessarily the same as engineering a reliable, repeatable process for building it.
In a recent conversation, Axian CTO Tyler Holmes compared the emerging role of the agentic engineer to that of a general contractor. A good general contractor doesn’t need to frame every wall, pull every wire, or install every pipe. But they’ve done enough of that work themselves to understand how the trades fit together, what high-quality work looks like, and which decisions made early in a project can create problems later.
The same principle applies when AI agents take on more of the work traditionally performed by developers, QA, tech leads, and DevOps. The agentic engineer’s job isn’t simply to produce more code with AI. It’s to design the jobsite: supplying the right context, establishing constraints, coordinating work, evaluating results, and improving the environment when something goes wrong. As Holmes puts it: “Just getting it to work usually isn’t engineering. That’s usually where the work begins.”
As the tools become more capable, coordinating them becomes a discipline of its own.
What Does an Agentic Engineer Do?
For Holmes, the difference between using AI and practicing agentic engineering comes down to turning capability into a craft. Getting a frontier or open-weight model to produce the desired result is only the beginning. Engineering means creating a system capable of producing the same results repeatedly, evolving toward lower cost, faster outputs, and improved quality.
Holmes’ general contractor analogy helps make this distinction concrete. A GC doesn’t simply assign work and wait for the finished building. They select crews for particular jobs, establish the conditions under which they work, divide the project into manageable assignments, verify completed work, and know when a problem requires escalation. An agentic engineer performs many of the same functions in a software delivery environment.
| Responsibility | General contractor | Agentic engineer |
| Crew selection | Assigns framing, electrical, and plumbing to crews suited to each job. | Selects models, harnesses, task context, and human-agent pairings for implementation and review. |
| Site governance | Checks qualifications, restricts access, and defines who may authorize work. | Routes tasks by risk and capability; sets identities, data permissions, tools, approval gates, and runtime limits. |
| Work sizing | Scopes work so one trade can complete it and have it inspected. | Creates bounded tasks with explicit inputs, outputs, and acceptance criteria that fit context, time, and cost limits. |
| Quality verification | Requires testing and inspection before work is accepted or concealed. | Requires functional, security, and performance checks before acceptance and makes test evidence part of “done.” |
| Escalation judgment | Stops work when a proposed change requires a specialist’s decision. | Sets escalation triggers for ambiguous requirements, destructive migrations, and architecture decisions requiring human judgment. |
A shared corpus can also provide the rules, history, and institutional knowledge needed to keep agents working from the same information.
Recent studies reinforce the importance of the environment surrounding AI, describing generative AI as an amplifier: it magnifies both the strengths of high-performing organizations and the dysfunctions of struggling ones. Teams with strong platforms, clear workflows, effective testing, and well-designed processes can amplify those advantages with AI. Weak foundations can be amplified just as easily.
This distinguishes the agentic engineer from someone who simply knows how to get useful output from an AI model. The agentic engineer designs and manages the environment that turns individual outputs into reliable work. Simply giving every subcontractor a better power tool, after all, doesn’t guarantee a better building.
More Output ≠ Safer, Better, or More Reliable Jobsites
One of AI’s biggest advantages can also create an entirely new kind of engineering problem: teams can produce software much faster, including software in areas where they have relatively little prior experience, than they can ensure its quality and safety. Holmes describes the unmanaged version of this as “spraying tokens everywhere.” Teams build quickly, move on quickly, and sometimes discover too late that they overlooked constraints around data volume, storage architecture, query performance, security, or infrastructure.
There’s good evidence that AI can accelerate individual development tasks. Recent surveys found that generative AI reduced time spent documenting code by 45–50%, generating code by 35–45%, and refactoring by 20–30%. Yet the gains fell below 10% for high-complexity tasks, suggesting that greater task complexity can narrow the advantage considerably.
Productivity at the task level also doesn’t necessarily translate neatly into productivity across an entire project. In a 2025 randomized controlled trial, 16 experienced open-source developers completed 246 tasks in repositories they knew well. Developers expected AI to make them 24% faster. With the early-2025 tools tested, they instead took 19% longer, even though they subsequently believed AI had accelerated their work.
These two findings aren’t necessarily contradictory. AI can make particular tasks dramatically faster without automatically making the entire engineering process more efficient. In fact, greater output can expose weak coordination and poor architectural decisions sooner. In other words, a faster subcontractor is useful. But someone still has to make sure the plumbing isn’t installed where the electrician needs to run the wiring.
Different Jobsites, Similar Blueprint
The details of agentic engineering will vary considerably from one organization to another. A GC building a hospital faces different requirements from one renovating a house, but the underlying job remains recognizable. Holmes sees the same pattern emerging across industries.
At an independent software vendor (ISV), the agentic engineer might assemble the architectural decisions, coding standards, infrastructure constraints, compliance requirements, and other context an agent needs to produce useful software. More importantly, when an agent produces bad code, the response isn’t simply to correct that piece of code. The engineer should also ask why the system allowed the mistake to happen, then improve the harness, corpus, or instructions so future agents are less likely to repeat it.
In manufacturing, the same role takes a different form. Holmes offers the example of a knife manufacturer with years of statistical process control data. A new design might look perfectly viable in CAD while closely resembling earlier designs that repeatedly failed because of particular materials or manufacturing tolerances. Making that history available to agents could surface the problem before the design reaches the production floor.
At a professional services firm like Axian, meanwhile, valuable context may be buried in MSAs, proposals, PDFs, scanned documents, and records of previous engagements. Private pipelines can extract details such as terms, pricing, assumptions, and previous work, making that institutional knowledge searchable without sending confidential client material to a public frontier model.
These are very different jobsites, but Holmes sees the same underlying responsibility at each one:
“We’re generally doing the same shapes of things: bringing information together, defining processes, enabling agents to do great work, and improving the environment those agents are operating in.”
The tools and tasks change, but the GC’s responsibility for coordinating the work remains recognizable.
Every Jobsite Needs Informed Workers
Human teams carry enormous amounts of context informally. An experienced engineer may know which systems are fragile, which shortcuts created software delivery problems in the past, which architectural decisions are effectively fixed, and which apparent requirements need clarification before anyone starts building. Some of that knowledge lives in documentation. Much of it lives in email, Slack conversations, ticket histories, and individual experience.
Just as importantly, an experienced engineer has developed a sense for when not to start. If the requirements are ambiguous or critical context is missing, they may stop and ask for clarification rather than simply proceed. AI agents don’t necessarily have this instinct. Therefore, the environment needs to provide not only sufficient context for the work but also explicit guidance about when an agent should escalate a decision, request more information, or refuse to proceed.
This creates one of the central responsibilities of the agentic engineer: building an agent-accessible corpus of organizational knowledge.
At its simplest, that corpus might begin as a collection of markdown files containing architectural guidance, coding standards, operating procedures, and known constraints. As the system matures, however, it can evolve into infrastructure of its own, combining vector embeddings for semantic retrieval with relational storage for structured information and an ingestion process for incorporating new knowledge.
Holmes describes two broad approaches to managing that knowledge. The first is an “LLM wiki,” an idea attributed to Andrej Karpathy consisting of a shared AI knowledge base that reconciles new information with what the system already knows before accepting it. This approach can produce a highly consistent corpus, but updates become increasingly expensive as the knowledge base grows because each new piece of information has to be checked against all existing facts.
One alternative is what Andrew B. Jones has called an “open brain.” Instead of resolving every contradiction during ingestion, the system prioritizes fast updates and identifies discrepancies as part of a maintenance process. The tradeoff is less consistency at ingestion in exchange for easier accumulation of knowledge.
Making more organizational knowledge available to agents also requires appropriate guardrails. The same corpus that gives an agent useful context may contain sensitive technical, operational, or client information, so access needs to be governed according to the work the agent is authorized to perform. Security risks can also originate in the information agents consume. The Open Worldwide Application Security Project (OWASP), for example, identifies prompt injection as a major risk for LLM applications because malicious instructions embedded in external content can influence model behavior.
Neither architecture is universally correct. The appropriate design depends on the organization, the use case, and how much consistency the application requires. The important point is that agents need access to the organizational context humans normally accumulate through lived experience. Unsurprisingly, informed agents make for better workers.
The Corpus Is How the Jobsite Learns
One of the most important differences between an agentic engineering system and simply using a better model is that the system itself can improve over time.
As Holmes puts it:
“Corpora like these, and the outputs they give agents, are usually the number one reason why these systems can actually improve (in place) over time.”
Without that shared knowledge layer, apparent improvement often comes from outside the organization. A new model is released, the team swaps it in, and performance improves. But the organization itself hasn’t necessarily learned anything.
A well-maintained corpus changes that. When an agent makes a mistake, the question becomes whether the environment can be changed so that the next agent is less likely to make the same mistake. If different crews repeatedly make the same error, you don’t want to spend your time following them around and repairing the same mistakes. You change the worksite: improve the job briefing packet, suggest better tools, or add a validation step that catches the problem before the work is accepted.
Better models can increase what individual agents are capable of doing, but the surrounding system determines whether those capabilities translate into reliable engineering. This is another area where the notion of AI as an amplifier is useful. Instead of simply waiting for better AI, your organization should set about deliberately improving the systems that AI amplifies.
Who Should Become an Agentic Engineer?
If agentic engineering is less about mastering a particular AI tool than understanding and coordinating the entire delivery environment, the people best positioned to fill the role may already exist inside many organizations.
Holmes sees today’s Solution Architect as the closest analogue. The role rewards breadth: enough experience with cloud infrastructure, data, web development, authentication, security, and software architecture to understand how decisions in one part of a system affect another. Just as importantly, it requires the communication and change-management skills to work across teams and earn trust.
Experience matters because much of the value comes from what Holmes calls “scar tissue.” Senior engineers have seen systems fail in ways that aren’t obvious from documentation or happy-path examples. They know which shortcuts tend to become expensive later, when a seemingly simple request hides architectural complexity, and when there isn’t enough information to proceed safely.
That judgment becomes particularly important as AI tools become easier to use. Stack Overflow’s 2025 Developer Survey found that 84% of respondents were using or planning to use AI tools in their development process. Yet 46% said they distrusted the accuracy of AI-generated output, compared with 33% who trusted it, and only 3% reported highly trusting it. Greater access to AI, in other words, doesn’t eliminate the need for experienced technical judgment.
For at least the next 18 months, Holmes expects agentic engineering to remain primarily a senior role. AI can make capable engineers considerably more productive, but it doesn’t substitute for the experience required to design the environment in which agents operate. As Holmes puts it, “You’re probably not going to be a good agentic engineer if you’re not already a good engineer.”
Over time, the tools and practices will become more standardized, and the role itself may become more accessible. For now, however, agentic engineering excellence requires much of the same foundation as good engineering more generally:
- Broad technical understanding
- Sound judgment
- Communication skills
- Enough experience to recognize problems before they become expensive
Better Tools Expand the General Contractor’s Reach
The rise of agentic engineering doesn’t mean developers stop writing code or that AI agents operate independently. It means more work can be delegated and performed in coordination, while experienced engineers increasingly focus on designing the environment in which that work happens.
In that sense, better tools don’t eliminate the need for GCs. They expand the GC’s reach and leverage the breadth of their knowledge. More capable agents can take on more work, but someone still has to understand how that work fits together, establish the conditions under which it should be performed, evaluate the results, and improve the system when something goes wrong.
Even with powerful AI models, the hard part of engineering remains larger than producing code. Organizations still need people who understand the whole project and are willing to take responsibility for how the pieces fit together.
Ready to explore where agentic engineering could fit in your organization? Contact Axian to start the conversation.