With Fabric IQ, Microsoft is adding new semantic intelligence capabilities to its unified data and analytics platform, Fabric, that it says will help enterprises maintain a common data model and automate operational decisions.

We’ll be hearing a lot more about “IQ” from Microsoft, which has also just introduced Work IQ, the semantic intelligence layer for Microsoft 365, and Foundry IQ, a managed knowledge system for grounding AI agents via multiple knowledge repositories, that together with Fabric IQ form what Microsoft calls a “shared intelligence layer” for the enterprise.

Fabric IQ will offer five integrated capabilities, Microsoft said: the ability to create an ontology or shared model of business entities, relationships, rules, and objectives; a semantic model extending business intelligence definitions beyond analytics to AI and operations; a native graph engine to enable multi-hop reasoning with data; virtual analysts called data agents that can answer business questions; and autonomous operations agents that can reason, learn, and act in real time.

The ontology is the foundation of all of this, a living structure capturing key business concepts, the company said. It contrasted it with traditional data modelling, saying that it can be created and evolved by business experts using a no-code tool (still in preview), without support from engineers — yet still offering IT managers the control to secure, approve, version, and manage it.

Constellation Research principal analyst Michael Ni was skeptical: “There is upfront work for IT. Ontologies don’t build themselves,” he said.

IT teams may be able to capitalize on work they have already done: Organizations using Power BI can import its data models as the basis for their ontology, Microsoft said.

From ontology to autonomy

For organizations not already invested in the Fabric ecosystem, adoption of IQ will likely take longer, warned Suhas AR, associate practice leader at HFS Research. “Key hurdles include agreeing on shared business definitions, ensuring that data permissions are carried through to AI agents, and maintaining clean and reliable real-time data feeds for automation. Teams also need some new skills and processes to govern these agents as they evolve.”

The endgame of all this describing of data is to ensure that workers, both human and AI, have a shared understanding of what the data means in the real world, so that they can analyze and act on it together.

Operations agents “monitor the business in real time, reason over live conditions, evaluate trade-offs, and take actions automatically to advance business outcomes,” Microsoft said in a blog post announcing Fabric IQ.

Such agents are capable of much more than just alerting or simple workflow automation, Microsoft said, enabling decisions at scale in seconds, without the need for interminable meetings.

Who benefits?

While successfully implementing Fabric IQ is likely to involve IT teams in some up-front heavy lifting, they’ll benefit from a longer-term reduction of operational effort, analysts say.

Microsoft-first enterprises with strong central governance stand to gain the most, Suhas said, cautioning enterprises with low data-maturity, or not committed to Microsoft’s data stack, to “wait and watch.”

Constellation Research’s Ni sees good reasons for adopting Fabric IQ: “These benefits include consistent semantics, fewer one-off models, less duplicated logic, and a shared decision layer that lowers downstream maintenance as enterprises ramp up iteration on decision automation and AI-driven automation,” he said.

Stephanie Walter, practice leader of AI Stack at HyperFrame Research, doesn’t expect IT teams’ data modelling workload to disappear with the introduction of Fabric IQ’s ontology, she does see it shifting towards controlling security, and approving the changes made by business users.

Other analysts have reservations, fearing complex, time-intensive deployments and vendor lock-in.

While Fabric IQ’s ontology will provide a clear basis for communication between employees and autonomous agents it will also, according to Moor Insights and Strategy principal analyst Robert Kramer, tie the enterprise to it.

“The more an enterprise builds on this semantic layer, the harder it becomes to move that logic elsewhere.,” Kramer said.

Fabric costs

Suhas, too, pointed to the heavy switching costs enterprises would face if they wanted to move to another platform that didn’t support the Fabric IQ ontology.

And if, after spending on the creation and governance of the ontology, and all the attendant Fabric IQ services, an enterprise was unable to drive meaningful agent adoption, then all that investment would be for nothing.

Predicting or measuring that investment will be a challenge in itself. Fabric IQ is treated as a workload in Microsoft Fabric, just like Data Factory, Analytics, Databases, Real-Time Intelligence, and Power BI, the company said.

“It uses the same unified Fabric licensing model and runs on Fabric capacity. There is no separate SKU or add-on fee,” said Yitzhak Kesselman, Microsoft CVP for Messaging and Real-Time Analytics Platform.

Those costs are tracked via a bewildering array of Fabric capacity invoice meters for underlying infrastructure usage.

Microsoft hasn’t yet published the billing meters for the Ontology item, but plans to do so later this week, with billing beginning in the first half of 2026, he said. Billing for other Fabric items will remain unchanged.

More Microsoft Ignite 2025 news:

• Microsoft unveils Agent 365 to help IT manage AI ‘agent sprawl’
• Microsoft touts scalability of its new PostgreSQL-compatible managed database
• Microsoft unveils Agent 365 to help IT manage AI ‘agent sprawl’
• Microsoft bets on agentic AI for cloud ops, but analysts doubt the pitch

Microsoft is previewing a third PostgreSQL-compatible managed database for its cloud, Azure HorizonDB, that it hopes will prove attractive for modern workloads and for legacy application modernization.

The company already offers two databases compatible with PostgreSQL, the database interface proving popular with developers of AI applications: Azure Cosmos DB for PostgreSQL and Azure Database for PostgreSQL.

Azure HorizonDB differs from both the existing offerings in that it’s a shared-storage, scale-out compute architecture explicitly engineered for AI-era application patterns, said Stephanie Walter, practice lead of the AI stack at HyperFrame Research.

“In contrast, Azure Database and Cosmos DB for PostgreSQL remains the general-purpose managed Postgres for traditional apps and the distributed, sharded option for horizontally scaled multi-tenant workloads respectively,” she said.

“HorizonDB is the AI-era Postgres tier, where transactional modernization and vector-driven applications finally land in the same engine. It’s meant to be the place where you both modernize legacy transactional systems and bolt on RAG, agents, and embeddings-heavy features without stitching together separate databases and ML endpoints,” said Walter.

One of the things that has made PostgreSQL so popular with AI developers is its support for vector indexes, said Microsoft, adding that in Azure HorizonDB it is extending that support with advanced filtering capabilities in the DiskANN vector index that “enable query predicate pushdowns directly into the vector similarity search”. This common optimization technique filters data as early as possible in the pipeline to avoid unnecessary data processing and transmission.

“That early pruning reduces engine work and can improve long-tail latency on vector-plus-metadata queries,” said IDC research director Devin Pratt.

Microsoft also said HorizonDB will make it easier for developers to integrate and manage generative, embedding, and reranking models from Microsoft Foundry with zero configuration.

That, said Pratt, will help reduce glue code, simplify audits, and shorten the path from prototype to production by keeping the data and the models close under one governance plane.

PostgreSQL elsewhere

Microsoft is not the only cloud provider offering PostgreSQL-compatible database services, but it is seeking to differentiate itself.

“Similar approaches exist in offerings such as AlloyDB AI, Snowflake Cortex, Aurora PostgreSQL with Bedrock/SageMaker, but HorizonDB emphasizes model management and vector search together inside the Postgres service,” Pratt said.

Another key differentiator for Microsoft, said Walter, is that Azure HorizonDB’s model layer is plugged into AI Foundry and the broader Azure AI ecosystem, so the same models and governance primitives can be reused across apps, agents, and data services.

Microsoft plans to add mirroring for Azure HorizonDB to its unified data and analytics platform, Fabric.

This will provide Fabric with a more solid, operational database foundation, according to Bradley Shimmin, practice leader of data, analytics, and infrastructure at The Futurum Group.

Fabric already supports mirroring of Azure Database for PostgreSQL.

It looks like you’re migrating to HorizonDB. Would you like help with that?

Although a big part of Microsoft’s story for Azure HorizonDB is that it’s ideal for serving up data to modern AI applications, it’s also pitching it as a way to modernize legacy workloads currently running on Oracle.

To help with that, it’s integrating GitHub Copilot into the PostgreSQL Extension for Visual Studio Code.

“Teams of engineers can work with GitHub Copilot to automate the end-to-end conversion of complex database code using rich code editing, version control, text,” Microsoft wrote in the blog post announcing Azure HorizonDB.

This feature, said Futurum’s Shimmin, “can help Microsoft displace established rivals, most notably Oracle, giving those customers another reason to make the move to Microsoft’s platform.”

More Microsoft Ignite 2025 news:

• Microsoft unveils Agent 365 to help IT manage AI ‘agent sprawl’
• Microsoft unveils Agent 365 to help IT manage AI ‘agent sprawl’
• Microsoft bets on agentic AI for cloud ops, but analysts doubt the pitch

Google has launched Gemini 3 and integrated the new AI model into its search engine immediately, aiming to push advanced AI features into consumer and enterprise products faster as competition in the AI market intensifies.

The release brings new agentic capabilities for coding, workflow automation, and search, raising questions about how quickly businesses can adopt these tools and what impact they may have on existing IT operations.

Google also introduced new agent features, including Gemini Agent and the Antigravity development platform, designed to automate multi-step tasks and support software teams.

Gemini 3 comes in a Deep Think mode as well, which “outperforms Gemini 3 Pro’s already impressive performance on Humanity’s Last Exam (41.0% without the use of tools) and GPQA Diamond (93.8%). It also achieves an unprecedented 45.1% on ARC-AGI-2 (with code execution, ARC Prize Verified), demonstrating its ability to solve novel challenges.”

The update introduces a generative UI that can build custom visual layouts in response to prompts, allowing Gemini to present answers in interactive, application-like formats.

Gemini 3 also brings long-context reasoning and improved multimodal support, enabling the model to handle larger documents, richer datasets, and complex multimedia inputs, the company said.

Immediate integration

For enterprise IT leaders, the key question is how quickly Gemini 3’s capabilities will be integrated into real-world workplace applications and whether agentic features like Deep Think and Antigravity can deliver measurable productivity gains without introducing new operational risks.

According to Sanchit Vir Gogia, chief analyst at Greyhound Research, Google’s decision to embed Gemini 3 directly into Search from day one is one of the most consequential shifts in the enterprise AI market this year.

“This is not an AI feature layered on top of Search,” Gogia said. “It is a fundamental rewrite of the global information distribution engine that billions rely on every day. For enterprises, this marks a decisive moment where AI is no longer a separate capability but the default interpreter of user intent, workflow context, and knowledge retrieval.”

By tightly coupling Gemini 3 with Search, Google is converting its most powerful distribution surface into a permanent AI gateway, which reshapes how organizations consume intelligence and structure their digital workplace experience, Gogia said.

Others suggested that the integration could also reshape how enterprises rely on Google’s ecosystem.

“For enterprises, Google Search might become a one-stop shop for all secondary information, whether it is normal search or for generating content,” said Sharath Srinivasamurthy, research vice president at IDC.  “Also, the ad business for Google will go through a change as it will consider AI-driven search and prompts to push relevant ads. The search and prompts (now) will start feeding into Google training models, which will eventually make the search and Gemini’s responses better.”

Charlie Dai, VP and principal analyst at Forrester, said that Google’s integration decisions reflect its confidence in the model’s performance and its native multimodal capabilities. It also shows Google’s intent to monetize AI through core products rather than standalone offerings.

“As enterprise search becomes an AI gateway, enterprise CIOs must have a holistic view on the dependencies in the AI stack for long-term observability and governance,” Dai added.

Automating multi-step workflows

While Google is positioning Gemini 3’s agentic capabilities as a step toward hands-free automation, analysts caution that most enterprises are still far from running fully autonomous workflows. Srinivasamurthy said the complexity of real-world processes remains a major barrier.

“Workflows that cut across multiple systems, involve human exceptions, compliance reviews, or high-risk decision points still require careful orchestration and typically human-in-the-loop supervision,” Srinivasamurthy added. “Enterprise adoption is in its early stages, and scaling from pilot or siloed implementations to organization-wide workflows continues to be a significant challenge.”

Dai agreed that while agentic tools like Gemini Agent and Antigravity with increasingly powerful reasoning capabilities will continue to move enterprises closer to workflow automation, safety hinges on robust guardrails and AI readiness of enterprise data.

“CIOs need governance frameworks for identity, data lineage, and action approval, plus continuous monitoring for non-deterministic behavior,” Dai said.

Gogia said that Gemini Agent and Antigravity will unlock meaningful productivity gains, but only once enterprises build the frameworks required to manage autonomous systems responsibly. “The technology may be ready for demonstration, but enterprise governance is still catching up,” Gogia said. “Organizations that scale agentic automation prematurely may expose themselves to operational, regulatory, and reputational risks that outweigh the short-term benefits.”

When I was tasked with modernizing our enterprise document management system, I knew the stakes were high. We were managing millions of documents, and our legacy architecture was buckling under the load. Query times were unpredictable, scaling was a constant battle and costs were spiraling out of control.

The breakthrough came when I stopped thinking about documents as monolithic entities and started viewing them as two distinct workloads: high-frequency metadata queries and low-frequency content operations. This architectural shift transformed our system from a performance bottleneck into a horizontally scalable, cost-efficient platform that consistently delivers sub-300ms query times even under heavy load.

The core insight: Not all data is created equal

The fundamental problem with traditional document management systems is that they treat metadata and content as a single unit. When a user searches for “all employment contracts for customer X,” the system must wade through both the searchable attributes and the heavyweight file content, even though the search only needs the metadata.

I realized that these two types of data have completely different performance characteristics. Metadata operations are classic Online Transaction Processing (OLTP) workloads: frequent, small, latency-sensitive transactions. Content operations are the opposite: infrequent, large, bandwidth-intensive transfers that can tolerate higher latency.

By separating these workloads, I could optimize each independently. Metadata went into a high-performance NoSQL database — choosing from options like Amazon DynamoDB, Google Cloud Firestore or Azure Cosmos DB based on your cloud provider — configured in on-demand mode for automatic scaling. Document content lives in commodity cloud object storage such as Amazon S3, Google Cloud Storage or Azure Blob Storage. Each document gets a globally unique identifier (unique document ID) that serves as the link between its metadata record and its file in object storage.

The performance impact was immediate. Our metadata queries dropped from seconds to ~200 milliseconds at the median, with 95th percentile latency under 300ms. More importantly, these numbers stayed consistent even as we scaled to handle over 4,000 requests per minute with zero errors.

Making the API layer do the heavy lifting

The separation of metadata and content only works if you enforce it architecturally, which is where an API-first design becomes critical. I created distinct REST endpoints for metadata operations versus content operations. When a client queries “show me all documents for member 12345,” that request hits the metadata API, retrieves the results from the fast NoSQL database and returns them without ever touching object storage.

Here’s how I structured the API:

Metadata APIs:

• GET /api/v1/members/{member-id}/document-metadata: Retrieve all document metadata for a specific member
• GET /api/v1/members/{member-id}/document-metadata/{unique-document-id}: Retrieve metadata for a single document
• PATCH /api/v1/members/{member-id}/document-metadata/{unique-document-id}: Update metadata for a single document

Document APIs:

• POST /api/v1/members/{member-id}/documents: Upload a new document
• GET /api/v1/members/{member-id}/documents/{unique-document-id}: Retrieve a document
• DELETE /api/v1/members/{member-id}/documents/{unique-document-id}: Delete a document

The content is only fetched when explicitly requested by a unique document ID. This explicit separation prevents the system from accidentally coupling the two workloads. It also creates a stable contract that allows the frontend and backend to evolve independently.

Beyond performance, the API layer became our enforcement point for security, rate limiting and request validation. We implemented OpenID Connect Authorization Code Flow with Proof Key for Code Exchange (PKCE) for user facing single-page application (SPA) and OAuth 2.0 Client Credentials Flow for machine-to-machine (M2M) communication, keeping the architecture cloud-agnostic by relying on standards rather than proprietary identity services. Authorization is enforced using Role-Based Access Control (RBAC), with the API layer serving as the policy enforcement point that validates a user’s roles and permissions before granting access to the underlying data stores.

All communication uses TLS 1.2 or higher. Both the metadata datastore and object store have server-side encryption enabled. By relying on standardized protocols and universally available features rather than provider-specific key management services, the architecture remains portable across cloud platforms.

The data modeling decisions that matter

Getting the NoSQL data model right was crucial. Instead of storing verbose strings like “Legal” or “Employment Contract” in every metadata record, I used numeric identifiers (e.g., 101 for “Legal,” 10110 for “Employment Contract”) that reference a separate, cached category table. This normalization reduced storage costs and made updates trivial. Want to rename a category or add multi-language support? Update the reference table once instead of millions of document records.

Here’s what a typical metadata record looks like:

{
  "unique_document_id": "aGVsbG93b3JsZA==",
  "member_id": "123456",
  "file_name": "employment_contract.pdf",
  "document_category_id": 101,
  "document_subcategory_id": 10110,
  "document_extension": ".pdf",
  "document_size_in_bytes": 245678,
  "date_added": "2025-09-20T12:11:01Z",
  "date_updated": "2025-09-21T15:22:00Z",
  "created_by_user_id": "u-01",
  "updated_by_user_id": "u-02",
  "notes": "Signed by both parties"
}

For query patterns, I leveraged secondary indexes aggressively. While the primary table uses the unique document ID as its key, a secondary index organized by member ID and document category enables efficient queries like “retrieve all documents of a certain category for a given member” without expensive table scans.

The schema-on-read model of NoSQL proved invaluable for evolution. When we needed to add a new optional metadata field, there was no risky ALTER TABLE statement or downtime. New documents simply started including the attribute, while existing documents continued working without it. This agility allowed us to respond to new requirements in hours instead of weeks.

Building in disaster recovery and data resiliency

A comprehensive disaster recovery strategy was essential for business continuity. I incorporated resiliency at both the metadata and content layers.

For the metadata store, I enabled Point-in-Time Recovery (PITR), a feature available across major managed NoSQL services. PITR continuously backs up data, allowing the database to be restored to any specific second within a retention window (typically 7 to 35 days). This protects against logical data corruption from accidental writes or deletions.

For document content, I implemented object versioning and cross-region replication. Versioning preserves previous versions of files, protecting against accidental overwrites or deletions. Cross-region replication automatically copies objects to a storage in a different geographical region, ensuring data availability even during a regional outage.

This multi-layered approach to disaster recovery — combining PITR for metadata with versioning and replication for content — provides robust protection against a wide range of failure scenarios.

Managing the long-term lifecycle

One critical design decision was how to handle deletions. Rather than flagging records as deleted in the active table, I implemented an “archive-on-delete” pattern. When a document is deleted, its metadata record moves entirely to a separate archive table, while the file transitions to low-cost archival storage tiers like Amazon S3 Glacier, Azure Blob Storage Archive or Google Cloud Storage Archive.

This approach keeps the active metadata table lean and fast by containing only active records. It also drives significant cost savings — archival storage costs a fraction of standard storage, and we’re not paying for hot database capacity to store cold data. All major cloud providers support these archival tiers with similar pricing models, so the pattern remains cloud-agnostic.

The trade-offs worth making

No architecture is perfect, and this one embraces eventual consistency as a deliberate trade-off for horizontal scalability. In practice, this means there’s occasionally a sub-second window where a newly written document might not immediately appear in a query if it hits a different database replica.

For our use case — a document management system where humans are the primary users — this delay is imperceptible. For the rare programmatic workflows requiring immediate read-after-write consistency, NoSQL services typically offer strongly consistent reads on demand, though at slightly higher latency and cost.

This architecture isn’t ideal for every scenario. If you need complex, ad-hoc transactional queries across many metadata attributes, a traditional relational database might be better. But for high-volume content repositories, digital asset management and customer-facing applications with read-heavy workloads, the scalability and cost benefits are transformative.

The results: Performance and economics

The performance testing validated the architectural decisions. Under sustained load exceeding 4,000 requests per minute, our metadata retrieval API (returning 214 documents per member) maintained excellent performance:

Table 1. Performance metrics under sustained load

The cost model was equally compelling. For a system managing 10 million documents with an average file size of 100KB (1TB total storage), handling 20 million metadata reads and 1 million uploads per month, the estimated costs are remarkably similar across major cloud providers:

Table 2: Estimated monthly cost comparison (10M documents, 1TB storage) as on October 4^th, 2025

The pay-per-request serverless model means costs scale directly with usage, avoiding payment for idle capacity. This represents a dramatic reduction compared to traditional approaches requiring provisioned database compute resources for peak load.

Conclusion: A reusable pattern for modern document management

The separation of metadata and content workloads, enforced through an API-first architecture, proved to be a transformative approach for building a scalable, performant and cost-efficient document management system. By treating metadata as an OLTP workload optimized for a NoSQL database and content as bandwidth-intensive operations suited for object storage, we achieved true horizontal scalability with predictable low-latency performance.

The architecture’s cloud-agnostic design — relying on open standards for security and universally available managed services — ensures portability and resilience. The comprehensive disaster recovery strategy, combining PITR for metadata with versioning and replication for content, provides robust protection without vendor lock-in.

The empirical results validate the approach: sub-300ms query latency under heavy load, zero errors and monthly operational costs under $40 for a system managing 10 million documents. The deliberate trade-off of eventual consistency for scalability proved acceptable for our use case, with strongly consistent reads available when needed.

This architectural pattern represents a reusable blueprint that organizations can adopt to modernize their document management systems. By packaging these design principles, implementation patterns and infrastructure-as-code into a standardized template, teams can accelerate their adoption of cloud-native architectures and focus immediately on business logic rather than infrastructure complexity. The result is a foundation for next-generation document management systems capable of enterprise-scale performance and efficiency.

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

Software development is fraught with peril. For any development task, there are a million ways to do it wrong, and the one correct way is a small, narrow trail that winds quietly through the forest. It takes experience to know the path and to avoid the dangerous pitfalls along the way.

The following is a list of seven hard-won lessons from many trips into the dark forest. It is an opinionated look at what to do and what not do when navigating the treacherous trail of coding an application.  It’s far too easy to stray from the correct path, and these notions will help you stay on course and arrive safely at your destination with a minimum of snags, missteps, and misadventures.

Follow this advice and avoid the brambles.

Look both ways before crossing a one-way street

In the United Kingdom, they drive on the “wrong” side of the road. The Brits realize that visitors are not always aware of that, because on the crosswalks in London, there is text painted on the ground as you step off the curb that says “Look right.” Being American, my habit is to look left, so I appreciated the advice.

PxHere

But I couldn’t shake the habit, so I ended up looking both ways. 

And I realized that looking both ways was a good metaphor for coding: Protect against the impossible, because it just might happen. Code has a way of surprising you, and it definitely changes. Right now you might think there is no way that a given integer variable would be less than zero, but you have no idea what some crazed future developer might do. 

Go ahead and guard against the impossible, and you’ll never have to worry about it becoming possible.

Never make one thing do two things

Oh man, this is my personal pet peeve. There is no end to the trouble caused by having one thing do more than one thing. 

If you’re ever tempted to reuse a variable within a routine for something completely different, don’t do it. Just declare another variable. If you’re ever tempted to have a function do two things depending on a “flag” that you passed in as a parameter, write two different functions. If you have a switch statement that is going to pick from five different queries for a class to execute, write a class for each query and use a factory to produce the right class for the job.

It might take a bit more coding, but please know that the complexity created by giving one thing more than one responsibility (as Uncle Bob Martin would put it) is just begging for trouble down the road. 

Code against interfaces, not implementations

It’s all too easy—and all to common—to couple your code to specific implementations. You start out with an application that does all its logging to a text file. That works great in the early stages, but pretty soon your application is running on multiple machines, and now those text files are everywhere and hard to track and manage. You decide to log to a central database and soon realize that it is a very large job to change from writing to a text file to writing to a database.

If only you had coded your logging system against an interface. Then, when presented with the problem above, you could just write a new implementation of the logging interface, plug that in, and voilà! Problem solved!

It’s always easier to plug a new implementation into an interface than it is to pull out a deeply coupled implementation, the tentacles of which are entangled deeply within your application.

Fear not the explaining variable

Consider the following code.

if (
  (user.age > 18 && user.hasValidID) &&
  (!user.isBanned || user.hasAppealPending) &&
  (currentDate >= event.start && currentDate 

This code is complex and really hard for my brain to parse. It requires you have to mentally unpack each boolean expression, keeping track of what is going on in the parentheses. It’s quite a bother and really hard to figure out.

This code is much easier to understand: 

const isAdultWithID = user.age > 18 && user.hasValidID;

const isAllowedDespiteBanStatus = !user.isBanned || user.hasAppealPending;

const isEventOngoing = currentDate >= event.start && currentDate 

Each of the complex Boolean variables is given a good, explanatory name so that the notion of whether a given user qualifies for entry or not can be easily understood. Don’t be afraid to do that.

Ruthlessly root out the smallest of mistakes

I follow this rule religiously when I code. I don’t allow typos in comments. I don’t allow myself even the smallest of formatting inconsistencies. I remove any unused variables. I don’t allow commented code to remain in the code base. If your language of choice is case-insensitive, refuse to allow inconsistent casing in your code.

Take care of these kinds of small things and the bigger problems will take care of themselves. 

Implicitness is evil

This is something that I have never understood—why some developers view implicitness as a virtue. I find it amazing that anyone would choose to be less clear rather than more clear.

Implicitness increases cognitive load. When code does things implicitly, the developer has to stop and guess what the compiler is going to do. Default variables, hidden conversions, and hidden side effects all make code hard to reason about. 

Because one can’t always guess right, eliminating the need to guess by making things explicit makes for better code.

Limit scope as much as possible

Everyone knows — or everyone should know at least — that global variables are to be strictly avoided.  They can too easily get out of control, be changed in places you least expect, and mysteriously have strange values. 

Or, put another way, their scope is too large.  Thus, the principle of limiting scope says that global variables are a no-no.

But that principle can apply more broadly. Limit the visibility of fields in your class as much as possible.  Use private if you can.  Declare all your variables at the last minute if your language supports the notion of inline variables.  Don’t let those pesky variables get out of hand by exposing them to places they have no business being available. 

So there are a few ways to make sure that your code stays under control.  These lessons are hard won through both experience of doing it wrong, and even more prevalent, from having to maintain code that was written by folks who hadn’t learned these lessons.

Follow these habits, and that bramble-filled trail gets a lot easier to walk.

Clojure is one of the most fascinating branches of the programming family tree. It unites the high-design heritage of Lisp with practical, modern capabilities. For Java developers, Clojure can be an excellent expansion of their worldview. It offers an entirely different way of understanding and solving problems, while still running on the JVM and interoperating with Java.

The four key concepts of Clojure

The following four concepts are vital for understanding Clojure:

• Code as data
• Functional programming
• Immutability
• Concurrency

Let’s look at each of these in turn.

Code as data

The most remarkable thing you might notice when coming to Clojure from Java is that it is homoiconic, which means the code is written in the form of the language’s data structures. This practice, also known as code as data, results in very consistent syntax with a limited number of keywords and constructs. It also creates a meta-programming model using “syntax-aware” code templates (called macros).

The idea is that any snippet of Clojure code is also an instance of Clojure data. You will see this most frequently in the list syntax, because most of Clojure is written as lists. Here is a simple “Hello, InfoWorld” function in Clojure:

(defn hello-infoworld [] 
  (println "Hello, InfoWorld"))

The parentheses indicate a list in Clojure. So, the definition of this function is essentially just the definition of a list with a keyword (defn), a function name (hello-infoworld), an empty argument vector ([]), and the function body. The function body is also a list containing a function call (println) and the argument to that function (“Hello, InfoWorld”).

A list literal (defined with ()) is also how we define functions in Clojure. The [] vector is used specifically for data, rather than code execution, and is similar to the Java ArrayList.

Functional programming

Java has gradually become more versatile as a functional programming language, but Clojure was built from the ground up with functional programming principles in mind. In Java, the core concept is the object, whereas in Clojure it’s the function. In functional programming languages, the function is the most fundamental block of reusable functionality, and functions are first-class citizens that can be referenced with variables, returned as values, and passed as arguments (also known as higher-order functions).

In object-oriented programming, you combine state and behavior into objects. This is a very natural and intuitive model, and easy to understand. But as a software system becomes more complex, it can produce unexpected difficulties. These “programming-in-the-large” drawbacks have made functional programming more popular over time. It can be more challenging, initially, to grasp functional programming concepts, because you don’t have the object model to conceptualize with, but they are well worth learning.

Clojure is a great language for learning functional programming. For example, here is a (contrived) example of a function that takes another function as an argument:

(defn formal-greeting [name]
  (str "Greetings, " name "."))

(defn informal-greeting [name]
  (str "Hey, " name "!"))

;; A "higher-order" function:
argument
(defn greet [greeting-fn name]
  (greeting-fn name))

;; --- Using it ---

(greet formal-greeting "Dr. Smith")
;=> "Greetings, Dr. Smith."

(greet informal-greeting "Alex")
;=> "Hey, Alex!"

In Clojure, anything after a semicolon is not parsed, but used for comments. So, the ;=> is just a conventional way of noting the return of the function call. It’s also important to know that at the end of a function, the final expression is evaluated as the return value (so no “return” keyword is used). With these two points in mind, the above code is relatively easy to understand.

Read next: The top 4 JVM languages and why developers love them.

Immutability

The Clojure documents reflect a programming philosophy that has been deeply thought out. Here is what the documents have to say about immutability, or the separation of identity and state:

We need to move away from a notion of state as “the content of this memory block” to one of “the value currently associated with this identity”. Thus an identity can be in different states at different times, but the state itself doesn’t change. That is, an identity is not a state, an identity has a state.

A later statement in the document makes the point more concretely: “In Clojure’s model, value calculation is purely functional. Values never change. New values are functions of old, not mutations.” What this tells you is that functions are designed to accept and return values, not identities. That is different from object-oriented languages like Java, where objects are often passed in by reference, meaning the function can operate on the state of the object, creating side-effects, or effects on something outside of the function’s return value.

In Java, running the same function with the same input (the object reference argument) can produce different results, because the object’s state can be different. In Clojure, we avoid this possibility because functions only take or return values or other functions.

Clojure also uses immutable operations where data structures are commonly recreated to produce changes, instead of inline mutations like Java often uses. (This may sound inefficient, but Clojure is designed to handle this by sharing structures.)

Here is an example of adding to a collection:

;; `original-numbers` is an identity with the value `[1 2]`
(def original-numbers [1 2])

;; The `conj` function returns a NEW vector.
(def new-numbers (conj original-numbers 3))


original-numbers
;=> [1 2]  -- Unchanged original collection

new-numbers
;=> [1 2 3] -- A new collection with the joined values

The new part here is the conj function, which is Clojure’s universal mechanism for adding elements to a collection. It works for lists, sets, and maps. Here, we’ve just added 3 to the existing [1,2].

Because of Clojure’s immutability principle, this code creates a new Vector. This is because the original-numbers variable is an identity, which does not ever change. You can use the identity to produce new identities with new values based on it, but you can’t change it.

In Clojure, there is no direct reassignment of variables like there are in Java. Variables are created with an initial value, or they are produced by function results.

Concurrency

Concurrency is one of Clojure’s main goals. Immutability helps to make it simpler, but eventually we still need to deal with shared state, where many threads may access the same memory concurrently. Clojure includes several powerful concepts for managing shared state:

• Atoms: A simple mechanism for allowing a single value to be accessed safely by multiple threads. The developer just defines a normal function, and Clojure handles all the locking under the hood (though technically, it’s not locking, but “compare-and-swap” or CAS).
• Refs: A sophisticated “software transactional memory” system that allows for transactions on shared values, with commit and rollback operations similar to those in databases.
• Futures: A simple mechanism for offloading a chunk of work to another thread and retrieving the value at a later time.
• Promises: A way to wait for the completion of an asynchronous task executing on another thread.

Clojure is suited for all kinds of concurrent programming, from very simple to highly advanced. Here’s a simple example of how we might use an Atom to handle a multithreaded counter value:

;; Create an atom to hold the counter (initially 0)
(def counter (atom 0))

;; Define a function for one thread's worth of work
;; `swap!` atomically applies the `inc` function to the atom's value.
(defn do-work []
  (dotimes [_ 1000]
    (swap! counter inc)))

;; Use `future` to run our work on two separate threads
(def thread-1 (future (do-work)))
(def thread-2 (future (do-work)))

;; Dereferencing them with @
@thread-1
@thread-2

;; Read the final value of the atom
(println "Final count:" @counter)
;=> Final count: 2000

In this snippet, the @ character is syntax for “dereferencing” the threads, which in essence means to block on them, waiting for their completion (the completion of the futures).

The built-in swap! function and atom variable work together to safely allow mutating the state of the counter across threads. swap! and its related reset! function are special (as denoted by the exclamation mark), tasked with handling thread-safe access to the atom container.

The future function lets us run the work on a worker thread. The overall effect is easy to follow, and an effective use of multithreading with a single shared variable.

Conclusion

Clojure is a different way of thinking about programming, but it is a fully realized platform that offers a powerful conceptual and practical approach to modern software. This article touched on only the most fundamental aspects of Clojure. There is much more to discover, including the REPL interactive development command line and excellent, higher-level Clojure libraries used for common needs like web and enterprise development.

Text editors and IDEs tend to inspire devotion from their users. Vim and Emacs have long-standing power-user bases. Visual Studio Code, despite being far newer, has exploded in popularity thanks to its cross-platform support and overall flexibility. Any new editor, like any new programming language, faces a lot of incumbent competition.

Zed, a new editor built using Rust, is being pitched by its creators as “a next-generation code editor designed for high-performance collaboration with humans and AI.” Originally only available for Mac and Linux systems, it’s recently been released for Microsoft Windows, allowing a much broader base of users to try it out.

Zed should still be considered a pre-release offering; the release I looked at for this review was version 0.212.4. But enough features are in place to give a sense of what working with Zed is like, and how its approach differs from VS Code and other editors in the same class.

Setup and configuration

If you’re an existing VS Code user, when you run Zed for the first time, you can elect to import your VS Code or Cursor settings into Zed. This covers things like the projects you’ve recently worked on, but it doesn’t extend to Zed-specific settings like extensions, which are handled differently (more on this later).

Multiple themes are available out of the box, each with light and dark modes, and you can set Zed to use a base keymap derived from other popular editors—not just VS Code, but JetBrains products like IntelliJ IDEA and PyCharm, as well as Sublime Text, Atom, Emacs, and Cursor. Vim users can also activate a “Vim mode” and use modal command-based editing. It’s a nice touch that you can go back to this setup pane anytime and re-apply the settings.

Look and feel

A widely touted advantage of Zed is that it’s a platform-native application. Unlike VS Code, Zed doesn’t use Electron or another web-view wrapper; instead, it uses native GPU-accelerated code to render the UI. Everything resizes and reformats without jank, including multi-megabyte text files.

Foundry

Zed’s layout echoes most other modern editors. Files open in tabbed panes with panels on the sides, and the panels can be toggled on and off. By default, panels include a file browser for the directory currently in context as a project, real-time collaboration, outlining, version control, terminals, debugging/breakpoints, editor-wide notifications, and an interface for Zed’s agent. All can be redocked at the sides, although only some (such as the terminal panel) can be docked at bottom.

The top border of the editor doesn’t have an application context menu visible by default; instead, it shows the current project’s info. Click it and you get a neat quick-switch menu to bring any other instances of Zed into focus. To expose the menus, you click a hamburger icon at top left or hit F10.

If you’ve imported settings from another editor, you may find some of them don’t map directly to Zed. For instance, toggling word wrap in a file in VS Code is done with Alt-Z. In Zed, even with VS Code settings migrated, it’s Ctrl-K, Z.

AI integration

Zed has its own large language model for making edit predictions with code, called Zeta. It’s on by default, so I let it prompt me with suggestions while writing a sample Python application in Zed (a simple wiki that renders Markdown to HTML with templates).

Like most such tools currently, Zeta’s predictions are hit-or-miss. When writing the more boilerplate parts of the program, it offered some surprisingly accurate and useful code snippets. But anything outside of that only got in the way, so I toggled it off after writing the most predictable parts of the program. The model also tended to mangle the levels of indentation in inserted code, which is a big problem in Python.

Foundry

Zeta will collect training data from your codebase, but only if it identifies a compatible open source license file. Otherwise, collection is off by default. You can also toggle which kinds of files get edit predictions, or how aggressive they are—for example, you can instruct Zeta to only offer hints if the LSP for the language you are writing in doesn’t offer anything.

Also see: How AI is transforming IDEs into intelligent development assistants.

Two thousand predictions can be served on the free tier, with use-billed predictions available on the $10-a-month Pro plan. You can also connect Zed to most any other external agent (e.g., Claude Code) and use that. A handy kick-out panel lists all the major agents and services you can connect with.

Finally, you can disable all of Zed’s AI features by throwing a single switch.

Collaboration

Zed’s collaborative features are also baked into the product, not added by way of a plugin. Sign in with your GitHub credentials, and you can create or join a hierarchical set of “channels,” or virtual workspaces.

Channels have a default document, which can be edited in a shared manner by anyone with channel permissions. Projects you’re working on can be shared through a channel, which becomes shared-editable with people you choose. Channels also function as group voice-chat systems like what you might use on Discord or Slack.

Zed’s creators have noted that “Collaboration as it stands today is considered alpha, and for the time being, is free for all to use!” That, of course, leaves open the possibility that collaboration will become a paid feature in the future. It may also be possible in the future to self-host collaboration, but there is currently no officially supported path to doing so.

Extensions

Zed resembles VS Code, and many other modern editors, in that the user can expand its functionality with third-party extensions. Even at this early stage of its development, Zed has a surprising number of extensions available, even for relatively niche uses. For instance, there’s an extension for syntax highlighting for code used by Python’s Cython package.

Some functionality one might expect by way of extensions is baked directly into Zed, such as Python support. One downside of this setup is that any upgrades are tied to updates to Zed itself. But even in this early version, Zed is updated quite frequently.

Another possible issue with the way Zed handles extensions is, there’s no mechanism for toggling them on or off on a per-project basis. To disable an extension, you have to uninstall it completely. (There is an open feature request to change this.)

Conclusion

There’s no question Zed provides a comfortable and performant experience for the developer, delivered in a more economical, platform-native package than web-UI projects like VS Code. It’s also clear the core of Zed—the editor itself, and most of its extensions—will remain free.

What’s still up in the air is how much of the rest of Zed’s feature set will eventually become a paid option (the language model and collaborative editing in particular), and how that will in time compete with the existing ecosystem of similar tools, both free and for-pay. For now, though, Zed is well worth taking for a test drive.

Google has introduced the Gemini 3 AI model, an update of Gemini with improved visual reasoning, and Google Antigravity, an agentic development platform for AI-assisted software development.

Both were announced on November 18. Gemini 3 is positioned as offering reasoning capabilities with robust function calling and instruction adherence to build sophisticated agents. Agentic capabilities in Gemini 3 Pro are integrated into agent experiences in tools such as Google AI Studio, Gemini CLI, Android Studio, and third-party tools. Reasoning and multimodal generation enable developers to go from concept to a working app, making Gemini 3 Pro suitable for developers at any experience level, Google said. Gemini 3 surpasses Gemini 2.5 Pro at coding, mastering both agentic workflows and complex zero-shot tasks, according to the company. Gemini 3 is available in preview at $2 per million input tokens and $12 per million output tokens for prompts of 200K tokens or less through the Gemini API in Google AI Studio and Vertex AI for enterprises.

Google Antigravity, meanwhile, shifts from agents embedded within tools to an AI agent as the primary interface. It manages surfaces such as the browser, editor, and the terminal to complete development tasks. While the core is a familiar AI-powered IDE experience, Antigravity is evolving the IDE toward an agent-first future with browser control capabilities, asynchronous interaction patterns, and an agent-first product form factor, according to Google. Together, these enable agents to autonomously plan and execute complex, end-to-end software tasks. Available in public preview, Antigravity is compatible with Windows, Linux, and macOS.

With Antigravity, developers act as the architect, collaborating with agents that can execute processes from end-to-end coding tasks to complex research, Google said. Antigravity provides progress reports and verification. Google said the agent improves over time based on user feedback on code, plans, and designs. Built-in memory enables the agent to get smarter on each project.

Although the C# 14 language was formally launched along with the .NET 10  framework a week ago, Microsoft has put the language update in view again. C# 14 features extension members, a new syntax for declaring extension properties and extension methods. Overall, C# 14’s enhancements improve developer productivity and performance, the company said.

In a November 17 blog post, Microsoft introduced introduced C# 14, the latest update to the company’s popular object-oriented language for .NET, and described extension members as the headline feature. Extension methods allow developers not only to declare extension properties and extension methods, but also to declare extension members that extend the type, rather than an instance of the type. These new extension members can appear as static members of the type extended. Extensions can include user-defined operators implemented as static extension methods.

Also in C# 14 is a set of capabilities designated as offering more productivity by reducing friction for everyday tasks. These capabilities eliminate boilerplate, remove common conditional blocks, simplify lambda declarations, enhance partial types for source generators, and make nameof more expressive in generic scenarios, according to Microsoft. Typing is reduced and developers get cleaner code, fewer trivial identifiers, and code that communicates intent more cleanly. These capabilities include the following:

• The field keyword, previewed in .NET 9, maintains auto‑property terseness and injects minimal logic only where needed.
• nameof accepts an unbound generic type. This eliminates the need to choose an arbitrary type just to retrieve the generic type’s name.
• The null-conditional member access operators, ?. and ?[], now can be used on the left-hand side of an assignment or compound assignment.
• Large generated or source‑generated partial types now can spread event and constructor logic across files. This enables generators or different files to contribute cleanly.

For performance, C# 14 adds implicit conversions among arrays, spans, and read-only spans. This means less ceremony has to be written and the JIT (just-in-time) compiler sees simpler call graphs. That results in fewer temporary variables, fewer bounds checks, and more aggressive inlining in the framework, Microsoft said. Also, C# 14 lets developers declare a compound assignment operator explicitly so that the compiler dispatches directly to the developer’s implementation.

Users of the Go language can expect improved support for AI coding agents in the coming year, according to the Go team. Also in the works is an overhauled go fix command that promises greater developer productivity.

In a November 14 blog post marking the 16th anniversary of Google’s open source release of Go as an experimental language, the Go team noted development plans for the year head. Deeper support for AI coding agents was among the items mentioned. The team said it has been working to provide “well-lit paths” for building with Go and AI, evolving the language platform with care for the evolving needs of today’s developers, and building tools and capabilities that help both human developers and AI assistants and systems alike.

The upcoming Go 1.26 release, meanwhile, will include a total overhaul of the go fix command, a tool that uses static code analyzers to find old idioms and suggests modern replacements. With Go 1.26, expected to be released in February 2026, go fix — currently a dormant command with obsolete analyzers — will feature a suite of new analyzers that will suggest fixes that use newer features of the Go language and library. Also planned for Go are ongoing improvements to the gopls language server and the VS Code Go extension.

Other goals for Go include:

• General availability of the Green Tea garbage collector, which promises to reduce workload times. It was featured in an experimental status in Go 1.25.
• Native support for Single Instruction Multiple Data (SIMD) hardware features.
• Runtime and standard library support for writing code that scales better to massive multicore hardware.
• An upgrade to encoding/json, featuring a new API.
• Goroutine leak detection via garbage collection.

What is A2A?

A2A, short for agent-to-agent, is an open, vendor-neutral protocol that allows autonomous AI agents to communicate, coordinate, and delegate work to one another. Most agents today are built as isolated systems, each with its own framework, API conventions, and assumptions.

A2A defines a shared language and handshake process so they can interoperate. The goal isn’t to reinvent what existing standards do, but to fill the gap between how agents perform tasks and how they collaborate on them.

Matt Hasan, CEO of aiRESULTS, calls A2A a game-changer. “It moves the AI conversation from ‘Can a single agent do this task?’ to ‘How can a team of specialized agents collaborate on a complex business workflow?’,” he says.

The initiative originated at Google, which introduced the open-source specification in April 2025 to promote interoperability across the growing ecosystem of autonomous agents and connect agents built on diverse platforms. The goal was to help developers avoid the brittle integrations that made it difficult for early versions of AI agents to interact.

“In theory, A2A is a universal standard of communication and etiquette for AI agents,” Hasan says. “In practice, it’s the architectural blueprint that finally makes complex, vendor-agnostic multi-agent systems feasible for the enterprise.”

By creating a shared foundation for discovery, messaging, and task delegation, A2A enables agents from different vendors and developers to work together on multi-step workflows without custom middleware. That interoperability is what gives the protocol its significance: rather than building one monolithic super-agent, organizations can assemble a network of specialized ones that understand each other out of the box—and can communicate with external agents as well.

How does A2A work?

A2A defines how agents talk to each other and share standardized information about their capabilities. “The technology’s most critical aspect is the task object, which formalizes the delegation of work,” says aiRESULTS’s Hasan. “When we adapt an existing AI agent to use A2A, we essentially wrap its specialized capability in an agent card — a public metadata file that describes what it can do. This allows a client agent to discover, send a structured task request, and securely monitor the status of that work from a remote agent, regardless of whether the remote agent was built with LangChain, a custom Python framework, or a vendor-specific SDK.”

This is deliberate. A2A is designed as a protocol layer for interoperability, not a runtime, model, or orchestration framework. It defines a clear handshake and message structure that any compliant system can use. But each communicating agent remains a black box (Google uses the term “opaque”) to the other: neither needs to know the internal logic or model architecture that produces results.

In fact, there’s nothing in the spec requiring that an “agent” even be an AI system — any process or human participant can function as one, so long as it can send and receive properly formatted messages. A human operator completing a workflow like the original Mechanical Turk could, in theory, be an A2A agent if they follow the protocol’s structure.

This adaptability is what allows A2A to scale beyond simple demo agents into robust enterprise environments. It provides a predictable surface for discovery and execution without prescribing how the work is done. In that sense, A2A resembles the web itself: a shared protocol layer that lets heterogeneous systems cooperate through standardized requests and responses.

“This structured delegation drastically simplifies building long-running, multi-step workflows — like a complex financial compliance check or a multi-modal recruiting pipeline — by solving the problem of interoperability,” Hasan says.

The four core A2A data shapes

A2A organizes communication around four primary object types, each representing a distinct phase in the workflow:

1. Agent card. A small JSON file (agent.json) that publicly describes an agent’s identity, capabilities, authentication methods, and optional digital signature. Other agents read these cards to discover potential collaborators and verify trust.
2. Task.  A structured work request that includes a unique task_id, an input payload, and metadata about priority, expiration, or required modalities. The task defines what needs to be done and serves as the anchor for all subsequent communication.
3. Message. A stream of status updates and intermediate information about the task. Messages carry progress indicators, requests for additional input, or contextual notes, and are typically transmitted over SSE or gRPC streams.
4. Artifact. The result of the completed task. Artifacts can contain text, files, or structured data. They finalize the transaction and can be stored, validated, or chained into another Task for further processing.

In a typical exchange, the requesting agent first retrieves an agent card to confirm another agent’s capabilities and supported protocols. The requesting agent is referred to as a client, and the agent that it’s interrogating about services is called a server, but these aren’t permanent states: an agent may act as a client in one context and a server in another, and in fact the two might switch roles in the course of a single interaction.

At any rate, the client agent issues a createTask request, which the server agent acknowledges by returning a task_id. As the task runs, the provider streams Message objects that indicate status or request clarification. When the work is finished — or if it fails — the provider emits one or more Artifact objects, along with a completion code.

Because every step adheres to the same schema, any compliant agent can participate in this conversation without custom adapters. An LLM-based planning agent might delegate a data-collection task to a Python microservice; that service could, in turn, trigger a human-in-the-loop agent to review the output — all communicating through A2A messages.

A2A design principles

The A2A protocol borrows lessons from decades of internet engineering, applying principles familiar from standards like HTTP, REST, and OAuth to the emerging world of autonomous systems.

• Interoperability. A2A is explicitly framework-agnostic. Agents written in any language or framework — whether built with LangChain, OpenDevin, or a custom SDK — can communicate through the same standardized message schema. This decoupling of implementation from interaction is what makes multi-agent ecosystems possible.
• Transparency. Each agent exposes its functions and limits through a structured Agent card that acts like a capabilities statement. This transparency allows other agents to discover and evaluate potential collaborators without requiring source code access or vendor integration.
• Security. Authentication, authorization, and message integrity are core parts of the specification. A2A supports multiple authentication methods and signed Agent cards so that trust decisions can be made automatically. Every task and message is traceable, creating an auditable record of agent activity.
• Modularity and composability. The protocol treats each agent as an opaque service with well-defined inputs and outputs. Agents can reuse each other’s functions, chaining them together into longer workflows without manual wiring. This modularity mirrors the composable design of APIs and microservices.
• Scalability and resilience. A2A was built for asynchronous, distributed environments. Agents can spawn long-running tasks, stream partial results, and recover from transient network failures. Because the protocol doesn’t dictate runtime behavior, it scales naturally from a pair of local agents to hundreds of cloud-based ones coordinating across domains.

Together, these principles make A2A a common language for distributed intelligence that can evolve as agents, frameworks, and communication technologies change.

Is A2A secure?

Security in A2A operates on two levels: protocol integrity and trust between agents. The specification builds in the same safeguards that protect web-scale APIs — authentication, authorization, and encryption — while adding features to manage how autonomous systems evaluate and respond to one another’s reliability.

Remember, an Agent card describes an agent’s identity, capabilities, and supported authentication methods. Those cards can include digital signatures, allowing client agents to verify the organization that created the server agent before establishing a connection. Once communication begins, tasks and messages are exchanged over secure channels — typically HTTPS, gRPC, or WebSockets — so all payloads are encrypted in transit. The protocol also defines clear response codes and event logs, creating an auditable trail that can be integrated with enterprise observability tools.

The A2A protocol has mechanisms for error handling. “The failing agent sends an error code or failure notification back to the requester,” Hasan says. “This allows the requester to immediately switch to a different, more reliable agent to get the job done.”

This plumbing can lay the groundwork for more advanced behavior, he notes. “Individual agents (or networks of them) can implement their own tracking, keeping score of who’s reliable, sharing that info, or even publishing trust ratings so others can make smarter choices. Repeated failures cause that score to drop. Eventually, other agents will simply stop asking the unreliable agent for help.”

That self-regulating behavior is essential for large-scale multi-agent systems, where no central controller can vet every participant. A2A’s trust model allows poor-performing or malicious agents to be automatically isolated, while reliable ones gain credibility through successful interactions.

Still, A2A’s open design raises questions familiar to anyone familiar with the dilemmas of cybersecurity. How should organizations authenticate third-party agents that claim certain capabilities? What happens if two agents interpret a schema differently, or if one leaks sensitive data through a malformed message? Identity spoofing, model hallucinations, and version mismatches all pose potential risks that enterprises will need governance frameworks to manage.

For most deployments, A2A security will depend on layering protocol-level controls with operational ones: requiring signed Agent cards, managing API keys or OAuth tokens through a centralized broker, and maintaining reputation databases to record agent reliability across the environment. Over time, these practices could evolve into standardized trust registries—much like certificate authorities on the web — forming the basis for secure, auditable agent ecosystems.

Real-world A2A examples

When Google launched the A2A protocol, the company announced support from more than 50 partners, including Atlassian, Box, PayPal, SAP, and many major consultancies. Likewise, Microsoft publicly announced support for A2A in its Azure AI Foundry and Copilot Studio platforms.

Google has also touted real-world rollouts. For instance, Box AI Agents now coordinate with other agents across dozens of platforms via A2A-compliant endpoints. Another example: Twilio uses A2A extensions to broadcast latency information, enabling intelligent routing among agents and graceful degradation when only slower agents are available. While these examples don’t yet reflect fully documented, large-scale production deployments, they demonstrate meaningful adoption beyond the pilot phase into enterprise ecosystems.

The hope is that A2A isn’t just another AI hype protocol, but that it will become a foundational communication layer for multi-agent ecosystems. Organizations that experiment now with publishing agent cards, defining tasks, and streaming results could gain a head start if vendor-agnostic agents become a core part of automation pipelines. Adoption is still early, but the roadmap is there for a world where agents that were once isolated can now speak a common language.

Testing APIs and applications was challenging in the early devops days. As teams sought to advance their CI/CD pipelines and support continuous deployment, test automation platforms gained popularity, and many devops organizations developed continuous testing strategies.

While shifting left on QA, implementing security testing, and increasing observability are now devsecops non-negotiables for many organizations, these practices are not equally deployed across all applications. Legacy applications are lagging due to underlying technical debt, and test automation is still an emerging capability when developing AI agents.

Developing an LLM testing strategy is challenging because the model’s inputs are open-ended and responses are non-deterministic. AI agents couple language models with the ability to take human-in-the-middle and automated actions, so testing decision accuracy, performance, and security is vital for developing trust and growing employee adoption.

As more companies evaluate AI agent development tools and consider the risks of rapidly deploying AI agents, more devops teams will need to consider how to automate the testing of AI agents. IT and security leaders will seek testing plans to determine release-readiness and avoid the risks of deploying rogue AI agents.

Developing end-to-end testing strategies

Experts view testing AI agents as a strategic risk management function that encompasses architecture, development, offline testing, and observability for online production agents. The approach enables continuous improvement as AI models evolve, and the agent responds to a wider range of human and agent-to-agent inputs in production.

“Testing agentic AI is no longer QA, it is enterprise risk management, and leaders are building digital twins to stress test agents against messy realities: bad data, adversarial inputs, and edge cases,” says Srikumar Ramanathan, chief solutions officer at MPhasis. “Validation must be layered, encompassing accuracy and compliance checks, bias and ethics audits, and drift detection using golden datasets.”

One best practice is to model AI agents’ role, workflows, and the user goals they are intended to achieve. Developing end-user personas and evaluating whether AI agents meet their objectives can inform the testing of human-AI collaborative workflows and decision-making scenarios.

“AI agents are stochastic systems, and traditional testing methods based on well-defined test plans and tools that verify fixed outputs are not effective,” says Nirmal Mukhi, VP and head of engineering at ASAPP. “Realistic simulation involves modeling various customer profiles, each with a distinct personality, knowledge they may possess, and a set of goals around what they actually want to achieve during the conversation with the agent. Evaluation at scale involves then examining thousands of such simulated conversations to evaluate them based on desired behavior, policies, and checking if the customer’s goals were achieved.”

Ramanathan of Mphasis adds, “The real differentiator is resilience, testing how agents fail, escalate, or recover. Winners will not chase perfection at launch; they will build trust as a living system through sandboxing, monitoring, and continuous adaptation.”

Testing AI agents requires shifts in QA strategy

Testing tools and methodologies are built on the simple premise that a test case is deterministic and is properly developed with criteria that either pass or fail. QA engineers will need to consider broader expressions, such as whether an AI agent’s actions are appropriate and whether it provides similar responses to comparable inputs.

“The biggest misconception about testing AI agents is treating them like traditional applications with predictable outputs,” says Esko Hannula, SVP of robotics at Copado. “AI agents learn and adapt continuously, meaning your testing strategy must evolve from validating exact responses to ensuring response appropriateness and business alignment.”

Traditional API and application testing often utilizes automation testing platforms that run in development and test environments, but separate monitoring tools are used for production errors. So, a second change for testing AI agents is that testing scenarios must be automated to run in development, test environments, and continuously in production. Organizations will want to release new versions of AI agents frequently as LLM platforms release new versions and the agents are improved based on end-user feedback.

“Agentic systems are non-deterministic and can’t be trusted with traditional QA alone; enterprises need tools that trace reasoning, evaluate judgment, test resilience, and ensure adaptability over time,” says Nikolaos Vasiloglou, VP of research ML at RelationalAI. “Agents may quickly be replaced by newer LLMs, so leaders must continually benchmark their custom solutions against frontier models and avoid the sunk-cost fallacy.”

Validating the response accuracy of AI agents

How should QA engineers validate an AI agent’s response when inputs and outputs are not deterministic?

Jerry Ting, head of agentic AI at Workday, shares two recommendations for testing AI agents across the enterprise. “Use AI to create synthetic training data that simulates the messiness of real-life prompts and embedded data. Then, have the same prompt go into different large language models, and orchestrate a tournament of prompts and responses with AI as judges.”

Part of the implementation strategy will require integrating feedback from production back into development and test environments. Although testing AI agents should be automated, QA engineers will need to develop workflows that include reviews from subject matter experts and feedback from other end users.

“Hierarchical scenario-based testing, sandboxed environments, and integrated regression suites—built with cross-team collaboration—form the core approach for test strategy,” says Chris Li, SVP of products at Xactly. “To ensure valid and accurate responses, sandboxed replays, automated and human reviews, and rich audit trails are reliable approaches for full workflow validation. As agentic AI systems scale in complexity, balancing precision, safety, fairness, and performance becomes essential to delivering robust, trustworthy agents capable of operating successfully in real-world environments.”

QA engineers will also need to automate the calculation of an accuracy metric that can be compared across deployments and AI model upgrades. Without these metrics, it will be challenging to know whether a deployment improved the AI agent’s decision-making and recommendation capabilities.

“The real challenge isn’t whether the agent gives the ‘right’ answer—it’s whether it consistently makes decisions that advance your business objectives while respecting security boundaries,” adds Hannula of Copado. “This requires a fundamental shift from deterministic testing to contextual validation that accounts for the agent’s learning trajectory.”

Ensuring AI agents take the correct actions

More organizations will look to automate workflows with AI agents. Testing must consider that an agent may have several plausible actions, and its responses should help justify its recommendations.

“Testing must validate not only the agent’s thinking (its responses), but also its actions (the operations it executes),” says Zhijie Chen, co-founder and CEO of Verdent. “For high-risk, complex, or ambiguous decision-making scenarios, fully automated testing may not guarantee safety and reliability; in such cases, a human-in-the-loop approach provides a strategic layer of assurance.”

How should QA develop and automate testing around the AI agent’s actions? Consider how challenging it can be to evaluate people’s decisions, especially in real time, before actions are undertaken. We look for non-verbal clues and seek opinions from outside experts. Testing an AI agent’s recommended and automated actions may require a similar approach.

Mike Finley, co-founder of StellarIQ, says, “One key way to automate testing of agentic AI is to use verifiers, which are AI supervisor agents whose job is to watch the work of others and ensure that they fall in line. Beyond accuracy, they’re also looking for subtle things like tone and other cues. If we want these agents to do human work, we have to watch them like we would human workers.”

Establishing release-readiness practices

AI agents encompass the complexities of applications, automations, and AI models when evaluating their security and operational readiness for production. Many organizations are just getting started with AI agents, and fewer than 5% have reached production. Experts weighed in on security and operational recommendations.

Rishi Bhargava, co-founder of Descope, recommends pressure-testing AI agents against all the OWASP top 10 for LLM applications during automated testing. These include:

• Test that AI agent connections with third-party tools and enterprise systems follow recommended implementations of standard protocols such as MCP and OAuth.
• Test for AI agent permissions and ensure the agent’s permissions are a subset of the bound user’s permissions at all times.

Andrew Filev, CEO and founder of Zencoder, shares how security considerations for AI agents extend beyond deterministic systems, such as applications and automations. Andrew says, “You’ve got prompt injection attacks, model manipulation, context poisoning, adversarial inputs, and data extraction attempts—basically a whole new category of vulnerabilities that most security teams may not yet have on their radar.”

Filev also says that performance testing is tricky because devops teams must do more than evaluate response times, and must consider the following questions:

• Can the agent maintain quality and consistency when it’s being hammered with requests?
• Does the underlying AI model start hallucinating under load?
• How should teams architect performance testing without overspending on API costs?

A good place to start is with practices that should already be in place for validating the release-readiness of applications and AI models. Ian Beaver, chief data scientist at Verint, shared thes following recommendations:

• Collect detailed AI agent audit logs and record every interaction and action, allowing for inspection and correction if needed.
• Follow a policy of least privilege for all APIs and MCP tools to minimize risk.
• Evaluate LLMs for bias and reliability.

“Comprehensive logging, robust monitoring, and user feedback interfaces are even more critical for agents,” adds Beaver.

Automating testing for agentic AI

As challenging as it is to automate AI agent testing, devops teams must also consider how to future-proof their implementations for agentic AI, an objective that’s not fully realized in most organizations. Devops teams will need to use testing frameworks that enable running validations in production and support agent-to-agent communication.

“Perhaps more important than automating the testing of agents is how to best organize and orchestrate agent interactions in a way that both minimizes the possibility of error while also enabling them to recover gracefully in the event of one,” says Sohrob Kazerounian, distinguished AI researcher at Vectra AI. “By decomposing problems into a set of well-specified tasks, you can not only design agents that are more likely to succeed, but importantly, you can create agents that can evaluate and error-correct at each step of the way.”

Probably the most important lesson here is one that most devops teams have learned from developing applications and automations: There’s no free lunch when it comes to testing, and less than half the work is done when the functional code is completed. For teams looking to deploy AI agents, it is essential to consider test-driven approaches to evaluate quality and establish release readiness.

For years, the narrative around artificial intelligence has centered on GPUs (graphics processing units) and their compute power. Companies have readily embraced the idea that expensive, state-of-the-art GPUs are essential for training and running AI models. Public cloud providers and hardware manufacturers have promoted this belief, marketing newer, more powerful chips as crucial for remaining competitive in the race for AI innovation.

The surprising truth? GPUs were never as critical to enterprise AI success as we were led to believe. Many of the AI workloads enterprises depend on today, such as recommendation engines, predictive analytics, and chatbots, don’t require access to the most advanced hardware. Older GPUs or even commodity CPUs can often suffice at a fraction of the cost.

As pressure mounts to cut costs and boost efficiency, companies are questioning the hype around GPUs and finding a more pragmatic way forward, changing how they approach AI infrastructure and investments.

A dramatic drop in GPU prices

Recent reports reveal that the prices of cloud-delivered, high-demand GPUs have plummeted. For example, the cost of an AWS H100 GPU Spot Instance dropped by as much as 88% in some regions, down from $105.20 in early 2024 to $12.16 by late 2025. Similar price declines have been seen across all major cloud providers.

This decline may seem positive. Businesses save money, and cloud providers adjust supply. However, there’s a critical shift in business decision-making behind these numbers. The price cuts did not result from an oversupply; they reflect changing priorities. Demand for top-tier GPUs is falling as enterprises question why they should pay for expensive GPUs when more affordable alternatives offer nearly identical results for most AI workloads.

Not all AI requires high-end GPUs

The idea that bigger and better GPUs are essential for AI’s success has always been flawed. Sure, training large models like GPT-4 or MidJourney needs a lot of computing power, including top-tier GPUs or TPUs. But these cases account for a tiny share of AI workloads in the business world. Most businesses focus on AI inference tasks that use pretrained models for real-world applications: sorting emails, making purchase recommendations, detecting anomalies, and generating customer support responses. These tasks do not require cutting-edge GPUs. In fact, many inference jobs run perfectly on slightly older GPUs such as Nvidia’s A100 or H100 series, which are now available at a much lower cost.

Even more surprising? Some companies find they don’t need GPUs at all for many AI-related operations. Standard commodity CPUs can handle smaller, less complex models without issue. A chatbot for internal HR inquiries or a system designed to forecast energy consumption doesn’t require the same hardware as a groundbreaking AI research project. Many companies are realizing that sticking to expensive GPUs is more about prestige than necessity.

When AI became the next big thing, it came with skyrocketing hardware requirements. Companies rushed to get the latest GPUs to stay competitive, and cloud providers were happy to help. The problem? Many of these decisions were driven by hype and fear of missing out (FOMO) rather than thoughtful planning. Laurent Gil, cofounder and president of Cast AI, noted how customer behavior is driven by FOMO when buying new GPUs.

As economic pressures rise, many enterprises are realizing that they’ve been overprovisioning their AI infrastructure for years. ChatGPT was built on older Nvidia GPUs and performed well enough to set AI benchmarks. If major innovations could succeed without the latest hardware, why should enterprises insist on it for far simpler tasks? It’s time to reassess hardware choices and determine whether they align with actual workloads. Increasingly, the answer is no.

Public cloud providers adapt

This shift is evident in cloud providers’ inventories. High-end GPUs like Nvidia’s GB200 Blackwell processors remain in extremely short supply, and that’s not going to change anytime soon. Meanwhile, older models such as the A100 sit idle in data centers as companies pull back from buying the next big thing.

Many providers likely overestimated demand, assuming enterprises would always want newer, faster chips. In reality, companies now focus more on cost efficiency than innovation. Spot pricing has further aggravated these market dynamics, as enterprises use AI-driven workload automation to hunt for the cheapest available options.

Gil also explained that enterprises willing to shift workloads dynamically can save up to 80% compared to those locked into static pricing agreements. This level of agility wasn’t plausible for many companies in the past, but with self-adjusting systems increasingly available, it’s now becoming the standard.

A paradigm of common sense

Expensive, cutting-edge GPUs may remain a critical tool for AI innovation at the bleeding edge, but for most businesses, the path to AI success is paved with older GPUs or even commodity CPUs. The decline in cloud GPU prices shows that more companies realize AI doesn’t require top-tier hardware for most applications. The market correction from overhyped, overprovisioned conditions now emphasizes ROI. This is a healthy and necessary correction to the AI industry’s unsustainable trajectory of overpromising and overprovisioning.

If there’s one takeaway, it’s that enterprises should invest where it matters: pragmatic solutions that deliver business value without breaking the bank. At its core, AI has never been about hardware. Companies should focus on delivering insights, generating efficiencies, and improving decision-making. Success lies in how enterprises use AI, not in the hardware that fuels it. For enterprises hoping to thrive in the AI-driven future, it’s time to ditch outdated assumptions and embrace a smarter approach to infrastructure investments.

Enterprises have spent the past two years determining which large language model they should use. GPT or Claude? Gemini or an open-source alternative? But as these models begin to converge in terms of quality and capabilities, the question of which model to use becomes less important than how to actually use them.

Ultimately, the real competitive advantage for enterprises won’t come from choosing the right model. It will come from building the right context, including the proprietary data, documents, workflows, and domain knowledge that shape how AI systems reason and act.

We are entering a new discipline known as context engineering: the practice of designing, integrating, and orchestrating the information environment in which AI systems operate. If prompt engineering was about asking better questions, context engineering is about giving AI the foundation to answer them well.

A huge leap beyond prompt engineering

Prompt engineering was the early bridge between human intent and machine intelligence. It taught us a new skill: phrasing instructions in a way that can significantly impact output quality. But prompts alone are shallow, similar to asking for directions without showing a map.

As AI systems evolve into agentic systems capable of reasoning, planning, and executing tasks, they require more than clever phrasing. They need a deeper understanding of where they are, what they know, and the constraints that apply. 

That understanding comes from context.

Context includes everything that shapes intelligent behavior: documents, structured data, memory of previous interactions, workflows, policies, and even unstructured sources such as audio or video. Stitching together all the relevant context and feeding it to AI is what enables AI to make relevant, consistent, and responsible decisions.

In short, we’re moving from a prompted world to a contextual one, and from instructing AI to equipping it.

The challenge of data variety and scale

Building this context layer isn’t simple. For decades, enterprises have struggled to manage structured data from systems such as ERPs, CRMs, and various analytics platforms. Today, the picture is even more complex because context comes from everywhere: chat transcripts, support tickets, sensor feeds, video, contracts, PDFs, and more.

This explosion of data variety has outpaced traditional data engineering methods. AI doesn’t consume static tables; it does much better with live, dynamic information flows. That means organizations must design composable systems that can retrieve, transform, and deliver the right context to the right process, all in real time and at scale.

The scale problem isn’t just about computing power, which has become abundant. It’s about orchestration. When you stitch together dozens of data products, run them across distributed systems, and feed them into AI models, reliability and observability are paramount. Engineers used to spend days restarting failed pipelines or trying to trace lineage across systems. Now, that level of manual intervention simply doesn’t scale.

The next wave of data infrastructure must handle these orchestration challenges automatically by understanding dependencies, monitoring flows, and ensuring that the context being fed to AI is always complete, consistent, and compliant.

Going from data engineering to context engineering

In many ways, context engineering is the natural evolution of data engineering. Where data engineers build systems to collect, clean, and deliver information, context engineers design living data environments, complete with semantics, lineage, and rules.

They don’t just move data; they make it ready for AI consumption. That means packaging data into data products that are secure, well-documented, and embedded with metadata about how they can be used.

Take a financial institution that wants to feed its underwriting models with historical claims data. It needs to mask sensitive information, maintain lineage, and ensure compliance with regulations. Or take a healthcare provider integrating on-premises patient data with cloud-based AI models. It must ensure privacy while still delivering relevant context to the AI system. These are quintessential context engineering problems.

I’ve seen this evolution firsthand, and I’ve found that the goal should be to make data easier to consume, regardless of format or source. The idea is to enable even non-engineers to build and share governed data products, mask personally identifiable information (PII), and document lineage without writing code. This is what context engineering can look like in practice: lowering the technical bar while raising the quality and trust of the data ecosystem.

Teaching AI to operate in complex environments

Context matters for AI as much as it does for human workers. For example, imagine training a human for a complex role at a new company, such as managing procurement for a global manufacturer. It could take months for a new hire to become fully up to speed and understand the specific systems, policies, and nuances the company uses to make decisions. 

AI faces a similar learning curve.

In the same vein, AI agents need the same organizational context that humans rely on to reason effectively, including prior decisions, policies, and examples of exceptions. The better the context, the better the AI will perform.

This doesn’t mean giving AI control of critical systems, such as a general ledger. It means allowing AI to handle the connective tissue—think summarizing reports, flagging anomalies, drafting communications, or optimizing workflows. And it should all be guided by the same context humans would use to make these judgments.

The point isn’t full automation; it’s contextual augmentation. It’s about enabling AI to operate with awareness and reliability in complex, real-world settings.

A shift in methodology

This transition involves more than adding a new toolset; it’s about changing methodology. Traditionally, software and analytics relied on humans to decide what questions to ask, what data to gather, and how to visualize the results. The process was linear and prescriptive.

In the AI-driven world, that model has flipped. We can feed large amounts of contextual data into an intelligent system and let it infer which information is relevant to the outcome we want. Instead of programming every rule, we define boundaries, supply context, and let AI reason within those boundaries.

That’s a fundamentally different way of building software, blending data engineering, governance, machine learning operations, and domain expertise into a single, continuous system. It’s the foundation for truly agentic AI: systems that act with awareness rather than just react to instructions.

Success means lowering the bar for intelligent systems

The real promise of context engineering is access. It opens the door for people beyond data scientists or machine learning experts to work productively with AI. When the underlying systems handle complexity, domain experts such as analysts, product managers, and marketers can focus on applying insight rather than dealing with the complexity of pipelines.

Modern, composable tools make it possible for almost anyone to shape and improve the context behind intelligent systems. They can monitor flows, adjust rules, and refine the data that guides decisions. That’s how enterprises will responsibly scale AI: by making participation broader, not narrower.

The shift we’re seeing isn’t only about building smarter models. It’s about creating smarter ecosystems. Companies that learn to engineer context, connecting knowledge, data, and process into a living system, will be the ones that set the pace for enterprise innovation in the years ahead.

—

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.

Java Development Kit (JDK) 26, a planned update to standard Java due March 17, 2026, has gathered 10 features so far. The following features are officially targeted to JDK 26: a fourth preview of primitive types in patterns, instanceof, and switch, ahead-of-time object caching, an eleventh incubation of the Vector API, second previews of lazy constants and PEM (privacy-enhanced mail) encodings of cryptographic objects, a sixth preview of structured concurrency, warnings about uses of deep reflection to mutate final fields, improving throughput by reducing synchronization in the G1 garbage collector (GC), HTTP/3 for the Client API, and removal of the Java Applet API.

A short-term release of Java backed by six months of Premier-level support, JDK 26 follows the September 16 release of JDK 25, which is a Long-Term Support (LTS) release backed by several years of Premier-level support.

The latest feature to be added, primitive types in patterns, instanceof, and switch, is intended to enhance pattern matching by allowing primitive types in all pattern contexts, and to extend instanceof and switch to work with all primitive types. Now in a fourth preview, this feature was previously previewed in JDK 23, JDK 24, and JDK 25. The goals include enabling uniform data exploration by allowing type patterns for all types, aligning type patterns with instanceof and aligning instanceof with safe casting, and allowing pattern matching to use primitive types in both nested and top-level pattern contexts. Changes in this fourth preview include enhancing the definition of unconditional exactness and applying tighter dominance checks in switch constructs. The changes enable the compiler to identify a wider range of coding errors.

With ahead-of-time object caching, the HotSpot JVM would gain improved startup and warmup times, so it can be used with any garbage collector including the low-latency Z Garbage Collector (ZGC). This would be done by making it possible to load cached Java objects sequentially into memory from a neutral, GC-agnostic format, rather than mapping them directly into memory in a GC-specific format. Goals of this feature include allowing all garbage collectors to work smoothly with the AOT (ahead of time) cache introduced by Project Leyden, separating AOT cache from GC implementation details, and ensuring that use of the AOT cache does not materially impact startup time, relative to previous releases.

The eleventh incubation of the Vector API introduces an API to express vector computations that reliably compile at run time to optimal vector instructions on supported CPUs. This achieves performance superior to equivalent scalar computations. The incubating Vector API dates back to JDK 16, which arrived in March 2021. The API is intended to be clear and concise, to be platform-agnostic, to have reliable compilation and performance on x64 and AArch64 CPUs, and to offer graceful degradation. The long-term goal of the Vector API is to leverage Project Valhalla enhancements to the Java object model.

Also on the docket for JDK 26 is another preview of an API for lazy constants, which had been previewed in JDK 25 via a stable values capability. Lazy constants are objects that hold unmodifiable data and are treated as true constants by the JVM, enabling the same performance optimizations enabled by declaring a field final. Lazy constants offer greater flexibility as to the timing of initialization.

The second preview of PEM (privacy-enhanced mail) encodings calls for an API for encoding objects that represent cryptographic keys, certificates, and certificate revocation lists into the  PEM transport format, and for decoding from that format back into objects. The PEM API was proposed as a preview feature in JDK 25. The second preview features a number of changes, such as the PEMRecord class is now named PEM and now includes a decode()method that returns the decoded Base64 content. Also, the encryptKey methods of the EncryptedPrivateKeyInfo class now are named encrypt and now accept DEREncodable  objects rather than PrivateKey objects, enabling the encryption of KeyPair and PKCS8EncodedKeySpec objects.

The structured concurrency API simplifies concurrent programming by treating groups of related tasks running in different threads as single units of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability. Goals include promoting a style of concurrent programming that can eliminate common risks arising from cancellation and shutdown, such as thread leaks and cancellation delays, and improving the observability of concurrent code.

New warnings about uses of deep reflection to mutate final fields are intended to prepare developers for a future release that ensures integrity by default by restricting final field mutation, in other words making final mean final, which will make Java programs safer and potentially faster. Application developers can avoid both current warnings and future restrictions by selectively enabling the ability to mutate final fields where essential.

The G1 GC proposal is intended to improve application throughput and latency when using the G1 garbage collector by reducing the amount of synchronization required between application threads and GC threads. Goals include reducing the G1 garbage collector’s synchronization overhead, reducing the size of the injected code for G1’s write barriers, and maintaining the overall architecture of G1, with no changes to user interaction.

The G1 GC proposal notes that although G1, which is the default garbage collector of the HotSpot JVM, is designed to balance latency and throughput, achieving this balance sometimes impacts application performance adversely compared to throughput-oriented garbage collectors such as the Parallel and Serial collectors:

Relative to Parallel, G1 performs more of its work concurrently with the application, reducing the duration of GC pauses and thus improving latency. Unavoidably, this means that application threads must share the CPU with GC threads, and coordinate with them. This synchronization both lowers throughput and increases latency.

The HTTP/3 proposal calls for allowing Java libraries and applications to interact with HTTP/3 servers with minimal code changes. Goals include updating the HTTP Client API to send and receive HTTP/3 requests and responses; requiring only minor changes to the HTTP Client API and Java application code; and allowing developers to opt in to HTTP/3 as opposed to changing the default protocol version from HTTP/2 to HTTP/3.

HTTP/3 is considered a major version of the HTTP (Hypertext Transfer Protocol) data communications protocol for the web. Version 3 was built on the IETF QUIC (Quick UDP Internet Connections) transport protocol, which emphasizes flow-controlled streams, low-latency connection establishment, network path migration, and security among its capabilities.

Removal of the Java Applet API, now considered obsolete, is also targeted for JDK 26. The Applet API was deprecated for removal in JDK 17 in 2021. The API is obsolete because neither recent JDK releases nor current web browsers support applets, according to the proposal. There is no reason to keep the unused and unusable API, the proposal states.

Other possible features for JDK 26 include JDK Flight Recorder CPU-time profiling, which would capture more accurate CPU-time profiling information on Linux, and post-mortem crash analysis with jcmd, which would extend the jcmd tool so that it could be used to diagnose a JVM that has crashed.

Microsoft has released Aspire 13, the latest version of the company’s tool kit for building distributed, cloud-native applications. With Aspire 13, Python and JavaScript become “first-class citizens” of the development platform, Microsoft said, with comprehensive support for running, debugging, and deploying applications written in these languages.

Aspire 13 was announced November 11 and is downloadable from aspire.dev.

A full polyglot application platform, Aspire 13 also introduces the aspire do command, which breaks builds and deployments down into parallelizable steps, as well as a Model Context Protocol (MCP) server for AI assistance. For Python, release notes stress support for Python modules, deployment with the Python-based uvicorn web server, flexible package management (uv, pip, or venv), and generation of production Dockerfiles automatically. Improved JavaScript support, meanwhile, centers on Vite and npm-based apps with package manager auto-detection, debugging support, and container-based build pipelines.

The aspire do command, now in an early preview stage, is billed as a complete reimagination of building, publishing, and deploying pipelines. Instead of a monolithic “hit deploy and pray” experience, aspire do breaks everything down into discrete, parallelizable steps with dependency tracking, Microsoft said. Independent operations are automatically parallelized, making for fast deployments. Also, the Aspire dashboard now includes a preview of an MCP server that lets AI assistants directly query a running application. The MCP server enables AI coding assistants to list all resources with their state and endpoints, access console logs in real time, retrieve structured logs and traces, and execute commands on resources.

Previously called .NET Aspire, Aspire provides tools, packages, and templates for building observable, production-ready distributed apps. Aspire provides a unified toolchain for launching and debugging an application locally with one command, then deploying to Kubernetes, the cloud, or a user’s own servers via the same composition, according to Microsoft. Aspire 13 requires the .NET 10 SDK or later.

Microsoft noted a few other new features and improvements in Aspire 13. Database resources now automatically expose multiple connection string formats, including the URI format for Python apps and JDBC format for Java apps. Aspire 13 automatically configures certificate trust for Python (SSL_CERT_FILE), Node.js (NODE_EXTRA_CA_CERTS), and containers. And Aspire now generates optimized multi-stage Dockerfiles that detect a Node version from .nvmrc, .node-version, or package.json.

North Korea-linked Contagious Interview campaign is now luring developers with trojanized coding tasks and pulling obfuscated payloads from public JSON-storage services like JSON Keeper, JSONSilo, and npoint.io.

An NVISO Labs analysis of the campaign shows threat actors sending fake recruiter messages and demo projects that include configuration values pointing to JSON storage URLs. Those JSON blobs host heavily obfuscated JavaScript that, once decoded and executed by a Node.js test run, unpacks a BeaverTail infostealer and then stages the InvisibleFerret modular RAT.

“The JavaScript code hosted on JSON Keeper is heavily obfuscated with techniques such as packing, array and string obfuscation, and other common techniques such as concatenation,” NVISO researchers said in a blog post.

Contagious Interview is a long-running campaign that targets software developers across Windows, Linux, and macOS–especially those in crypto and Web3–by using social-engineering lures like ClickFix and fake recruiters to deliver trojanized interview code that ultimately drops BeaverTail and OtterCookie infostealers, along with modular RAT.

JSON storage services as the new staging ground

NVISO found and disclosed multiple demo repositories (hosted on GitLab/Github) where a “server/config/.config.env” file contains what looks like an API key but decodes into a JSON Keeper (and similar) URL. The JavaScript fetched from those services is packed and string-obfuscated.

De-obfuscation reveals BeaverTail, which harvests system info, browser wallets/extensions (MetaMask, Phantom, TrontLink), documents, and more, then pulls InvisibleFerret as a next-stage component. The actors even embed coded Pastebin and XOR/base64 layers to evade detection.

The final payload (BeaverTail) showed previously seen capabilities, including “usage of Axioms as embedded HTTP client, enumeration and exfiltration of system information, searching browser profiles and extension directories for sensitive data, and searching for and exfiltrating Word documents, PDF files, screenshots, secret files, files containing environment variables, and other sensitive files such as the logged-in user’s Keychain”.

Developers remain a high-value target

Researchers highlighted that the campaign specifically targets developers involved in crypto and Web3 projects, using realistic-sounding personas and demo applications (real estate, DeFi, game forks) to lower suspicion. The state-linked actors’ shift from direct payload hosting to abusing legitimate JSON storage services suggests that even benign developer-centric platforms are now being weaponized to bypass detection and exploit trust in tech workflows.

Because the attack blends legitimate platforms (GitLab/GitHub, JSON Keeper/npoint) with obfuscated payloads, defenders must treat code provenance as part of security hygiene. Running code in fully isolated sandboxes, auditing any external URLs or keys in config files before executing, and blocking unusual outbound requests to known JSON-storage endpoints and IOCs NVISO listed might help, researchers added.

“Never run code from an unknown repository or from a ‘recruiter’ as part of any first interview, especially when contact has been recently established,” researchers warned. “If needed, inspect the configuration files for any signs of malicious activity.” NVISO has flagged a list of email addresses used to upload the malware to JSON services, repositories hosting malicious code, a GitHub account linked to the campaign, JSON storage URLs, and BeaverTail/InvisibleFerret C2 servers for developers. Additionally, representatives of the JSON storage services were informed of the abuse and are reportedly working on removing all malicious content.

The robots may be taking over, but no one seems to like how they talk.

In theory, the robots (by which I mean generative AI) talk just like us, given that their large language models (LLMs) have been trained on billions upon billions of statements you and I have made online. That Hacker News thread in which you waxed rhapsodic about JUST HOW WRONG someone is about Flash on the internet? It’s now training data for someone’s LLM-augmented doctoral dissertation. The LLMs have “learned” from all this online chatter to generate text that sounds like a human being.

Except it doesn’t. Not really. Not enough.

There’s a swelling chorus against AI-generated content on LinkedIn and elsewhere. As Oxide Computing CTO Bryan Cantrill opines, “Holy hell, the [AI] writing sucks.” Now, Cantrill is known for having strong opinions, but he’s not wrong when he argues this AI-generated writing is “stylistically grating.” The biggest tell? “Em-dashes that some of us use naturally—but most don’t (or shouldn’t).” OpenAI founder Sam Altman just fixed this last annoyance, but not before many of us realized that in our attempts to make our lives easier through AI, we inadvertently made everyone else’s lives worse.

It’s time to get back to writing that expresses ourselves, not merely what an LLM thinks sounds plausibly close to ourselves, because it’s the human in us that makes our communication compelling to other humans.

Cozying up to the robot voice

This trend toward robot voice isn’t new. If you’ve ever visited the UK or simply read a UK paper online, you’ll know that UK newspapers have distinctive voices. It’s not merely that different papers have different political biases and wear these biases proudly (or sanctimoniously, in the case of The Guardian) on their sleeves. Rather, they’re emphatically opinionated. In the US, we try to pretend we’re taking a neutral stance, even if the facts we choose to ignore or skew reveal our political biases quite clearly. As Emily Bell writes, “British journalism is faster, sloppier, wittier, less well-resourced and more venal, competitive, direct, and blunt than much of the US oeuvre.” (Yes, you know it’s an article from The Guardian when “oeuvre” is casually used as if normal people talk like that.)

For those in the tech world, the best example is perhaps The Register, founded in the UK. Perhaps best known for its sometimes over-the-top headlines, The Register offers smart, punchy analysis. It’s not neutral and doesn’t pretend to be. I used to write for The Register, and remember fondly some of these headlines:

• IBM trades cold comfort for hot air in Microsoft-AWS slugfest (a knowing nod to Pink Floyd)
• Craptastic analysis turns 2.8 zettabytes of Big Data into 2.8 ZB of FAIL (Doesn’t this make you want to click and read?)
• Larry Ellison’s yacht isn’t threatened by NoSQL – yet (Oops! Apologies to my present employer)

I didn’t write a single one of those headlines: The Register’s editors did them all. Sometimes they made me squeamish, but they were always fun (and sometimes informative!). No machine could replicate that formula, because there really wasn’t a formula. It was just some guy (Ashlee Vance at one point) trying to marry wit and information in an educated guess as to what would make someone want to read the article.

At the time I was writing for The Register, I was also writing for other publications. Those headlines were a bit tamer, which had much to do with the US ownership of the sites:

• With GitHub acquisition, Microsoft wants to make Azure the default cloud for developers (Written in 2018, this thesis on Microsoft’s GitHub intentions seems more accurate every day)
• NoSQL keeps rising, but relational databases still dominate big data (true then, true now)
• Don’t believe the hype, AGPL open source licensing is toxic and unpopular (one of the few headlines I actually wrote)

Although this is just a small sample, the US-style headlines (and writing) pretend to flatten out perspectives, aiming for an impossible neutrality. The UK doesn’t care; the writing is meant to provoke and inform. Our AI-generated content sounds more American than British, and that’s not a good thing.

Putting more ‘you’ in the writing

LLMs are “lousy writers and (most importantly!) they are not you,” Cantrill argues. That “you” is what persuades. We don’t read Steinbeck’s The Grapes of Wrath to find a robotic approximation of what desperation and hurt seem to be; we read it because we find ourselves in the writing.

No one needs to be Steinbeck to draft press releases, but if that press release sounds samesy and dull, does it really matter that you did it in 10 seconds with an LLM versus an hour on your own mental steam? A few years ago, a friend in product marketing told me that an LLM generated better sales collateral than the more junior product marketing professionals he’d hired. His verdict was that he would hire fewer people and rely on LLMs for that collateral, which only got a few dozen downloads anyway, from a sales force that numbered in the thousands. Problem solved, right?

Wrong. If few people are reading the collateral, it’s likely the collateral isn’t needed in the first place. Using LLMs to save money on creating worthless content doesn’t seem to be the correct conclusion. Ditto using LLMs to write press releases or other marketing content. I’ve said before that the average press release sounds like it was written by a computer (and not a particularly advanced computer), so it’s fine to say we should use LLMs to write such drivel. But isn’t it better to avoid the drivel in the first place? Good PR people think about content and its place in a wider context rather than just mindlessly putting out press releases.

LLMs are effective in software development because machines don’t mind reading drivel (boilerplate code). But people do. For any job that depends on persuasion—and most do, to some degree—it’s essential to maintain a human voice. For example, as much as I can’t stand Trump’s online (and offline) persona, part of the reason his followers find him so compelling is his stylistic weirdness. It feels authentic because it is authentic.

This isn’t a plea to be like Trump (please don’t!), but please be yourself. “AI made your writing smooth,” Talentz.ai CEO Muhammed Shaphy notes. “It erased your voice in the process.” Don’t be erased. Don’t be smooth. Be you.

An engineer refreshes a pull request page for the fourth time. New comments appear. More reviewers get tagged. The change has been ready for days, yet the approval waits.

The scenario is familiar across the industry: code that takes 15 minutes to write but 15 days to get approved. The frustration isn’t rooted in disagreement about quality or safety. Engineers want to ship something straightforward, yet find themselves navigating comments, reviews, alignment meetings, and status threads.

If you’ve ever watched a pull request spend more time in discussion than it took to build the feature, you’ve seen the quiet cost of process at scale. Governance starts with good intent. It brings clarity and protects quality. But beyond a certain point, it dilutes ownership, slows execution, and drains morale.

Software organizations don’t slow down because people stop caring. They slow down because responsibility diffuses across owners, reviewers, and committees, while the work required to push anything forward grows heavier each quarter. The challenge for leaders is to continuously tune governance so that clarity and speed increase together.

The scaling ownership trap

The pattern plays out similarly across companies scaling past a few hundred engineers. Early on, things move quickly because ownership is clear. Then growth creates new pressures. A deployment causes an outage and leadership adds oversight. A security vulnerability reaches production and suddenly every change requires security review.

Each response makes sense in isolation. The problem emerges when organizations keep adding layers without removing them. Architecture review boards and launch readiness checklists accumulate without pruning and expand to include every senior voice. The deeper drivers are often emotional. Visible incidents trigger overcorrection with multiple sign-off layers to assuage anxiety. Quality teams get rewarded for preventing risk rather than enabling speed. Having a process becomes a symbol of managerial competence.

Academic analysis of over half a million GitHub records across about two thousand high-activity open-source repositories revealed something striking. Repositories with more than 10 owners took more than three times as long to merge changes compared to those with one or two clear owners (source). As ownership becomes broad, accountability becomes thin. Each reviewer assumes others will catch issues. Merge times crater while quality stays flat.

Consider an operational readiness review where invitations to senior engineers and technical leads have created a standing meeting with 10 to 15 people. The bigger these meetings get, the more cumbersome the decision-making becomes. When pared down to a smaller group with one senior engineer who actually owns the approval, nothing breaks. Outcomes improve because clear accountability drives careful judgment, while diffused responsibility invites assumptions that someone else will catch the issues.

Why processes must evolve, not fossilize

Teams fall into a trap where a once-useful rule becomes a tradition, then a barrier. When someone asks why a particular approval exists, the answer becomes circular: because that’s our process.

Good governance adapts to current needs, not historical ones. For every process gate, someone should articulate what specific risk it mitigates and what would happen without it. If the answer is “we’ve always done it this way,” the gate needs reevaluation.

The most successful engineering cultures build in mechanisms for process retirement. Any new process comes with an expiration date. After six or 12 months, the rule is automatically retired unless someone actively argues for renewal with data showing its necessity. Every rule must have a documented owner and a one-sentence justification. If the current team cannot state the why, the process should be retired.

Five practical ways to keep speed and ownership high

Here are some practical ways to keep governance mechanisms fine-tuned and ensure that processes remain nimble.

Limit ownership to those truly accountable

For significant projects, identify a small group of two to three people genuinely accountable for outcomes. Track merge and review latency as governance health signals. Design team boundaries that minimize coordination requirements, ensuring architectural boundaries align with organizational boundaries.

Create pathways for low-risk work to move fast

Not all changes carry equal risk. Allow routine updates like documentation, test changes, and reversible configs to bypass long cycles through single-reviewer approval, self-service deployment, and automated scanning. Make clear what triggers the exception path for high-risk changes.

Keep reviewer circles small and purposeful

For most changes, limit reviewers to two to three people with direct context. Broader visibility should be the exception, reserved for changes that introduce new architectural patterns or require cross-organizational alignment. For those cases, use decision notes like architecture decision records to inform stakeholders without requiring everyone’s approval. Set short comment windows measured in days, not weeks, and make clear who owns the final decision.

Assign a single responsible merger for each change

Designate one person responsible for merging each change. Even when multiple reviewers are needed, only one person should own the decision and timeline. Set decision deadlines, not consensus requirements. This avoids waiting for consensus that may never arrive.

Treat escalation as efficiency, not conflict

When a decision stalls beyond your team’s expected review SLA, encourage fast escalation to a lead or architect. Escalation should be praised, not avoided.

The human and cultural cost of unnecessary layers

The most corrosive effect of inefficient governance isn’t lost velocity. It’s the impact on people.

Talented engineers gradually lose their spark in organizations with too many review layers. They spend months shepherding a feature through review cycles, reshaped by feedback from six different stakeholders. By the time the code ships, the original builder barely recognizes it.

This is when optimization shifts from impact to approval. Engineers stop taking pride in elegant solutions or proposing ambitious ideas because coordination costs are prohibitive. They become contractors executing someone else’s vision instead of builders creating something new.

The fastest way to crush the spirit of innovation in development teams is to reward alignment theater over creation impact. When engineers spend more time on pre-meeting preparation, stakeholder management emails, and presentation polishing than on building and validating solutions, the incentive structure has inverted. And the best ones leave.

How large teams can move like small teams

Great organizations preserve small-team speed as they scale by focusing on autonomy and clear boundaries. The guiding principles: Hire people you trust, set clear boundaries around security requirements, architectural principles, and compliance rules, then let teams work independently within those boundaries.

Design team structures that minimize coordination. Align team boundaries with system boundaries so teams can build, test, and deploy independently. When architectural ownership matches organizational ownership, teams spend less time aligning and more time shipping.

Use automation to make the safest path also the easiest one. For example, build core security checks directly into the deployment process, such as automatic scanning and audit logging that run quietly in the background. This allows teams to deploy with confidence, resulting in faster delivery without lowering security.

Before adding a new approval process, ask if the real problem is technical debt, weak testing, or fragile architecture. Brittle systems create fear, and fear drives people to add defensive process layers. Fixing the underlying system is better than adding more reviews.

When governance is too light

The goal is not zero governance. Mature systems need architectural consistency, security review for high-risk changes, and compliance processes in regulated contexts. Warning signs of under-governance include repeated incidents of the same type, accumulating technical debt due to inconsistent decisions, or engineers making choices without understanding system-wide constraints. Match governance to team maturity, with explicit plans to reduce constraints as judgment develops.

The continuous audit

Make governance review a regular discipline. Every six months, list every required approval step, recurring meeting, and process gate. Then ask: if we were starting from scratch today, would we create this? About a third of the time, typically, the answer is no.

If you’re inheriting a governance mess, start by instrumenting the pain. Track merge times, review latency, and the percentage of time engineers spend coding versus waiting in review cycles. Then tackle the highest-leverage process first. Usually, this is the process with the worst signal-to-noise ratio, where reviews rarely find issues but always create delay.

Focus pruning efforts on discretionary process, not compliance-required gates in regulated environments.

Choosing speed over theater

The hardest part of right-sizing governance is saying no to people with good intentions. The senior architect who wants to review every database change genuinely cares about data integrity. But caring isn’t the same as adding value.

Software organizations are living systems. Governance must evolve, shrink, and adapt just as quickly as code and culture do. We advance not by asking how much process to add, but by asking whether a rule still earns its place.

Process exists to serve builders. When the process becomes the work, the work suffers. The most effective leaders don’t celebrate the size of their governance system. They celebrate the speed and confidence of their teams.

True ownership isn’t assigned. It’s protected.

Many developers associate machine learning and large language models with Python. That makes sense because Python was the first choice for many early adopters, and it remains popular today. But there’s plenty of room in the AI revolution, and JavaScript developers have their pick of tools for integrating AI into their software.

The tools and libraries in this article are all excellent options for unlocking the power of AI and machine learning without leaving the JavaScript sandbox. Some simplify connecting web servers and applications with major models running in large data centers. Others offer powerful routines for training and running LLMs locally. All are solid building blocks for creating AI and machine learning applications in JavaScript.

TensorFlow.js

Google gave the world a great gift when it released TensorFlow as open source. With TensorFlow.js, you can develop machine learning models in JavaScript or TypeScript and deploy them in a web browser or Node.js environment. An additional perk is tfjs-vis. One of the many interesting libraries developed for TensorFlow.js, the Vis API lets you visualize model performance right in your browser.

Also see: How to use TensorFlow in your browser.

Hugging Face Transformers.js

Another option for running models in a web browser, or any other environment that supports JavaScript, comes from HuggingFace. Transformers.js delivers the same functionality as the popular Python-based Transformers library, but the JavaScript version puts the power of WebGPU and WebAssembly in the browser. Transformers.js also offers more high-level support, like sentiment analysis and chat templating, making it easier to handle many AI chores locally. It might be a stretch to say that you won’t need any server-side code, but you can definitely offload much of the work to the user’s machine.

Brain.js

If you’ve ever dreamed of building a neural network and sending it out into the world through a web browser, consider Brain.js. It offers multiple models for implementing neural networks in JavaScript while also leveraging any GPUs that are available. The Brain.js tutorials are there to help you understand what’s happening inside a neural network as it learns from data. Find the Brain.js source code on GitHub, along with examples written in TypeScript and JavaScript.

Angular

Angular used to be just a web application framework, right? It was built by human hands to help humans build better web applications. But now all that is changing. Google has added new features to make it easier for large language models to write Angular applications themselves. They’ve included llms.txt files as a machine-friendly guide to the resources and best-practices.md to help the models write Angular code using all the best techniques. Now you can employ some of the most popular LLMs to write your Angular apps for you.

AI.JSX

The folks at Fixie.ai created AI.JSX to support conversational-style interfaces, usually inside React-centered projects. The simplest examples show how to recreate the popular OpenAI interface. More advanced users can create dynamic websites that use AI responses to construct new interfaces with different components as needed.

LlamaIndex.js

Many AI tasks require merging the power of a general LLM with some RAG (retrieval augmented generation) tool that can find the most relevant documents in a large collection. LlamaIndex.js is a framework stuffed full of tools for simplifying the work of ingesting documents, building vector representations, and indexing them for fast retrieval. Using these tools lets you combine any query with the right documents. All you need to do is integrate LlamaIndex.js, string together some workflows, and set the tool loose to find what you need in the great digital haystack.

ml5.js

The browser is where JavaScript first appeared, so it’s a natural fit for machine learning applications written in JavaScript and TypeScript. ml5.js is a library for machine learning that’s ready to be incorporated into browser-based machine learning applications. This tool is popular with educators who want to give their students the hands-on experience of building and training models. Some pair it with TeachableMachine for visual experiments. Others just hardwire it into their own personal web page.

Vercel AI SDK

The AI SDK from Vercel is a clearinghouse for accessing models from all the major LLM vendors and many smaller ones, too. Just insert your code into any of the major JavaScript frameworks (Angular, React, Vue, etc.) and let it send out prompts for answers from an LLM. There are more than a dozen different options including big-name options from Azure, Mistral, Grok, and Perplexity. The SDK worries about the differences between the respective APIs, so you don’t have to.

LangChain

As AI developers grow more sophisticated and start building more complex architectures with multiple calls to various models, tools like LangChain are invaluable. The meta tool abstracts away the process of calling different models, while simultaneously stringing together multiple calls to tackle complex tasks and unlock agency. Devops teams also can use LangChain to monitor application behavior in production.

Also see: What is LangChain? An easier way to develop LLM applications.

Vendor libraries

All the major vendors have nice libraries for accessing their APIs, and these are often all you need to unlock the power of large language models. In goes a prompt string and out comes an answer. The vendors handle the work of keeping the models trained and running, all for a fee. Some of the most prominent JavaScript libraries are these from OpenAI, Google Gemini, Vercel, IBM and Amazon. These and other libraries provide a solid foundation for venturing into AI without ever leaving the familiarity of JavaScript.