The New Engineering Problem: Managing What AI Decides to Import
7 minute read time
AI makes it faster to turn an idea into working software. A developer describes a feature, integration, or service and receives an implementation in minutes. Coding agents go further by editing files, running tests, troubleshooting failures, and preparing changes for review.
But generating code is only part of the work required to ship and maintain software. The code must also be understood, tested, secured, updated, and eventually retired. Every component it chooses becomes part of that responsibility.
That creates a less visible engineering problem. AI does not simply produce more code. It makes more decisions about the packages, versions, frameworks, APIs, models, services, and configurations that code relies on. Once granted access to a development environment, coding agents can act on those decisions, selecting and installing dependencies or modifying build files, without a developer reviewing each change first.
The result is not just more software but faster growth in the dependencies organizations must manage and less clarity about why many of them entered the environment.
The Bottleneck Moves Downstream
AI can reduce the time required to move from an idea to an initial implementation. But it does not eliminate the work that follows. It compounds it.
Every package an agent selects becomes something the organization must:
-
Evaluate for maintenance, compatibility, security, licensing, and internal policy.
-
Monitor as risks and project conditions change.
-
Update or replace when it no longer meets requirements.
Multiply that work across more applications, releases, and AI-generated changes, and the constraint shifts. Writing code becomes easier while understanding and maintaining the resulting software becomes harder.
A feature delivered quickly is not an enduring productivity gain if it leaves behind dependencies nobody can confidently manage.
Every Prompt Can Become a Dependency Decision
Consider a seemingly simple request: Build a service that accepts customer data, validates it, stores it, and sends a notification.
To fulfill that request, an AI assistant or agent might select:
-
A web framework, validation library, and database client.
-
Authentication, logging, messaging, and testing packages.
-
A container image, infrastructure configuration, or external service.
The developer asked for one capability, but the implementation may introduce dozens of direct and transitive dependencies. Those choices affect maintainability, compatibility, licensing, security, and the team’s ability to upgrade the application later.
AI models do not inherently have the current context required to make those decisions well. Training data cannot reliably reflect the live state of package registries, newly disclosed vulnerabilities, recent malware, project health, or internal policies.
The stakes rise when an agent can install its recommendation, modify the build, and continue working without human confirmation. A flawed suggestion is no longer just text in a chat window. It can become part of the application.
Agent-to-Agent Development Raises the Stakes
The problem expands when agents begin delegating work to other agents. A primary coding agent might ask a specialist agent to research an implementation, another to generate or refactor the code, and another to test or troubleshoot it.
Each delegated step can introduce its own tools, sources, assumptions, and package preferences. One agent may choose a library based on an online example. Another may add a testing utility. A third may modify deployment configuration to make the build pass. By the time a developer reviews the result, no single participant may have a complete view of how all the dependencies and configurations were selected.
Agent-to-agent development deserves deeper treatment of its own. As decision-making becomes more distributed, its record must become more durable.
From a Component Inventory to a Decision Record
As agentic development distributes more software decisions across agents, tools, and workflows, traditional component visibility becomes only part of the picture.
A software bill of materials (SBOM) can identify components, including dependencies a developer did not select directly. Repository controls can govern their sources, while software composition analysis (SCA) can reveal known vulnerabilities and licensing concerns.
But an inventory does not necessarily explain the decision that created it. When an agent introduces a component, engineering teams may also need to know:
-
Which agent or workflow selected it?
-
Which source and version information informed the choice?
-
What alternatives were considered?
-
Which organizational policy applied at the time?
-
Did a person approve the decision, or was it allowed automatically?
This context becomes part of an emerging agent supply chain of agents, instructions, tools, data sources, permissions, and inherited choices involved in producing software.
But, an agent is not a software dependency. It participates in a decision and execution chain that creates dependencies. Managing that chain requires visibility into both the resulting artifact and the process that assembled it.
Existing Review Processes Cannot Carry the Full Load
Code review remains important, but it was not designed to reconstruct every machine-made dependency decision. A reviewer may see that a package was added without knowing whether a safer version was available, whether the project is actively maintained, or why the agent chose it over an approved alternative.
SCA remains essential for identifying components and continuously monitoring open source risk throughout the SDLC. The limitation comes from applying those insights only after a dependency has been selected. By then, the component may already have shaped the implementation, and replacing it could require rework across code, tests, integrations, and configuration.
Developers should not be expected to manually investigate every decision at the same speed agents can produce them. The sustainable answer is to place reliable context and enforceable policies closer to the moment of selection.
Build Guardrails Into the Agentic Workflow
Responsible agentic development requires clear boundaries for what agents can decide independently and what should trigger review.
Organizations should establish several capabilities:
-
Current dependency intelligence: Agents need live information about available versions, vulnerabilities, malware, licensing, project quality, and safer alternatives.
-
Policy before execution: Approved sources, component standards, and risk thresholds should guide selection before a package is installed or code is built around it.
-
Agent identity and scoped permissions: Teams should be able to identify which agent performed an action and limit its access to the tools, repositories, credentials, and environments required for the task.
-
Decision provenance: Important choices should preserve who or what made them, the information used, and whether human approval was required.
-
Delegation limits: Workflows should define when agents may invoke other agents or external tools and when recursive delegation must stop for review.
-
Continuous monitoring: A component that was acceptable when selected may become vulnerable, malicious, abandoned, or inconsistent with policy later.
Controls must match potential impact. Low-risk suggestions differ from introducing production services, sharing data externally, or modifying permissions. Higher-risk, irreversible actions demand stronger justification and explicit sign-off.
Put Intelligence at the Moment of Choice
As agents take on more implementation and maintenance work, no single developer can own every dependency decision generated across autonomous workflows. The operating model demands shared responsibility: leadership determines autonomy limits, platform engineering creates paved paths and controls, security automates risk policies, and procurement and legal establish boundaries for third-party tools.
The shared objective is not to review more AI output manually but to make acceptable choices routine, questionable choices visible, and high-impact choices deliberate.
That requires treating agentic development as a production system with observable decisions, enforceable boundaries, and clear ownership. Rather than allowing each workflow to make dependency choices from model memory and repairing the consequences later, organizations can bring current software supply chain intelligence directly into the tools developers and agents use.
Speed without stewardship becomes debt. As agentic development scales, organizations need to be able to answer three increasingly important questions: Which agent introduced this dependency? Why is it here? And who is responsible for it now?
Learn how Sonatype Guide can help govern AI dependency decisions with up-to-date software intelligence at the moment of choice.
Aaron is a technical writer at Sonatype. He works at a crossroads of technical writing, developer advocacy, and information design. He aims to get developers and non-technical collaborators to work better together in solving problems and building software.
Explore All Posts by Aaron LinskensTags
Build Smarter with AI and ML.
Take control of your AI/ML usage with visibility, policy enforcement, and regulatory compliance.