AI software development in financial services is changing the speed, shape, and operating model of software delivery. As Rich Theil, founder of Product Forge, explained on A Platform for Modern Finance, software creation has historically been a major bottleneck. AI is beginning to remove that bottleneck, which creates both opportunity and risk for regulated organizations.

The old delivery model was built around small user stories, handoffs, and waiting for engineering to return with working software weeks later. In an AI-assisted development environment, teams can work from richer specs, take larger steps, and move from idea to prototype much faster.

That does not mean financial services organizations automatically create business value faster. The bottleneck often shifts upstream to strategy, requirements, business context, approval processes, compliance checks, and the ability of leaders to communicate what good looks like.

Platform engineering becomes more important in this environment, not less. Internal developer platforms, golden paths, agent harnesses, observability, self-service environments, and compliance-by-default workflows help teams move faster while keeping control, security, and governance intact.

Watch the full episode of A Platform for Modern Finance‍

Listen to the full episode on Apple Podcasts or Spotify

Why does AI software development feel different now?

AI is not just making individual developers a little faster. It is changing the workflow around software creation.

Rich Theil described the shift plainly: speed is the game changer. For years, software creation was the bottleneck. A business or product team could define work, hand it to engineering, and wait three, six, or eight weeks before getting something back to react to. In Rich’s view, that model is breaking down because engineering teams can now take much larger steps with AI-assisted development.

Instead of breaking work into the smallest possible user stories, teams can provide a larger body of context and ask the model to help create something useful much faster. Rich described working from a 10-page spec and getting a feature out the other side in hours rather than weeks.

That speed changes the operating model. If software can be created faster, the organization around engineering has to become clearer, faster, and more disciplined too.

“The bottleneck no longer lives at engineering in the way that it did before.” — Rich Theil

‍

What happens when engineering is no longer the slowest part of delivery?

When engineering moves faster, the bottleneck does not disappear. It moves.

That was one of the most important themes in the episode. Justin Billig described the old “contract” between business and technology as being blown up. For years, executives had a rough understanding of how long it took to define requirements, build software, review work, and ship it. AI changes those assumptions.

But speed creates pressure on the business side too. Leaders now have to articulate what they want more clearly. Product teams have to translate customer needs into usable context faster. The one person in the business who “just knows everything” can quickly become the new constraint because that person cannot produce enough clarity for engineering teams moving at AI speed.

Joe Kerstanoff named the new bottlenecks directly: unclear requirements, unclear handoffs, approval processes, security reviews, and compliance checks. Those are not new problems, but AI makes them more visible because code is no longer always the slowest step.

“It’s not the code, it’s the communication and the handoffs.” — Joe Kerstanoff

For financial services and fintech organizations, this is the central challenge. Faster software creation only helps if the business, product, engineering, security, and compliance operating model can keep pace.

Are user stories dead in AI-assisted software development?

Rich offered one of the clearest hot takes of the episode: user stories are dead.

The point was not that every agile practice disappears overnight. The point was that the traditional user story was designed for a different constraint. User stories helped make work small enough that an engineer could hold the context, work on it for a few days, and hand it back.

AI-assisted development changes that constraint. Models can handle much more context than a human engineer would reasonably keep in working memory. That makes richer specs more valuable than tiny slices of work. Rich’s argument is that if you spend time writing a small user story for work an AI-assisted developer could complete almost immediately, you may be slowing the process down rather than helping it.

The new question is not just, “What is the smallest story we can hand to engineering?” The better question may be, “What context does the team and the model need to produce the right outcome safely?”

That context includes business goals, customer needs, product behavior, technical expectations, security requirements, compliance constraints, and environmental standards. In AI software development, the spec becomes more than a planning artifact. It becomes a source of truth for what the team is trying to build and why.

“User stories are dead.” — Rich Theil

‍

Why do richer specs matter more in the AI era?

AI models do what they are asked to do, but they also fill in gaps. That makes clear context more important, not less.

Rich explained that richer specs matter because they increase the likelihood that the team gets what it actually wants. The context is not only business context. It also includes the environment where the work will run, the development setup, the architectural standards, and the constraints that should shape the output.

Justin tied this back to financial services risk. If leaders hand off unclear direction, they may not lose months of engineering time in the same way they once did. But they can still create serious problems. A team can move quickly in the wrong direction, expose the organization to security issues, mishandle customer data, or miss regulatory requirements.

That is the uncomfortable reality of AI-assisted development in regulated industries. Fast output does not guarantee safe output. A model can help build software quickly, but regulators, auditors, customers, and executives still care whether the software is secure, compliant, reliable, and aligned to the business.

This is why specs and platforms matter together. Specs define what should be built and why. Platforms define the safe, repeatable ways that work should be built, tested, deployed, observed, and governed.

Why does faster coding not automatically create faster business value?

Faster development can create more value, but it can also create more waste.

Justin pushed on this point during the episode. If the work does not drive revenue, improve customer experience, reduce risk, improve speed to market, or support another meaningful business outcome, then simply building it faster does not make it valuable.

That distinction matters because AI can make it easier to build almost anything. But the ability to build does not answer whether the organization should build it. In fact, when the cost and time of building drop, the quality of decision-making becomes even more important.

Rich described a similar risk from the product side. As writing code gets easier, product managers and business leaders may become enamored with the technology itself. They may start building because they can, instead of staying focused on the customer problem, business objective, or market signal that should guide the work.

For financial services leaders, this is where governance has to become more outcome-oriented. The question cannot be, “Can AI help us build this faster?” The question has to be, “What business result are we trying to create, and how will we know whether this work helped?”

“If it’s not aligning to what we’re trying to accomplish, then was the work valuable?” — Justin Billig

‍

Where does platform engineering fit into AI software development?

Platform engineering becomes more important when AI makes development faster because the platform defines the guardrails around that speed.

Joe described this in terms of harnesses. In regulated industries, teams need to know who is making a request, what data they can access, what tools the model or agent is allowed to use, where deterministic behavior is required, and where it is acceptable for the model to operate with more flexibility.

That is not just a developer tooling problem. It is an operating model problem. As agentic AI moves beyond engineering teams into functions like legal, finance, operations, and analytics, organizations need reusable ways to govern access, evaluate outputs, monitor behavior, manage cost, and trace decisions.

Platform engineering teams are well positioned for that work because they have been solving related problems for years: standardizing delivery, creating self-service workflows, reducing manual approvals, embedding security checks, and helping teams move faster without bypassing governance.

In the AI era, those same patterns apply to agents, models, specs, environments, deployments, and data access. A strong internal developer platform gives teams a safe foundation. It does not eliminate autonomy. It makes autonomy safer.

‍

What should be in place before teams let AI agents move faster?

AI agents need more than enthusiasm. They need a harness.

Joe described several technical foundations that matter when faster development could otherwise create more operational risk, rework, or production issues. Teams need observability so they can see what is happening in the system. They need alerts and governance so issues can be identified and corrected. They need deterministic workflows where consistency is required, and they need feedback loops so the platform can improve over time.

One practical starting point Joe mentioned was building a small, thin slice around a pull request review workflow. That kind of MVP can touch key parts of the harness and platform without trying to solve every AI governance problem at once.

For financial services organizations, that is a useful lesson. The goal should not be to “roll out AI everywhere” as quickly as possible. The better approach is to start with a use case that is narrow enough to govern, meaningful enough to teach the organization, and connected enough to validate the platform foundation underneath it.

That is the same principle Tensure often applies to internal developer platforms: prove value through a focused MVP, measure what matters, and scale from there.

“Agent harnesses and agent gateways are conversations that we have essentially daily now.” — Joe Kerstanoff

‍

How does AI change the role of engineers?

AI does not make engineers less important. It changes what makes them valuable.

In the episode, Justin argued that the engineer of the future will need more understanding of the business, the customer, and the vertical context they are building for. Joe agreed, noting that AI can free developers to get closer to the business rather than simply receiving requirements and working in isolation.

Rich pushed this even further. Engineers make hundreds or thousands of small decisions during implementation. Those decisions are not just technical. They are shaped by assumptions about scalability, audience, customer experience, product behavior, and business goals.

If engineers do not understand the “why,” they will still make decisions. They will just make them with incomplete context, and AI will help them make those decisions faster.

That is why empowerment matters. Leaders have to give engineers enough context, vision, and guardrails to make good decisions without waiting for permission at every step. Platform engineering helps by removing low-value decisions from the engineer’s plate, such as how to provision standard environments or follow approved deployment paths, so engineers can focus more energy on solving the business problem.

“The engineer of the future is going to have so much understanding of the business and what the customer is doing.” — Justin Billig

“They will just make mistakes faster.” — Rich Theil

What does it mean to treat the platform as the product?

Joe’s closing principle was simple: platform is a product.

That matters because many organizations already have a platform whether they realize it or not. It may be a formal internal developer platform, or it may be an accidental collection of scripts, workflows, cloud accounts, CI/CD pipelines, approval processes, and tribal knowledge.

The difference is whether leaders manage it intentionally.

Justin framed this from the technology executive’s perspective. If you are a technology executive and you do not see the platform as the product you own, you may be missing the point. In an AI-driven delivery environment, the platform is what gives the business a safe and secure place to innovate.

Joe described it as the operating system that runs the business. That framing is useful because it makes the platform more than an engineering tool. It becomes the foundation that connects development speed, business objectives, risk management, compliance posture, and operational resilience.

For Tensure, this is the core of platform engineering in financial services. Internal developer platforms should reduce cognitive load, standardize delivery, embed security and compliance, and create adoption through workflows developers actually want to use.

“You have a platform whether you realize it or not. It just might not be good.” — Joe Kerstanoff

‍

Is AI creating a new version of shadow IT?

The group had an interesting exchange about whether AI is creating a new era of shadow IT.

Justin used the phrase “golden age of shadow IT,” but the conversation quickly sharpened the idea. This is not necessarily shadow IT in the old sense, where teams build risky, unapproved systems outside the view of technology leadership. If the right platform exists, business teams can build useful tools on top of approved APIs, guardrails, deployment patterns, and security standards.

That is closer to IT democratization than traditional shadow IT.

But the distinction depends on the platform. Giving people faster cars without roads creates chaos. Giving them well-designed roads, lanes, guardrails, traffic rules, and approved destinations creates controlled autonomy.

Justin used the road analogy well. A neighborhood road, state highway, and interstate all have different requirements. The CTO’s job is increasingly to build the roads so the organization can move faster without every team inventing its own route.

This is where culture and platform meet. The platform enables autonomy, but leaders still need to define what good looks like, what matters, what should be measured, and how teams should make decisions.

Why is AI transformation also a culture transformation?

Rich made a useful distinction: culture transformation by itself usually does not work. Technology transformation with culture transformation can work because it gives the organization a concrete reason to change.

Platform engineering can become that vehicle. When teams adopt a new platform, they also change how they work. They shift from tickets to self-service. They shift from bespoke workarounds to golden paths. They shift from command-and-control delivery to a model where engineers and teams have more autonomy inside approved guardrails.

Financial services organizations often have conservative cultures for good reasons. They are dealing with people’s money, regulated processes, sensitive data, and long-standing trust obligations. The answer is not to ignore those realities or pretend risk does not matter.

The answer is to create a delivery model where teams can learn and move faster without abandoning control.

That means technology leaders need to think about AI adoption as both a platform transformation and an operating model transformation. The tools matter, but the way teams define work, review work, approve work, and measure value matters just as much.

“What works is to do a technology transformation that has a culture transformation with it.” — Rich Theil

What should financial services leaders ask before telling teams to move faster with AI?

Before leaders tell teams to “move faster with AI,” they need to ask whether the organization is ready for the speed it is requesting.

Justin suggested a practical first question: does the organization clearly understand what good looks like? That includes business outcomes, customer pain, organizational direction, and how each team’s work connects to higher-level objectives.

That question matters because AI lowers the friction to create output. If teams do not understand the direction, they can generate more activity without creating more value.

Leaders should also ask whether the platform can support the behavior they want. Can teams self-serve environments safely? Are security and compliance checks embedded into the workflow? Are models and agents governed? Is observability in place? Are product and engineering teams working from clear specs? Are teams measuring adoption, risk, cost, and business impact?

Without those foundations, an AI mandate can create confusion. With those foundations, AI can become a multiplier for teams that already know where they are going.

Where should organizations start?

Rich’s closing advice for financial services and fintech leaders was not to wait until everything is figured out. The space is moving too quickly for a wait-and-see posture to be a safe strategy.

That does not mean moving recklessly. It means learning deliberately. Put your foot in the water. Understand how AI is changing engineering right now. Start with a focused use case. Build the platform foundations. Learn where the regulatory, compliance, and operating model constraints show up. Then use those lessons to decide how AI-assisted development should fit into the broader business.

For many organizations, a smart starting point is a narrow developer-facing use case that can validate the platform without creating uncontrolled exposure. Examples might include pull request review, environment provisioning, documentation generation, test generation, or internal developer workflow automation.

The exact use case matters less than the pattern: start small, build guardrails, measure outcomes, and scale what works.

“Waiting is going to be a very expensive proposition.” — Rich Theil

Final thought: speed needs a stronger foundation

AI software development in financial services is not just a faster version of the old delivery model. It changes where the constraints show up.

Engineering teams can move faster. Models can hold more context. Specs can become more powerful. Prototypes can appear in hours. But the organization still needs clear goals, secure workflows, compliance controls, business context, and an intentional platform foundation.

That is why platform engineering matters more as AI adoption grows. The platform gives teams the roads, guardrails, and operating model they need to move quickly without losing control.

For financial services and fintech organizations, the opportunity is significant. Teams can learn faster, ship faster, and respond to customer needs faster. But the organizations that benefit most will not be the ones that simply tell people to use AI. They will be the ones that pair AI-assisted development with clear business direction, strong developer platforms, and a culture of empowered, accountable engineering.

Watch the full episode of A Platform for Modern Finance with Rich Theil

FAQ

What is AI software development in financial services?

AI software development in financial services is the use of AI tools, models, and agents to help define, build, test, review, and ship software in banks, credit unions, fintechs, insurance firms, payment companies, and other regulated financial organizations. The goal is to increase delivery speed while maintaining security, compliance, reliability, and business alignment.

How is AI changing software delivery?

AI is changing software delivery by reducing the time it takes to move from idea to working software. Teams can now work from richer specs, generate code faster, prototype more quickly, and iterate sooner. This shifts the bottleneck from coding alone to business clarity, requirements, governance, and operating model design.

Are user stories still useful in AI-assisted development?

User stories may still be useful in some contexts, but the traditional model of breaking everything into very small stories is becoming less relevant for AI-assisted development. Richer specs with more complete business, technical, and environmental context are often more useful when AI tools can process larger bodies of information.

Why do richer specs matter for AI-assisted software development?

Richer specs matter because AI models need context to produce useful output. A good spec helps define the business goal, customer need, product behavior, technical constraints, security expectations, and compliance requirements. Without that context, teams may generate software quickly but still miss the real objective.

Why does faster development not always create business value?

Faster development does not automatically create business value because speed only matters when the work supports a meaningful outcome. Software should connect to goals such as revenue growth, better customer experience, risk reduction, lower operating cost, faster time to market, or improved internal productivity.

How does platform engineering support AI software development?

Platform engineering supports AI software development by creating reusable workflows, self-service environments, secure deployment patterns, observability, governance, and golden paths. These foundations help teams move faster while staying inside approved security, compliance, and operational standards.

What are AI agent harnesses?

AI agent harnesses are the technical and governance structures around AI agents. They can define what data an agent can access, what tools it can use, what workflows must be deterministic, how outputs are evaluated, how behavior is observed, and how teams trace or improve agent performance over time.

Why is platform as a product important in the AI era?

Platform as a product is important because the platform becomes the foundation for faster software delivery. Treating the platform as a product means investing in it intentionally, understanding its users, measuring adoption, improving the developer experience, and tying platform capabilities to business outcomes.

What risks do financial services firms face with AI-assisted development?

Financial services firms face risks including unclear requirements, insecure code, mishandled customer data, weak governance, compliance gaps, poor observability, shadow IT, duplicated work, and faster production of software that does not align to business goals. These risks can be reduced with strong platforms, guardrails, and operating models.

Where should financial services leaders start with AI-assisted software delivery?

Financial services leaders should start with a focused use case that teaches the organization how AI affects software delivery without creating uncontrolled risk. Good starting points include pull request review, developer workflow automation, test generation, documentation, environment provisioning, or other contained workflows that can validate the platform foundation.

‍