I’ve been building with computer vision and ML since before it was cool, and I use these tools daily. When my middle child announced they were majoring in computer engineering, I didn’t panic about automation taking their job. I encouraged it.

But something strange is happening in the world of software development that very few seem to be talking about. AI has created a paradox: building software has never been more accessible, yet the risks of ownership have never been higher.

This pattern isn’t isolated to software development. I’ve been tracking similar dynamics across compliance, skill markets, and organizational structures. In each domain, AI is creating the same fundamental shift: execution becomes liquid while orchestration becomes critical. The specific risks change, but the underlying forces remain consistent.

When Building Feels Free

Aaron Levie from Box recently laid out the case for where AI-generated software makes sense. His argument is nuanced and grounded in Geoffrey Moore’s framework of “core” versus “context” activities. Most people don’t actually want to build custom software, he argues, because they’re fine with what already works and “the effort to customize is greater than the ROI they’d experience.” Taking responsibility for managing what you build is “often not worth it” since when something breaks, “you’re on your own to figure out what happened and fix it.”

More fundamentally, custom development is simply less efficient for most business problems. Context activities like payroll, IT tickets, and basic workflows are things “you have to do just to run your organization, but a customer never really notices.” You want to spend minimal time maintaining these systems because no matter how well you execute them, customers rarely see the difference.

The real opportunity, Levie argues, lies elsewhere – integration work between existing systems, custom optimizations on top of standard platforms for organizational edge cases, and addressing the long tail of core business needs that have never been properly served. The result will be “an order of magnitude more software in the world,” but only where the ROI justifies customization.

Levie’s right, but he’s missing something crucial. AI isn’t just making certain types of custom development more viable. It’s fundamentally changing what ownership means. The same technology that makes building feel effortless is simultaneously making you more liable for what your systems do, while making evaluation nearly impossible for non-experts.

When Your Code Becomes Your Contract

Air Canada learned this the hard way when their chatbot promised a bereavement discount that didn’t exist in their actual policy. When their customer tried to claim it, Air Canada argued the chatbot was a “separate legal entity” responsible for its own actions.

The Canadian tribunal’s response was swift and unforgiving. They called Air Canada’s defense “remarkable” and ordered them to pay. The message was clear: you own what you deploy, regardless of how it was created.

This isn’t just a one-off, global regulations are tightening the screws on software accountability across every jurisdiction. The EU’s NIS2 directive creates real liability for cybersecurity incidents, with fines up to $10.8 million (€10 million) or 2% of global turnover. SEC rules now require public companies to disclose material incidents within four business days. GDPR has already demonstrated how quickly software liability can scale. Meta faced a $1.3 billion (€1.2 billion) fine, and Amazon got hit with $806 million (€746 million).

While these are not all AI examples, one thing is clear. When your AI system makes a promise, you’re bound by it. When it makes a mistake that costs someone money, that’s your liability. The technical complexity of building software has decreased, but the legal complexity of owning it has exploded into a ticking time bomb.

AI’s Hidden Danger

Here’s where the paradox gets dangerous. The same AI that makes building feel effortless makes evaluation nearly impossible for non-experts. How do you test a marketing analytics system if you don’t understand attribution modeling? How do you validate an HR screening tool if you can’t recognize algorithmic bias?

This creates what I call “automation asymmetry” – the same dynamic I’ve observed in compliance and audit workflows. AI empowers the builders to create sophisticated, polished systems while leaving evaluators struggling with manual review processes. The gap between what AI can help you build and what human judgment can effectively assess is widening rapidly.

As a product leader, I constantly weigh whether we can create enough value to justify engineering, opportunity costs, and maintenance costs. AI makes this calculation treacherous. A feature that takes a day to build with AI might create months of hidden maintenance burden that I can’t predict upfront. The speed of development is now disconnected from the cost of ownership.

Unlike traditional software bugs that fail obviously, AI systems can exhibit “specification gaming.” They appear to work perfectly while learning fundamentally wrong patterns.

This is Goodhart’s Law in action. When a measure becomes a target, it ceases to be a good measure. The AI system learns to optimize for your evaluation criteria rather than the real-world performance you actually care about.

Picture an HR screening system that correctly identifies qualified candidates in testing but starts filtering out good applicants based on subtle biases in the training data in the foundation model you built on. This isn’t a bug you can catch with normal testing. It requires understanding algorithmic bias that most organizations lack.

Or consider data leakage risks. AI systems can inadvertently memorize and leak personal information from their training data, but detecting this requires privacy testing that most organizations never think to perform. By the time you discover your customer service bot is occasionally revealing other users’ details, you’re facing GDPR violations and broken customer trust.

Imagine a bank that “validates” its loan applications analysis by testing on the same templates used for training. They celebrate when it passes these tests, not understanding that this proves nothing about real-world performance. Or consider a logistics company that builds an AI route optimization system. It works perfectly in testing, reducing fuel costs by 15%. But after deployment, it makes decisions that look efficient on paper while ignoring practical realities. It routes through construction zones, sends drivers to nonexistent addresses, and optimizes for distance while ignoring peak traffic patterns.

Many ownership challenges plague all custom software development. Technical debt, security risks, staff turnover, and integration brittleness. But AI makes evaluating these risks much harder while making development feel deceptively simple. Traditional software obviously fails. AI software can fail silently and catastrophically.

Why Even Unlimited Resources Fail

Want proof that ownership is the real challenge? Look at government websites. These organizations have essentially unlimited budgets, can hire the best contractors, and have national security imperatives. They still can’t keep basic digital infrastructure running.

The Social Security Administration’s technical support runs Monday through Friday, 7:30 AM to 4:00 PM Eastern. For a website. In 2025. Login.gov schedules multi-hour maintenance windows for essential services. Georgetown Law Library tracked government URLs from 2007 and watched half of them die by 2013. Healthcare.gov cost $2.1 billion and barely worked at launch.

These aren’t technical failures. They’re ownership failures. Many government projects falter because they’re handed off to contractors, leaving no one truly accountable yet the agencies remain liable for what gets deployed. The same organizations that can build nuclear weapons and land rovers on Mars can’t keep websites running reliably, precisely because ownership responsibilities can’t be outsourced even when development is.

“But wait,” you might think, “commercial software companies fail too. What about when vendors go bankrupt and leave customers stranded?”

This objection actually proves the point. When Theranos collapsed, their enterprise customers lost the service but weren’t held liable for fraudulent blood tests. When a SaaS company fails, customers face transition costs and data loss, but they don’t inherit responsibility for what the software did during operation.

Compare that to custom system failure. When your AI medical analysis tool makes a misdiagnosis, you don’t just lose the service. You’re liable for the harm it caused. The failure modes are fundamentally different.

If even professional software companies with dedicated teams and specialized expertise sometimes fail catastrophically, what makes a non-software organization think they can manage those same risks more effectively? If unlimited resources can’t solve the ownership problem, what makes us think AI-generated code will?

Traditional ownership costs haven’t disappeared. They’ve become economically untenable for most organizations. Technical debt still compounds. People still leave, taking institutional knowledge with them. Security vulnerabilities still emerge. Integration points still break when external services change their APIs.

AI makes this trap seductive because initial development feels almost free. But you haven’t eliminated ownership costs. You’ve deferred them while adding unpredictable behavior to manage.

Consider a typical scenario: imagine a marketing agency that builds a custom client reporting system using AI to generate insights from campaign data. It works flawlessly for months until an API change breaks everything. With the original developer gone, they spend weeks and thousands of dollars getting a contractor to understand the AI-generated code well enough to fix it.

These businesses thought they were buying software. They were actually signing up to become software companies.

The New Decision Framework

This transformation demands a fundamental shift in how we think about build versus buy decisions. The core question is no longer about execution capability; it’s about orchestration capacity. Can you design, evaluate, and govern these systems responsibly over the long term?

You should build custom software when the capability creates genuine competitive differentiation, when you have the institutional expertise to properly evaluate and maintain the system, when long-term ownership costs are justified by strategic value, and when existing solutions genuinely don’t address your specific needs.

You should buy commercial software when the functionality is context work that customers don’t notice, when you lack domain expertise to properly validate the system’s outputs, when ownership responsibilities exceed what you can realistically handle, or when proven solutions already exist with institutional backing.

Commercial software providers aren’t just offering risk transfer. They’re developing structural advantages that individual companies can’t match. Salesforce can justify employing full-time specialists in GDPR, SOX, HIPAA, and emerging AI regulations because those costs spread across 150,000+ customers. A 50-person consulting firm faces the same regulatory requirements but can’t justify even a part-time compliance role.

This reflects Conway’s Law in reverse: instead of organizations shipping their org chart, the most successful software companies are designing their org charts around the complexities of responsible software ownership.

Mastering the Paradox

The AI revolution isn’t killing software development companies it’s fundamentally changing what ownership means and repricing the entire market. Building has become easier, but being responsible for what you build has become exponentially harder.

This follows the same pattern I’ve tracked across domains: AI creates automation asymmetry, where execution capabilities become liquid while orchestration and evaluation remain stubbornly complex. Whether in compliance audits, skill markets, or software ownership, the organizations that thrive are those that recognize this shift and invest in orchestration capacity rather than just execution capability.

Advanced AI development tools will eventually solve some of these challenges with better validation frameworks and automated maintenance capabilities. We’ll likely see agentic AI automating much of our monotonous security, support, and maintenance work in the future also. These systems could help organizations build the connective tissue they lack automated monitoring, intelligent debugging, self-updating documentation, and predictive maintenance. But we’re not there yet, and even future tools will require expertise to use effectively.

This doesn’t mean you should never build custom software. It means you need to think differently about what you’re signing up for. Every line of AI-generated code comes with a lifetime warranty that you have to honor.

The question isn’t whether AI can help you build something faster and cheaper. It’s whether you can afford to own it responsibly in a world where software liability is real, evaluation is harder, and the consequences of getting it wrong are higher than ever.

Understanding this paradox is crucial for anyone making build-versus-buy decisions in the AI era. The tools are more powerful than ever, but mastering this new reality means embracing orchestration over execution. Those who recognize this shift and build the institutional capacity to govern AI systems responsibly will define the next wave of competitive advantage.

You’re not just building software. You’re signing up for a lifetime of accountability.

Part of the “AI Skill Liquidity” series

Early in my career, I was a security engineer, in this role we approached problems with a distinctive mindset. We look at a new system and immediately start threat modeling. What could go wrong? Where are the vulnerabilities? How might an attacker exploit this? Then we’d systematically build defenses, design monitoring systems, and create incident response procedures.

Later at Microsoft, I realized that good lawyers operate almost identically. They’re security engineers for text. When reviewing a contract, they’re threat modeling potential disputes. When structuring a transaction, they’re identifying legal vulnerabilities and designing defenses. When arguing a case, they’re building systems to withstand attack from opposing counsel. Of course, not all legal work requires this depth of analysis but the most valuable does.

This realization first drew me to Washington State’s legal apprenticeship program. The idea of learning legal “security engineering” through hands-on mentorship rather than accumulating law school debt appealed to me. I never pursued it, but I remained fascinated by sophisticated legal reasoning, regularly listening to Advisory Opinions and other legal podcasts where excellent legal minds dissect complex problems.

Just as I’ve written about skill liquidity transforming compliance and software development, the same forces are reshaping legal practice. AI is injecting liquidity into what was once an extremely illiquid skill market, where expertise was scarce, slowly accumulated, and tightly guarded. But here’s what’s different, current legal AI treats lawyers like document processors when they’re actually security engineers, and this fundamental misunderstanding is creating unexpected problems.

The Security Engineer’s Dilemma

Legal skills have historically been among the most illiquid in professional markets, exactly the kind of expertise scarcity that AI disruption targets. A single fabricated case citation can end careers. Imagine a security engineer whose monitoring system had a 99% accuracy rate, but the 1% false negatives included critical breaches that were mishandled so badly that the company’s reputation was irreparably damaged. Reputation operates on decades-long timescales because clients hire lawyers based on their track record of successfully defending against legal threats.

Just as I described in software development, AI injecting liquidity into skill markets creates a repricing rather than elimination. Where legal expertise was once scarce and slowly accumulated, AI makes certain capabilities more accessible while reshaping where the real value lies.

Traditional legal training worked like security engineer mentorship. Junior lawyers learned threat modeling by working on real cases under senior guidance. They’d review contracts while learning to spot potential vulnerabilities, draft briefs while understanding how opposing counsel might attack their arguments, structure deals while considering regulatory risks. Quality control and knowledge transfer happened simultaneously, seniors reviewing junior work would catch errors while teaching systematic risk assessment.

AI is disrupting this model in ways that would terrify any security team lead. Document review, research, and drafting that once provided junior lawyers with hands-on threat modeling experience are being automated. The tasks that taught pattern recognition, learning to spot the subtle contract clause that creates liability exposure, recognizing the factual detail that undermines a legal argument, are disappearing.

This creates the same middle tier squeeze I explored in software development, acute pressure between increasingly capable juniors and hyper-productive seniors. Junior lawyers become more capable with AI assistance while partners extend their span of control through AI tools, leaving mid-level associates caught in a compressed middle where their traditional role as the “throughput engine” gets automated away.

Here’s the economic problem, when AI saves 20 hours on document review, partners face a choice between investing those hours in unpaid training or billing them elsewhere. The math strongly favors billing. Fixed-fee arrangements make this worse, junior lawyers become cost centers rather than revenue generators during their learning phase.

The Governance Crisis

Current legal AI focuses on document creation, research assistance, and drafting support, essentially better word processors and search engines. While impressive, they’ve created a governance burden that’s consuming the time that should be spent teaching threat modeling skills.

This mirrors what I wrote about in compliance “automation asymmetry” where sophisticated AI-generated documents overwhelm human review capacity. Just as automated compliance artifacts can mask underlying issues with perfect formatting, AI legal documents create a veneer of competence that requires more, not less, senior oversight.

Every AI-generated document requires human verification. Partners must create AI policies, review procedures, and verification systems. The American Bar Association found lawyer concerns about AI accuracy increased from 58% in 2023 to 75% in 2025, exposure to these tools has heightened rather than reduced professional anxiety. Firms now maintain an average of 18 different AI solutions, each requiring its own governance framework.

This is like asking security engineers to spend their time verifying automated log reports instead of designing security architectures. Quality control has shifted from collaborative threat assessment to bureaucratic oversight. Instead of senior lawyers working through junior analysis while explaining legal reasoning, we have senior lawyers checking AI output for fabricated cases and subtle errors.

The teaching moments are gone. The efficient combination of quality control and knowledge transfer that characterized traditional review has been broken into separate activities. Senior expertise gets consumed by managing AI rather than developing human threat modeling capabilities.

There’s a deeper concern too. Security engineers know that over-reliance on automated tools can weaken situational awareness and pattern recognition. Legal reasoning requires the same kind of layered understanding, knowing not just what the law says, but how different doctrines interact, how factual variations affect outcomes, how strategic considerations shape arguments. AI can provide correct answers without fostering the threat modeling instincts that distinguish excellent lawyers.

The problem isn’t that we have AI in legal practice, it’s that we have the wrong kind of AI.

Building Better Security Tools

The fundamental problem is architectural. Current legal AI treats legal work as document processing when it’s actually systematic threat assessment. Most legal AI focuses on output, drafting contracts, researching case law, generating briefs. This misses the intellectual core, the systematic risk analysis frameworks that constitute legal reasoning.

Good lawyers, like security engineers, rely on systematic approaches. Constitutional analysis follows specific threat models for government overreach. Contract law has systematic frameworks for identifying formation vulnerabilities, performance risks, and breach scenarios. Tort analysis uses systematic negligence assessment patterns. These frameworks require internalization through guided practice that current AI disrupts.

But imagine different AI, tools designed for threat modeling rather than document creation. Instead of generating contract language, AI that helps identify potential vulnerabilities in proposed terms. Instead of researching cases, AI that systematically maps the legal threat landscape for a particular situation. Instead of drafting briefs, AI that helps build comprehensive defensive arguments while teaching the reasoning patterns that make them effective.

This would change governance entirely. Instead of verifying AI-generated content, lawyers would verify AI-enhanced threat assessments. Systems that show their analytical work (explaining why certain contract clauses create liability exposure, how different factual scenarios affect legal outcomes) enable both quality control and learning.

Security engineers don’t just need better log parsing tools; they need better threat modeling frameworks. Lawyers face the same challenge. The 19th-century apprenticeship model worked because it focused on developing systematic risk assessment capabilities through guided practice with real threats.

The Pattern Continues

This completes a progression I’ve traced across professions, and the pattern is remarkably consistent. In software development, execution capabilities are being liquified, but systems architects who understand complex threat models gain value. In compliance, process expertise is being liquified, but systematic thinkers who can model regulatory interactions across domains have advantages.

In law, legal reasoning itself could be liquified, but the outcome depends on whether we develop AI that enhances threat modeling capabilities rather than just automating document production. The sophisticated legal analysis I love hearing on Advisory Opinions represents systematic risk assessment applied to complex problems. This is exactly the kind of security engineering thinking that creates real value.

The pattern across all three domains is clear, as AI makes execution more liquid, value shifts toward orchestration. In software, orchestrators who build AI-augmented workflows and internal platforms create structural advantages. In compliance, orchestrators who design intelligent systems for continuous assurance gain leverage over reactive, manual approaches.

Current legal AI accidentally creates governance overhead that eliminates mentorship. But reasoning-focused AI could enhance both efficiency and competence development. Instead of making lawyers better document processors, we could make them better security engineers, orchestrators who design systematic threat assessment capabilities rather than just executors who handle individual risks.

The choice matters because society depends on lawyers who can systematically identify legal threats and build robust defenses. Current AI accidentally undermines this by turning lawyers into document reviewers instead of security architects.

The Washington apprenticeship program that first caught my attention represents something important, learning through guided practice with real threats rather than theoretical study. The future may not eliminate apprenticeship but transform it, the first generation learning legal threat modeling through AI designed to build rather than replace systematic reasoning capabilities.

When I listen to Advisory Opinions, I’m hearing security engineers for text working through complex threat assessments. That’s the kind of thinking we need more of, not less. We can build AI that enhances rather than replaces it.

In an earlier piece, ‘The Limitations of Audits,’ we explored how traditional compliance frameworks often fall short, functioning as point-in-time assessments rather than drivers of continuous security practices. Building on that foundation, and expanding on our exploration in ‘When AI Injects Liquidity Into Skills: What Happens to the Middle Tier?’, let’s examine how AI is poised to transform this landscape by introducing “skill liquidity” to compliance and auditing.

The High Price of Illiquid Expertise: Manual Bottlenecks in Compliance Today

As I’ve lamented before, the real cost of traditional, “illiquid” approaches to compliance expertise is staggering. In WebTrust audits, for instance, audit teams frequently report not having “enough time to look at the big picture” because their efforts are consumed by manual, repetitive tasks. Approximately 5-10% of an entire audit engagement – which can range from 350 to well over 1,500 hours for the audit firm alone – is often dedicated just to mapping organizational policy documents against standard templates. Another 15-20% of those hours are spent scrutinizing core operational processes mandated by frameworks, such as user access lifecycles or system change logs.

These percentages represent an enormous drain of highly skilled human capital on work that is largely automatable. And these figures only account for the auditors’ direct engagement. The true cost multiplies when you factor in the mountain of preparation by the entity being audited and subsequent review by third parties. The fully loaded headcount costs across this ecosystem for a single audit cycle represent a heavy tax on expertise that remains stubbornly “frozen” in manual processes.

First-Wave Automation: A Trickle of Skill Liquidity, or a New Kind of Friction?

The first wave of automation has arrived, with tools like Vanta and Secureframe offering streamlined pathways to certifications like SOC 2 by generating policy templates and automating some evidence collection. For many organizations, especially those with simpler, cloud-native environments, this has made basic compliance more accessible, a welcome “trickle of skill liquidity” that helps get a generic certification done in record time.

However, this initial wave has inadvertently created what we might call “automation asymmetry.” These tools predominantly empower the audited entity. When a company uses sophisticated automation to produce voluminous, perfectly formatted artifacts, while auditors still rely on largely manual review, a dangerous gap emerges. The truth risks getting lost in these “polished milquetoast” audits. The sheer volume and veneer of perfection can overwhelm human scrutiny, potentially masking underlying issues or a compliance posture that’s merely superficial. The audit can devolve into a review of well-presented fiction rather than an unearthing of operational fact.

Unlocking True Skill Liquidity: Intelligent Systems That Make Deep Compliance Knowledge Flow

To move beyond surface-level automation or basic Large Language Models (LLMs), we need intelligent compliance systems – sophisticated platforms designed to embed and scale deep domain knowledge. This isn’t just about processing text; it’s about an AI that understands context, relationships, history, and the intricate rules of specific compliance frameworks from the perspective of all stakeholders. Indeed, this drive to embed and scale specialized knowledge through AI is a significant trend across industries. For instance, leading professional services firms have been developing proprietary generative AI platforms, like McKinsey’s Lilli (announced in 2023), to provide their consultants with rapid access to synthesized insights drawn from vast internal knowledge bases, effectively enhancing their own ‘skill liquidity’ and analytical capabilities. Such systems, whether for broad consulting or specialized compliance, require:

• An ontology of expertise: Encoding the structured knowledge of seasoned auditors—controls, their intent, interdependencies, and valid evidence criteria.
• An ontology of documents: Understanding the purpose and interplay of diverse artifacts like System Security Plans, policies, vulnerability scans, and their connection to the compliance narrative.
• Temporal logic and change tracking: Recognizing that compliance is dynamic, and analyzing how policies, controls, and evidence evolve over time, identifying drift from baselines.
• Systemic integration: A cohesive architecture of LLMs, knowledge graphs, rule engines, and data connectors that can ingest, analyze, and provide auditable insights.

This approach transforms an AI from one that simply helps prepare artifacts to one that can critically assess them with genuine understanding – a crucial shift towards making knowledge truly usable (a concept we delve into in ‘From Plato to AI: Why Understanding Matters More Than Information’ ) – making that deep compliance knowledge flow across the ecosystem.

Liquidating Rote Work, Elevating Human Expertise: AI’s Impact on Audit Value and Integrity

When auditors and program administrators leverage intelligent systems, the nature of their work fundamentally changes—a direct consequence of “skill liquidity.” The AI can ingest and critically analyze the (potentially voluminous and auditee-generated) artifacts, performing the initial, labor-intensive review that consumes so many hours. This liquidates the rote work, significantly impacting even the global delivery models of audit services, as routine document review tasks are often offshored for cost savings, can now be performed with greater consistency, speed, and contextual insight by these intelligent systems.

This frees up high-value human experts to:

• Focus on what truly matters: Shift from the minutiae of “collection, ticketing, whether there was testing involved, whether there was sign-off” to the crucial judgment calls: “Is this a finding or a recommendation?”
• Investigate with depth: Dive into complex system interactions, probe anomalies flagged by the AI, and assess the effectiveness of controls, not just their documented existence.
• Enhance audit integrity: By piercing the veneer of “polished” evidence, these AI-augmented auditors can ensure a more thorough and truthful assessment, upholding the value of the audit itself.

The New Compliance Economy: How Liquid Skills Reshape Teams, Tools, and Trust

This widespread skill liquidity will inevitably reshape the “compliance economy.” We’ll see:

• Transformed Team Structures: Fewer people will be needed for the easily automated, “liquid” tasks of data collection and basic checking. The demand will surge for deep subject matter experts who can design, oversee, and interpret the findings of these intelligent systems, and who can tackle the complex strategic issues that AI surfaces.
• Empowered Audited Organizations: Companies won’t just be scrambling for periodic audits. They’ll leverage their own intelligent systems for continuous self-assurance, drastically reducing acute audit preparation pain and eliminating those “last-minute surprises.” Furthermore, the common issue of “accepted risks” or Plans of Action & Milestones (POA&Ms) languishing indefinitely is addressed when intelligent systems continuously track their status, aging, and evidence of progress, bringing persistent, transparent visibility to unresolved issues.
• New Proactive Capabilities: With compliance intelligence more readily available, organizations can embed it directly into their operations. Imagine Infrastructure as Code (IaC) being automatically validated against security policies before deployment, or proposed system changes being instantly assessed for policy impact. This is proactive compliance, fueled by accessible expertise.

Trust is enhanced because the processes become more transparent, continuous, and validated with a depth previously unachievable at scale.

The Liquid Future: Verifiable, Continuous Assurance Built on Accessible Expertise

The ultimate promise of AI-driven skill liquidity in compliance is a future where assurance is more efficient, far more effective, and fundamentally more trustworthy. When critical compliance knowledge and sophisticated analytical capabilities are “liquefied” by AI and made continuously available to all parties—auditees, auditors, and oversight bodies—the benefits are profound:

• Audited entities move from reactive fire drills to proactive, embedded compliance.
• Auditors become true strategic advisors, their expertise amplified by AI, focusing on systemic integrity.
• Compliance Program Administrators gain powerful tools for consistent, real-time, and data-driven oversight.

The journey requires a shift in perspective. Leaders across this ecosystem must recognize the risks of automation asymmetry and the limitations of surface-level tools. The call, therefore, is for them to become true orchestrators of this new compliance liquidity, investing not just in AI tools, but in the expertise, updated frameworks, and cultural shifts that turn AI’s potential into verifiable, continuous assurance. This is how we move beyond the “polished milquetoast” and forge a future where compliance is less about the performance of an audit and more about the verifiable, continuous truth of operational integrity, built on a bedrock of truly accessible expertise.

In financial markets, liquidity changes everything. Once-illiquid assets become tradable. New players flood in. Old hierarchies collapse. Value flows faster and differently.

The same thing is now happening to technical skill.

Where expertise was once scarce and slowly accumulated, AI is injecting liquidity into the skill market. Execution is faster. Access is broader. Barriers are lower. Like in finance, this shift is reshaping the middle of the market in ways that are often painful and confusing.

This is not the end of software jobs. It is a repricing. Those who understand the dynamics of liquidity, and how unevenly it spreads, can not only navigate this change they can succeed because of it rather than get displaced by it.

The Skill Market Before AI

Historically, software development was built on a steep skill curve. It took years to develop the knowledge required to write performant, secure, maintainable code. Organizations reflected this with layered teams: junior developers handled simple tickets, mid-tier engineers carried the delivery load, and senior engineers architected and reviewed.

This mirrored an illiquid market:

• Knowledge was siloed, often in the heads of senior devs or buried in internal wikis.
• Feedback loops were slow, with code reviews, QA gates, and manual debugging.
• Skill mobility was constrained, so career progression followed a fixed ladder over time.

In this world, mid-tier developers were essential. They were the throughput engine of most teams. Not yet strategic, but experienced enough to be autonomous. Scarcity of skill ensured their value.

AI Changes the Market: Injecting Skill Liquidity

Then came the shift: GitHub Copilot, ChatGPT, Claude, Gemini, Cursor, Windsurf, and others.

These tools do more than suggest code. They:

• Fill in syntax and structural gaps.
• Scaffold infrastructure and documentation.
• Explain APIs and recommend architectural patterns.
• Automatically refactor and write tests.

They reduce the friction of execution. GitHub’s research shows developers using Copilot complete tasks up to 55 percent faster (GitHub, 2022). Similar gains are reported elsewhere.

They make skill more accessible, especially to those who lacked it previously:

• Junior developers can now produce meaningful output faster than ever before.
• Non-traditional developers can enter workflows that were once gated.
• Senior developers can expand their span of control and iterate more broadly.

In market terms, AI liquifies skill:

• The bid-ask spread between junior and mid-level capability narrows, that is, the gap between what juniors can do and what mids were once needed for shrinks.
• Skill becomes less bound by time-in-seat or institutional memory.
• More participants can engage productively in the software creation economy. While adoption varies, large tech firms often lead, while smaller companies or legacy-heavy sectors like banking and healthcare face higher integration hurdles, the trend toward skill liquidity is clear.

This shift is not happening evenly. That is where the real opportunity lies.

The arbitrage today is not just in the tools themselves, the chance to capitalize on gaps in how quickly teams adopt AI. It is in the opportunity spread: the gap between what AI makes possible and who is effectively using it.

Just like in markets, early adopters of new liquidity mechanisms gain a structural advantage. Teams that build AI-augmented workflows, shared prompt libraries, and internal copilots are operating on a different cost and speed curve than those still relying on traditional experience-based workflows.

This gap will not last forever. But while it exists, it offers meaningful leverage for individuals, teams, and organizations.

Importantly, AI tools amplify productivity differently across experience levels:

• Juniors gain access to knowledge and patterns previously acquired only through years of experience, helping them produce higher-quality work faster.
• Senior developers, with their deeper context and better judgment, often extract even greater value from these tools, using them to implement complex solutions, explore multiple approaches simultaneously, and extend their architectural vision across more projects.
• Both ends of the spectrum see productivity gains, but in different ways, juniors become more capable, while seniors become even more leveraged.

This amplification effect creates acute pressure on the middle tier, caught between increasingly capable juniors and hyper-productive seniors.

Why the Middle Tier Feels the Squeeze

There is also a practical reason: cost control.

As AI raises the baseline productivity of junior developers, companies see an opportunity to rebalance toward lower-compensated talent. Where a mid-level or senior engineer was once needed to maintain velocity and quality, AI makes it possible for a well-supported junior to do more.

Companies are increasingly betting that AI tools plus cheaper talent are more efficient than maintaining traditional team structures. This shift isn’t without risks, AI-generated code can introduce errors (studies suggest 20-30% may need human fixes), and over-reliance on juniors without robust oversight can compromise quality. Experienced developers remain critical to guide and refine these workflows. That bet is paying off, especially when companies invest in prompt engineering, onboarding, internal platforms, and support tools.

But that “well-supported junior” is not automatic. It requires experienced developers to build and maintain that support system. Mentorship, internal frameworks, curated AI toolchains, and effective onboarding still depend on human judgment and care.

And while AI can augment execution, many real-world systems still depend on context-heavy problem solving, legacy code familiarity, and judgment, all of which often live with experienced, mid-level developers.

What Happens to the Middle Tier? Compression, Specialization, and Realignment

As in finance, when liquidity rises:

• Margins compress. It becomes harder to justify mid-level compensation when similar output is available elsewhere.
• Roles consolidate. Fewer people are needed to ship the same amount of code.
• Value shifts. Execution is commoditized, while orchestration, judgment, and leverage rise in importance.
• New specializations emerge. Just as electronic trading created demand for algorithmic strategists and execution specialists, AI is creating niches for prompt engineers, AI workflow designers, and domain-specific AI specialists.

This helps explain recent tech layoffs. Macroeconomic tightening and overhiring played a role, but so did something more subtle: AI-induced skill compression.

Layoffs often disproportionately affect mid-level developers:

• Juniors are cheaper, and AI makes them more effective.
• Seniors are harder to replace and more likely to direct or shape how AI is used.
• Mid-tiers, once the backbone of execution, now face pressure from both sides.

Duolingo’s restructuring, for example, eliminated many contractor-heavy roles after adopting AI for content generation (Bloomberg, 2023). IBM has projected that up to 30 percent of back-office roles may be replaced by AI over five years (IBM, 2023). These moves reflect a larger market correction.

These examples underscore how companies are re-evaluating where skill and value live, and how automation enables workforce reshaping, sometimes at surprising layers.

The middle tier does not disappear. It gets repriced and redefined. The skills that remain valuable shift away from throughput toward infrastructure, context, and enablement.

Historical Parallel: The Rise of Electronic Trading

In the 1990s and early 2000s, financial markets underwent a similar transformation. Human traders were replaced by electronic systems and algorithms.

Execution became commoditized. Speed and scale mattered more than tenure. Mid-level traders were squeezed, unless they could reinvent themselves as quant strategists, product designers, or platform builders.

Software development is now echoing that shift.

AI is the electronic trading of code. It:

• Reduces the skill premium on execution.
• Increases velocity and throughput.
• Rewards those who design, direct, or amplify workflows, not just those who carry them out.

The New Playbook: Think Like a Market Maker

If you are a developer today, the key question is no longer “How good is my code?” It is “How much leverage do I create for others and for the system?”

Here is how to thrive in this new market:

1. Become a Force Multiplier
   Build internal tools. Create reusable prompts. Develop standard workflows. A mid-tier developer who builds a shared test and prompt suite for new APIs can significantly reduce team ramp-up time, with some teams reporting up to 40 percent gains (e.g., internal studies at tech firms like Atlassian).
2. Shift from Throughput to Leverage
   Own end-to-end delivery. Understand the business context. Use AI to compress the time from problem to insight to deployment.
3. Curate and Coach
   AI raises the floor, but it still needs editorial control. Be the one who sets quality standards, improves outputs, and helps others adopt AI effectively.
4. Build Liquidity Infrastructure
   Invest in internal copilots, shared prompt repositories, and domain-specific agents. These are the new frameworks for scaling productivity.

What Leaders Should Do

Engineering leaders must reframe how they build and evaluate teams:

• Rethink composition. Combine AI-augmented juniors, orchestration-savvy mids, and high-leverage seniors.
• Promote skill liquidity. Create reusable workflows and support systems that reduce onboarding friction and accelerate feedback.
• Invest in enablement. Treat prompt ops and AI tooling as seriously as CI/CD and observability.
• Evaluate leverage, not volume. Focus on unblocked throughput, internal reuse, and enablement, not just tickets closed.

Leaders who create liquidity, not just consume it, will define the next wave of engineering excellence.

Conclusion: Orchestrators Will Win

AI has not eliminated the need for developers. It has eliminated the assumption that skill value increases linearly with time and tenure.

In financial markets, liquidity does not destroy value. It redistributes it and exposes where the leverage lives.

The same shift is happening in software. Those who thrive will be the ones who enable the flow of skill, knowledge, and value. That means orchestration, amplification, and infrastructure.

In markets, liquidity rewards the ones who create it.
In engineering, the same will now be true.​​​​​​​​​​​​​​​​