The Bottleneck Moved: Notes From the ELC 2026 Floor (Part 1)

Part 1 of 2. Engineering leaders have stopped asking whether to adopt AI. At ELC this year, every serious question was about operating it: who owns it, how to measure it, and how to run it inside regulated walls.

Over two days at the ELC Annual Conference, our CTO Lucas Hendrich and our engineering team spoke with VPs of Engineering, platform owners, product leads and founders across healthcare, life sciences, media, ad tech, enterprise infrastructure and services. Below are the questions that came up most, and how we answered them. Attendees are described by role and sector rather than name; their questions are condensed, our answers lightly edited.
‍

What changed since last year

Four signals from the floor, before any Q&A:

1. The question shifted from "should we" to "who owns this." Nobody we spoke with was debating adoption. They were debating ownership, measurement and risk.
2. Less noise, more confusion. The halls were quieter than last year. Buyers weren't skeptical about AI; they were unsure which problem to solve first.
3. Code generation is no longer the constraint. Review, architecture and maintainability are.
4. "Tokens versus people" is now a budget line. Some leadership teams would rather fund tokens than outside engineers. The leaders closest to delivery were less sure that trade holds up in production.
   ‍

1. The bottleneck moved downstream

Q — Director of Engineering, 20 engineers across four teams: One team is at 100% AI-assisted development. Another is at maybe 20%. The fast team ships so much code that architecture and code review can't keep up. My most expensive engineers now spend hours reviewing. How are others handling this?

Lucas (CTO): This is the most common pattern we saw this year. Generation scales, but review doesn't. Three things usually sit underneath it:

• It's never just an AI problem. It turns into a data problem, then a source-of-truth problem, then a standards problem. Teams discover them in that order.
• Nobody owns the system. Each engineer runs their own skills, MCP connections and prompts. Velocity in one team becomes someone else's debt.
• Review is still designed for human-written code. One senior reviewer, line by line, against an AI-sized volume of change.

Q — same leader: Then the budget question arrives. Why aren't we faster? Why are we spending this much on tokens? How do I prove any of it?

Lucas: Most teams can't answer because they never took a baseline, and they have no telemetry linking a tooling change to a business outcome. Without both, every AI budget conversation is one opinion against another. Activity metrics like PR counts, lines of code and tokens burned are context, not evidence.

Q — same leader: Part of my resistance is cultural. Engineers worry about maintainability: code nobody fully understands when an incident hits.

Lucas: Treat that as a real risk, not a morale issue. Agentic delivery is not run-and-done. It needs maintenance, exception handling and incident ownership. If nobody can explain a module during an outage, the speed it was written at doesn't matter.

Monday move: Name one owner for how AI is used across teams: skills, MCP connections, review rules. Then baseline one business metric, such as cycle time, change failure rate or time to market, before buying more seats or tokens.

‍

2. On-prem AI is back in the cost conversation

Q — Product lead, enterprise private-cloud AI: We sell full-stack AI boxes, from 2 to 256 GPUs, running open-weight models on-prem. A mid-market company could own its AI infrastructure for years at a fraction of cloud cost. Why don't more of them?

Lucas: I've run that math myself. At a wealth management firm, we were spending heavily on Azure, mostly to store data we didn't need. When cloud prices rose in 2022, the model was simple: hire two DevOps engineers, buy a couple of racks, cut cost by roughly an order of magnitude. Hardware was never the barrier. Rearchitecting was. It is not a lift and shift.

Newer companies have no legacy to move, so for them the barrier is perception. Most buyers assume the choice is a frontier API or nothing. That assumption is already out of date.

Q — same leader: Which open models are worth watching?

Lucas: Mistral is underrated, especially for European and mid-market buyers who need control over where models run. The open-weight field is widening fast.

Q — Founder, AI infrastructure security: My regulated and government customers can't depend on a cloud-hosted attestation service; it's an attack vector. So attestation, firmware patching and trusted execution all have to run on-prem, across a cluster.

Lucas: That's the hidden cost of on-prem AI. Most AI infrastructure guidance assumes the cloud. Once you leave it, trust tooling becomes your problem: attestation, firmware updates and cluster-wide workflow automation, at the hardware level. Those skills are scarce, so budget for them explicitly.

Q — same founder: My hiring list is AI, Rust, Go, Python, networking and infrastructure, all at once.

Lucas: That's one of the hardest hiring profiles of 2026. Treat it as a sequencing problem. Decide which skills must be permanent and which you only need to stand the platform up.

Monday move: Rerun the cloud-versus-own math for one AI workload, and include the rearchitecture and trust-tooling cost. If it's close, open-weight on-prem deserves a real evaluation, not a reflexive no.
‍

Key Takeaways

1. Code generation is solved enough. Review, architecture and maintainability are the new constraints.
2. AI problems arrive in sequence: data, then source of truth, then standards. Budget for all three.
3. No baseline, no telemetry, no defensible AI budget. Activity metrics won't survive a CFO.
4. In regulated environments, access control is designed into retrieval. It doesn't come with the model.
5. On-prem and open-weight models are back on the table. The hard part is rearchitecture and trust tooling, not hardware.

‍