The economics of software development have fundamentally shifted. Things that were previously too expensive to build in-house may no longer be. While I don’t expect most large enterprises to abandon their typical posture of focusing on core strengths and outsourcing the rest, past decisions grounded in cost and risk deserve a fresh look. The calculus has changed, and organizations that don’t revisit those assumptions will overpay for commodity solutions and cede innovation to vendors when they could build, own, and control better solutions themselves.
So how do you actually translate this shift into shipped systems?
Start With the Right People
Not every developer will thrive in this new model. Some have always coded for the beauty of code itself rather than for the goal of producing working business systems. AI agents will displease those who love coding for its own sake, and empower those who love to ship real outcomes.
Find a handful of those people and experiment with them first. I don’t believe there’s a strong level of experience correlation here; what matters is mindset. Specifically, look for developers who:
Are curious and willing to learn. Working with AI agents is a new discipline. The people who will succeed are those who approach it with genuine curiosity and a willingness to experiment.
Are driven to ship business value, not just code. The agent handles much of the raw coding. What remains is the harder, more critical work of translating business problems into working systems.
Understand the business itself. People who grasp what the organization is trying to accomplish will be far more effective at steering agents toward the right outcome. This matters more than ever, because the bottleneck is no longer typing speed, it’s judgment.
Have used AI coding tools and can talk about what they’ve done. There’s simply no excuse for not having used a number of tools at this point. If you meet someone who hasn’t committed to that growth mindset and at least done personal work with it, start to ask a lot of questions.
Pick the Right Problems
Once you have one or more small teams, the challenge is finding the right kind of problem to experiment with. AI agents work best on greenfield projects, though they absolutely help with legacy systems too.
Regarding scope, the obvious answer is often the right one - you should start small with a single end-to-end feature. However, more importantly, you must start with something verifiable. AI agents shine when they can validate their own work. Focus on problems with clear, measurable results - a well-defined API, a calculation that can be checked, a workflow with observable outputs. Avoid anything ambiguous where success is subjective and hard to confirm.
Recognize Where the Pain Shifts
This is a point that catches many organizations off guard. The development itself is no longer the long pole. The pain moves upstream and downstream: to specification and to review.
Before an agent can build the right thing, someone needs to clearly articulate what the right thing is. This loops back to having developers with a solid handle on the business problem being solved. They should also have a strong understanding of architecture, organizational standards, and deployment constraints so that the agent doesn’t produce something technically impressive that can never actually ship.
On the other end, review becomes the critical bottleneck. AI agents can generate substantial volumes of working code, but someone still needs to verify that it does the right thing, in the right way, within the right guardrails. Plan for this. Build review capacity into your workflow from the start - and that doesn’t have to be manual.
To make this a bit more concrete: inside the product engineering team at AI One, we have shifted design reviews to the left: the story initiator writes the initial design document (AI-assisted), one or more other team members review it and provide feedback, and then we assign a single developer to take it forward from that point to production. During development, we use AI tooling (alongside heavily automated, high coverage end-to-end testing) to perform reviews across a number of different dimensions: correctness, functionality, and security. Then, once the developer has proven the story is in a state of readiness, they submit the PR for another team member to review. The team member then reviews the evidence and the high risk areas of the PR before approving it (or requesting changes). This sits around level 3 to level 4 of Dan Shapiro’s Five Levels of AI coding. As a SOC II compliant organization, we require at least some human oversight of the code so this approach fits well into a highly regulated context.
Invest in Infrastructure and Test Environments
This follows naturally from the review constraint. AI agents perform dramatically better when they can interact with real systems in controlled environments. If you’re building something that connects to a custom internal API, give the agent access to a live instance of that API in a sandbox. If this cannot be achieved, build as close a digital twin as you can. Then, let it validate that API calls actually did what it expected.
Agents are remarkably good at feeling their way around systems and figuring out how best to use them once given real access. Static documentation alone is a poor substitute.
A Practical Example: Building Integration Gateways
We recently needed to build gateways for both Google Workspace (authentication and access to Drive, Sheets, Calendars, and more) and Microsoft 365 (authentication, Teams, SharePoint, and related services). Rather than handing agents documentation and hoping for the best, we stood up full sandbox environments for them to work against.
We populated these environments with real data - files in SharePoint and Drive, channels in Teams, calendar entries - and gave the agents well-defined tasks: authenticate, retrieve a file from SharePoint, list items in a Drive folder, post to a Teams channel. The agents had full access to these sandbox environments, access to the internet for API documentation, and crucially, the ability to verify every step of their work against real system responses.
The result was high-quality integration gateways that were proven from the start to work correctly. They weren’t built in theory and then tested, they were built through testing, with the agent iterating against live systems until everything behaved as expected. We still reviewed the output for security, architectural fit, and edge cases, but the heavy lifting - the tedious, iterative work of getting OAuth flows, API pagination, error handling, and data mapping right - was all done by the agents.
This is the pattern that works: give agents real environments, clear objectives, and the ability to validate their own results. The quality of the output is dramatically higher than what you get from agents working blind against documentation alone.
Then, critically, ensure the agent builds out the tests necessary to enable quick and safe changes in the future. The first build is just the beginning - the test suite is what makes it sustainable.
Don’t Overthink Costs - Invest to Experiment
It’s surprisingly uncommon for developers to be given truly high-quality tools - whether that’s powerful laptops, top-tier IDEs, or $200/month subscriptions to AI agents. Use your small teams to experiment and build the business case - it’s a very small investment for a potentially massive return.
As a closing piece of advice, I’d also strongly encourage organizations not to be too restrictive about letting curious developers use their subscriptions at home for personal projects. Building a small side project, automating something in their own life, experimenting with a new framework - this is all part of learning to work effectively with the tools. That fluency will flow directly back into their professional output. Treat it as professional development, because that’s exactly what it is.