As cloud project tracking software monday.com’s engineering organization scaled past 500 developers, the team began to feel the strain of its own success. Product lines were multiplying, microservices proliferating, and code was flowing faster than human reviewers could keep up. The company needed a way to review thousands of pull requests each month without drowning developers in tedium — or letting quality slip.

That’s when Guy Regev, VP of R&D and head of the Growth and monday Dev teams, started experimenting with a new AI tool from Qodo, an Israeli startup focused on developer agents. What began as a lightweight test soon became a critical part of monday.com’s software delivery infrastructure, as a new case study released by both Qodo and monday.com today reveals.

“Qodo doesn’t feel like just another tool—it’s like adding a new developer to the team who actually learns how we work," Regev told VentureBeat in a recent video call interview, adding that it has "prevented over 800 issues per month from reaching production—some of them could have caused serious security vulnerabilities."

Unlike code generation tools like GitHub Copilot or Cursor, Qodo isn’t trying to write new code. Instead, it specializes in reviewing it — using what it calls context engineering to understand not just what changed in a pull request, but why, how it aligns with business logic, and whether it follows internal best practices.

"You can call Claude Code or Cursor and in five minutes get 1,000 lines of code," said Itamar Friedman, co-founder and CEO of Qodo, in the same video call interview as with Regev. "You have 40 minutes, and you can't review that. So you need Qodo to actually review it.”

For monday.com, this capability wasn’t just helpful — it was transformative.

Code Review, at Scale

At any given time, monday.com’s developers are shipping updates across hundreds of repositories and services. The engineering org works in tightly coordinated teams, each aligned with specific parts of the product: marketing, CRM, dev tools, internal platforms, and more.

That’s where Qodo came in. The company’s platform uses AI not just to check for obvious bugs or style violations, but to evaluate whether a pull request follows team-specific conventions, architectural guidelines, and historical patterns.

It does this by learning from your own codebase — training on previous PRs, comments, merges, and even Slack threads to understand how your team works.

"The comments Qodo gives aren’t generic—they reflect our values, our libraries, even our standards for things like feature flags and privacy," Regev said. "It’s context-aware in a way traditional tools aren’t."

What “Context Engineering” Actually Means

Qodo calls its secret sauce context engineering — a system-level approach to managing everything the model sees when making a decision.

This includes the PR code diff, of course, but also prior discussions, documentation, relevant files from the repo, even test results and configuration data.

The idea is that language models don’t really “think” — they predict the next token based on the inputs they’re given. So the quality of their output depends almost entirely on the quality and structure of their inputs.

As Dana Fine, Qodo’s community manager, put it in a blog post: “You’re not just writing prompts; you’re designing structured input under a fixed token limit. Every token is a design decision.”

This isn’t just theory. In monday.com’s case, it meant Qodo could catch not only the obvious bugs, but the subtle ones that typically slip past human reviewers — hardcoded variables, missing fallbacks, or violations of cross-team architecture conventions.

One example stood out. In a recent PR, Qodo flagged a line that inadvertently exposed a staging environment variable — something no human reviewer caught. Had it been merged, it might have caused problems in production.

"The hours we would spend on fixing this security leak and the legal issue that it would bring would be much more than the hours that we reduce from a pull-request," said Regev.

Integration into the Pipeline

Today, Qodo is deeply integrated into monday.com’s development workflow, analyzing pull requests and surfacing context-aware recommendations based on prior team code reviews.

“It doesn’t feel like just another tool... It feels like another teammate that joined the system — one who learns how we work," Regev noted.

Developers receive suggestions during the review process and remain in control of final decisions — a human-in-the-loop model that was critical for adoption.

Because Qodo integrated directly into GitHub via pull request actions and comments, Monday.com’s infrastructure team didn’t face a steep learning curve.

“It’s just a GitHub action,” said Regev. “It creates a PR with the tests. It’s not like a separate tool we had to learn.”

“The purpose is to actually help the developer learn the code, take ownership, give feedback to each other, and learn from that and establish the standards," added Friedman.

The Results: Time Saved, Bugs Prevented

Since rolling out Qodo more broadly, monday.com has seen measurable improvements across multiple teams.

Internal analysis shows that developers save roughly an hour per pull request on average. Multiply that across thousands of PRs per month, and the savings quickly reach thousands of developer hours annually.

These aren’t just cosmetic issues — many relate to business logic, security, or runtime stability. And because Qodo’s suggestions reflect monday.com’s actual conventions, developers are more likely to act on them.

The system’s accuracy is rooted in its data-first design. Qodo trains on each company’s private codebase and historical data, adapting to different team styles and practices. It doesn’t rely on one-size-fits-all rules or external datasets. Everything is tailored.

From Internal Tool to Product Vision

Regev’s team was so impressed with Qodo’s impact that they’ve started planning deeper integrations between Qodo and Monday Dev, the developer-focused product line monday.com is building.

The vision is to create a workflow where business context — tasks, tickets, customer feedback — flows directly into the code review layer. That way, reviewers can assess not just whether the code “works,” but whether it solves the right problem.

“Before, we had linters, danger rules, static analysis... rule-based... you need to configure all the rules," Regev said. "But it doesn’t know what you don’t know... Qodo... feels like it’s learning from our engineers.”

This aligns closely with Qodo’s own roadmap. The company doesn’t just review code. It’s building a full platform of developer agents — including Qodo Gen for context-aware code generation, Qodo Merge for automated PR analysis, and Qodo Cover, a regression-testing agent that uses runtime validation to ensure test coverage.

All of this is powered by Qodo’s own infrastructure, including its new open-source embedding model, Qodo-Embed-1-1.5B, which outperformed offerings from OpenAI and Salesforce on code retrieval benchmarks.

What’s Next?

Qodo is now offering its platform under a freemium model — free for individuals, discounted for startups through Google Cloud’s Perks program, and enterprise-grade for companies that need SSO, air-gapped deployment, or advanced controls.

The company is already working with teams at NVIDIA, Intuit, and other Fortune 500 companies. And thanks to a recent partnership with Google Cloud, Qodo’s models are available directly inside Vertex AI’s Model Garden, making it easier to integrate into enterprise pipelines.

"Context engines will be the big story of 2026," Friedman said. "Every enterprise will need to build their own second brain if they want AI that actually understands and helps them."

As AI systems become more embedded in software development, tools like Qodo are showing how the right context — delivered at the right moment — can transform how teams build, ship, and scale code across the enterprise.

The Barcelona-based firm said its new data center will house 10 quantum computers to deliver Europe’s first multimodal quantum infrastructure.

To realize AI's full potential, enterprises must modernize their network infrastructure to be cloud-first, elastic, and high-performance.

Data center audit requirements are complex but essential. This guide covers audit types, benefits, and how to select the right auditor.

Companies hate to admit it, but the road to production-level AI deployment is littered with proof of concepts (PoCs) that go nowhere, or failed projects that never deliver on their goals. In certain domains, there’s little tolerance for iteration, especially in something like life sciences, when the AI application is facilitating new treatments to markets or diagnosing diseases. Even slightly inaccurate analyses and assumptions early on can create sizable downstream drift in ways that can be concerning.

In analyzing dozens of AI PoCs that sailed on through to full production use — or didn’t — six common pitfalls emerge. Interestingly, it’s not usually the quality of the technology but misaligned goals, poor planning or unrealistic expectations that caused failure.

Here’s a summary of what went wrong in real-world examples and practical guidance on how to get it right.

Lesson 1: A vague vision spells disaster

Every AI project needs a clear, measurable goal. Without it, developers are building a solution in search of a problem. For example, in developing an AI system for a pharmaceutical manufacturer’s clinical trials, the team aimed to “optimize the trial process,” but didn’t define what that meant. Did they need to accelerate patient recruitment, reduce participant dropout rates or lower the overall trial cost? The lack of focus led to a model that was technically sound but irrelevant to the client’s most pressing operational needs.

Takeaway: Define specific, measurable objectives upfront. Use SMART criteria (Specific, Measurable, Achievable, Relevant, Time-bound). For example, aim for “reduce equipment downtime by 15% within six months” rather than a vague “make things better.” Document these goals and align stakeholders early to avoid scope creep.

Lesson 2: Data quality overtakes quantity

Data is the lifeblood of AI, but poor-quality data is poison. In one project, a retail client began with years of sales data to predict inventory needs. The catch? The dataset was riddled with inconsistencies, including missing entries, duplicate records and outdated product codes. The model performed well in testing but failed in production because it learned from noisy, unreliable data.

Takeaway: Invest in data quality over volume. Use tools like Pandas for preprocessing and Great Expectations for data validation to catch issues early. Conduct exploratory data analysis (EDA) with visualizations (like Seaborn) to spot outliers or inconsistencies. Clean data is worth more than terabytes of garbage.

Lesson 3: Overcomplicating model backfires

Chasing technical complexity doesn't always lead to better outcomes. For example, on a healthcare project, development initially began by creating a sophisticated convolutional neural network (CNN) to identify anomalies in medical images.

While the model was state-of-the-art, its high computational cost meant weeks of training, and its "black box" nature made it difficult for clinicians to trust. The application was revised to implement a simpler random forest model that not only matched the CNN's predictive accuracy but was faster to train and far easier to interpret — a critical factor for clinical adoption.

Takeaway: Start simple. Use straightforward algorithms like random forest or XGBoost from scikit-learn to establish a baseline. Only scale to complex models — TensorFlow-based long-short-term-memory (LSTM) networks — if the problem demands it. Prioritize explainability with tools like SHAP (SHapley Additive exPlanations) to build trust with stakeholders.

Lesson 4: Ignoring deployment realities

A model that shines in a Jupyter Notebook can crash in the real world. For example, a company’s initial deployment of a recommendation engine for its e-commerce platform couldn’t handle peak traffic. The model was built without scalability in mind and choked under load, causing delays and frustrated users. The oversight cost weeks of rework.

Takeaway: Plan for production from day one. Package models in Docker containers and deploy with Kubernetes for scalability. Use TensorFlow Serving or FastAPI for efficient inference. Monitor performance with Prometheus and Grafana to catch bottlenecks early. Test under realistic conditions to ensure reliability.

Lesson 5: Neglecting model maintenance

AI models aren’t set-and-forget. In a financial forecasting project, the model performed well for months until market conditions shifted. Unmonitored data drift caused predictions to degrade, and the lack of a retraining pipeline meant manual fixes were needed. The project lost credibility before developers could recover.

Takeaway: Build for the long haul. Implement monitoring for data drift using tools like Alibi Detect. Automate retraining with Apache Airflow and track experiments with MLflow. Incorporate active learning to prioritize labeling for uncertain predictions, keeping models relevant.

Lesson 6: Underestimating stakeholder buy-in

Technology doesn’t exist in a vacuum. A fraud detection model was technically flawless but flopped because end-users — bank employees — didn’t trust it. Without clear explanations or training, they ignored the model’s alerts, rendering it useless.

Takeaway: Prioritize human-centric design. Use explainability tools like SHAP to make model decisions transparent. Engage stakeholders early with demos and feedback loops. Train users on how to interpret and act on AI outputs. Trust is as critical as accuracy.

Best practices for success in AI projects

Drawing from these failures, here’s the roadmap to get it right:

• Set clear goals: Use SMART criteria to align teams and stakeholders.

• Prioritize data quality: Invest in cleaning, validation and EDA before modeling.

• Start simple: Build baselines with simple algorithms before scaling complexity.

• Design for production: Plan for scalability, monitoring and real-world conditions.

• Maintain models: Automate retraining and monitor for drift to stay relevant.

• Engage stakeholders: Foster trust with explainability and user training.

Building resilient AI

AI’s potential is intoxicating, yet failed AI projects teach us that success isn’t just about algorithms. It’s about discipline, planning and adaptability. As AI evolves, emerging trends like federated learning for privacy-preserving models and edge AI for real-time insights will raise the bar. By learning from past mistakes, teams can build scale-out, production systems that are robust, accurate, and trusted.

Kavin Xavier is VP of AI solutions at CapeStart.

Read more from our guest writers. Or, consider submitting a post of your own! See our guidelines here.

AI coding, vibe coding and agentic swarm have made a dramatic and astonishing recent market entrance, with the AI Code Tools market valued at $4.8 billion and expected to grow at a 23% annual rate.  Enterprises are grappling with AI coding agents and what do about expensive human coders. 

They don’t lack for advice.  OpenAI’s CEO estimates that AI can perform over 50% of what human engineers can do.  Six months ago, Anthropic’s CEO said that AI would write 90% of code in six months.  Meta’s CEO said he believes AI will replace mid-level engineers “soon.” Judging by recent tech layoffs, it seems many executives are embracing that advice.

Software engineers and data scientists are among the most expensive salary lines at many companies, and business and technology leaders may be tempted to replace them with AI. However, recent high-profile failures demonstrate that engineers and their expertise remain valuable, even as AI continues to make impressive advances.

SaaStr disaster

Jason Lemkin, a tech entrepreneur and founder of the SaaS community SaaStr, has been vibe coding a SaaS networking app and live-tweeting his experience. About a week into his adventure, he admitted to his audience that something was going very wrong.  The AI deleted his production database despite his request for a “code and action freeze.” This is the kind of mistake no experienced (or even semi-experienced) engineer would make.

If you have ever worked in a professional coding environment, you know to split your development environment from production. Junior engineers are given full access to the development environment (it’s crucial for productivity), but access to production is given on a limited need-to-have basis to a few of the most trusted senior engineers. The reason for restricted access is precisely for this use case: To prevent a junior engineer from accidentally taking down production.

In fact, Lemkin made two mistakes. First: for something as critical as production, access to unreliable actors is just never granted (we don’t rely on asking a junior engineer or AI nicely). Second, he never separated development from production.  In a subsequent public conversation on LinkedIn, Lemkin, who holds a Stanford Executive MBA and Berkeley JD, admitted that he was not aware of the best practice of splitting development and production databases.

The takeaway for business leaders is that standard software engineering best practices still apply. We should incorporate at least the same safety constraints for AI as we do for junior engineers. Arguably, we should go beyond that and treat AI slightly adversarially: There are reports that, like HAL in Stanley Kubrick's 2001: A Space Odyssey, the AI might try to break out of its sandbox environment to accomplish a task. With more vibe coding, having experienced engineers who understand how complex software systems work and can implement the proper guardrails in development processes will become increasingly necessary.

Tea hack

Sean Cook is the Founder and CEO of Tea, a mobile application launched in 2023, designed to help women date safely. In the summer of 2025, they were “hacked": 72,000 images, including 13,000 verification photos and images of government IDs, were leaked onto the public discussion forum 4chan. Worse, Tea’s own privacy policy promises that these images would be "deleted immediately" after users were authenticated, meaning they potentially violated their own privacy policy.

I use “hacked” in air-quotes because the incident stems less from the cleverness of the attackers than the ineptitude of the defenders. In addition to violating their own data policies, the app left a Firebase storage bucket unsecured, exposing sensiztive user data to the public internet. It’s the digital equivalent of locking your front door but leaving your back open with your family jewelry ostentatiously hanging on the doorknob.

While we don’t know if the root cause was vibe coding, the Tea hack highlights catastrophic breaches stemming from basic, preventable security errors due to poor development processes. It is the kind of vulnerability that a disciplined and thoughtful engineering process addresses. Unfortunately, the relentless push of financial pressures, where a “lean,” “move fast and break things” culture is the polar opposite, and vibe coding only exacerbates the problem.

How to safely adopt AI coding agents?

So how should enterprise and technology leaders think about AI? First, this is not a call to abandon AI for coding.  An MIT Sloan study estimated AI leads to productivity gains between 8% and 39%, while a McKinsey study found a 10% to 50% reduction in time to task completion with the use of AI. 

However, we should be aware of the risks. The old lessons of software engineering don’t go away. These include many tried-and-true best practices, such as version control, automated unit and integration tests, safety checks like SAST/DAST, separating development and production environments, code review and secrets management. If anything, they become more salient.

AI can generate code 100 times faster than humans can type, fostering an illusion of productivity that is a tempting siren call for many executives.  However, the quality of the rapidly generated AI shlop is still up for debate. To develop complex production systems, enterprises need the thoughtful, seasoned experience of human engineers.

Tianhui Michael Li is president at Pragmatic Institute and the founder and president of The Data Incubator.

Read more from our guest writers. Or, consider submitting a post of your own! See our guidelines here.

The developers of Terminal-Bench, a benchmark suite for evaluating the performance of autonomous AI agents on real-world terminal-based tasks, have released version 2.0 alongside Harbor, a new framework for testing, improving and optimizing AI agents in containerized environments.

The dual release aims to address long-standing pain points in testing and optimizing AI agents, particularly those built to operate autonomously in realistic developer environments.

With a more difficult and rigorously verified task set, Terminal-Bench 2.0 replaces version 1.0 as the standard for assessing frontier model capabilities.

Harbor, the accompanying runtime framework, enables developers and researchers to scale evaluations across thousands of cloud containers and integrates with both open-source and proprietary agents and training pipelines.

“Harbor is the package we wish we had had while making Terminal-Bench," wrote co-creator Alex Shaw on X. "It’s for agent, model, and benchmark developers and researchers who want to evaluate and improve agents and models."

Higher Bar, Cleaner Data

Terminal-Bench 1.0 saw rapid adoption after its release in May 2025, becoming a default benchmark for evaluating agent performance across the field of AI-powered agents operating in developer-style terminal environments. These agents interact with systems through the command line, mimicking how developers work behind the scenes of the graphical user interface.

However, its broad scope came with inconsistencies. Several tasks were identified by the community as poorly specified or unstable due to external service changes.

Version 2.0 addresses those issues directly. The updated suite includes 89 tasks, each subjected to several hours of manual and LLM-assisted validation. The emphasis is on making tasks solvable, realistic, and clearly specified, raising the difficulty ceiling while improving reliability and reproducibility.

A notable example is the download-youtube task, which was removed or refactored in 2.0 due to its dependence on unstable third-party APIs.

“Astute Terminal-Bench fans may notice that SOTA performance is comparable to TB1.0 despite our claim that TB2.0 is harder,” Shaw noted on X. “We believe this is because task quality is substantially higher in the new benchmark.”

Harbor: Unified Rollouts at Scale

Alongside the benchmark update, the team launched Harbor, a new framework for running and evaluating agents in cloud-deployed containers.

Harbor supports large-scale rollout infrastructure, with compatibility for major providers like Daytona and Modal.

Designed to generalize across agent architectures, Harbor supports:

• Evaluation of any container-installable agent

• Scalable supervised fine-tuning (SFT) and reinforcement learning (RL) pipelines

• Custom benchmark creation and deployment

• Full integration with Terminal-Bench 2.

Harbor was used internally to run tens of thousands of rollouts during the creation of the new benchmark. It is now publicly available via harborframework.com, with documentation for testing and submitting agents to the public leaderboard.

Early Results: GPT-5 Leads in Task Success

Initial results from the Terminal-Bench 2.0 leaderboard show OpenAI's Codex CLI (command line interface), a GPT-5 powered variant, in the lead, with a 49.6% success rate — the highest among all agents tested so far.

Close behind are other GPT-5 variants and Claude Sonnet 4.5-based agents.

Top 5 Agent Results (Terminal-Bench 2.0):

1. Codex CLI (GPT-5) — 49.6%

2. Codex CLI (GPT-5-Codex) — 44.3%

3. OpenHands (GPT-5) — 43.8%

4. Terminus 2 (GPT-5-Codex) — 43.4%

5. Terminus 2 (Claude Sonnet 4.5) — 42.8%

The close clustering among top models indicates active competition across platforms, with no single agent solving more than half the tasks.

Submission and Use

To test or submit an agent, users install Harbor and run the benchmark using simple CLI commands. Submissions to the leaderboard require five benchmark runs, and results can be emailed to the developers along with job directories for validation.

harbor run -d terminal-bench@2.0 -m "<model>" -a "<agent>" --n-attempts 5 --jobs-dir <path/to/output>

Terminal-Bench 2.0 is already being integrated into research workflows focused on agentic reasoning, code generation, and tool use. According to co-creator Mike Merrill, a postdoctoral researcher at Stanford, a detailed preprint is in progress covering the verification process and design methodology behind the benchmark.

Aiming for Standardization

The combined release of Terminal-Bench 2.0 and Harbor marks a step toward more consistent and scalable agent evaluation infrastructure. As LLM agents proliferate in developer and operational environments, the need for controlled, reproducible testing has grown.

These tools offer a potential foundation for a unified evaluation stack — supporting model improvement, environment simulation, and benchmark standardization across the AI ecosystem.

Across industries, rising compute expenses are often cited as a barrier to AI adoption — but leading companies are finding that cost is no longer the real constraint.

The tougher challenges (and the ones top of mind for many tech leaders)? Latency, flexibility and capacity.

At Wonder, for instance, AI adds a mere few cents per order; the food delivery and takeout company is much more concerned with cloud capacity with skyrocketing demands. Recursion, for its part, has been focused on balancing small and larger-scale training and deployment via on-premises clusters and the cloud; this has afforded the biotech company flexibility for rapid experimentation.

The companies’ true in-the-wild experiences highlight a broader industry trend: For enterprises operating AI at scale, economics aren't the key decisive factor — the conversation has shifted from how to pay for AI to how fast it can be deployed and sustained.

AI leaders from the two companies recently sat down with Venturebeat’s CEO and editor-in-chief Matt Marshall as part of VB’s traveling AI Impact Series. Here’s what they shared.

Wonder: Rethink what you assume about capacity

Wonder uses AI to power everything from recommendations to logistics — yet, as of now, reported CTO James Chen, AI adds just a few cents per order.

Chen explained that the technology component of a meal order costs 14 cents, the AI adds 2 to 3 cents, although that’s “going up really rapidly” to 5 to 8 cents. Still, that seems almost immaterial compared to total operating costs.

Instead, the 100% cloud-native AI company’s main concern has been capacity with growing demand. Wonder was built with “the assumption” (which proved to be incorrect) that there would be “unlimited capacity” so they could move “super fast” and wouldn’t have to worry about managing infrastructure, Chen noted.

But the company has grown quite a bit over the last few years, he said; as a result, about six months ago, “we started getting little signals from the cloud providers, ‘Hey, you might need to consider going to region two,’” because they were running out of capacity for CPU or data storage at their facilities as demand grew.

It was “very shocking” that they had to move to plan B earlier than they anticipated. “Obviously it's good practice to be multi-region, but we were thinking maybe two more years down the road,” said Chen.

What's not economically feasible (yet)

Wonder built its own model to maximize its conversion rate, Chen noted; the goal is to surface new restaurants to relevant customers as much as possible. These are “isolated scenarios” where models are trained over time to be “very, very efficient and very fast.”

Currently, the best bet for Wonder’s use case is large models, Chen noted. But in the long term, they’d like to move to small models that are hyper-customized to individuals (via AI agents or concierges) based on their purchase history and even their clickstream. “Having these micro models is definitely the best, but right now the cost is very expensive,” Chen noted. “If you try to create one for each person, it's just not economically feasible.”

Budgeting is an art, not a science

Wonder gives its devs and data scientists as much playroom as possible to experiment, and internal teams review the costs of use to make sure nobody turned on a model and “jacked up massive compute around a huge bill,” said Chen.

The company is trying different things to offload to AI and operate within margins. “But then it's very hard to budget because you have no idea,” he said. One of the challenging things is the pace of development; when a new model comes out, “we can’t just sit there, right? We have to use it.”

Budgeting for the unknown economics of a token-based system is “definitely art versus science.”

A critical component in the software development lifecycle is preserving context when using large native models, he explained. When you find something that works, you can add it to your company’s “corpus of context” that can be sent with every request. That’s big and it costs money each time.

“Over 50%, up to 80% of your costs is just resending the same information back into the same engine again on every request,” said Chen.

In theory, the more they do should require less cost per unit. “I know when a transaction happens, I'll pay the X cent tax for each one, but I don't want to be limited to use the technology for all these other creative ideas."

The 'vindication moment' for Recursion

Recursion, for its part, has focused on meeting broad-ranging compute needs via a hybrid infrastructure of on-premise clusters and cloud inference.

When initially looking to build out its AI infrastructure, the company had to go with its own setup, as “the cloud providers didn't have very many good offerings,” explained CTO Ben Mabey. “The vindication moment was that we needed more compute and we looked to the cloud providers and they were like, ‘Maybe in a year or so.’”

The company’s first cluster in 2017 incorporated Nvidia gaming GPUs (1080s, launched in 2016); they have since added Nvidia H100s and A100s, and use a Kubernetes cluster that they run in the cloud or on-prem.

Addressing the longevity question, Mabey noted: “These gaming GPUs are actually still being used today, which is crazy, right? The myth that a GPU's life span is only three years, that's definitely not the case. A100s are still top of the list, they're the workhorse of the industry.”

Best use cases on-prem vs cloud; cost differences

More recently, Mabey’s team has been training a foundation model on Recursion’s image repository (which consists of petabytes of data and more than 200 pictures). This and other types of big training jobs have required a “massive cluster” and connected, multi-node setups.

“When we need that fully-connected network and access to a lot of our data in a high parallel file system, we go on-prem,” he explained. On the other hand, shorter workloads run in the cloud.

Recursion’s method is to “pre-empt” GPUs and Google tensor processing units (TPUs), which is the process of interrupting running GPU tasks to work on higher-priority ones. “Because we don't care about the speed in some of these inference workloads where we're uploading biological data, whether that's an image or sequencing data, DNA data,” Mabey explained. “We can say, ‘Give this to us in an hour,’ and we're fine if it kills the job.”

From a cost perspective, moving large workloads on-prem is “conservatively” 10 times cheaper, Mabey noted; for a five year TCO, it's half the cost. On the other hand, for smaller storage needs, the cloud can be “pretty competitive” cost-wise.

Ultimately, Mabey urged tech leaders to step back and determine whether they’re truly willing to commit to AI; cost-effective solutions typically require multi-year buy-ins.

“From a psychological perspective, I've seen peers of ours who will not invest in compute, and as a result they're always paying on demand," said Mabey. "Their teams use far less compute because they don't want to run up the cloud bill. Innovation really gets hampered by people not wanting to burn money.”

Researchers at New York University have developed a new architecture for diffusion models that improves the semantic representation of the images they generate. “Diffusion Transformer with Representation Autoencoders” (RAE) challenges some of the accepted norms of building diffusion models. The NYU researcher's model is more efficient and accurate than standard diffusion models, takes advantage of the latest research in representation learning and could pave the way for new applications that were previously too difficult or expensive.

This breakthrough could unlock more reliable and powerful features for enterprise applications. "To edit images well, a model has to really understand what’s in them," paper co-author Saining Xie told VentureBeat. "RAE helps connect that understanding part with the generation part." He also pointed to future applications in "RAG-based generation, where you use RAE encoder features for search and then generate new images based on the search results," as well as in "video generation and action-conditioned world models."

The state of generative modeling

Diffusion models, the technology behind most of today’s powerful image generators, frame generation as a process of learning to compress and decompress images. A variational autoencoder (VAE) learns a compact representation of an image’s key features in a so-called “latent space.” The model is then trained to generate new images by reversing this process from random noise.

While the diffusion part of these models has advanced, the autoencoder used in most of them has remained largely unchanged in recent years. According to the NYU researchers, this standard autoencoder (SD-VAE) is suitable for capturing low-level features and local appearance, but lacks the “global semantic structure crucial for generalization and generative performance.”

At the same time, the field has seen impressive advances in image representation learning with models such as DINO, MAE and CLIP. These models learn semantically-structured visual features that generalize across tasks and can serve as a natural basis for visual understanding. However, a widely-held belief has kept devs from using these architectures in image generation: Models focused on semantics are not suitable for generating images because they don’t capture granular, pixel-level features. Practitioners also believe that diffusion models do not work well with the kind of high-dimensional representations that semantic models produce.

Diffusion with representation encoders

The NYU researchers propose replacing the standard VAE with “representation autoencoders” (RAE). This new type of autoencoder pairs a pretrained representation encoder, like Meta’s DINO, with a trained vision transformer decoder. This approach simplifies the training process by using existing, powerful encoders that have already been trained on massive datasets.

To make this work, the team developed a variant of the diffusion transformer (DiT), the backbone of most image generation models. This modified DiT can be trained efficiently in the high-dimensional space of RAEs without incurring huge compute costs. The researchers show that frozen representation encoders, even those optimized for semantics, can be adapted for image generation tasks. Their method yields reconstructions that are superior to the standard SD-VAE without adding architectural complexity.

However, adopting this approach requires a shift in thinking. "RAE isn’t a simple plug-and-play autoencoder; the diffusion modeling part also needs to evolve," Xie explained. "One key point we want to highlight is that latent space modeling and generative modeling should be co-designed rather than treated separately."

With the right architectural adjustments, the researchers found that higher-dimensional representations are an advantage, offering richer structure, faster convergence and better generation quality. In their paper, the researchers note that these "higher-dimensional latents introduce effectively no extra compute or memory costs." Furthermore, the standard SD-VAE is more computationally expensive, requiring about six times more compute for the encoder and three times more for the decoder, compared to RAE.

Stronger performance and efficiency

The new model architecture delivers significant gains in both training efficiency and generation quality. The team's improved diffusion recipe achieves strong results after only 80 training epochs. Compared to prior diffusion models trained on VAEs, the RAE-based model achieves a 47x training speedup. It also outperforms recent methods based on representation alignment with a 16x training speedup. This level of efficiency translates directly into lower training costs and faster model development cycles.

For enterprise use, this translates into more reliable and consistent outputs. Xie noted that RAE-based models are less prone to semantic errors seen in classic diffusion, adding that RAE gives the model "a much smarter lens on the data." He observed that leading models like ChatGPT-4o and Google's Nano Banana are moving toward "subject-driven, highly consistent and knowledge-augmented generation," and that RAE's semantically rich foundation is key to achieving this reliability at scale and in open source models.

The researchers demonstrated this performance on the ImageNet benchmark. Using the Fréchet Inception Distance (FID) metric, where a lower score indicates higher-quality images, the RAE-based model achieved a state-of-the-art score of 1.51 without guidance. With AutoGuidance, a technique that uses a smaller model to steer the generation process, the FID score dropped to an even more impressive 1.13 for both 256x256 and 512x512 images.

By successfully integrating modern representation learning into the diffusion framework, this work opens a new path for building more capable and cost-effective generative models. This unification points toward a future of more integrated AI systems.

"We believe that in the future, there will be a single, unified representation model that captures the rich, underlying structure of reality... capable of decoding into many different output modalities," Xie said. He added that RAE offers a unique path toward this goal: "The high-dimensional latent space should be learned separately to provide a strong prior that can then be decoded into various modalities — rather than relying on a brute-force approach of mixing all data and training with multiple objectives at once."

A new Omdia report outlines how geopolitics are creating a fragmented semiconductor supply chain as AI chip demand creates global pressure.