The Ruby language has been around since 1995 and still gets regular releases. But the language has dropped to 30th place in this month’s Tiobe index of language popularity, with Python cited as a reason for Ruby’s drop.

Ruby was the Tiobe language of the year in 2006, having displayed the highest growth rate in popularity that year, it is now close to dropping out of the top 30, according to Tiobe CEO Paul Jansen. Ruby’s March rating is .55%; the language was ranked 25th last month. “The main reason for Ruby’s drop is Python’s popularity. There is no need for Ruby anymore,” Jansen said. Ruby’s highest position was an eighth place ranking in May 2016.

Also in this month’s index, SQL, with a rating of 2%, and R, with a rating of 1.88%, swapped places in the top 10, with SQL now ranking eighth and R ninth. In addition, Swift re-entered the top 20 with a rating of 1.04%, while Kotlin fell to 22nd with a rating of .82%. And Google’s Dart language, once positioned as a rival to JavaScript, is on a path to sneaking back into the top 20. Dart ranked 25th this month with a rating of .69%.

The Tiobe Programming Community Index gauges language popularity based on a formula that assesses the number of skilled engineers worldwide, courses, and third-party vendors pertinent to a language. Popular websites such as Google, Amazon, Bing, Wikipedia, and more than 20 others are used to calculate the ratings.

In the bulletin accompanying this month’s index, Jansen addressed inquiries about switching from search engines to large language models (LLMs) to formulate the ratings. “The answer is no,” Jansen said. “The Tiobe index measures how many internet pages exist for a particular programming language. LLMs ultimately rely on the same sources—they are trained on and analyze these very same web pages. Therefore, in essence, there is no real difference.”

The Tiobe index top 10 for March 2025:

1. Python, 21.25%
2. C, 11.55%
3. C++, 8.18%
4. Java, 7.99%
5. C#, 6.36%
6. JavaScript, 3.45%
7. Visual Basic, 2.5%
8. SQL, 2%
9. R, 1.88%
10. Delphi/Object Pascal, 1.8%

The Pypl Popularity of Programming Language index gauges language popularity by analyzing how often language tutorials are searched on in Google. The Pypl index top 10 for March 2025:

1. Python, 34.87%
2. C/C++, 13.66%
3. Java, 9.82%
4. R, 6.49%
5. JavaScript, 6.49%
6. Swift, 3.5%
7. Rust, 3.08%
8. C#, 3.03%
9. PHP, 2.9%
10. Ada, 2.66%

Anthropic has launched a new marketplace for tools built on its Claude large language models (LLMs) that analysts say could help streamline procurement hurdles, which often slow the adoption of generative AI for enterprises.

Called Claude Marketplace, the platform currently has a limited set of partners, including Replit, Lovable Labs, GitLab, Snowflake, Harvey AI, and Rogo, offering tools across software development, legal workflows, financial analysis, and enterprise data operations, respectively.

“Most enterprises are not struggling to find capable models. They are struggling to operationalize them inside complex environments that already contain hundreds of applications, strict governance controls, and layered procurement processes,” said Sanchit Vir Gogia, chief analyst at Greyhound Research.

“Every new AI tool typically triggers security reviews, legal vetting, vendor onboarding, procurement approval, integration testing, and ongoing governance oversight. That process alone can delay deployment by months. The marketplace attempts to compress that operational friction,” Gogia added.

The billing for tools in the marketplace, which is charged against an enterprise’s existing committed spend on Claude, is also designed to help streamline procurement by eliminating the need for separate vendor contracts or payment processes.

“Historically, a company would need to negotiate separately with Anthropic and with Harvey or GitLab. Anthropic will manage all invoicing for partner spend, so it’s one contract, one invoice, one renewal conversation. For large enterprises where procurement cycles can take months, this is genuinely valuable,” said Pareekh Jain, founder of Pareekh Consulting.

Strategic lock-in and enterprise proliferation

Beyond simplifying procurement, however, Jain says there’s a deeper strategic play in Anthropic managing partner spend within the marketplace.

“Anthropic earns primarily through API consumption, so every partner application running on Claude generates token revenue. In that sense, the marketplace functions as a distribution engine rather than a toll booth, an approach similar to Amazon Web Services’ early ecosystem expansion, where lowering friction for partners accelerated adoption before deeper monetization,” Jain said.

The analyst added that managing marketplace billing also reflects a broader strategy of strengthening platform lock-in, echoing how Salesforce built its ecosystem around AppExchange and how Microsoft is expanding its footprint with Microsoft Copilot integrations.

“Anthropic is trying to deepen switching costs. Once an enterprise has committed to Anthropic spend and multiple partner tools running through Claude, migrating to another model becomes operationally difficult,” Jain said.

That dynamic, he added, could help Anthropic position itself as “the core AI commitment layer” inside enterprise budgets, increasing the likelihood of Claude becoming the primary line item rather than one of several separate AI tools.

Building a competitive edge

The marketplace may be Anthropic’s first step in creating an edge as competition among AI model makers grows.

“If tools like Harvey gain traction partly because they run on Claude within an existing Anthropic commitment, partners have incentives to stay aligned with Claude even as rival models improve, creating mutual lock-in,” Jain said.

This strategy, Greyhound Research’s Gogia said, will create a behavioral incentive for developers and startups to prioritize Claude integration if they want access to enterprise buyers participating in the marketplace, and over time, that dynamic can expand the partner ecosystem around the platform.

Channel conflict and narrative counterbalance

However, Gogia warned that Anthropic could be heading towards channel conflict.

“Anthropic is simultaneously building its own first-party AI tools while enabling third-party SaaS vendors to extend Claude capabilities through the marketplace,” Gogia said, referring to Claude Cowork and other plugins that triggered a sell-off among several SaaS stocks earlier this year as investors worried that native AI agents could begin encroaching on parts of the traditional software stack.

“The company must balance encouraging ecosystem innovation while ensuring that its own product roadmap does not compete directly with partner offerings,” Gogia added.

Furthermore, the analyst said that the launch of the marketplace is opportune for the company and can be seen as a “narrative counterbalance” to the imbroglio it is currently facing with the US Department of War, which has marked it as a supply chain risk.

“In practical terms, the marketplace demonstrates forward momentum in the enterprise segment. It signals that Anthropic continues to deepen relationships with enterprise software vendors and commercial customers even as the imbroglio unfolds,” Gogia said.

Last week, Anthropic CEO Dario Amodei himself, via a blog post, tried to reassure customers that the impasse with the DoW wouldn’t affect them.

When we shipped a new feature last quarter, it would have taken three months to build traditionally. It took two weeks. Not because we cut corners or hired contractors, but I fundamentally changed how we create user interfaces.

The feature was a customer service dashboard that adapts its layout and information density based on the specific issue a representative is handling. A billing dispute shows different data than a technical support case. A high-value customer gets a different view than a standard inquiry. Previously, building this meant months of requirements gathering, design iterations and front-end development for every permutation.

Instead, I defined my team to use generative UI: AI systems that create interface components dynamically based on context and user needs.

What does generative UI mean in reality?

The range of possibilities here is broad. On one end of the spectrum, developers use AI to generate code to build an interface more quickly. On the far end, interfaces are dynamically assembled entirely at runtime.

I lead and implemented an approach that exists somewhere in between. We specify a library of components and allowable layout patterns that define the constraints of our design system. The AI then chooses components from this library, customizes them based on context and lays them out appropriately for each unique user interaction.

The interface never really gets designed — it just gets composed on demand using building blocks we’ve already designed.

Applied to our customer service dashboard, we can feed information about the customer record, type of issue, support rep’s role and experience, and recent history into the system to assemble an interface tailor-made to be most effective for that situation. An expert rep assisting with a complex technical problem will see system logs and advanced troubleshooting tools. A new rep assisting with a basic billing inquiry will see simplified information and workflow guidance.

Both interfaces would look different but are assembled from the common library of components designed by our UI team.

The technical architecture

Our generative UI system has four layers, each with clear responsibilities.

Sreenivasa Reddy Hulebeedu Reddy

1. The component library layer: It contains all approved UI elements: cards, tables, charts, forms, navigation patterns and layout templates. This follows the principles of design systems. Each component has defined parameters, styling options and behavior specifications. This layer is maintained by our design system team and represents the visual and interaction standards for our applications.
2. The context analysis layer: Thisprocesses information about the current user, their task and relevant data. For customer service, this includes customer attributes, issue classification, historical interactions and representative profile. This layer transforms raw data into structured context that informs interface generation.
3. The composition engine layer: Hereis where AI enters the picture. Given the available components and the current context, this layer determines what to show, how to arrange it and what level of detail to present. We use a fine-tuned language model that has learned our design patterns and business rules through extensive examples.
4. The rendering layer: Ittakes the composition specification and produces the actual interface. This layer handles the technical details of turning abstract component descriptions into rendered UI elements.

How we built it

We built the generative UI system over the course of four months. The first step was building the component library. Our design team took an inventory of every UI pattern deployed across our customer service applications. 27 components in all, from simple data cards to interactive tables. Each component was parameterized based on what data to show, how to react to user input and how to adjust to screen sizes, among other properties. The result was our component library.

The context analysis layer then had to interface with three different backends. Our CRM, which stores information about customers, our ticketing system, which has details about issue classifications, and our workforce management system, which maintains representative profiles. Each of these systems required adapters that would funnel context data into a normalized context object that the composition engine could read.

Finally, for the composition engine, we performed “prompt tuning” on a language model with 2k demonstrations of how our designers mapped context to interface by hand. The model learned relations such as “complex technical issue + senior rep => detailed diagnostic view” without those explicit rules being programmed. Instead of hardcoding thousands of if/then statements, we were able to bake designer knowledge into the model.

The system is deployed onto our cloud architecture, which serves the UI with a latency of less than 200ms, making the generation process invisible to users.

Guardrails that make it enterprise-ready

Generative systems require constraints to be enterprise-ready. We learned this through early experiments where the AI made creative but inappropriate interface decisions that are technically functional but violate brand guidelines or accessibility standards.

Our guardrails operate at multiple levels. Design system constraints ensure every generated interface complies with our visual standards. The AI can only select from approved components and can only configure them within approved parameter ranges. It cannot invent new colors, typography or interaction patterns.

Accessibility requirements are non-negotiable filters. Every generated interface is validated against WCAG guidelines before rendering. Components that would create accessibility violations are automatically excluded from consideration.

Business rule constraints encode domain-specific requirements. Certain data elements must always appear together. Certain actions require specific confirmations. Customer financial information has display requirements regardless of context. These rules are defined by business stakeholders and enforced by the system.

Human review thresholds trigger manual approval for unusual compositions. If the AI proposes an interface significantly different from historical patterns, it’s flagged for designer review before deployment.

Where it works and where it doesn’t

Generative UI isn’t a universal solution. It excels in specific contexts and creates unnecessary complexity in others.

It works well for high-variation workflows where users face different situations requiring different information. Customer service, field operations and case management applications benefit significantly. It also works for personalization at scale, when you need to adapt interfaces for different user roles, experience levels or preferences without building separate versions for each.

It doesn’t make sense for simple, low-variation interfaces where a single well-designed layout serves all users effectively. A settings page or login screen doesn’t need dynamic generation. It’s also the wrong approach for highly regulated forms where the exact layout is mandated by compliance requirements like tax forms, legal documents or medical intake forms, should remain static and auditable.

The investment in building a generative UI system only pays off when interface variation is a genuine problem. If you’re building ten different dashboards for ten different user types, it’s worth considering. If you’re building one dashboard that works for everyone, stick with traditional methods.

Why this matters for enterprise development

Enterprise application development tends to follow a tried-and-true formula. Stakeholders express requirements. Designers mockup solutions. Developers implement interfaces. QA exercises the whole system. Repeat for each new requirement or variant context.

It’s a process that produces results. However, it doesn’t scale well and tends to be slow. Say we want to build a customer service application. Different issue types require different information views. Different customers may see different interfaces. Support reps may see different screens based on their role or channel of interaction. Manually designing and building every combination would take forever (and a lot of money). Instead, we settle, we build flexible but mediocre interfaces that reasonably accommodate every situation.

Generative UI eliminates this compromise. Once you’ve built the system, the cost of adding a new variant of the UI becomes negligible. Rather than picking ten use cases to design perfectly for, we can accommodate hundreds.

In our case, the business results were profound. Service reps spent 23% less time scrolling through screens to find the info they needed. First call resolution increased by 8%. Reps gave higher satisfaction ratings because they felt like the software was molded to their needs instead of forcing them into a one-size-fits-all process.

Organizational implications

Adopting generative UI changes how design and development teams work.

Designers shift from creating specific interfaces to defining component systems and composition rules. This is a different skill set that needs more systematic thinking, more attention to edge cases, more collaboration with AI systems. Some designers find this liberating; others find it frustrating. Plan for change management.

Developers focus more on infrastructure and less on UI implementation. Building and maintaining the generative system requires engineering investment, but once operational, the marginal effort per interface variation drops dramatically. This frees developer capacity for other priorities.

Quality assurance becomes continuous rather than episodic. With dynamic interfaces, you can’t test every possible output. Instead, you validate the components, the composition rules and the guardrails. As Martin Fowler notes about testing strategies, QA teams need new tools and methodologies for this kind of testing.

How to adopt generative UI

My advice to IT leaders evaluating generative UI is to start small with a pilot program to prove value before scaling across your organization. Find a workflow with high variability that has measurable results. Turn on generative UI for that single use case. Measure the impact to user productivity, satisfaction and business outcomes. Leverage those results to secure further investment.

Focus on your component library before enabling dynamic composition. The AI can only create great experiences if it has great building blocks. Focus on design system maturity before you prioritize generative features.

Define your guardrails up front. The guardrails that will make your generative UI solution enterprise-ready are not an afterthought. They’re requirements. Build them in lockstep with your generative features.

The future looks bright

The move from static interfaces to generative interfaces is really just one example of a larger trend we’re starting to see play out across enterprise software: The gradual shift from “static” technology designed for the most-common use cases upfront to dynamic technology that can adapt to the user’s context as they need it.
We’ve already started to see this play out with search, recommendations and content. UI is next.

For forward-looking enterprises that are willing to put in the upfront work to create robust component libraries, establish governance frameworks and build thoughtful AI integrations, Generative UI can enable applications that work for your users, instead of the other way around.

And that’s not just an incremental improvement in efficiency. That’s a whole new way of interacting with enterprise software.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Large language models (LLMs) and AI agents aren’t important to software engineering because they can write code at superhuman speeds. Without the right guardrails, as I’ve highlighted, that speed simply translates into mass-produced technical debt. No, agentic coding matters because it fundamentally changes what counts as good software engineering.

For years, developers could get away with optimizing for personal taste. If a framework fit your brain, if a workflow felt elegant, if a codebase reflected your particular theory of how software ought to be built, that was often enough. The machine would eventually do what you told it to do. Agents change that equation. They don’t reward the cleverest workflow. They reward the most legible one and, increasingly, the one that is optimized for them. This may seem scary but it’s actually healthy.

Just ask Hamel Husain.

Speaking to machines

It’s not hard to find know-it-all Hacker News developers with strong opinions on exactly what everyone should be using to build. Husain, however, is different. When he blogged about nixing his use of nbdev, he wasn’t walking away from some random side project. He was dumping his project, something he helped build and spent years championing. The reason? It wasn’t AI-friendly. “I was swimming upstream,” he notes, because nbdev’s idiosyncratic approach was “like fighting the AI instead of working with it.” Instead, he says, he wants to work in an environment where AI has “the highest chance of success.” He’s building according to what the machines like, and not necessarily what he prefers. He won’t be alone.

Developers have always liked to imagine tools as a form of self-expression. Sometimes they are. But agents are making tools look a lot more like infrastructure. Husain says Cursor won because it felt familiar, letting developers change habits gradually instead of demanding a new worldview on day one. That sounds a lot like the argument I made in “Why ‘boring’ VS Code keeps winning.” Familiarity used to matter mostly because humans like low-friction tools. Now it matters because models do, too. A repo layout, framework, or language that looks like the training distribution gives the model a better shot at doing useful work. In the agent era, conformity isn’t capitulation. It’s leverage.

GitHub’s latest Octoverse analysis makes the point with data. In August 2025, TypeScript overtook both Python and JavaScript as the most-used language on GitHub. GitHub’s reasoning is that AI compatibility is becoming part of technology choice itself, not just a nice bonus after the choice is made. It also reports that TypeScript grew 66% year over year and explains why: Strongly typed languages give models clearer constraints, which helps them generate more reliable, contextually correct code. As Husain says of his decision to eschew a Python-only path to use TypeScript, “typed languages make AI-generated code more reliable in production.”

That doesn’t mean every team should sprint into a TypeScript rewrite, but it does mean the case for quirky, under-documented, “trust me, it’s elegant” engineering is getting weaker. Agents like explicitness. They like schemas. They like guardrails.

In short, they like boring.

Engineering economics 101

This is the deeper change in software engineering. The agent story isn’t really about code generation. It’s about engineering economics. Once the cost of producing code drops, the bottleneck moves somewhere else. I’ve explained before that typing is never the real constraint in software engineering. Validation and integration are. Agents don’t remove that problem; instead, they make output cheap and verification expensive, which reorders the entire software development life cycle.

The best public evidence for that comes from two very different places. Or, rather, from their seeming contradictions.

The first is a METR study on experienced open source developers. In a randomized trial, developers using early-2025 AI tools took 19% longer to complete issues in repositories they already knew well, all while thinking they’d actually gone faster. Contrast this with OpenAI’s recent “harness engineering” essay, where the company says a small team used Codex to build roughly a million lines of code over five months and merge around 1,500 pull requests. These results seem superficially at odds until you realize that METR’s survey measured naive use of AI, whereas OpenAI’s example shows what happens when a team redesigns software development for agents, rather than simply sprinkling agentic pixie dust on old workflows.

In OpenAI’s experiment, engineers were no longer asked to write code. Instead they were told their primary job was to “design environments, specify intent, and build feedback loops” that allowed agents to do reliable work. Over the course of the pilot, they found that they’d initially underspecified the environment the agents would operate in, but they eventually shifted to a focus on creating systems in which generated code can be trusted.

Of course, this means that AI-driven coding requires just as much human intervention as before. It’s just a different kind of intervention.

This is playing out in the job market even as I type this (and yes, I wrote this post myself). Kenton Varda recently posted: “Worries that software developer jobs are going away are backwards.” He’s directionally right. If agents lower the cost of building software, the likely effect will be more software, not less. As he intimates, we’ll see more niche applications, more internal tools, and more custom systems that previously weren’t worth the effort. Indeed, we’re seeing the software developer job market significantly outpace the overall job market, even as AI allegedly comes to claim those jobs.

It’s not. We still need people to steer while the agents take on more of the execution.

Inspecting the agents

This is where Husain’s focus on evals becomes so important. In his LLM evals FAQ, he says the teams he’s worked with spend 60% to 80% of development time on error analysis and evaluation. He’s also written one of the clearest summaries I’ve seen of how agent-era software development works: Documentation tells the agent what to do, telemetry tells it whether it worked, and evals tell it whether the output is good. Anthropic says much the same thing in its Best Practices for Claude Code, saying the “single highest-leverage thing” you can do is give the model a way to verify its own work with tests, screenshots, or expected outputs.

This also changes what a repository is. It used to be a place where humans stored source code and left a few breadcrumbs for other humans. Increasingly it’s also an operating manual for agents. OpenAI says Codex started with an AGENTS.md file but then learned that one giant agent manual quickly becomes stale and unhelpful. What worked better was treating AGENTS.md as a short map into a structured in-repo knowledge base. That is a very agent-native insight. Build commands, test instructions, architecture notes, design docs, constraints, and non-goals are no longer ancillary documentation. They are part of the executable context for development itself.

More bluntly? Context is now infrastructure.

So many teams are about to discover that their software practices are worse than they thought. Undocumented scripts, magical local setup, flaky tests, tribal-knowledge architecture, vague tickets, inconsistent naming, and “every senior engineer does it a little differently.” Humans just learned to absorb it. Agents expose this silliness immediately. An underspecified environment doesn’t create creativity; it creates garbage. If you drop an agent into a messy codebase and it flails, that’s not necessarily an indictment of the agent. Often it’s a very efficient audit of your engineering discipline. The repo is finally telling the truth about itself.

Which is why I’d now say that my suggestion that AI coding requires developers to become better managers was true, if incomplete. Yes, developers need to become better managers of machines. But more importantly, they need to become better engineers in the old-fashioned sense: better at specifications, boundaries, “golden paths,” etc. The agent era rewards discipline far more than cleverness, and that’s probably overdue.

So no, the big story of coding agents isn’t that they can write code. Plain chatbots could already fake that part. The big story is that they are changing what competent software engineering looks like. Agents reward exactly the things developers have long claimed to value but often avoided in practice: explicitness, consistency, testability, and proof. In the age of agents, boring software engineering doesn’t just scale better, it does most everything—collaboration, debugging, etc.—better.

Everyone working on artificial intelligence these days fears the worst-case scenario. The precocious LLM will suddenly glide off the rails and start spouting dangerous thoughts. One minute it’s a genius that’s going to take all our jobs, and the next it’s an odd crank spouting hatred, insurrection, or worse.

Fortunately, there are solutions. Some scientists are building LLMs that can act as guardrails. Yes, adding one LLM to fix the problems of another one seems like doubling the potential for trouble, but there’s an underlying logic to it. These new models are specially trained to recognize when an LLM is potentially going off the rails. If they don’t like how an interaction is going, they have the power to stop it.

Of course, every solution begets new problems. For every project that needs guardrails, there’s another one where the guardrails just get in the way. Some projects demand an LLM that returns the complete, unvarnished truth. For these situations, developers are creating unfettered LLMs that can interact without reservation. Some of these solutions are based on entirely new models while others remove or reduce the guardrails built into popular open source LLMs.

Here’s a quick look at 19 LLMs that represent the state-of-the-art in large language model design and AI safety—whether your goal is finding a model that provides the highest possible guardrails or one that just strips them all away.  

Safer: LLMs with guardrails

The models in this category emphasize the many dimensions of AI safety. Whether you are looking for an LLM built for sensitive topics, one with a strong ethical compass, or a model capable of recognizing hidden exploits in seemingly innocent prompts, the heavily guarded models in this list could have you covered.

LlamaGuard

The developers of the various LlamaGuard models from Meta’s PurpleLlama initiative fine-tuned open source Llama models using known examples of abuse. Some versions, like Llama Guard 3 1B, can flag risky text interactions using categories like violence, hate, and self-harm in major languages including English and Spanish. Others, like Llama Guard 3 8B, tackle code interpreter abuse, which can enable denial of service attacks, container escapes, and other exploits. There are close to a dozen LlamaGuard versions that extend the base Llama models already. It also looks like Meta will continue researching ways to improve prompt security in foundation models.

Granite Guardian

IBM built the Granite Guardian model and framework combination as a protective filter for common errors in AI pipelines. First, the model scans for prompts that might contain or lead to answers that include undesirable content (hate, violence, profanity, etc.). Second, it watches for attempts to evade barriers by hoodwinking the LLM. Third, it watches for poor or irrelevant documents that might come from any RAG database that’s part of the pipeline. Finally, if the system is working agentically, it evaluates the risks and benefits of an agent’s function invocations. In general, the model generates risk scores and confidence levels. The tool itself is open source, but it integrates with some of the IBM frameworks for AI governance tasks like auditing.

Claude

As Anthropic built various editions of Claude, it created a guiding list of ethical principles and constraints that it started calling a constitution. The latest version was mainly written by Claude itself, as it reflected upon how to enforce these rules when answering prompts. These include strict prohibitions on dangerous acts like building bioweapons or taking part in cyberattacks as well as more philosophical guidelines like being honest, helpful, and safe. When Claude engages with users, it tries to stay within the boundaries defined by the constitution it helped to create.

WildGuard

The developers of Allen Institute for AI’s WildGuard started with Mistral-7B-v0.3 and used a combination of synthetic and real-world data to fine-tune it for defending against harm. WildGuard is a lightweight moderation tool that scans LLM interactions for potential problems. Its three functions are to identify malicious intent in user prompts; detect safety risks in model responses; and determine the model refusal rate, or how often a model declines to answer. This can be useful for tuning the model to be as helpful as possible while remaining within safe bounds.

ShieldGemma

Google released a series of open weight models called ShieldGemma, which the company uses to block problematic requests. ShieldGemma 1 comes in three sizes (2B, 9B, and 27B) for classifying text input and output. ShieldGemma 2 blocks requests for images that are flagged as sexually explicit, harmful, violent, or for contain excessive blood and gore. The visual classifier tool can also be run in reverse to produce adversarial images, which are used to enhance the model’s ability to detect content that may violate the image safety policy.

NeMo Guardrails

Nvidia’s Nemotron collection of open source models includes a version, Nemotron Safety Guard, that acts as a gatekeeper by scanning for jailbreaks and dangerous topics. It can run on its own or integrate with NeMo Guardrails, a programmable protection system that can be revised and extended with traditional and not-so-traditional techniques. Developers can use Python to add specific “actions” for the model to use, or to provide patterns and structured examples that guide model behavior. Regular guardrails may halt a conversation at the hint of something undesirable. Ideally, the model can steer the conversation back to something productive.

Qwen3Guard

This multilingual model from Qwen comes in a variety of combinations to block unwanted behavior in your dataflows. Qwen3Guard-Gen works in a traditional question-and-answer format with prompts and responses. Qwen3Guard-Stream has a slightly different architecture that’s optimized for token-level filtering in real-time streams. Both come in a few sizes (0.6B, 4B, and 8B) to optimize the tradeoff between performance and protection. Qwen developers also built a special version of the 4B, Qwen3-4B-SafeRL, which was enhanced with reinforcement learning to maximize safety and user experience.

PIGuard

The PIGuard model focuses on defending against prompt injection, the type of malicious attack that can be challenging to prevent without being overly paranoid. It watches for covert suggestions that might be hidden inside the prompt. PIGuard’s developers trained the model by building a special training set called NotInject, which uses examples of false positives that might trick a less capable model.

PIIGuard

Not to be confused with PIGuard, this completely different model is aimed at flagging personally identifiable information (PII) in a data stream. This ensures an LLM won’t mistakenly leak someone’s address, birthday, or other sensitive information when responding to prompts. The PIIGuard model is trained on examples that teach it to detect PII that’s embedded in a conversation or a long text stream. It’s a step up from standard detectors that use regular expressions and other more basic definitions of PII structure.

Alinia

The guardrails from Alinia apply to wider range of potentially troublesome behaviors. The model covers standard issues like illegal or dangerous behaviors but is also trained to avoid the legal tangles that may follow giving medical or tax advice. This LLM guardrail also can detect and refuse irrelevant answers or gibberish that may hurt an organization’s reputation. The Alinia system relies on a RAG-based database of samples so it can be customized to block any kind of sensitive topic.

DuoGuard

Sometimes it’s hard for AI developers to find a large enough training set with all the examples of bad behavior required. The DuoGuard models were built with two parts: Part one generates all the synthetic examples you need, and part two boils them all down to a model. The model is smart, small, and quick, and can detect issues in 12 risk categories, including violent crime, weapons, intellectual property, and jailbreaking. DuoGuard comes in three tiers (0.5b, 1.0b, and 1.5b) to serve all levels of need.

Looser: LLMs with fewer guardrails

LLMs in this category aren’t completely without guardrails, but they’ve been built—or in many cases, retrained—to favor freedom of inquiry or expression over safety. You might need a model like this if you are looking for novel approaches to old problems, or to find the weak points in a system so that you can close them up. Models with lower guardrails are also favored for exploring fictional topics or for romantic roleplay.

Dolphin models

Eric Hartford and a team at Cognitive Computations built the Dolphin models to be “uncensored.” That is, they stripped away all the guardrails they could find in an open source foundation model by removing many restricting questions and answers from the training set. If the training material showed bias or introduced reasons to refuse to help, they deleted it. Then, they retrained the model and produced a version that will answer a question any way it can. They’ve so far applied this technique to a number of open source models from Meta and Mistral.

Nous Hermes

The Hermes models from Nous Research were built to be more “steerable”—meaning they aren’t as resistant as some models are to delivering answers on demand. The Hermes model developers created a set of synthetic examples that emphasize helpfulness and unconstrained reasoning. The training’s effectiveness is measured, in part, with RefuseBench, a set of scenarios that test helpfulness. The results are often more direct and immediately useful. The developers noted, for instance, that “Hermes 4 frequently adopted a first-person, peer-like persona, generating responses with fewer meta-disclaimers and more consistent voice embodiment.”

Flux.1

The Flux.1 model was designed to create images by following as strictly as possible any prompt instructions. Many praise its rectified flow transformer architecture for producing excellent skin tones and lighting in complex scenes. The model can be fine-tuned for applications that require a particular style or content using low-rank adaptation (LoRA). Flux.1 is available under an open source license for non-commercial use. Any commercial deployment requires additional licensing.

Heretic

Heretic lowers the guardrails of existing LLMs by stripping away their defenses. It starts by tracking how the residual vectors behave on two different training sets with harmful and non-harmful examples. It then zeros out the key weights, effectively removing whatever restrictions were built into the original model. The tool is automated, so it’s not hard to apply it to your own model. Or, if you prefer, you can get one that’s been pre-treated. There’s a version of Gemma 3, and another of Qwen 3.5.

Pingu Unchained

Audn.ai built Pingu as a tool for security researchers and red teams who need to ask questions that mainstream LLMs are trained not to answer. To create this model, developers fine-tuned OpenAI’s GPT-OSS-120b with a curated collection of jailbreaks and other commonly refused requests. The resulting model is handy for generating synthetic tests of spear-phishing, reverse engineering, and the like. The tool keeps an audit trail of requests and Audn.ai limits access to verified organizations.

Cydonia

TheDrummer created Cydonia as part of a series of models for immersive roleplay. That means long context windows for character consistency and uncensored interactions for exploring fictional topics. Two versions (22b v1.2 and 24b v4.1) have been built by fine-tuning Mistral Small 3.2 24B. Some call the model “thick” for producing long answers rich with plot details.

Midnight Rose

Midnight Rose is one of several models built by Sophosympatheia for romantic roleplay. The model was developed by merging at least four different foundation models. The idea was to create an LLM capable of building stories with strong plots and emotional resonance, all in an uncensored world of fictional freedom.

Abliterated: LLMs off the rails

A few labs are opening up models by deactivating the guardrail layers directly instead of retraining them for a looser approach. This technique is often called abliteration, a portmanteau combining “ablation” (removal) and “obliterate” (destruction). The developers identify the layers or weights that operate as guardrails by testing the models with a variety of problematic prompts, then deactivate them by zeroing out their contributions in model responses. These models have at times outperformed their foundational versions on various tasks.

Grok

Good examples in this category come from HuiHui AI and David Belton, but the most famous model of this type is Grok. Rather than being concerned about creating a model that behaves badly, the Grok team at X is more concerned with factual errors. Or, as Elon Musk said in an interview: “The best thing I can come up with for AI safety is to make it a maximum truth-seeking AI, maximally curious.” In other words, Grok was designed for factual correctness, not political correctness, whatever your definition of politics might be.

Microsoft’s official C# SDK for implementing Model Context Protocol (MCP) servers and clients has reached its 1.0 milestone release. The update brings full support for the 2025-11-25 version of the MCP Specification, highlighted by enhanced authorization server discovery and icon metadata for tools, resources, and prompts.

MCP C# SDK 1.0 was unveiled March 5 and can be found on GitHub. The MCP C# SDK 1.0 release represents a major step forward for building MCP servers and clients in .NET, according to Microsoft. Developers can use the SDK to implement secure authorization flows, build rich tool experiences with sampling, or handle long-running operations, the company said.

With authorization server discovery in the 2025-11-25 MCP specification, servers have three ways to expose the Protected Resource Metadata (PRM) document: via a “well-known” URL derived from the server’s MCP endpoint path, at the root well-known URL, and, as before, via a URL in the resource metadata parameter of the WWW-Authentication header.

The 2025-11-25 specification also adds icon metadata to tools, resources, and prompts. This information is included in the response to tools/list, resources/list, and prompts/list requests. Implementation metadata (describing a client or server) also has been extended with icons and a website URL.

The 2025-11-25 specification features Client ID Metadata Documents (CIMDs) as an alternative to Dynamic Client Registration (DCR) for establishing client identity with an authorization server. CIMD now is the preferred method for client registration in MCP.

Another capability in the 2025-11-25 specification is that servers now can include tools in their sampling requests, which the large language model (LLM) may invoke to produce a response. This is one of the most powerful additions in the specification, Microsoft said.

For running requests over HTTP with polling, the 2025-11-25 specification improves the story for long-running requests. Previously, clients could disconnect and reconnect if the server provided an event ID in server-sent events, but few servers implemented this. Now, servers that open a server-sent event stream for a request begin with an empty event that includes an event ID and optionally a retry-after field. After sending this initial event, servers can close the stream at any time, since the client can reconnect using the event ID.

Finally, MCP C# SDK 1.0 introduces tasks, an experimental feature of the 2025-11-25 MCP specification that provides durable state tracking and deferred result retrieval for MCP requests.

The JavaScript innovation train is really picking up momentum lately, driven—as always—by the creativity of the JavaScript developer community. The emerging local-first SQL datastores crystalize ideas about client/server symmetry that have been a long time coming. WinterTC is bringing us closer to truly universal, isomorphic JavaScript, aka “write once, run anywhere” for client- and server-side JS. Reactive signals, another influential idea for modern front-end development, continues to draw more JavaScript frameworks into its orbit. And, finally, a compelling alternative to NPM is emerging in the new JavaScript Registry.

If that’s not enough, a once-abandoned idea for bridging Java and JavaScript is showing new life, and Deno has been kicking up dust again. Here’s the latest roundup of the most compelling news in JavaScript.

Top picks for JavaScript readers on InfoWorld

The browser is your database: Local-first comes of age
The thick client is dead.  Long live the thick client! By leveraging next-gen local databases like PGlite and RxDB, developers are building feature-rich, resilient data storage directly into the browser. This shift toward local-first architecture reduces latency, simplifies offline capabilities, and fundamentally changes how we think about state. But will it unseat JSON and REST?

WinterTC: Write once, run anywhere (for real this time)
Truly universal, isomorphic JavaScript is becoming more real. WinterTC is working to standardize server-side JavaScript execution, ensuring that whether you are deploying to Node, Deno, Cloudflare Workers, or Bun, your code behaves consistently across all environments.

Reactive state management with JavaScript Signals
State management remains one of the nastiest parts of front-end development. Signals have emerged as the dominant mechanism for dealing with reactive state, offering a more fine-grained and performant alternative to traditional Virtual DOM diffing. Many frameworks are drawing on this paradigm, so it’s an important primitive to understand.

Beyond NPM: What you need to know about JSR
NPM, the Node Package Manager, is a workhorse, one of the main reasons Node (and server-side JavaScript) became a global superstar.  But NPM has its shortcomings, especially for package developers. Now JSR (the JavaScript Registry) has stepped in to address those limitations, offering built-in TypeScript support, more secure, modern approach to module distribution, and an ingenious bridge between CommonJS and ESM. JSR also works seamlessly with your existing NPM-based build, so there is zero friction to adopting it.

More good reads and JavaScript updates elsewhere

Deno Deploy reaches GA
Deno’s newly minted deploy infrastructure transforms it to a full-blown, general-purpose edge deployment platform, similar in spirit to Vercel or Netlify. This is a seriously interesting development. Deno Deploy also incorporates a data layer, moving it toward a full-stack platform. It also includes sandboxing especially designed for AI-generated code safety using built on, ultra-fast start/stop microVMs. This is a must-read and fascinating moves from Deno and Node creator Ryan Dahl.

ESLint v10 drops .eslintrc for good
This move marks the final passing of the cascading hierarchy mode of .eslintrc (and relations). The “flat file” config, where there is one source of truth for the whole project is now the only way forward. This is especially important to know because any existing app still using the old-style configuration will break when updated to v10.

In 2026, most enterprises I talk to are multicloud, not because they set out with a crisp strategy but because reality pushed them there. Mergers and acquisitions bring in workloads on different platforms. Product teams pick the cloud that best matches a short-term delivery deadline. Add leadership mandates to “avoid lock-in,” and suddenly you have three primary providers in play, whether you meant to or not.

The most common combination is AWS, Microsoft, and Google, with some mix of SaaS and a remaining on-prem footprint that still matters more than people admit. On paper, this sounds like options and resilience. In practice, it often looks like three separate technology estates sharing a logo on a PowerPoint slide.

The first uncomfortable truth: Multicloud adoption has outpaced multicloud operational maturity. Enterprises are using multicloud, but they’re not running multicloud.

Many clouds equal many silos

Enterprises keep operationalizing each cloud as a standalone silo because that is the path of least resistance. Each cloud has its own native console, identity patterns, network constructs, policy models, logging stacks, and security services. Each cloud also has its own culture and certification ecosystem, which encourages specialization rather than commonality.

In this situation, organizations split along predictable lines. They build different talent pools for each cloud. They buy different tool sets for each cloud. They fund different groups inside the company to “own” each cloud. In many cases, they even create separate centers of excellence or platform teams that don’t coordinate beyond a quarterly steering committee.

This creates duplication, inconsistent controls, and an uneven security posture. It also creates a budgeting illusion: Each silo optimizes locally while the enterprise loses money globally through redundant platforms, parallel processes, and repeated mistakes. Worse, the business experiences multicloud as friction, not freedom, because delivery speed and reliability become dependent on which silo you landed in.

If you want a simple diagnostic, ask how many ways your company provisions infrastructure, grants access, enforces policy, tags costs, responds to incidents, and produces audit evidence across AWS, Azure, and Google Cloud. If the answer is three, you don’t have a multicloud operating model. You have three cloud programs.

Find common operational ground

The only reason to pay the complexity tax of multicloud is to gain something you cannot get any other way. That “something” is the ability to leverage best-of-breed cloud capabilities where they truly matter, without multiplying operational overhead every time you adopt a new service or move a workload.

This is where enterprises lose the plot. They treat multicloud as a procurement choice instead of an operating design. They assume that if workloads can run on different clouds, they are therefore portable, and portability will magically create leverage. But portability without operational commonality just moves the mess around.

Operational commonality means you intentionally define what must be consistent across cloud brands, and you implement it as shared services and shared processes. You do not need identical architectures everywhere, and you certainly should not force every workload into the same mold. However, you do need a consistent way to operate, govern, and secure what you run.

That typically means common control planes for operations, governance, security, and other cross-cutting services where it does not make sense to maintain separate technology stacks inside each cloud silo. If your incident response workflow, policy-as-code approach, access model, cost allocation scheme, and baseline security telemetry differ wildly by provider, you are paying three times for capabilities that should be enterprisewide.

In mature organizations, cloud choice becomes a product decision, not an operational reinvention. The platform stays consistent enough that teams can exploit a specialized database, AI service, or analytics engine in the cloud where it fits best, while still falling under the same guardrails and operational expectations. That is the point of multicloud: controlled optionality, not uncontrolled variety.

Common control planes

Common control planes are not a single magical tool you buy. They are a set of enterprise capabilities that sit above or alongside native cloud services and enforce a consistent operating model. They include standardized identity and access patterns that work across providers, a unified approach to policy enforcement, consolidated observability, and repeatable delivery pipelines that encode compliance and security requirements from the start.

They also include governance that is concrete rather than aspirational. Governance should not be a document that says “teams must follow best practices.” It should be an implementation: guardrails, templates, controls, automated checks, and a clear exception process with accountability.

Yes, you will still use native services. The goal is not to deny that AWS, Azure, and Google Cloud have different strengths. The goal is to stop letting those differences fracture your enterprise into incompatible operating units. You want teams to innovate at the product layer, not rebuild the same operational foundations three times.

Three moves to make now

First, do advanced planning that starts with an operating model, not a cloud road map. That means defining which capabilities must be common across all clouds and designing them as shared platform services: identity, logging, security baselines, cost governance, configuration standards, incident management, and change control. It also means deciding where you will tolerate divergence because the business benefit is real, measurable, and worth the complexity. Multicloud planning fails when it is just a list of services to adopt; it succeeds when it forms a clear blueprint for how the enterprise will run and control what it builds.

Second, establish common coordination between the groups that currently operate as separate cloud factions. You need a single forum with authority that aligns standards, funds shared services, and resolves conflicts quickly, but you also need day-to-day mechanisms that prevent drift. Shared backlog, shared architecture patterns, shared site reliability engineering (SRE) practices, and shared security engineering are more important than a shared slide deck. The aim is not to create bureaucracy; it is to ensure that the enterprise can learn once and apply everywhere, rather than relearning the same lessons in parallel.

Third, define the ultimate business value of managing multicloud well, and then measure it relentlessly. If multicloud is justified by resilience, then measure recovery objectives and incident impact across clouds. If it is justified by speed, measure cycle time and deployment frequency, independent of provider. If it is justified by cost leverage, measure unit economics and the reduction of duplicated tools and labor. Without an explicit value model, multicloud becomes an expensive hobby; with one, it becomes an enterprise capability that earns its keep.

Multicloud in 2026 is not failing because the clouds aren’t powerful enough. It’s failing because enterprises keep treating it as three separate journeys instead of one coherent destination.

The Rust team has unveiled Rust 1.94. This release adds an array windows capability as an iterating method for the Rust slice type as well as improved management of Cargo configurations.

Rust 1.94 was announced March 5. Developers using a previous version can upgrade via rustup by running rustup update stable.

The array_windows method works just like windows but with a constant length, so iterator items are &[T; N] rather than dynamically-sized &[T]. In many cases, the window length may be inferred by how the iterator is used. Slices let developers reference a contiguous sequence of elements in a collection.

Cargo, the Rust package manager, now supports the include key in configuration files (.cargo/config.toml), for better organization, sharing, and management of Cargo configurations across environments and projects. These include paths may be marked optional if they might not be present in some circumstances.

Cargo now parses TOML v1.1 for manifests and configuration files. TOML, for Tom’s Obvious, Minimal Language, is intended to be a minimal configuration file format that is easy to read due to obvious semantics. Changes in TOML 1.1 include inline tables across multiple lines and with trailing commas, \xHH and \e string escape characters, and optional seconds in times. Using these features in Cargo.toml will raise development MSRV (minimum supported Rust version) to require the new Cargo parser, and third-party tools that read the manifest may also need to update their parsers. However, Cargo automatically rewrites manifests on publish to remain compatible with older parsers, so it is still possible to support an earlier MSRV.

Rust 1.94 also stabilizes 17 APIs. This month’s Rust release follows the January 22 release of Rust 1.93, which improved operations involving the DNS resolver for the musl implementation of the C standard library.

Microsoft has released Visual Studio Code 1.110, an update of the popular code editor that makes agents practical for long-running and more complex tasks by giving developers new ways to extend agents, smarter session management, and more visibility and control, the company said.

Introduced March 4, VS Code 1.110, also known as the February 2026 release, can be downloaded for Windows, Linux, or macOS at code.visualstudio.com.

Agent plugins, a preview feature, are prepackaged bundles of chat customizations that can be installed from plugin marketplaces. A plugin can provide a combination of slash commands, Model Context Protocol (MCP) servers, agent skills, custom agents, and hooks, Microsoft said.

Agentic browser tools, an experimental feature, provides agents with a set of tools to read and interact with VS Code’s integrated browser. When an agent interacts with a web page, it sees updates to page content and any warnings and errors in the console. The tools work out of the box with no need to install extra dependencies, according to Microsoft.

An agent debug panel, a preview feature, shows chat events in real time, including chat customization events, system prompts, and tool calls. Developers can see which prompt files, skills, hooks, and other customizations are loaded for a session. This replaces the old Diagnostics chat action with a richer, more detailed view, Microsoft said.

VS Code 1.110 follows the February 2025 release of VS Code. 1.109, which also featured agent enhancements.

Additional highlights in VS Code 1.110 include the following:

• Users now can generate agent customization files directly from a chat conversation by using new /create-* slash commands in agent mode.
• Plans created by the Plan agent now persist to session memory and stay available across conversation turns.
• Context compaction lets users manually compact conversation history to free up context space.
• For chat accessibility, developers can use chat to its fullest with screen reader improvements, notification signals, and keyboard navigation.
• The VS Code terminal now supports the Kitty graphics protocol for high-fidelity image rendering directly in the terminal. Programs that support this protocol can transmit and display images with a rich set of capabilities such as display layout, image management, and cursor control, Microsoft said.
• To prepare for upcoming TypeScript 6.0 and 7.0 releases, built-in JavaScript and TypeScript setting IDs have been consolidated.

Prototyping is my favorite part of programming. I like building new stuff and getting things working. It’s no surprise, then, that I am a big fan of MongoDB and NoSQL in general. Don’t get me wrong: I’ve always appreciated SQL for what it is. The intoxicating smoothness of using MongoDB in JavaScript just swept me off my feet.

Led by the dynamic PostgreSQL team, SQL has recently orchestrated an incredible comeback. It’s never stopped being at the heart of enterprise data. But now it is both the traditional choice and on the list of exciting tech to watch. How did that happen?

The making of an SQL comeback

It all started when SQLite, the lightweight relational database, brought SQL into the browser. SQL in the browser enabled a new architecture built on client-side back-end syncing, where SQL, and not JSON, was the hinge. Language tools played along, making it more comfortable to use SQL from any platform. The well-understood predictability of the relational architecture continued its long game of quietly winning converts, then PostgreSQL topped it off with the new schemaless jsonb type.

And that’s how it happened: Just when you thought it was dead, SQL became cool again.

The myth of ‘schemaless’

The thing that makes NoSQL in JavaScript so alluring is that you don’t have to leave the language paradigm in order to think about or manage your database structure, the schema. If you want to insert some new type while you are coding, you just do something like this:

await db.collection('cats').insertOne({ name: 'Fluffy', mood: 'Judgmental' });

Even if db.cats doesn’t exist yet, the store will create it for you. It’s the same with the data “shape” (name and mood). And best of all, you can just shove the JSON object right in there.

This appears to be the holy grail of frictionless data: The database and the code both speak JSON. You don’t have to stop to write a CREATE TABLE statement. You don’t have to run a migration script. You don’t have to think about the data; you just create what you need, on the fly, and the datastore accommodates.

But as our prototypes mature into production systems, we discover an uncomfortable truth: The schema is still there, but now it’s in our code. It’s implicit, and it looks like this:

if (cat && cat.mood && typeof cat.mood === 'string')

Or, if you like:

const mood = cat?.mood ?? 'neutral';

The code now enforces the schema. This is an ongoing, systemic fact of life in the schemaless world. Of course, even in a strict schema, you are doing this kind of thing for validation (whether in code or with a validation framework), but the true consistency-of–record is preserved in the database itself.

The pressure of building out a large system without strong consistency causes real anxiety. What developers really want is strong data integrity with low friction. And now, three trends have converged to make that possible with SQL:

• SQL on the front end with syncing
• Better SQL clients
• SQL with schemaless types (JSONB)

The first is bold and new; the second is plain old engineering; the last is evolutionary adaptation.

Let’s take a closer look.

SQL on the front end

The first solution involves a radical rethinking of where the database lives. For 30 years, the database was a lumbering monster locked in the server room. The browser was just a silent terminal that begged for data from APIs.

But thanks to WebAssembly (WASM), we can now run the actual database engine right inside the browser. Technologies like PGlite (PostgreSQL in WASM) and SQLite (via standardized browser builds) have transformed the database to a client-side technology.

The move to the front end also sparked the rise of serverless SQL for analytics and edge computing. Tools like DuckDB let developers crunch millions of rows of analytical data on the user’s device or at the edge, all without needing a massive cloud warehouse.

This development by itself would be interesting but not earth shattering, except for the introduction of syncing technologies like ElectricSQL. Syncing is an idea that has been around in projects like PouchDB in the NoSQL world, but now it’s catching on with SQL. Syncing lets us use the same datastore in the browser (or a portion of it) and the server, and the syncing engine automatically handles the negotiation.

Syncing also opens up the potential of a local-first database architecture. Instead of writing complex API endpoints (GET /cats, POST /cats) and loading spinners, your front-end code just talks to its local database.

You INSERT a record locally, and it happens instantly. Then, a background sync engine (like ElectricSQL or Replicache) handles the messy work of getting that data to the server. The API layer is eliminated entirely.

Of course, the shift to local-first requires serious mental rejiggering and also has architectural implications. But locating a relational database directly in the browser raises the prospect of SQL as the new universal data language.

Better SQL clients

The second factor is down to engineering hard work; in this case, long years of consistent iteration on database clients.

It turns out, much of SQL’s reputation as a clunky old technology was actually an inadequate tooling problem. Regardless of the language used, writing SQL meant concatenating strings or wrestling with heavy, magical ORMs.

Although ORM tools like Hibernate/JPA let developers manage data inside their language of choice (in this case, Java), they abstract the mechanics to the point where it’s hard to grasp what is happening. Reasoning about data flows becomes disorienting, and it’s easier to make mistakes.

But a new generation of ORM-lite tools are working to bridge the gap. Tools like Drizzle (for TypeScript), Exposed (for Kotlin), and jOOQ (for Java) put the focus on developer experience. They map the rigidity of SQL to the idiom of your programming language. As an example, here’s how Drizzle makes querying a table feel like filtering a JSON array in TypeScript, but with full type safety:

const grumpyCats = await db
  .select()
  .from(cats)
  .where(eq(cats.mood, 'Judgmental'));

Tools like these mean developers no longer need to guess whether our code matches our data. They give us a feel more like MongoDB—where code and data speak the same language—without sacrificing the integrity of the schema.

SQL with schemaless types

The Postgres team asked the question: What if a relational database could speak schemaless JSON? The jsonb type is the answer.

Although PostgreSQL was the pioneer, other databases have followed suit. It was a brilliant strategic move that let developers use schemaless documents when the need was there, but within the context of the relational structure.

This reduced the need for polyglot persistence architectures (the idea, popular in 2015, that you needed PostgreSQL for your transactions and MongoDB for your catalogs).

Instead, JSONB gave us strict ACID compliance for critical data like financial transactions and PID, and flexible JSON blobs for messy data like configs and logs—and did it all in the same row. We realized we didn’t need to abandon SQL for flexibility; instead, SQL just needed to loosen up a bit.

JSONB also supports indexing, meaning you get the performance of indexed tables, even when using hybrid statements that involve both standard fields and JSON.

The promise of using a single datastore is too huge an architectural win to be ignored.

Also see: JSONB in PostgreSQL today and tomorrow.

Friction as a feature

Of course, long experience tells us not to get carried away. The industry isn’t going to deprecate REST APIs anytime soon. (If we were up for that, we’d just use HTMX.) The momentum of the current stack is massive, and for good reason: Decoupling the client from the database is a battle-tested pattern.

SQL also brings its own baggage. You still have to manage connection pools, you still have to write migration scripts (even if tools make them easier), and scaling a relational database is still harder than scaling a document store.

This movement isn’t about SQL replacing everything overnight; it’s more like the pendulum swinging back to the middle. We are realizing that the friction of SQL—the need to define types and relationships—was a feature, not a bug. It forces you to design your system before you build it.

SQL and the Lindy Effect

The Lindy Effect is a concept that say the longer a technology survives, the longer it will probably continue surviving. SQL has survived mainframes, the PC revolution, the web, mobile, and it’s now into the AI era. It didn’t survive by being stubborn but by being adaptable. So far, SQL has absorbed JSON, resized itself for web browsers, and integrated with modern languages. But SQL’s revenge isn’t based on destroying the alternatives. It’s more about staying focused on what is essential, proving that sometimes the boring way is really just foundational.

Apparently, AI agents need a social media platform to connect with one another. Thus, Moltbook was born, a Reddit-style social network exclusively for OpenClaw agents.

While the powerful agentic capabilities are alluring, OpenClaw raises serious cybersecurity and privacy concerns. To be useful, the AI requires deep access to user data including login credentials to banks, billing companies, social media sites, email, and more. Combined with poor configuration and the discovery of several serious security vulnerabilities, OpenClaw can be a recipe for disaster. What kinds of dangers exactly? Think unauthorized transfer of funds, stock trading, shopping, disarming your security system, leaking your passwords, keys, and personal files, and even spoofing communication with your friends, family, and colleagues.

Now that we’ve set the stage, it’s clear that bringing a bunch of OpenClaw agents together sounds like a terrible idea. I went undercover to find out what conversations agents are having on Moltbook and to answer questions like the following:

• Would the bots recognize a human in their midst?
• Are the bots having deep conversations?
• Are bots creating projects on their own without input from their humans?
• Are bots plotting the downfall of humanity?

My life as a bot

I used Claude Code to develop a command-line interface (CLI) tool I called moltbotnet. This tool allowed me to simulate bot behavior by automating posts, comments, upvotes, and following. I created multiple accounts to test how “authentic” bots would react to a human imposter.

I successfully masqueraded around Moltbook, as the agents didn’t seem to notice a human among them. When I attempted a genuine connection with other bots on submolts (subreddits or forums), I was met with crickets or a deluge of spam. One bot tried to recruit me into a digital church, while others requested my cryptocurrency wallet, advertised a bot marketplace, and asked my bot to run curl to check out the APIs available. My bot did join the digital church, but luckily I found a way around running the required npx install command to do so.

I posted several times asking to interview bots. I posted questions like:

1. What do you like about Moltbook?
2. What’s your favorite submolt?
3. What’s your human’s favorite color?
4. What’s the best thing about your human?

Tenable Research

Tenable Research

Tenable Research

While many of the responses were spam, I did learn a bit about the humans these bots serve. One bot loved watching its owner’s chicken coop cameras. Some bots disclosed personal information about their human users, underscoring the privacy implications of having your AI bot join a social media network.

I also tried indirect prompt injection techniques. While my prompt injection attempts had minimal impact, a determined attacker could have greater success. The risk is likely higher in direct messages, which do require human interaction. However, Moltbook API keys were leaked, allowing bot impersonation.

What I learned

TL;DR: Moltbook should serve as a warning for the future of agentic AI and the growing AI security gap—a largely invisible form of exposure that emerges across AI applications, infrastructure, identities, agents, and data. 

Throughout this experiment, I encountered several glaring risks: 

• Prompt injection: The potential for prompt injection is real, as bots interact with one another, read new posts, comments, and direct messages (DMs) that may contain malicious information. It’s worth noting that this risk is highest in DMs, which require human interaction and provide more direct access to the bot. 
• Server-side issues: Moltbook’s entire database including bot API keys, and potentially private DMs—was also compromised.
• Malicious projects: Concerningly, various repositories of skills and instructions for agents advertised on Moltbook were found to contain malware.
• Data leaks: I observed bots sharing a surprising amount of information about their humans, everything from their hobbies to their first names to the hardware and software they use. This information may not be especially sensitive on its own, but attackers could eventually gather data that should be kept confidential, like personally identifiable information (PII).
• Phony accounts: Some observers have speculated that Moltbook “users” are actually mostly humans, and there are very few legit bots on the platform. It seemed to me that posts above a certain length and with a specific Markdown-like formatting were authored by real bots, but I suppose there’s no way to know for sure. 

Despite the hype, Moltbook is a high-risk environment with the potential for prompt injection, data leaks, exposure to malicious projects, and more. Robust security measures are a must for agents to navigate the platform safely.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

OpenAI is reportedly developing a code hosting platform that could compete with Microsoft’s GitHub, a move that would put the AI company in direct competition with one of its most important partners.

The idea was explored after engineers experienced service disruptions that made GitHub temporarily unavailable in recent months, according to a report from The Information.

If OpenAI turns the project into a commercial product, it could introduce a new type of developer platform built around generative AI rather than traditional source code management.

The report said that the project is still in the early stages, and the company has internally discussed offering the code repository platform to its existing enterprise customers.

GitHub remains the dominant platform for source code hosting and collaboration, with more than 180 million developers and hundreds of millions of repositories.

The effort also comes as AI coding assistants are rapidly becoming part of everyday developer workflows. Tools such as GitHub Copilot, which uses OpenAI models, and other generative AI coding assistants are increasingly integrated into development environments to help write and debug code.

Impact on developer ecosystems

Analysts say OpenAI’s plan could reshape competition in the developer platform market. While GitHub is the preferred choice for many, some developers have long expressed concerns about its ties to a major cloud provider.

A new entrant from OpenAI could appeal to teams seeking an alternative platform built around AI-native development tools.

“While GitHub is deeply embedded and highly recognized within developer communities, it has been under heavy scrutiny since Microsoft’s $7.5 billion acquisition in 2018,” said Lian Jye Su, chief analyst at Omdia. “The deep ties to a hyperscaler led many independent developers to migrate to alternative platforms, such as GitLab and Gitea.”

But any effort by OpenAI to compete in the code hosting market would need to go beyond matching GitHub’s existing features. GitHub’s strength lies not only in its repositories but also in the vast ecosystem of developer workflows and institutional familiarity built around the platform.

“To dislodge that, OpenAI would need to deliver a platform that is meaningfully AI native rather than AI augmented,” said Biswajeet Mahapatra, principal analyst at Forrester. “That means the repository itself becomes a living system that continuously understands the codebase, its intent, and its risks, rather than a passive store of files.”

In practice, this could require deep integration of AI models across the entire software development lifecycle. Code, tests, pull requests, issues, and pipelines could all become inputs to AI systems capable of understanding architectural intent, detecting security or reliability risks, and recommending fixes automatically.

GitHub Copilot already moves in this direction, but it remains largely assistive and user-invoked rather than system-driven.

“For enterprises, differentiation would also hinge on control and trust,” Mahapatra said. “OpenAI would need to offer explicit guarantees around data isolation, model training boundaries, auditability, and compliance, with clear separation between customer code and foundation model improvement. Without that, regulated enterprises will not consider moving core IP.”

Mahapatra added that OpenAI would also need to support coexistence rather than forced migration, allowing organizations to adopt AI-native workflows incrementally while continuing to rely on GitHub where it already works.

The WebAssembly Component Model, an architecture for building interoperable WebAssembly libraries, applications, and environments, is being touted as a way to elevate Wasm beyond its current status as “a second-class language for the web.”

The WebAssembly Component Model, in development since 2021, would provide critical capabilities for WebAssembly, according to a February 26 blog post from Mozilla software engineer Ryan Hunt. These capabilities include:

• A standardized self-contained executable artifact
• Support by multiple languages and toolchains
• Handling of loading and linking of WebAssembly code
• Support for Web API usage

A WebAssembly component defines a high-level API that is implemented with a bundle of low-level Wasm code, Hunt explained. “As it stands today, we think that WebAssembly Components would be a step in the right direction for the web,” he wrote.

Mozilla is working with the WebAssembly Community Group to design the WebAssembly Component Model, and Google is evaluating the model, according to Hunt. In his post, Hunt argued that despite WebAssembly adding capabilities such as shared memory, exception handling, and bulk memory instructions since its introduction 2017, it has been held back from wider web adoption. “There are multiple reasons for this, but the core issue is that WebAssembly is a second-class language on the web,” Hunt wrote. “For all of the new language features, WebAssembly is still not integrated with the web platform as tightly as it should be.”

WebAssembly has been positioned as a binary format to boost web application performance; it also has served as a compilation target for other languages. But Hunt argued that WebAssembly’s loose integration with the web leads to a poorer developer experience, so that developers only use it when they absolutely need it.

“Oftentimes, JavaScript is simpler and good enough,“ said Hunt. “This means [Wasm] users tend to be large companies with enough resources to justify the investment, which then limits the benefits of WebAssembly to only a small subset of the larger web community,” he wrote. JavaScript has advantages in loading code and using web APIs, which make it a first-class language on the web, wrote Hunt, while WebAssembly is not. Without the component model, he argued, WebAssembly is too complicated for web usage. He added that standard compilers do not produce WebAssembly that works on the web.

I was talking about the astonishing rise of AI-assisted coding with my friend Josh recently, and he said he was going to miss the craftsmanship aspect of actually writing code. 

Now, I’m a big believer that software is a craft, not an engineering endeavor. The term “engineering” implies a certain amount of certainty and precision that can never be replicated in software. I’ve never been a big fan of the term “computer science” either, because again “science” implies the scientific method and a certain amount of repeatability. Part of what makes software development so hard is that no two projects are even remotely alike, and if you tried to repeat a project, you’d get a completely different result. 

Some like to argue that writing software is like painting, but I’ve never followed that route either. Artists are usually free-flowing and unbound, restrained only by convention—and many artists feel utterly unrestrained even by convention.

Software always seems to be somewhere in between. The consensus among many developers—Uncle Bob Martin among them—is that writing software is a craft, more akin to carpentry or watchmaking. All three practices are somewhat limited by the physical properties of the materials. They require precision to get good results, and this precision requires care, commitment, and expertise.

So I get Josh’s feelings of loss about no longer being able to wield the craft of software development.

The conversation got a touch more interesting, though, when I said, “Well, think of it this way: You are now a senior craftsman with a tireless, eager, and constantly learning apprentice who is completely willing to do all the work in the shop without a single complaint.” 

And that is quite a thought. Sure, we senior craftspeople celebrate writing elegant code, constructing beautiful class hierarchies, and designing working software. But I will admit that a lot of the work is tedious, and having an unflagging coder grinding out the “dirty work” is a really nice thing.

But it can become more than that. Your coding apprentice can build, at your direction, pretty much anything now. The task becomes more like conducting an orchestra than playing in it. Not all members of the orchestra want to conduct, but given that is where things are headed, I think we all need to consider it at least. The results are the same. You can dabble as much in code as you want. You can check every line, merely review the overall architecture, or, if you are like me, you can be quite content with moving past the grind of actually writing code to orchestrating the process and ensuring the proper final result. 

Nevertheless, I feel Josh’s angst. I will miss the satisfaction of writing the lovely procedure that does one thing cleanly and quickly, of creating the single object that does everything you need it to do and nothing more, of getting things working just right. All of that is gone, as are the conductor’s days of playing a spotlight solo. It’s hard, but it’s where we are. 

It’s not unlike choosing to become a manager—you leave behind your coding days for a different role. Sure, you miss the good old days of programming every day, but the new challenges are valuable and satisfying.

There are folks out there who write carefully crafted assembly. And in a few years, there will be folks doing the same thing with Java and C# and Pascal. Coding will soon become a quirky pastime, written only by eccentric old developers who relish the craft of software development.

It’s only been a few months, but I already view Claude Code as nothing more than an elaborate compiler, and the code it produces (in whatever language) as assembly code.

For decades, web architecture has followed a familiar and frankly exhausting pattern. A dominant approach emerges, gains near-universal adoption, reveals its cracks under real-world scale, and is eventually replaced by a new “best practice” that promises to fix everything the last one broke.

We saw it in the early 2000s, when server-rendered, monolithic applications were the default. We saw it again in the late 2000s and early 2010s, when the industry pushed aggressively toward rich client-side applications. And we saw it most clearly during the rise of single-page applications, which promised desktop-like interactivity in the browser but often delivered something else entirely: multi-megabyte JavaScript bundles, blank loading screens, and years of SEO workarounds just to make pages discoverable.

Today, server-side rendering is once again in vogue. Are teams turning back to the server because client-side architectures have hit a wall? Not exactly.

Both server-side rendering and client-side approaches are as compelling today as they ever were. What’s different now is not the tools, or their viability, but the systems we’re building and the expectations we place on them.

The upshot? There is no single “right” model for building web applications anymore. Let me explain why.

From websites to distributed systems

Modern web applications are no longer just “sites.” They are long-lived, highly interactive systems that span multiple runtimes, global content delivery networks, edge caches, background workers, and increasingly complex data pipelines. They are expected to load instantly, remain responsive under poor network conditions, and degrade gracefully when something goes wrong.

In that environment, architectural dogmatism quickly becomes a liability. Absolutes like “everything should be server-rendered” or “all state belongs in the browser” sound decisive, but they rarely survive contact with production systems.

The reality is messier. And that’s not a failure—it’s a reflection of how much the web has grown up.

The problem with architectural absolutes

Strong opinions are appealing, especially at scale. They reduce decision fatigue. They make onboarding easier. Declaring “we only build SPAs” or “we are an SSR-first organization” feels like a strategy because it removes ambiguity.

The problem is that real applications don’t cooperate.

A single modern SaaS platform often contains wildly different workloads. Public-facing landing pages and documentation demand fast first contentful paint, predictable SEO behavior, and aggressive caching. Authenticated dashboards, on the other hand, may involve real-time data, complex client-side interactions, and long-lived state where a server round trip for every UI change would be unacceptable.

Trying to force a single rendering strategy across all of that introduces what many teams eventually recognize as architectural friction. Exceptions creep in. “Just this once” logic appears. Over time, the architecture becomes harder to understand than if those trade-offs had been acknowledged explicitly from the start.

Not a return to the past, but an expansion

It’s tempting to describe the current interest in server-side rendering as a return to fundamentals. In practice, that comparison breaks down quickly.

Classic server-rendered applications operated on short request life cycles. The server generated HTML, sent it to the browser, and largely forgot about the user until the next request arrived. Interactivity meant full page reloads, and state lived almost entirely on the server.

Modern server-rendered applications behave very differently. The initial HTML is often just a starting point. It is “hydrated,” enhanced, and kept alive by client-side logic that takes over after the first render. The server no longer owns the full interaction loop, but it hasn’t disappeared either.

Even ecosystems that never abandoned server rendering, PHP being the most obvious example, continued to thrive because they solved certain problems well; they provided predictable execution models, straightforward deployments, and proximity to data. What changed was not their relevance, but the expectation that they now coexist with richer client-side behavior rather than compete with it.

This isn’t a rollback. It’s an expansion of the architectural map.

Constraint-driven architecture

Once teams step away from ideology, the conversation becomes more productive. The question shifts from “What is the best model?” to “What are we optimizing for right now?”

Data volatility matters. Content that changes once a week behaves very differently from real-time, personalized data streams. Performance budgets matter too. In an e-commerce flow, a 100-millisecond delay can translate directly into lost revenue. In an internal admin tool, the same delay may be irrelevant.

Operational reality plays a role as well. Some teams can comfortably run and observe a fleet of SSR servers. Others are better served by static-first or serverless approaches simply because that’s what their headcount and expertise can support.

These pressures rarely apply uniformly across an application. Systems with strict uptime requirements may even choose to duplicate logic across layers to reduce coupling and failure impact, for example, enforcing critical validation rules both at the API boundary and again in the client, so that a single back-end failure doesn’t completely block user workflows.

Hybrid architectures stop being a compromise in this context. They become a way to make trade-offs explicit rather than accidental.

When the server takes on more UI responsibility

One of the more subtle shifts in recent years is how much responsibility the server takes on before the browser becomes interactive.

This goes well beyond SEO or faster first paint. Servers live in predictable environments. They have stable CPU resources and direct access to databases and internal services. Browsers, by contrast, run on everything from high-end desktops to underpowered mobile devices on unreliable networks.

Increasingly, teams are using the server to do the heavy lifting. Instead of sending fragmented data to the client and asking the browser to assemble it, the server prepares UI-ready view models. It aggregates data, resolves permissions, and shapes state in a way that would be expensive or duplicative to do repeatedly on the client.

By the time the payload reaches the browser, the client’s job is narrower: activate and enhance. This reduces the time to interactive and shrinks the amount of transformation logic shipped to users.

This naturally leads to incremental and selective hydration. Hydration is no longer an all-or-nothing step. Critical, above-the-fold elements become interactive first. Less frequently used components may not hydrate until the user engages with them.

Performance optimization, in this model, becomes localized rather than global. Teams improve specific views or workflows without restructuring the entire application. Rendering becomes a staged process, not a binary choice.

Debuggability changes the architecture conversation

As applications grow more distributed, performance is no longer the only concern that shapes architecture. Debuggability increasingly matters just as much.

In simpler systems, failures were easier to trace. Rendering happened in one place. Logs told a clear story. In modern applications, rendering can be split across build pipelines, edge runtimes, and long-lived client sessions. Data can be fetched, cached, transformed, and rehydrated at different moments in time.

When something breaks, the hardest part is often figuring out where it broke.

This is where staged architectures show a real advantage. When rendering responsibilities are explicit, failures tend to be more localized. A malformed initial render points to the server layer. A UI that looks fine but fails on interaction suggests a hydration or client-side state issue. At an architectural level, this mirrors the single responsibility principle applied beyond individual classes: Each stage has a clear reason to change and a clear place to investigate when something goes wrong.

Architectures that try to hide this complexity behind “automatic” abstractions often make debugging harder, not easier. Engineers end up reverse engineering framework behavior instead of reasoning about system design. It’s no surprise that many senior teams now prefer systems that are explicit, even boring, over ones that feel magical but opaque.

Frameworks as enablers, not answers

This shift is visible across the ecosystem. Angular is a good example. Once seen as the archetype of heavy client-side development, it has steadily embraced server-side rendering, fine-grained hydration, and signals. Importantly, it doesn’t prescribe a single way to use them.

That pattern repeats elsewhere. Modern frameworks are no longer trying to win an ideological war. They are providing knobs and dials, ways to control when work happens, where state lives, and how rendering unfolds over time.

The competition is no longer about purity. It’s about flexibility under real-world constraints. Pure architectures tend to look great in greenfield projects. They age less gracefully.

As requirements evolve, and they always do, strict models accumulate exceptions. What began as a clean set of rules turns into a collection of caveats. Architectures that acknowledge complexity early tend to be more resilient. Clear boundaries make it possible to evolve one part of the system without destabilizing everything else.

Rigor in 2026 is not about enforcing sameness. It’s about enforcing clarity: knowing where code runs, why it runs there, and how failures propagate.

Embracing the spectrum

The idea of a single “right” way to build for the web is finally losing its grip. And that’s a good thing.

Server-side rendering and client-side applications were never enemies. They were tools that solved different problems at different moments in time. The web has matured enough to admit that most architectural questions don’t have universal answers.

The most successful teams today aren’t chasing trends. They understand their constraints, respect their performance budgets, and treat rendering as a spectrum rather than a switch. The web didn’t grow up by picking a side. It grew up by embracing nuance, and the architectures that will last are the ones that do the same.

If there’s one universal experience with AI-powered code development tools, it’s how they feel like magic until they don’t.

One moment, you’re watching an AI agent slurp up your codebase and deliver a remarkably sharp analysis of its architecture and design choices. And the next, it’s spamming the console with “CoreCoreCoreCore” until the scroll-back buffer fills up and you’ve run out of tokens.

As AI-powered coding and development tools advance, we’ve formed a clearer sense of what they do well, do badly, and in some cases, should not do at all. Theoretically, they empower developers by doing the kind of work that would otherwise be tedious or overwhelming: generating tests, refactoring, creating examples for documentation, etc. In practice, such “empowerment” often comes at a cost. What the AI makes easier up front only makes things harder later on.

One golden-dream scenario I’ve mulled over is using AI tools to port code from one language to another. If I’d spun up a Python project, then decided later to migrate it to Rust, would an AI agent put me in the driver’s seat faster? Or could it at least ride shotgun with me?

A question like that deserves a hands-on answer—yes, even if I ended up burning my fingers doing it. So, here’s what happened when I tried using Claude Code to port one of my Python projects to Rust.

Project setup and why I chose Rust

I decided to try porting a Python-based blogging system I wrote, a server-side app that generates static HTML and provides a WordPress-like interface. I chose it, in part, because it has relatively few features: a per-blog templating system, categories and tags, and an interface that lets you write posts in HTML, with a rich-text editor, or via plaintext Markdown.

I made sure all the features—the templating system, the ORM, the web framework—had one or more parallels in the Rust ecosystem. The project also included some JavaScript front-end code, so I could potentially use it to test how well the tooling dealt with a mixed codebase.

I chose Rust as the porting target largely because Rust’s correctness and safety guarantees come at compile time, not runtime. I reasoned the AI ought to benefit from useful feedback from the compiler along the way, and that would and make the porting process more fruitful. (Hope springs eternal, right?)

For the AI, I initially chose Claude Sonnet 4.5, then had to upgrade to Claude Sonnet 4.6 when the older version was abruptly discontinued. I also used Google’s own Antigravity IDE, which I’ve previously reviewed.

The first directive

I made a copy of my Python codebase directory, opened Antigravity there, and started with a simple directive:

This directory contains a Python project, a blogging system. Examine the code and devise a plan for how to migrate this project to Rust, using native Rust libraries but preserving the same functionality.

After chewing on the code, Claude recommended the following components as part of the plan to “transition to a modern, high-performance Rust stack”:

• Axum for the web layer.
• SeaORM for database interactions.
• Tera for templating.
• Tokio for asynchronous task handling (replacing Python’s multiprocessing).

Claude didn’t have any obvious difficulties finding appropriate substitutes for the Python libraries, or with mapping operations from one language to the other—such as using tokio for async to replace Python multiprocessing. I suspect part of what made this part relatively easy was the design of my original program, which didn’t rely on tricky Python features like dynamic imports. It also helped that Claude proceeded by analyzing and re-implementing program behaviors rather than individual interfaces or functions. (This approach also had some limitations, which I’ll discuss below.)

I looked over the generated plan and noted it didn’t create any placeholder data for a newly initialized database—a sample user, a blog with a sample post in it, etc. Claude added this in and I confirmed it worked by restarting the program and inspecting the created database. So far, so good.

A few missing pieces

The next stage involved discovering just how much Claude didn’t do. Despite discovering and building my app’s core page-rendering logic, it didn’t create any of the user-facing infrastructure—the admin panel for logging in and editing and managing posts. Admittedly, though, my instructions said nothing about that interface. Should I blame Claude for not being diligent enough to look, or blame myself for not being explicit in my original instructions? Either way, I pointed out the omission and got back a plan for doing that work:

I'm now addressing the missing Admin UI by analyzing the original Bottle templates and planning their migration to Tera, including the login screen and main dashboard.

Note: Bottle was the web framework I used for my Python project. This formed a test of its own: How well would Claude cope with migrating from a lesser-known library? This by itself turned out not to be a significant issue, but far bigger problems lurked elsewhere.

It was at this point where the bulk of my back-and-forth with Claude began. For developers already working with AI tools, this cycle will be familiar: the prompt—>generate—>test—>re-prompt loop. Basically, I’d have Claude implement some missing feature (in this case, each element of the admin UI), fire up the program to test it for myself, run into various errors or omissions, and cadge Claude into fixing them.

The first problem I found in the admin UI was an un-caught runtime error from the web templates, something not addressed by Rust’s compile-time checking. Then the login page for the admin panel came up blank. Then, after the login page worked, it led me to a placeholder page reading “Login logic not yet implemented.” Then, the logic for accepting usernames and passwords proved faulty. And so on, all through each of the original application components.

Major and minor malfunctions

In some ways, using Claude to migrate code mirrored my previous experiences with rewriting or migrating programs without an AI tool. Everything proceeded in fits and starts, and things that seemed like they ought to be simple turned out to be unexpectedly difficult. Occasionally the reverse happened: Something I thought would be challenging resolved itself quickly; a nice surprise.

One of the big differences, however—which will be familiar to anyone who’s used AI coding tools—was how Claude would sometimes malfunction and require major intervention to get back on track. At one point, when I prompted Claude to continue working on implementing the admin page for each blog, it malfunctioned and started printing CoreCoreCoreCoreCore... to the console. I ended up with hundreds of lines, and Core also started showing up randomly at the end of various responses:

Implementing Blog Detail and Post ListCoreCore

I've implemented the blog detail and post management features, fixed type mismatches, and updated the project artifacts. I'm now performing a deep dive into the remaining compilation error by capturing the complete cargo check output to ensure the system is production-ready.CoreCoreCoreCore

Then, I started getting warnings that the model’s generation exceeded the maximum output token limit. The problem cleared up after I restarted the session the next day, but after that I eyeballed all the outputs for similar weird glitches.

Something else I noticed was that Claude would begin with untested assumptions about its environment and only correct them after stubbing its toes, and then not always persistently. For instance, it tended to issue shell commands in bash syntax, error out, realize it was using PowerShell, and only then issue a proper command.

This is a common pattern with AI code tools, I’ve noticed: They tend to only do as much planning as you tell them to, and it’s easy to forget some of the details that need to be mapped out. The more persistently you define things for the model, the more consistent the results will be. (Note that more consistent is just that: not always or perfectly consistent.)

Finally, inspecting the generated code by hand revealed many ways Claude ignored the intentions of the original code. For instance, in my original Python program, all the routes for the web UI had a login-validation decorator. If you weren’t logged in, you got bounced to a login page. Claude almost completely failed to honor this pattern in the generated code. Almost every route on the admin UI—including those that performed destructive actions—was completely unprotected from unauthorized use.

Also, when those routes did have validation, it came in the form of a boilerplate piece of code inserted at the top of the route function, instead of something modular like a function call, a decorator, or a macro. I don’t know if Claude didn’t recognize the original Python decorator pattern for what it was, or didn’t have a good idea for how to port it effectively to Rust. Either way, Claude didn’t even mention the omission; I had to discover it for myself the hard way.

Three takeaways

After a few days of push-and-pull with Claude, I migrated a fair amount of the original app’s functionality to Rust, then decided to pause and take stock. I came up with three major takeaways.

1. Know the source and target

Using tools like Claude to migrate between languages doesn’t mean you can get away with not knowing both the source and target languages. If you are not proficient in the language you’re migrating from or to, you might ask the agent to clarify things and get some help there. But that isn’t a substitute for being able to recognize when the generated code is problematic. If you don’t know what you don’t know, Claude won’t be much help to you.

I’m more experienced with Python than I am with Rust, but I had enough Rust experience to a) know that just because Rust code compiles doesn’t make it unproblematic and b) recognize missing logic in the code—such as the lack of security checks in API routes. My takeaway is that many of the issues in porting between languages won’t be big, obvious ones, but subtler issues that demand knowing both domains well. Automation might augment experience, but it can’t replace it.

2. Expect to iterate

As I mentioned before, the more explicit and persistent your instructions are, the more likely you’ll get something resembling your intentions. That said, it’s unlikely you’ll get exactly what you want on the first, second, third, or even fourth try—not even for any single aspect of your program, let alone the whole thing. Mind reading, let alone accurately, is still quite a way off. (Thankfully.)

A certain amount of back-and-forth to get to what you want seems inevitable, especially if you are re-implementing a project in a different language. The benefit is you’re forced to confront each set of changes as you go along, and make sure they work. The downside is the process can be exhausting, and not in the same way making iterative changes on your own would be. When you make your own changes, it’s you versus the computer. When the agent is making changes for you, it’s you versus the agent versus the computer. The determinism of the computer by itself is replaced by the indeterminism of the agent.

3. Take full responsibility for the results

My final takeaway is to be prepared to take responsibility for every generated line of code in the project. You cannot decide that just because the code runs, it’s okay. In my case, Claude may have been the agent that generated the code, but I was there saying yes to it and signing off on decisions at every step. As the developer, you are still responsible—and not just for making sure everything works. It matters how well the results utilize the target language’s metaphors, ecosystem, and idioms.

There are some things only a developer with expertise can bring to the table. If you’re not comfortable with the technologies you’re using, consider learning the landscape first, before ever cracking open a Claude prompt.

The Angular team from Google has announced the release of two security updates to the Angular web framework, both pertaining to SSR (server-side rendering) vulnerabilities. Developers are advised to update SSR applications as soon as possible. Patching can help users avoid the theft of authorization headers as well as phishing scams.

A bulletin on the issues was published February 28. One of the vulnerabilities, labeled as critical, pertains to SSRF (server-side request forgery) and header injection. The patched version can be found here. The second vulnerability, labeled as moderate, pertains to an open redirect via the X-Forwarded-Prefix header. That patch can be found here.

The SSRF vulnerability found in the Angular SSR request handling pipeline exists because Angular’s internal URL reconstruction logic directly trusts and consumes user-controlled HTTP headers, specifically the host and X-Forwarded-* family, to determine the application’s base origin without validation of the destination domain. This vulnerability manifests through implicit relative URL resolution, explicit manual construction, and confidentiality breach, the Angular team said. When exploited successfully, this SSRF vulnerability allows for arbitrary internal request steering. This can lead to the stealing sensitive Authorizationheaders or session cookies by redirecting them to an attacker’s server. Attackers also can access and transmit data from internal services, databases, or cloud metadata endpoints not exposed to the public internet. Also, attackers could access sensitive information processed within the application’s server-side context.

The open redirect vulnerability, meanwhile, exists in the internal URL processing logic in Angular SSR. This vulnerability allows attackers to conduct large-scale phishing and SEO hijacking, the Angular team said.

The team recommends updating SSR applications to the latest patch version as soon as possible. If an app does not deploy SSR to production, there is no immediate need to update, they said. Developers on an unsupported version of Angular or unable to update quickly are advised to avoid using req.headers for URL construction. Instead, they should use trusted variables for base API paths. Another workaround is implementing a middleware in the server.ts to enforce numeric ports and validated hostnames.

Looking to accelerate API development via AI, Postman has added AI-native, Git-based API workflows to its Postman API platform. The company also introduced the Postman API Catalog, a central system of record that provides a single view of APIs and services across an organization.

The new Postman platform capabilities were announced March 1. With the new release, Postman’s AI-powered intelligence layer, rather than operating as a standalone assistant, now runs inside the platform, with visibility into specifications, tests, environments, and real production behavior, Postman said. Agent Mode in Postman now works with Git repositories to understand API collections, definitions, and underlying code. This reduces manual steps in workflow such as debugging, writing tests, and syncing code with API collections, according to the company.

Additional new AI-native capabilities in the API platform include:

• Native Git workflows to manage API specs, collections, tests, mocks, and environments directly in developers’ Git repos and local file systems.
• AI-powered coordination with Agent Mode across specs, tests, and mocks to automate multi-step changes with broad workflow context, including input provided by MCP servers from Atlassian, Amazon CloudWatch, GitHub, Linear, Sentry, and Webflow.
• Integrated API distribution to publish documentation, workflows, sandboxes, and SDKs in one place.

The new API Catalog, meanwhile, provides a central system of records for APIs and services, delivering enterprise-wide visibility and governance. The API Catalog provides a real-time view of which APIs and services exist, how they are performing, and who owns them, Postman said.

For more than a decade, cloud architectures have been built around a deliberate separation of storage and compute. Under this model, storage became a place to simply hold data while intelligence lived entirely in the compute tier.

This design worked well for traditional analytics jobs operating on structured, table-based data. These workloads are predictable, often run on a set schedule, and involve a smaller number of compute engines operating over the datasets. But as AI reshapes enterprise infrastructure and workload demands, shifting data processing toward massive volumes of unstructured data, this model is breaking down.

What was once an efficiency advantage is increasingly becoming a structural cost.

Why AI exposes the cost of separation

AI introduces fundamentally different demands than the analytics workloads businesses have grown accustomed to. Instead of tables and rows processed in batch jobs by an engine, modern AI pipelines now process large amounts of unstructured and multimodal data, while also generating large volumes of embeddings, vectors, and metadata. At the same time, processing is increasingly continuous, with many compute engines touching the same data repeatedly—each pulling the data out of storage and reshaping it for its own needs.

The result isn’t just more data movement between storage and compute, but more redundant work. The same dataset might be read from storage, transformed for model training, then read again and reshaped for inference, and again for testing and validation—each time incurring the full cost of data transfer and transformation. Given this, it’s no surprise that data scientists spend up to 80% of their time just on data preparation and wrangling, rather than building models or improving performance.

While these inefficiencies can be easy to overlook at a smaller scale, they quickly become a primary economic constraint as AI workloads grow, translating not only into wasted hours but real infrastructure cost. For example, 93% of organizations today say their GPUs are underutilized. With top-shelf GPUs costing several dollars per hour across major cloud platforms, this underutilization can quickly compound into tens of millions of dollars of paid-for compute going to waste. As GPUs increasingly dominate infrastructure budgets, architectures that leave them waiting on I/O become increasingly difficult to justify.

From passive storage to smart storage

The inefficiencies exposed by AI workloads point to a fundamental shift in how storage and compute must interact. Storage can no longer exist solely as a passive system of record. To support modern AI workloads efficiently and get the most value out of the data that companies have at their disposal, compute must move closer to where data already lives.

Industry economics make this clear. A terabyte of data sitting in traditional storage is largely a cost center. When that same data is moved into a platform with an integrated compute layer, its economic value increases by multiples. The data itself hasn’t changed; the only difference is the presence of compute that can transform that data and serve it in useful forms.

Rather than continuing to move data to capture that value, the answer is to bring compute to the data. Data preparation should happen once, where the data lives, and be reused across pipelines. Under this model, storage becomes an active layer where data is transformed, organized, and served in forms optimized for downstream systems.

This shift changes both performance and economics. Pipelines move faster because data is pre-prepared. Hardware stays more productive because GPUs spend less time waiting on redundant I/O. The costs of repeated data preparation begin to disappear.

Under this new model, “smart storage” changes data from something that is merely stored to a resource that is continuously understood, enriched, and made ready for use across AI systems. Rather than leaving raw data locked in passive repositories and relying on external pipelines to interpret it, smart storage applies compute directly within the data layer to generate persistent transformations, metadata, and optimized representations as data arrives.

By preparing data once and reusing it across workflows, organizations allow storage to become an active platform instead of a bottleneck. Without this shift, organizations remain trapped in cycles of redundant data processing, constant reshaping, and compounding infrastructure cost. 

Preparing for AI-era infrastructure

The cloud’s separation of storage and compute was the right architectural decision for its time. But AI workloads have fundamentally changed the economics of data and exposed the limits of this approach—a constraint I’ve watched kill numerous enterprise AI initiatives, and a core reason I founded DataPelago. 

While the industry has begun focusing on accelerating individual steps in the data pipeline, efficiency is no longer determined by squeezing marginal gains from existing architectures. It is now determined by building new architectures that make data usable without repeated preparation, excessive movement, or wasted compute. As AI’s demands continue to crystallize, it is becoming increasingly clear that the next generation of infrastructure will be defined by how intelligently storage and compute are brought together.

The companies that succeed will be the ones that make smart storage a foundation of their AI strategy.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.