Ben Lorica and Evangelos Simoudis on AI Layoffs, Enterprise ROI, and R&D Groupthink.
Subscribe: Apple • Spotify • Overcast • Pocket Casts • AntennaPod • Podcast Addict • Amazon • RSS.
In this episode, Ben Lorica and Evangelos Simoudis of Synapse Partners explore the complex reality behind AI-driven layoffs, from automation and upskilling gaps to strategic shifts in R&D. They also dive into the massive capital investments in AI, discussing the growing pressure for ROI and the emergence of LLMOps as a form of financial management. The conversation highlights practical strategies for enterprises, emphasizing the need to break down organizational silos to succeed in the AI era.
Interview highlights – key sections from the video version:
Related content:
- A video version of this conversation is available on our YouTube channel.
- Agentic AI Applications: A Field Guide
- McKinsey Survey on how headcount has changed across various business functions over the past year as a result of AI.
- Before you scale your AI, read this
- Ben Lorica and Evangelos Simoudis → Stop Piloting, Start Shipping: A Playbook for Measurable AI
- Ben Lorica and Evangelos Simoudis → When AI Eats the Bottom Rung of the Career Ladder
- Ben Lorica and Evangelos Simoudis → Why China’s Engineering Culture Gives Them an AI Advantage
- Ben Lorica and Evangelos Simoudis → Beyond the Agent Hype
Support our work by subscribing to our newsletter📩
Transcript
Below is a heavily edited excerpt, in Question & Answer format.
Workforce & Organizational Impact
What are the main categories of AI-driven layoffs happening now?
AI is driving layoffs in three distinct ways, though some companies may also be using AI as a justification for cuts that have other causes (post-pandemic rightsizing, macroeconomic pressures):
- Upskilling gaps: Companies like Accenture have explicitly stated they will let go of employees who cannot be upskilled to work in an AI-centric environment. This isn’t traditional automation—it’s a structural shift in required skill sets.
- Automation and augmentation: Roles are being replaced or reduced through AI systems. Klarna’s customer support cuts exemplify this trend, even though some positions were later reinstated. This is where the “hollowing out” of junior roles becomes visible—organizations use AI to absorb entry-level tasks and hire fewer people at those levels.
- Strategic R&D shifts: Companies are laying off AI researchers who aren’t focused on currently favored approaches. Meta’s restructuring of parts of its AI research organization is one example. This reflects growing groupthink around current AI techniques (transformers, scaling laws) rather than exploring alternative approaches, and it’s particularly concerning for long-term innovation.
Which roles are most vulnerable to AI-driven workforce reductions?
Two categories are particularly at risk:
- Junior pipeline roles: Entry-level positions are contracting across multiple sectors. Companies are hiring fewer entry-level employees as AI tools handle tasks traditionally assigned to new hires. This “hollowing out” effect is well-documented and creates challenges for how future senior talent will be developed.
- Middle management and coordination roles: Positions that primarily coordinate small teams (around five people or fewer) are increasingly targeted. Tech companies are aggressively flattening organizational structures, with AI tools expected to handle coordination overhead. These managers are either eliminated or pushed back to individual contributor roles.
This trend is progressing across sectors: starting in tech companies, moving to knowledge services (consulting firms like Accenture and Deloitte), and expanding into financial services, manufacturing, automotive, and hospitality.
If you’re building AI applications, recognize that they are not neutral—they will influence which roles your organization keeps, reshapes, or eliminates.
ROI, Cost Management & Infrastructure
How should enterprises think about ROI for AI projects?
You should not demand positive ROI from prototypes or pilots—that expectation can kill promising projects before they mature. However, you must define how you’ll measure value before you scale. Build your ROI framework early, even if you don’t expect the pilot itself to be positive.
Too many current pilots are driven purely by technology hype, vendor pressure, or board enthusiasm without a clear path to deployment or value creation. Define your ROI model upfront with these elements:
Four justification buckets:
- Productivity improvement
- Cost reduction
- New revenue generation
- Capability expansion (doing things you couldn’t do before)
ROI function considerations:
- What time horizon makes sense for your industry and use case (1 year vs 3 years)?
- How will you quantify benefits (saved hours, fewer errors, higher conversion, reduced churn)?
- What are the full costs (infrastructure, integration, data preparation, change management, ongoing support)?
The ROI timeline and components will vary significantly by industry and use case—a customer support system in hospitality will have a different profile than one in manufacturing. Make sure your telemetry can actually measure the metrics you care about once you scale.
What are the critical cost considerations for teams building LLM applications?
Cost management has become central to LLM operations. What’s being called “LLMOps” is essentially FinOps—the technical teams on the ground are acutely aware that costs spike immediately when users engage with deployed systems.
Key cost areas:
- Token economics: Every token you process or generate costs money. Monitor and optimize token counts, as this is a direct cost driver for API-based models. While token costs have decreased, they still add up at scale.
- Cloud infrastructure costs: GPU instances for training and especially inference represent significant expense that can spike unpredictably with user engagement.
- Architecture decisions: Do you need the verbosity of a vanilla LLM or foundation model, or would a more compact, task-specialized model work? As you move to higher-level agents, this becomes critical for cost containment. Your serving mechanism and deployment setup directly impact operational costs.
- Trust and governance: While not a direct financial line item, the cost of failure is high. The Deloitte/Australian government incident—where AI-generated reports contained significant errors requiring refunds—illustrates the stakes. Build in trust mechanisms, validation processes, and governance frameworks from the start.
What practical strategies can control the rising costs of deploying AI systems?
Several strategic levers can help manage costs:
- Use less capable hardware when appropriate: Chinese companies have demonstrated that you can accomplish significant enterprise tasks with older generation or less capable hardware. While everyone would prefer cutting-edge chips (and Chinese teams are working under export restrictions, not by choice), they’re proving you don’t always need the latest technology for many use cases. Evaluate what capability tier you actually need rather than defaulting to the most powerful and expensive option.
- Adopt smaller, specialized models: As applications evolve from simple chatbots to more complex agents, the need for verbose, general-purpose foundation models often decreases. For many tasks, a more compact, specialized model can be more efficient, faster, and significantly cheaper to run. Consider this progression:
- Start with a strong general model to validate value and learn what users actually do
- Identify stable, well-understood tasks (specific support flows, document classification, routing, data extraction)
- For those tasks, move to more compact or specialized models: fine-tuned smaller LLMs, task-specific models, or even non-LLM approaches where appropriate
- Use routing or orchestration so only the hardest, least frequent tasks hit the large, expensive model
- Leverage capable open-source models: High-quality open-source models, including many from China, provide cost-effective alternatives to expensive proprietary APIs. These can be fine-tuned and hosted on your own infrastructure, giving you more control over performance and cost. Hyperscalers and commercial model providers need to pay attention to this competitive pressure.
What infrastructure challenges are affecting enterprise AI adoption?
Three major bottlenecks exist that affect application teams, not just infrastructure providers:
- Energy constraints: Many data centers have been built and equipped but can’t get sufficient power. Energy availability is becoming the critical bottleneck in some regions, not data center construction itself.
- Chip supply: TSMC can’t produce enough AI chips to meet demand. This affects not just Nvidia but anyone with an ASIC design.
- Capacity and access implications: You may hit capacity constraints—quotas, throttling, longer lead times for scaling—that aren’t purely commercial; they’re physical. Regions and cloud providers with better energy and chip access will have better latency and reliability, making deployment location a strategic choice.
The massive capital investments being made (trillions of dollars in data centers) create pressure for near-term returns, even though AI infrastructure should be viewed as a utility with high upfront costs, similar to electricity or internet infrastructure. For hyperscalers building this infrastructure, the utility model makes sense. For enterprises using it, carefully consider what capability tier you actually need and what bills you can sustain as you move from prototypes to deployed systems.
Design with scarcity in mind, not infinite elastic capacity. Efficiency work you do—prompt optimization, caching, distillation, smarter routing between models—may be the difference between being able to scale and being stuck in a capacity queue.
Agents & Technical Architecture
What architectural decisions should teams consider for agent systems?
Many enterprises are moving from chatbots to agents—both software agents (orchestrating tools, workflows, and APIs) and embodied agents (robots, devices). There’s a spectrum of agency, from simple assistants to more autonomous, multi-step agents, and different points on that spectrum require different architectural approaches.
Two critical requirements:
- Connected data, not siloed snippets: Vanilla conversational models are trained to chat, not to operate over your specific enterprise graph of customers, assets, workflows, and events. To build useful agents you need:
- Linked transactional and operational data (orders, tickets, logs, telemetry)
- Clear semantics and relationships (who owns what, which systems are of record)
- A way to feed that structured, connected context into your agents
- Specialized models: reasoning and action, not just chat: As agent capabilities expand, you need to think beyond vanilla conversational models. General-purpose LLMs are often not the right backbone as agency grows. Consider:
- Large reasoning models (LRMs) to plan, decompose problems, and evaluate options
- Large action models (LAMs) to decide which tools to invoke, in what order, and when to stop or escalate
The architecture you choose affects both capability and cost. Teams are often defaulting to general-purpose LLMs when more specialized, compact models would be more appropriate and cost-effective for their specific agent tasks.
Practical approach:
- Start small: define your agent’s scope, tools, and guardrails very clearly
- Instrument everything (steps, decisions, tool calls) so you can see where it’s failing
- Treat agents as products, not just prompts—they need data architecture, model architecture, monitoring, and lifecycle management
- Don’t assume that a chat-oriented LLM plus a tool-calling API is sufficient for higher-agency use cases
Trust, Governance & Operational Concerns
Why are enterprises running into trust problems with AI systems?
Trust issues are no longer theoretical—they’re affecting production deployments and enterprise confidence. The pattern is common: prototypes look good in demos, but under deadline pressure AI output slips into deliverables without enough verification. When systems are used at full scale or by non-experts, error rates and consequences become visible. The Deloitte/Australian government case, where AI-generated reports contained significant errors requiring refunds, illustrates the real stakes.
Key operational considerations:
- Trust and governance as core “Ops” functions: Explainability, governance, and error management must be built in from the start. This includes logging, evaluation, human review workflows, and auditability—not patched in after an incident.
- Make validation workflows mandatory: Use workflow engines or agents that require human sign-off for high-impact actions. Make reviewers accountable and give them good tooling to spot issues.
- Align incentives properly: If success is measured purely by speed or volume (tickets handled, pages written), teams will overlook quality issues. Tie metrics to correctness, user satisfaction, and downstream outcomes.
LLMOps encompasses more than just cost management—it requires a combination of FinOps (cost dashboards, per-use-case budgets), traditional MLOps (deployment pipelines, A/B experiments, rollback strategies), and governance (policies, access control, red-teaming, and continuous evaluation).
Why is usage of code automation tools dropping as teams move to full system development?
Organizations are starting with high enthusiasm for AI code assistants, but usage drops when they move from prototypes to full system development. Several reasons emerge:
- Complexity of real systems: In small repositories or greenfield prototypes, assistants can guess correctly more easily. In large, messy codebases with implicit constraints, integrations, and performance requirements, hallucinated or naive code becomes costly.
- False sense of correctness: Generated code often compiles and runs but is subtly wrong—inefficient, insecure, or misaligned with business rules. These issues surface weeks later in testing or production.
- Maintenance burden: Accepting too much AI-generated code can create a codebase that’s harder for humans to understand and refactor, especially if patterns are inconsistent.
Code automation is augmentation, not a path to eliminating developers. Practical implications:
- Use AI for boilerplate, scaffolding, and exploration—not critical business logic
- Keep tests and CI/CD extremely strong; treat AI-written code as untrusted input that must pass the same gates as human code
- Capture patterns that work and embed them into prompts, templates, or internal tools so the assistant is nudged toward your architecture
Research Consolidation & Innovation Risks
What’s the risk of current AI research consolidation?
There’s dangerous groupthink emerging around current approaches—deep neural networks and transformers scaled with more data and compute. While the industry has achieved important milestones, it hasn’t solved the complete problem. Several concerning patterns are visible:
- Narrowing research bets: Companies are laying off researchers not focused on currently popular themes, limiting future innovation. Meta’s restructuring of AI research teams is one example—teams working on alternative approaches can look “off-theme” and get cut, even if their work could address current limitations.
- Competitive pressure driving conformity: Every major player is chasing roughly the same paradigm. Competitive pressure pushes everyone to match each incremental improvement rather than exploring orthogonal directions. Companies fear appearing inferior by not matching the scaling investments of competitors.
- Over-indexing on a single design pattern: Betting everything on “more data + bigger transformer” is a fallacy. This leaves gaps in areas like reasoning, action, and robustness.
Even as the industry consolidates around current techniques, organizations should maintain teams exploring alternative directions. For applied teams building AI applications, you can:
- Reserve a slice of effort for non-mainstream approaches, especially around reasoning, planning, and symbolic/structured methods
- Pilot new model classes (models specialized for reasoning or action) in parallel with the standard LLM-plus-RAG stack
- Avoid assuming that current LLM behavior is the endpoint—design your systems so you can swap in different model types over time
Organizational Transformation
What organizational changes are necessary for effective AI adoption?
AI adoption is a company-wide transformation, not just a tech project. Traditional organizational silos must come down. The old model—tech teams run pilots in isolation, throw them “over the wall” to business units, then engage HR for staffing, and finally go to the CFO for budget—doesn’t work for AI transformation.
Four functions must work together from the beginning:
- Technology/AI/Data teams: To build and operate the systems
- Business units/Product: To define use cases, success metrics, and workflows
- HR: To plan skills, staffing, and workforce transformation (upskilling vs hiring vs redeployment)
- Finance/CFO: To manage budgets, cost profiles, and ROI expectations
This integrated approach enables better decisions about AI use cases, more realistic planning for deployment costs, and proper workforce transformation. Companies should merge or closely align these functions rather than treating them as separate stakeholders who get updated at project milestones.
