Microsoft has launched the fifth preview of its planned .NET 10 open source developer platform. The preview release fits C# 14 with user-defined compound assignment operators and enhances the .NET runtime with escape analysis, among other updates.

Announced June 10, .NET 10 Preview 5 can be downloaded from dotnet.microsoft.com. It includes enhancements to features ranging from the runtime and C# 14 to F# 10, NET MAUI, ASP.NET Core, and Blazor.

C# 14 type authors can now implement compound assignment operators in a user-defined manner that modifies the target in place rather than creating copies. Pre-existing code is unchanged and works the same as before. Meanwhile, in the .NET runtime, the JIT compiler’s escape analysis implementation has been extended to model delegate invokes. When compiling source code to IL (intermediate language), each delegate is transformed into a closure class with a method corresponding to the delegate’s definition and fields matching any captured variables. At runtime, a closure object is created to instantiate the captured variables along with a Func object to invoke the delegate. This runtime preview also enhances the JIT’s inlining policy to take better advantage of profile data. Additionally, F# 10 introduces scoped warning controls with a new #warnon directive supporting fine-grained control over compiler diagnostics.

A production release of .NET 10 is expected this November. .NET 10 Preview 5 follows Preview 4, announced May 13. The first preview was unveiled February 25, followed by a second preview on March 18, and the third preview, announced April 10. Other improvements featured in Preview 5 include:

• For ASP.NET Core, developers now can specify a custom security descriptor for HTTP.sys request queues using a new RequestQueueSecurityDescriptor property on HttpSysOptions. This enables more granular control over access rights for the request queue, allowing developers to tailor security to an application’s needs.
• The OpenAPI.NET library used in ASP.NET Core OpenAPI document generation has been upgraded to v2.0.0-preview18.
• Blazor now provides an improved way to display a “not Found” page when navigating to a non-existent page. Developers can specify a page to render when NavigationManager.NotFound() is called by passing a page type to the Router component using the NotFoundPage parameter.
• For .NET MAUI, projects now can combine XML namespaces into a new global namespace, xmlns="http://schemas.microsoft.com/dotnet/maui/global", and use these without prefixes.
• For Windows Presentation Foundation, the release introduces a shorthand syntax for defining Grid.RowDefinitions and Grid.ColumnDefinitions in XAML, with support for XAML Hot Reload. Performance and code quality are also improved.

Databricks has previewed a no-code version of its Data Intelligence platform — Databricks One — that aims to provide AI and BI tools to non-technical users through a conversational user interface.

According to analysts, Databricks One draws inspiration from Microsoft’s M365 Copilot strategy to reimagine the user interface of M365, centering on generative AI, and applies this approach to the enterprise data analytics tools that Databricks provides.

“Databricks One mirrors Microsoft’s M365-Copilot strategy in that it reimagines the user interface, although not for productivity apps, but for enterprise data and AI,” said Michael Ni, principal analyst at Constellation Research.

Speaking to Computerworld, last month, a top Microsoft executive said that the company was planning to move away from a typical apps based interface to a Copilot driven experience in the future: instead of accessing individual apps like Word, Excel and PowerPoint, users prompts Copilot with the task at hand and the generative AI assistant spins up the required application.

Databricks One similarly offers a simplified, AI-assisted access point to governed data, metrics, and insights, helping business teams engage without code or complexity.

“It’s not about replacing business intelligence (BI) tools, but about embedding decision intelligence into daily workflows,” Ni said.

One comes with AI/BI Dashboards and apps

As part of the One platform, which is currently in private preview and can be accessed by Data Intelligence platform subscribers for free, Databricks is offering AI/BI Dashboards, Genie, and Databricks Apps along with built-in governance and security features via Unity Catalog and the Databricks IAM platform.

While AI/BI Dashboards will enable non-technical enterprise users to create and access data visualizations and perform advanced analytics without writing code, Genie, a conversational assistant, will allow users to ask questions on their data using natural language.

The conversational assistant is also expected to support deep research on data as it understands business-specific semantics, the company said.

Additionally, Databricks Apps inside One will allow non-technical users to package complex workflows that interweave analytics, AI, and transactional processing in a custom app for a particular use case, the company said.

However, Moor Insights and Strategy principal analyst Robert Kramer pointed out that enterprises shouldn’t expect every advanced feature of the Data Intelligence platform to be baked inside One, despite it connecting to the same backend core engine of the platform and working on the same enterprise data.

Centralizing metadata on Databricks’ platform

Analysts see Databricks One as a vehicle for the lakehouse provider to drive stickiness of its products.

“Databricks One is a Trojan horse for garnering enterprise mindshare and an effort towards centralizing metadata on Databricks’ platform. The more users rely on One to make decisions, the more sticky the Databricks platform becomes,” said Constellation Research’s Ni.

The decision to launch One could be seen as Databricks’ first salvo in the next war engulfing the data and analytics space: It isn’t just about which vendor has captured more enterprise data, but which vendor helps enterprises understand it better and makes it easy to use for business scenarios or use cases, Ni added.

Although, when compared to rivals, Databricks’ approach to making analytics easier without code and accessible via natural language is not new, Kramer pointed out that Databricks One stands out.

“Other vendors like Snowflake (with Cortex AI) and Microsoft (with Fabric and Copilot) also offer natural language tools for business users. Databricks One stands out because it’s built directly into the lakehouse platform,” Kramer said. Separately, Databricks has also launched a free edition of its Data Intelligence platform in order to encourage users to try out the gamut of tools and capabilities that the platform offers.

Analysts see the free edition as a “classic category capture.”

While at one end it will help shape the talent ecosystem when it comes to Databricks’ stack, it is also a moat builder at the other end, Ni said, adding that the earlier developers and data analysts get hooked into Databricks, the harder it is for rivals to pry them loose later.

However, Kramer pointed out that the free edition only includes basic computing resources while placing limits on how many jobs or apps a user can run.

“It doesn’t include enterprise features like advanced security or large-scale storage,” Kramer said.

Databricks has not provided any information on the usage limitations of the free editions.

In contrast, rivals such as Snowflake offer free trials that usually expire after a set time, often 30 days.

More DataBricks news:

• Databricks targets AI bottlenecks with Lakeflow Designer
• Databricks aims to optimize agent building for enterprises with Agent Bricks
• Databricks to acquire open-source database startup Neon to build the next wave of AI agents
  

Among his many achievements, pioneering computer scientist and Microsoft Technical Fellow Jim Gray came up with what he called the “fifth paradigm” of science: using large amounts of data and machine learning to discover new things about the world around us. That idea led to Microsoft’s work with scientists across the planet through its AI for Earth and similar projects.

Part of that work led to the development of a common source of geospatial data for use in research projects. Dubbed the Planetary Computer, the project built on a set of open standards and open source tools to deliver a wide variety of different geographic and environmental data sets that can be built into scientific computing applications. There are more than 50 petabytes of geospatial data in 120 data sets.

Adding geospatial data to scientific computing

Open the Planetary Computer data catalog and you will find all kinds of useful data: from decades’ worth of satellite imagery to biomass maps, from the US Census to fire data. All together, there are 17 different classes of data available, often with several different sources, all ready for research applications, on their own or to provide valuable context to your own data. A related GitHub repository provides the necessary code to implement much of it yourself.

Along with the data, the research platform includes a tool to quickly render data sets onto a map, giving you a quick way to start exploring data. It also provides the necessary Python code to include the data in your own applications. For example, you could mix demographic information with terrain data to show how population is affected by physical geography.

Data like this can help quickly prove or disprove hypotheses. This makes it a valuable tool for science, but what if you want to use it alongside the information stored in your own business systems?

From the lab to the enterprise

At Build 2025, Microsoft announced a preview of a new enterprise-focused version of this service, called Planetary Computer Pro. It’s wrapped as an Azure service and suitable for use across your applications or as part of machine learning services. The service can be managed using familiar Azure tools, including the portal and CLI, as well as with its own SDK and APIs.

Like the academic service, Planetary Computer Pro builds on the open SpatioTemporal Asset Catalog (STAC) specification, which allows you to use a standard set of queries across different data sets to simplify query development. It provides tools for visualizing data and supports access controls using Entra ID and Azure RBAC. It’s for your own data; it doesn’t provide third-party data sets for now, though direct links to the Planetary Computer service are on the road map, and the examples in Microsoft Learn show how to migrate data between the services.

Building a geospatial computing environment on top of Azure makes a lot of sense. Underneath Azure, tools like Cosmos DB and Fabric provide the necessary at-scale data platform, and support for Python and the Azure AI Foundry allow you to build analytical applications and machine learning tools that can mix geospatial and other data—especially time-series data from Internet of Things hardware and other sensors.

Planetary Computer Pro provides the necessary storage, management, and visualization tools to support your own geospatial data in 2D and 3D, with support for the necessary query tools. A built-in Explorer can help show your data on a map, letting you layer different data sets and find insights that may have been missed by conventional queries.

Microsoft envisions three types of user for the service. First are solution developers who want a tool for building and running geospatial data-processing pipelines and hosting applications using that data. The second group is data managers who need catalog tools to control and share data and provide access to developers across the enterprise. Finally, data scientists can use its visualization tools to explore geospatial data for insights.

Building your own geospatial catalog

Getting started with Planetary Computer Pro requires deploying a GeoCatalog resource into your Azure tenant. This is where you’ll store and manage geospatial data, using STAC to access data. You can use the Azure Portal or a REST API to create the catalog. While the service is in preview, you’re limited to a small number of regions and can only create publicly accessible catalogs. Deployment won’t take long, and once it’s in place you can add collections of data.

With a GeoCatalog in place you can now start to use the Planetary Computer Pro web UI. This is where you create and manage collections, defining data sources and how they’re loaded. It includes an Explorer view based on the one in Planetary Computer, which takes STAC data and displays it on a map.

You need to understand STAC to use Planetary Computer Pro, as much of the data used to define new collections needs to be written in STAC JSON. This can be uploaded from a development PC or authored inside the web UI. You can use Planetary Computer Pro’s own templates to simplify the process.

Data can now be brought into your collection. Data needs to be stored in Azure Blob Storage Containers; once it’s in place, all you need to do is provide the storage URI to Planetary Computer Pro. Azure’s identity management tool allows you to ensure only authenticated accounts can import data.

Importing data into a catalog

Imports use Python to copy data into a collection, using the STAC libraries from pip. This allows you to add metadata to images, along with data about the source, the time the data was collected, and the associated coordinates, for example, a bounding box around an image or precise coordinates for a specific sensor. There’s a lot of specialized information associated with a STAC record, and this can be added as necessary, allowing you to provide critical information about the data you’re cataloging. It’s important to understand that you’re building a catalog, akin to one in a library, not a database.

The STAC data you create can be used to find the data you need and then align it appropriately on a map, ready for use. That data can then be used alongside traditional queries for, say, time-series data to show how weather and geographic relief affect a vineyard’s yield.

If you have a lot of data to add to a catalog, you can use the service’s bulk ingestion API to add it to a collection. All the data needs to be in the same Blob Container, with code to provide the STAC data for each catalog entry based on your source’s metadata. The built-in Explorer helps you validate data on maps.

With data stored in a catalog, you can now use the Planetary Computer Pro APIs to start using it your own applications, with tools for searching STAC data, as well as tiling images onto maps ready for display. You can even link it to geographic information systems like ESRI’s ArcGIS, Microsoft’s own Fabric data lakes, or the Azure AI Foundry as part of machine learning applications.

Building a geographic Internet of Things

How can you use Planetary Computer Pro? One use case is to provide added context for machine learning systems or teams using Fabric’s new Digital Twin feature. Large-scale energy production systems are part of much larger environmental systems, and Planetary Computer Pro can provide more inputs as well as visualization tools. Having geospatial data alongside the sensor data adds other prediction options.

Planetary Computer Pro also fits in well with Microsoft’s work in precision agriculture, adding tools for better weather prediction features and a deeper understanding of how a local ecosystem has developed over time using historical satellite imaging data to track biodiversity and growth patterns. You can even use your own drones and aerial photography to add geospatial data to applications, comparing your current growth and yield with historical regional data.

Too often we think of the systems we’re building and modeling as isolated from the planet they’re part of. We are learning otherwise, and geospatial tools can help us make our systems part of the wider world, reducing harmful impacts and improving operations at the same time. Having geospatial data and the tools to work with it lets Microsoft deliver on the vision of a truly Planetary Computer, one that can add intelligence and analytics to the interfaces between our systems and the broader environment.

Developers often grapple with the available options in their quest to use the most suitable data structure for their application. The various collections in C# offer different ways to store data objects and search, sort, insert, modify, delete, and iterate across those objects. For example, the .NET Base Class Library (BCL) provides support for read-only, immutable, and frozen collections. Each of these collection types has distinct use cases.

Read-only collections provide read-only access to data in a mutable collection, i.e., a collection that can be altered by other means. Immutable collections are collections that preserve their structure, meaning they cannot be altered after creation. An immutable collection enables thread-safe modifications to the data by creating a new instance of the collection each time you change its data. Typical examples of immutable collections are ImmutableStack, ImmutableList, and ImmutableHashSet.

Frozen collections, including the FrozenSet and FrozenDictionary classes, were introduced in .NET 8. These are immutable collections that have been optimized for fast look-ups. In addition, frozen collections provide a thread-safe way to access an immutable collection. In this article, we’ll examine how we can use frozen collections in C#. We’ll also look at the performance advantages of frozen collections by comparing the look-up speed of a FrozenSetto other collection types.

Create a console application project in Visual Studio

First off, let’s create a .NET Core console application project in Visual Studio. Assuming Visual Studio 2022 is installed in your system, follow the steps outlined below to create a new .NET Core console application project.

1. Launch the Visual Studio IDE.
2. Click on “Create new project.”
3. In the “Create new project” window, select “Console App” from the list of templates displayed.
4. Click Next.
5. In the “Configure your new project” window, specify the name and location for the new project.
6. Specify the Solution name for your project and select the check box to place the solution and the project files in the same directory.
7. Click Next.
8. In the “Additional information” window shown next, choose “.NET 9.0 (Standard Term Support)” as the framework version you would like to use.
9. Ensure that the check boxes for enabling container support, specifying container build type, and enabling native AOT publish are unchecked. We won’t be using any of these features in this example.
10. Click Create.

We’ll use this .NET 9 Core console application project to work with frozen collections in the subsequent sections of this article.

What are frozen collections? Why do we need them?

Frozen collections refer to a specific type of collection that blends the benefits of immutability and fast read performance. The term immutable here implies that these collections cannot be altered after they are created, thereby ensuring thread safety. Frozen collections eliminate the need to synchronize code that uses these collections in concurrent applications, i.e., applications that handle multiple threads simultaneously.

The System.Collections.Frozen namespace in .NET 8 introduces two new collection classes, FrozenSet and FrozenDictionary. “Frozen” here implies that the collections are immutable. You cannot change these collections once an instance of these classes has been created. These new collection classes enable you to perform faster look-ups and enumerations using methods such as TryGetValue() and Contains().

Key features of frozen collections in .NET Core

These are the key features of frozen collections in .NET Core:

• Immutability: Because frozen collections are immutable, you cannot alter them after they are created. As a result, your application’s data will remain thread-safe and consistent without requiring the use of synchronization techniques.
• Performance optimization: Frozen collections allow only read access, which reduces their memory footprint or overhead during initialization while improving lookup times. Hence, these collections are a great choice when your application needs frequent read-only access to data.
• Thread safety: Thanks to their immutable nature, frozen collections are thread-safe, allowing multiple threads to access the same frozen collection simultaneously without encountering race conditions or synchronization issues.
• Simplicity: Frozen collections are easy to use. You can easily integrate frozen collections into your application because their APIs are the same as the APIs of traditional collections.

Types of frozen collections in .NET Core

Basically, there are two types of frozen collections in .NET Core:

• FrozenDictionary: A FrozenDictionary represents a read-only dictionary that is optimized for fast searches. You can use this collection when the collection needs to be created once and read frequently.
• FrozenSet: A FrozenSet represents a read-only immutable set optimized for fast searches and enumeration. Like a FrozenDictionary, you cannot alter this collection after creation.

Because both FrozenSet and FrozenDictionary are read-only collections, you cannot add, change, or remove items in these collections.

Create frozen collections in C#

The following code snippet shows how you can create a FrozenSet from a HashSet instance, populate it with sample data, and then search for an item inside it. Recall that a HashSet is an unordered collection of unique elements that supports set operations (union, intersection, etc.) and uses a hash table for storage.

var hashSet = new HashSet { "A", "B", "C", "D", "E" };
var frozenSet = hashSet.ToFrozenSet();
bool isFound = frozenSet.TryGetValue("A", out _);

In the preceding code snippet, the ToFrozenSet() method is used to convert a HashSet instance to a FrozenSet instance. The method TryGetValue() will return true in this example because the data searched for is present in the collection.

The following code shows how you can create a FrozenDictionary, store data in it, and search for a particular key in the collection.

var dictionary = new Dictionary
{
    { 1, "A" },{ 2, "B" },{ 3, "C" },{ 4, "D" },{ 5, "E" }
};
var frozenDictionary = dictionary.ToFrozenDictionary();
bool isFound = dictionary.TryGetValue(7, out _);

When the above code is executed, the TryGetValue method will return false because the key 7 is not available in the collection.

Benchmarking performance of frozen collections in .NET Core

Let us now benchmark the performance of a frozen collection, specifically a FrozenSet, against other collection types using the BenchmarkDotNet library. For comparison, we’ll use a List, a HashSet, and an ImmutableHashSet.

Recall that a List is a mutable, strongly-typed, dynamically-sized, ordered collection of elements (even duplicates), and that a HashSet is a mutable, array-based collection of unique elements that is optimized for fast look-ups. Note that the time complexity for searching an item in a HashSet is O(1), compared to a time complexity of O(n) for a List (where n is the number of elements in the collection). Clearly, a HashSet is useful in cases where quick access is necessary. On the downside, a HashSet consumes more memory than a List and cannot include duplicate elements. You should use a List if you want to store an ordered collection of items (possibly duplicates) and where resource consumption is a constraint.

An ImmutableHashSet is the immutable counterpart of a HashSet, i.e., an array-based collection of unique elements that cannot be changed once created. Note that, whereas a HashSet is a mutable, array-based hash bucket optimized for fast searches, an ImmutableHashSet is a persistent data structure that uses AVL trees for immutability. Because this introduces additional overhead, searches of an ImmutableHashSet are much slower than searches of a HashSet.

Install BenchmarkDotNet

To use BenchmarkDotNet, you must first install the BenchmarkDotNet package. You can do this either via the NuGet Package Manager in the Visual Studio IDE, or by executing the following command at the NuGet Package Manager Console:

Install-Package BenchmarkDotNet

Create a benchmark class

In the console application project we created earlier, create a class named CollectionPerformanceBenchmark in a file with the same name and a .cs extension as shown below.

[MemoryDiagnoser]
public class CollectionPerformanceBenchmark
{
  [GlobalSetup]
  public void SetupData()
  {
  }
}

In the preceding code snippet, the attribute MemoryDiagnoser has been attached to the CollectionPerformanceBenchmark class to include memory consumption metrics in our benchmark results. The SetupData method is where we will write the initialization code for our benchmark, i.e., the code to create our collections, populate them with dummy data, and so on. The [GlobalSetup] attribute is used to ensure that SetupData method is executed before any benchmark methods.

Write the initialization code

The following code snippet implements the SetupData method that initializes each of the collection instances and populates them with data.

[GlobalSetup]
public void SetupData()
{
   list = Enumerable.Range(0, NumberOfItems).ToList();
   hashSet = Enumerable.Range(0, NumberOfItems).ToHashSet();
   immutableHashSet = Enumerable.Range(0, NumberOfItems).ToImmutableHashSet();
   frozenSet = Enumerable.Range(0, NumberOfItems).ToFrozenSet();
}

Write the benchmark code

Next, we must write the necessary code for benchmarking. Each method that contains code for benchmarking should be decorated using the [Benchmark] attribute as shown below.

[Benchmark(Baseline = true)]
public void SearchList()
{
    for (var i = 0; i 

In the preceding code snippet, the SearchList method has been decorated using the [Benchmark] attribute and has been set as the baseline against which the performance of the other benchmark methods will be compared.

The complete source code of our CollectionPerformanceBenchmark benchmarking class is given below for reference. Note that it includes the necessary code for the other benchmark methods (SearchFrozenSet, SearchHashSet, and SearchImmutableHashSet), which are implemented in much the same way we implemented the SearchList method.

[MemoryDiagnoser]
public class CollectionPerformanceBenchmark
{
    private const int NumberOfItems = 1000;
    private List list;
    private FrozenSet frozenSet;
    private HashSet hashSet;
    private ImmutableHashSet immutableHashSet;

    [GlobalSetup]
    public void SetupData()
    {
        list = Enumerable.Range(0, NumberOfItems).ToList();
        hashSet = Enumerable.Range(0, NumberOfItems).ToHashSet();
        immutableHashSet = Enumerable.Range(0, NumberOfItems).ToImmutableHashSet();
        frozenSet = Enumerable.Range(0, NumberOfItems).ToFrozenSet();
    }

    [Benchmark(Baseline = true)]
    public void SearchList()
    {
        for (var i = 0; i 

Faster searches in frozen collections

When you run the benchmarks above, you’ll notice the distinct performance differences between searching data in a frozen collection (in this case a FrozenSet) compared to a normal collection such as a List as shown in Figure 1.

IDG

As you can see in the benchmark results, searching a FrozenSet is not only much faster than searching a List, it is even faster than searching a HashSet. So, when you need fast look-ups in a mutable set, use a HashSet. When you need fast look-ups in an immutable set, use a FrozenSet. Keep in mind that, because a FrozenSet is immutable, it incurs a significantly higher overhead cost of creation compared to a HashSet.

Performance and scalability have improved with every release of .NET Core. The introduction of frozen collections heralds a new approach to efficiently searching data, and future releases will include more such improvements.

Apple at its Worldwide Developers Conference (WWDC) this week announced the latest advancements for the Swift language, SwiftUI framework, and Xcode IDE. Highlights include concurrency enhancements and improved C++ and Java interoperability for Swift, compilation caching for Xcode, and new design APIs in SwiftUI.

With Swift 6.2, developers can incrementally adopt Swift in existing C++, C, and Objective-C apps to make code safer and more efficient, Apple said. The swift-java interoperability project now allows developers to incorporate Swift in Java code. Updates to concurrency make asynchronous and concurrent code easier to write correctly. Inline arrays enable developers to declare fixed-size arrays, which allows for compile-time optimizations. A new Span type provides an alternative to unsafe buffer pointers. Apple also introduced Containerization, an open-source project written in Swift for building and running Linux containers on macOS and Apple silicon.

With Xcode 26, in addition to built-in support for ChatGPT, Xcode now allows developers to use generative AI powered by a large language model of their choice, either by using API keys from other providers or running local models on their Mac (Apple silicon required). Coding Tools now provides suggestions to help developers quickly write documentation, fix an issue, or make a code change, Apple said. Compilation caching, introduced as an opt-in feature, speeds up iterative build and test cycles for Swift and C-family languages. Compilation caching caches the results of compilations that were produced for a set of source files and, when it detects that the same set of source files are getting re-compiled, speeds up builds by providing prior compilation results directly from the cache.

Xcode 26 also includes a preview of a new implementation for Swift package builds, based on shared code with Swift Package Manager. This should improve the consistency and stability of builds across the package manager and Xcode, Apple said.

Finally, SwiftUI, Apple’s user interface toolkit, has been updated to support Apple’s new Liquid Glass, which Apple describes as a dynamic design material that combines the optical properties of glass with a sense of fluidity. SwiftUI also adds new APIs for immersive spaces in visionOS, new WebKit APIs for bringing web content into Swift apps, and 3D Swift Charts based on RealityKit, Apple’s 3D and augmented reality framework.

Salesforce’s Slack platform has changed its API terms of service to stop organizations from using Large Language Models (LLMs) to ingest the platform’s data as part of its efforts to implement better enterprise data discovery and search.

While it sounds like a largely technical tweak, it could nevertheless have profound implications for a raft of internal and third-party AI apps that organizations have started using to tame data sprawl.

The new policy was outlined under the new heading Data usage in the latest terms of service, published on May 29. It prohibits the bulk export of Slack data via the API, and explicitly states that data accessed via Slack APIs can no longer be used to train LLMs. Instead, organizations will have to rely on the company’s new Real-Time Search API, which offers search only from within Slack itself.

Databricks has released a beta version of a new agent building interface to help enterprises automate and optimize the agent building process.

Agent Bricks is a new generative AI-driven interface combining technologies developed by MosaicML, which Databricks acquired in 2023, includng TAO, synthetic data generation API, and the Mosaic Agent platform.

However, it is not a rebranded Mosaic Agent Platform, said Robert Kramer, principal analyst at Moor Insights and Strategy, but rather a higher-level, automated abstraction that streamlines agent development for enterprises.

Agent Bricks is intended for use mainly by data professionals and developers, and can be accessed via the “Agent” button in the lakehouse software provider’s Data Intelligence platform.

Using Agent Bricks

Users begin by selecting from a variety of task types they want to execute via agents, such as extracting information from documents, creating a conversational agent, or building a multi-agent workflow system.

Next, they provide a high-level description of the type of agent or agents they are trying to build and attach different knowledge sources for the required task.

Agent Bricks then automatically creates a custom evaluation benchmark for the specified task, said Databricks’ CTO of neural networks, Hanlin Tang, said, giving the example of an agent for customer support.

“We will build a custom LLM judge that’ll measure whether the customer will churn during that support call, or the customer is happy or unhappy. Once we have the benchmark for the task, Agent Bricks then looks at how to optimize the agent itself,” Tang added.

During the optimization phase, Agent Bricks uses techniques including synthetic data generation, prompt engineering, model selection, and fine tuning to deliver an agent that is optimized for quality and cost that enterprises can deploy.

Optimization

Databricks is pitching Agent Bricks as a way to take the complexity out of the process of building agents, as most enterprises don’t have either the time or the talent to go through an iterative process of building and matching an agent to a use case.

“Agent Bricks is notable for automating the agent creation lifecycle from evaluation to optimization, an area where most competitors focus on hosting or orchestrating models rather than lifecycle automation,” said Kramer.

“Snowflake Cortex, for example, supports hosted AI agents but lacks synthetic data and auto-optimization features. AWS Bedrock and Azure OpenAI provide model hosting and tooling but do not offer integrated evaluation and cost tuning at this level,” he said.

Teradata doesn’t offer direct agent-building capabilities either, while Salesforce’s Agentforce platform, though offering evaluation tools for agents, doesn’t automate the process and leaves a lot of engineering to data professionals and developers.

At Constellation Research, Principal Analyst Michael Ni pointed out that though Agent Bricks automates and optimizes the agent building process, it will not replace data engineers, but rather help them save them time in building agentic applications.

“Data engineers still oversee integration and deployment, but they’re no longer blocked by repetitive, low-value scaffolding work,” Ni said, adding he doesn’t see Agent Bricks as a point-and-click tool for non-technical users.

Support for MCP

As part of the new interface, Databricks is adding some templatized agents that enterprises can use out-of-the-box: Information Extraction Agents for getting structured data from unstructured data, Knowledge Assistant Agent for supporting conversational agents, Multi-Agent Supervisor for building multi-agent systems, and Custom LLM Agent for custom tasks.

These agents are use-case templates or archetypes designed for common enterprise scenarios and act as starting points that can be customized based on organizational data and performance requirements, rather than rigid building blocks or mandatory frameworks.

Agent Bricks also supports Anthropic’s Model Context Protocol (MCP), an increasingly popular framework for connecting agents across disparate technology stacks or systems.

The Multi-Agent supervisor inside Agent Bricks can read and accept an MCP server as an agent, making agents on other systems accessible, said Databricks’ Tang, adding that an agent produced on Agent Bricks can also be exposed as an endpoint in order to connect to other agent systems.

Databricks is also working on support for Google’s A2A protocol, Tang said, cautioning that development is in “very early days.”

A different approach to agent lifecycle management

Agent Bricks takes a different approach to agent lifecycle management when compared to similar offerings from other vendors.

While most vendors have built agent lifecycle management tools inside their agent builders, Databricks is leveraging Unity Catalog and MLflow 3.0 for managing agents built on Agent Bricks — meaning ongoing AgentOps tasks, such as, monitoring, evaluation, deployment, and rollback, are handled by MLflow 3.0 and Unity Catalog.

Snowflake, on the other hand, integrates agent lifecycle management within Cortex, while AWS and Azure embed monitoring directly into their agent environments.

Kramer said that enterprises with smaller teams may think twice before adopting Agent Bricks as Databricks’ approach requires users to work across multiple services. “This separation may slow adoption for teams expecting a unified toolset, especially those new to Databricks’ platform,” he said.

But, said Bradley Shimmin, the lead of the data and analytics practice at The Futurum Group, some enterprises may align with Databricks’ approach towards agent lifecycle management: an agent, like a data table or machine learning model, is an asset and should be governed by the same central catalog.

Data scientists today face a perfect storm: an explosion of inconsistent, unstructured, multimodal data scattered across silos – and mounting pressure to turn it into accessible, AI-ready insights. The challenge isn’t just dealing with diverse data types, but also the need for scalable, automated processes to prepare, analyze, and use this data effectively.

Many organizations fall into predictable traps when updating their data pipelines for AI. The most common: treating data preparation as a series of one-off tasks rather than designing for repeatability and scale. For example, hardcoding product categories in advance can make a system brittle and hard to adapt to new products. A more flexible approach is to infer categories dynamically from unstructured content, like product descriptions, using a foundation model, allowing the system to evolve with the business.

Forward-looking teams are rethinking pipelines with adaptability in mind. Market leaders use AI-powered analytics to extract insights from this diverse data, transforming customer experiences and operational efficiency. The shift demands a tailored, priority-based approach to data processing and analytics that embraces the diverse nature of modern data, while optimizing for different computational needs across the AI/ML lifecycle.

Tooling for unstructured and multimodal data projects

Different data types benefit from specialized approaches. For example:

• Text analysis leverages contextual understanding and embedding capabilities to extract meaning;
• Video pipelines processing employs computer vision models for classification;
• Time-series data uses forecasting engines.

Platforms must match workloads to optimal processing methods while maintaining data access, governance, and resource efficiency.

Consider text analytics on customer support data. Initial processing might use lightweight natural language processing (NLP) for classification. Deeper analysis could employ large language models (LLMs) for sentiment detection, while production deployment might require specialized vector databases for semantic search. Each stage requires different computational resources, yet all must work together seamlessly in production.

Representative AI Workloads

The different data types and processing stages call for different technology choices. Each workload needs its own infrastructure, scaling methods, and optimization strategies. This variety shapes today’s best practices for handling AI-bound data:

• Use in-platform AI assistants to generate SQL, explain code, and understand data structures. This can dramatically speed up initial prep and exploration phases. Combine this with automated metadata and profiling tools to reveal data quality issues before manual intervention is required.
• Execute all data cleaning, transformation, and feature engineering directly within your core data platform using its query language. This eliminates data movement bottlenecks and the overhead of juggling separate preparation tools.
• Automate data preparation workflows with version-controlled pipelines inside your data environment, to ensure reproducibility and free you to focus on modeling over  scripting.
• Take advantage of serverless, auto-scaling compute platforms so your queries, transformations, and feature engineering tasks run efficiently for any data volume.  Serverless platforms allow you to focus on transformation logic rather than infrastructure.

These best practices apply to structured and unstructured data alike. Contemporary platforms can expose images, audio, and text through structured interfaces, allowing summarization and other analytics via familiar query languages. Some can transform AI outputs into structured tables that can be queried and joined like traditional datasets.

By treating unstructured sources as first-class analytics citizens, you can integrate them more cleanly into workflows without building external pipelines. 

Today’s architecture for tomorrow’s challenges

Effective modern data architecture operates within a central data platform that supports diverse processing frameworks, eliminating the inefficiencies of moving data between tools. Increasingly, this includes direct support for unstructured data with familiar languages like SQL. This allows them to treat outputs like customer support transcripts as query-able tables that can be joined with structured sources like sales records –  without building separate pipelines.

As foundational AI models become more accessible, data platforms are embedding summarization, classification, and transcription directly into workflows, enabling teams to extract insights from unstructured data without leaving the analytics environment.  Some, like Google Cloud BigQuery, have introduced rich SQL primitives, such as AI.GENERATE_TABLE(), to convert outputs from multimodal datasets into structured, queryable tables without requiring bespoke pipelines.

AI and multimodal data are reshaping analytics. Success requires architectural flexibility: matching tools to tasks in a unified foundation. As AI becomes more embedded in operations, that flexibility becomes critical to maintaining velocity and efficiency.

Learn more about these capabilities and start working with multimodal data in BigQuery.

Databricks showcased a new no-code data management tool, powered by a generative AI assistant, at its ongoing Data + AI summit, which is designed to help enterprises eliminate data engineering bottlenecks slowing down AI projects.

Called Lakeflow Designer, the tool is designed to empower data analysts build no-code ETL (extract, transform, load) pipelines — a task, typically, left to data engineers who are always busy, thus creating a barrier to accelerate AI projects or uses cases, said Bilal Aslam, senior director of product management at Databricks. Lakeflow Designer is currently in preview.

While enterprises employ low-code or no-code tools for data analysts to curtail the load on data engineers, these tools lack governance and scalability, Aslam said, adding that  Lakeflow Designer is designed to alleviate these challenges.

“Lakeflow Designer addresses a key data management problem: data engineering bottlenecks are killing AI momentum with disconnected tools across data ingestion, preparation, cleansing, and orchestration,” said Michael Ni, principal analyst at Constellation Research. “Lakeflow Designer blows the doors open by putting the power of a no-code tool in analysts’ hands, while keeping it enterprise safe.”

Ni called Lakeflow Designer the “Canva of ETL” — instant, visual, AI-assisted development of data pipelines — yet under the hood, it’s Spark SQL at machine scale, secured by Unity Catalog.

Advisory firm ISG’s director of software research, Matt Aslett, said the new tool is expected to reduce the burden on data engineering teams but pointed out that data analysts are highly likely to still be working with data engineering teams for use cases that have more complex integration and transformation requirements that require additional expertise.

Lakeflow Designer makes collaboration between data analysts and engineers in an enterprise easier as it allows sharing of metadata and CI/CD pipelines, meaning these can be inspected, edited by engineers if required, Ni said.

The tool also supports Git and DevOps flows, providing lineage, access control, and auditability, Ni added.

Like Aslett, the analyst pointed out that the new tool is likely to aid enterprises in less complex use cases, such as regional margin tracking, compliance, metric aggregation, retention window monitoring, and cohorting, although it supports custom development.

Lakeflow Designer is part of Lakeflow, which will now be generally available. Lakeflow has three modules — Lakeflow Connect, Lakeflow Declarative Pipelines, and Lakeflow Jobs. Designer is integrated within Declarative Pipelines.

United in purpose, divided in approach

Lakeflow Designer, despite being very similar to rival Snowflake’s Openflow, differs in its approach, analysts say.

“Lakeflow and OpenFlow reflect two philosophies: Databricks integrates data engineering into a Spark-native, open orchestration fabric, while Snowflake’s OpenFlow offers declarative workflow control with deep Snowflake-native semantics. One favors flexibility and openness; the other favors consolidation and simplicity,” Ni said.

Both the offerings also differ in maturity, ISG’s Aslett said. While Snowflake’s OpenFlow is relatively new, Lakeflow has matured in functionality over the years, with Designer being its latest tool. “The Connect capabilities were acquired along with Arcion in 2023. Declarative pipelines functionality is the evolution of DLT (Delta Live Tables), and Jobs is the evolution of Databricks Workflows,” Aslett added.

Separately, Databricks also released another pro-code integrated development environment (IDE) for data engineers, which unifies the data engineer’s full pipeline lifecycle — code, DAGs, sample data, and debugging — all in one integrated workspace.

Releasing Lakeflow Designer and the new IDE together is a strategic play, according to Ni, as the lakehouse provider is targeting both ends of the pipeline maturity curve — low-code to move fast and the full IDE to scale and maintain pipelines.

Even with competition from newer runtimes Deno and Bun, Node.js remains the flagship JavaScript platform on the server. Server-side Node frameworks like Express, build-chain tools like Webpack, and a host of developer-friendly utilities make Node a hugely popular way to leverage the power and expressiveness of JavaScript on the back end.

Of course, Node owes much of its popularity to JavaScript, the multiparadigm language that supports many different styles of programming. Originally developed as a dynamic scripting language to fill the gaps in HTML, modern JavaScript is used for functional programming, reactive programming, and object-oriented programming. Developers can focus on one style or move flexibly between them as different use cases require.

But JavaScript’s multiparadigm nature can be a double-edged sword. It is vital to really understand how to use the different programming paradigms in JavaScript specifically. Given such a versatile language, it also doesn’t make much sense to just pick one style and insist it’s always the best. The language’s flexibility also puts more of the burden of keeping things structured and maintainable on the developer. When working with Node, you have the additional challenge of keeping in mind that it is a single-threaded platform; even the asynchronous code you write isn’t truly concurrent.

JavaScript can be a boon if used with care—or a bane if used recklessly. Here are the 10 JavaScript concepts you’ll need to write scalable code in Node.js.

Promises and async/await

JavaScript and Node let you perform many tasks at the same time in a “non-blocking” way. This means you can tell the platform to do several things at once, without waiting for other operations to finish. The main mechanisms used for asynchronous programming in JavaScript are Promise objects and the async/await keywords. (We’ll discuss the event loop in the next section.)

Promises may be hard to grasp at first, but once you understand them, they offer a very simple means to provide and consume asynchronous jobs. Most often in Node, we are on the consuming end:

const fileReadPromise = fs.readFile(filePath, 'utf-8');
fileReadPromise.then(fileData => {
  console.log('Success… file content:');
  console.log(fileData);
});

The .then() syntax is used to handle what happens after a Promise has been resolved. It also includes a .catch() function for dealing with errors. Between them, the two syntax elements provide a simple way to describe what happens after a Promise has been issued.

With async/await, we use a synchronous (or linear) syntax to describe the same kind of thing (note that we are ignoring error handling in this code):

async function readFileAsync() { 
  const fileData = await fs.readFile(filePath, 'utf-8');
  console.log('Success... file content:'); 
  console.log(fileData);
}

This code does the same thing as the version using Promise. We decorate the readFileAsync function with the async keyword, which lets the interpreter know we will perform an async operation. Then, when we need to call out to the actual operation (fs.readfile), we decorate the call with await.

Learn more about Promises and async/await in JavaScript.

The event loop

To effectively use Promise objects and async/await in your Node operations, you’ll also need to understand the Node event loop. When we say Node is single-threaded, the event loop is the reason why. If these are newer concepts for you, don’t worry. Just make a mental note that inside Node (and similar platforms) your code is never fully multitasked. This is different from some concurrent platforms like Java or Go, where the platform can make direct use of operating system threads.

This is not a limitation that you have to wrestle until you are dealing with scale. In understanding Node, it is just important to know how it works with asynchronous operations.

Let’s say you initiate an asynchronous operation, for instance with a fetch() call:

const response = await fetch(“https://anapioficeandfire.com/api/characters/232”)

The operation is submitted to Node, which schedules the request with the operating system’s networking service. At that point, the event loop is free to do other things, including initiating other network requests that can proceed in parallel. When one of those in-flight requests is complete, the event loop is notified. When the event loop has time, it proceeds with whatever handlers you defined. Take this one, for example:

const characterData = response.json().then( /* do stuff */ );

When that task is done, the asynchronous operation is done. This is the general flow for all asynchronous programming on Node.

Streams

Streams are how Node models flows of data in networking, filesystem, and other channels. Streams represent a series of “things,” like bits coming in or going out to a file. When something important occurs within a series, an event is raised that calls out to the application code based on its handlers.

If this sounds similar to our discussion of asynchronous programming, it’s because the two concepts are closely related. Streams are the code mechanism Node provides for dealing with data flows, which may be large, in a non-blocking fashion.

For example, the fs (filesystem) standard library in Node lets us open a file as you’ve just seen, but it also lets us consume events from the file so we can accept the data in chunks and be notified of file endings and errors. This is critical when dealing with large files (where otherwise we’d load the entire dataset into memory, no bueno):

const filePath = 'hugefile.txt';
const readableStream = fs.createReadStream(filePath, { encoding: 'utf8' });
readableStream.on('data', (chunk) => { 
  console.log(`Received ${chunk.length} characters of data.`); 
}

readableStream.on('end', () => { 
  console.log('Finished reading the file.');
});

readableStream.on('error', (error) => { 
  console.error(`An error occurred: ${error.message}`); 
});

The .on() callbacks let you define which event you are watching for, and then the actual function for doing the work.

Modules

In JavaScript, you use modules to organize code into manageable chunks. It’s common to import one or more modules into your code to make use of functionality defined by others, like the filesystem library:

import fs from 'fs/promises';

Or, you might import code from the project you are working on, from a local file:

import utils from './utils/mjs';

You can also import specific parts of the module if they were named in the export:

import { specificUtil } from './utils.mjs'; 

Exporting a module is done like this:

export const utilA = () => { /* ... */ }; 
export function utilB() { /* ... */ };
const defaultValue = { /* ... */ }; 
export default defaultValue;

Notice that the default export is what you get when you do a straight import, whereas the named ones map to the named imports. Also notice that you can define exports with two syntaxes as seen with utilA and utilB. You might also notice the use of the .mjs extension on the module files here. This is necessary unless you set “type”: “modules” in your NPM package.json file. We’ll talk more about that in the NPM section below.

Important note: What we have looked at so far is the ESM (EcmaScipt Module Syntax) which Node and JavaScript have generally standardized on. But there is another syntax, CommonJS, that much of Node has used for years. You will often see it in Node code:

// Import:
const fs = require('fs'); 
const myUtil = require('./utils.js'); 
// Export:
function utilityOne() { /* ... */ } 
module.exports = { utilityOne };
exports.utilityOne = utilityOne; 

Conceptually, the most important thing is to take from this section is how breaking up software into components is absolutely key in managing complexity. Modules are the high-level mechanism for doing that in Node.

Closures and scope

When you define and execute a function in JavaScript and Node, the variables that exist around it are available to the function. This simple idea, known as a closure, gives us some serious power. The idea is that the “scope” of the variables defined in the surrounding context are accessible to the insides of the nested function.

A standard function has access to those variables in its parent context:

let album = "Abbey Road";  
let rank = function(){ 
  console.log(`${album} is very good!`); // output: “Abbey Road is very good!”
}
rank();

But in a closure, the inner function has access to the scope, even after the parent has completed:

function setupRanker() {
  let album = "Abbey Road";
  let rank = function() {
    console.log(`${album} is very good!`);
  };
  return rank; // Return the inner function
}

const rankerFunction = setupRanker(); 
rankerFunction(); 

This is sometimes called “lexical scope” to highlight that these variables are available to the function, even after the runtime execution of the surrounding context has finished.

This is a toy example, but it makes clear that the rank() function has access to the album variable defined in the surrounding context. That is the core concept. Keeping a clear understanding of this basic idea will help you navigate as you get further into the ramifications of the idea.

Closures are a core feature in JavaScript, and central to Node as well. Closures are also central in functional programming.

Classes

Modern JavaScript gives us a strong class-based syntax for defining objects. Understanding the concept of objects, how create them and make use of them, is essential. Behind the scenes, JavaScript still uses what’s called prototypes, but classes are the more common approach. This is no surprise, given the widespread use of classes in many languages and their simplicity.

Although using object leads us toward the more advanced realms of object-oriented programming, we don’t need to go there just to use objects and classes. A class simply defines a particular type of object:

// Definition:
class Album {
  #tracklist;
  constructor(title) {
    this.title = title;       
    this.#tracklist = [];
  }

  addTrack(trackName) {
    this.#tracklist.push(trackName);
  }
  displayAlbumInfo() {
    console.log(`Album: ${this.title}`);
    console.log(`Tracks: ${this.#tracklist.length}`);
  }

  static getGenreCategory() {
    return "Recorded Music";
  }
}

// Usage:
const album1 = new Album("Abbey Road");
const album2 = new Album("The Joshua Tree");


album1.addTrack("Carry That Weight");
album2.addTrack("In God’s Country");


album1.displayAlbumInfo();
album2.displayAlbumInfo();

This example gives us an Album class for modeling musical albums. It’s pretty clear what it does, in that it holds data like a string title and an array tracklist. Each object can have its own variants of those bits. (Notice the hash syntax gives us private variables with #trackList).

Conceptually, you just need to understand how much power this simple idea gives us for modeling interacting sets of data. The basic mechanism for “encapsulating” (a.k.a. containing) related information and “behavior” (functions) together is must-know for Node developers.

NPM and the Node ecosystem

Most applications rely on external libraries to get their work done, and Node has a powerful package manager called NPM (Node package manager) for specifying and using them. A massive ecosystem has grown up around NPM, as you can see here.

NPM gives you a package.json file that you can put in your program. This is a JSON file with a variety of properties. The main one is “dependencies.” NPM will install the dependencies you list in the file into the /node_modules directory of your app. When the app is running, it will have access to those modules as imports.

That is the basic concept, but there are other important features like the ability to define scripts for your program in the scripts property and setting the type property to module to default to using ESM module files without the .mjs extension. This is common practice even if you are developing a project that isn’t strictly intended to be a module alone. If you don’t set this property, NPM will assume your .js files are CommonJS modules.

NPM is a pillar of Node development. There are other, newer tools (like yarn and pnpm) but NPM is the standard. Conceptually, the insides of your Node programs are JavaScript, but the outsides are NPM.

JSON

It’s hard to imagine JavaScript and Node without JSON, which stands for JavaScript Object Notation. In fact, it’s hard to imagine the modern programming universe without it. It’s a simple yet incredibly versatile means for describing and sharing data between applications.

The basics are simple:

{ 
  “artist”: “Rembrandt”,
  “work”: “Self Portrait”,
  “url”: “https://id.rijksmuseum.nl/200107952”
}

There’s nothing much to see here; just a pair of curly braces and colons with name/value pairs. You can also have arrays and other JSON objects inside of that for complete object graphs. But beyond that is range of techniques and tools for manipulating JSON, starting with the built in JSON.stringify and JSON.parse, to turn JSON into strings or vice versa.

JSON is more or less the way to send data over the wire, from client to server and elsewhere. It also is now common in datastores, especially with NoSQL databases like MongoDB. Getting comfortable with JSON will make programming in Node much smoother.

Error handling

Good error handling is a key concept in Node. You’ll encounter two kinds of errors in Node: the standard runtime kind and the asynchronous kind.

Whereas async errors on Promises are handled by using the .catch() callback, normal runtime errors are handled with try/catch keyword blocks:

try {
  /* do something risky */
} catch (error) {
  /* do something with the error */
}

If an error occurs during the asynchronous operation, that callback will execute and receive the error object.

When using async/await, you use the standard try/catch blocks.

Conceptually, the important thing to bear in mind is that things will go wrong, and catching errors is the main way to address it. We want to recover the operation if possible. Otherwise, we want to make the error condition as painless as we can for the end user. We also want to log the error if possible. If we are interacting with an external service, we might be able to return an error code.

The best error handling is dictated by the circumstances. The main thing is to keep errors in the back of your mind. It’s the error conditions we don’t think about that usually get us, more than the ones we think about and get wrong. Also, beware of “swallowing” errors, which is to define a catch block that does nothing at all.

Keep it flexible

At the beginning of this article, I mentioned that JavaScript can handle a variety of programming styles. These are functional, object-oriented, reactive, imperative, and programmatic. Here we have a vast range of powerful concepts—some of the most important in programming. In the next paragraph, we’ll cover each of them in detail …

Just kidding! There’s no way to do justice to all these programming styles, even in a book-length treatment. The main point is that JavaScript is flexible enough to let you embrace them all. Use what you know and be open to new ideas.

You’ll be often faced with work that must be done, and there is always more than one way to do it. Being concerned that there is a cooler, faster, or more efficient way to get the job done is normal. You have to find a balance between doing the work now and researching newer technologies and best practices for later.

As you add to your understanding, you’ll naturally find tasks and areas where certain paradigms fit. Someone who truly loves programming will not indulge (much) in the “my paradigm/tool/framework is better than yours” game. A better approach, that will serve you throughout your career, is: “This is the best tool I know for the job right now, and I’m open to improving.”

Just like any other worthy discipline—say music or martial arts—the real master knows there’s always more to discover. In this case, the practice just happens to be building server-side JavaScript apps with Node.

In 2010, I got fired. I deserved it. I wasn’t wrong, but I deserved it. And I think there is an interesting lesson in that dichotomy.

I was managing a team of developers at a once-great Silicon Valley firm that had fallen from its peak. The development team was very good—elite, even. Our product was a once-popular but fading software development tool. Our management team—we called it “the Core Team”—was a great bunch. I enjoyed the job. 

The product was monolithic—a single, large install that had to be built and deployed all at once. We shipped about once a year, and all development was geared around building new features and fixing bugs that would all culminate in that big, annual release. Being a development tool, it had many complex components, including a compiler, a run-time library, a visual framework, and an IDE. Getting everything pulled together and built was no mean feat.

A big part of keeping the product viable in the marketplace was doing platform shifts. The first one was going from the Win16 platform to the Win32 platform. The product made an ill-fated foray into Linux, as well as smaller shifts to newer Windows versions and Win64. The product was large and complex, and these platform shifts were not easily done. 

The development and QA teams were very experienced and they knew what they were doing. They knew well what it took to ship a new version of the product, and they knew the extra effort it took to do a platform shift. 

Seeds of misunderstanding

One of the ways that the company had been humbled was that a smaller database tools company had bought it and brought in a new team of senior leadership. The process went pretty normally, with our middle management team cautiously optimistic as we adjusted to a new set of executives. We did our best to integrate and be integrated into the new order of things.

While SQL/database development tools and more general software development tools have much in common, and seem very similar on the surface, our product was a level deeper and more complex than our new parent company’s product. This incongruity proved to be challenging to integrate. While a SQL IDE and a programming language IDE seem the same on the surface, our product’s underlying frameworks, libraries, and compilers were orders of magnitude more complex than a SQL parser and editor. 

This difference was a challenge for the new leadership to understand. So, when the decision was made to take our tool cross-platform to both Linux and Mac OS at the same time, the new executive team appeared not to understand the challenges and difficulties of doing these platform shifts.

We on the Core Team looked at what it would take to provide support for those two platforms, and arrived at a general estimate of 18 months for each, given the current staffing levels. We recommended plans that could shorten that cycle by front-loading the projects and hiring more staff, doing our best to avoid Brooks’s law in the process (“Adding manpower to a late software project makes it later”).

And here’s where things started getting a bit dicey. Upper management was shocked at the notion that it would take three years to migrate to the two new platforms. They seemed to take the attitude that the team was “sandbagging” and “was exaggerating because they didn’t want to do it.” So they set a deadline of six months to do both platforms. 

Temperatures rising

Doing two platform shifts in six months was beyond challenging—it was absurd. We couldn’t have hacked together a half-baked version for even one platform in that time. It was flat-out impossible.

Let’s just say I was quite unhappy with this request. It was completely unreasonable. My team of developers was being asked to work evenings and weekends on a task that was guaranteed to fail. The subtle implication that we were being rebellious and dishonest was difficult to swallow. 

So I set about making my position clear. I tried to stay level-headed, but I’m sure that my irritation showed through. I fought hard to protect my team from a pointless death march—my time in the Navy had taught me that taking care of the team was my top job. 

My protestations were met with little sympathy. My boss, who like me came from the software development tool company, certainly knew that the request was unreasonable, but he told me that while it was a challenge, we just needed to “try.”

This, of course, was the seed of my demise. I knew it was an impossible task, and that “trying” would fail. How do you ask your team to embark on a task that you know will fail miserably and that they know will fail miserably? Well, I answered that question very poorly. 

What I did and what I should have done

What I did was exactly wrong. In the name of defending my team and sticking up for my people, I failed to at least pretend like I was on board with the project. I didn’t even remotely try to be a team player. I told the developers that I thought the plan was nuts and that they shouldn’t even try. I kept telling upper management that that plan was ridiculous and that the team could never do it.  

What should I have done? This is the hard part. What I should have done was to make the best of a very difficult situation. I should have found a middle path. I should have found a way that supported management even though the plan was not doable and that supported my team even though they were being put in an impossible position. Would that have been challenging? Yes. Should I have at least tried? Again, yes.

In the end, my immature approach got me fired. Was I right that the project wouldn’t be completed in the ridiculous timeline? Sure. Was I right to press the issue so hard that I lost my job? No, I was not. 

The lesson? Sometimes being a manager is hard—even impossible. Sometimes you have to give up being right and put the needs of the entire organization over yourself. Sometimes you have to balance protecting your people with being a loyal member of the management team. Sometimes you have to manage up as well as you manage down.

Being right isn’t enough—being effective matters more. I learned that the hard way.

Python is a first-class citizen on Microsoft Windows. That means you can install and remove the Python interpreter like any other application, and run multiple versions of the interpreter side-by-side using the py tool.

But there’s been one long-standing weakness: While you have a central way to select which of your installed versions of Python to use for a given task, you can’t actually manage the installed versions.

Python’s core development team has developed a new tool, the Python Installation Manager for Windows, to handle both of these functions: managing installed versions of Python, and choosing which version to use when launching Python. It’s currently only available as a pre-release, but as of Python 3.16, it’s intended to become the preferred way to manage and select Python installations in Windows.

This article is a quick guide to getting started with the Python Installation Manager.

Setting up the Python Installation Manager

The Python Installation Manager is itself just another Windows app, so there are a few ways to install it:

• The Microsoft Store app offers a convenient one-click installation method.
• The official Python site offers a direct download, although this link is somewhat obscure and likely to change with each new release.
• You can also use the WinGet package manager: winget install 9NQ7512CXL7T. (Note that in the future, this alias may be changed to something more readable.)

Python Installation Manager replaces ‘py’

If you used the earlier incarnation of the py tool for Python to manage Python versions, the Python Installation Manager eclipses its functionality. Typing py will now bring up the Python Installation Manager, although all the commands you used with py before will still work.

If you want to see for yourself how things are different, open a command line and type py help. You’ll see the command list for the Python Installation Manager:

IDG

In the original py launcher, this command would have given an error. Now, it provides details about all the available command-line options for the Python Installation Manager.

Adding and removing Python versions

To see which versions of Python are already present in your system, type py list:

IDG

If you had Python instances installed before you set up the Python Installation Manager, you’ll be able to see them, but you won’t be able to change anything. If you want to make changes, you’ll need to manually remove the old instances (through the Apps pane in your Windows settings), then re-install them using the Python Installation Manager.

In this case, the Python 3.14 instance shown in green (at the top of the screen) is managed by the Python Installation Manager; the others were added by hand earlier.

Adding a version of Python is a simple command: py install :

IDG

Once installed, you can invoke that version by typing py -:

IDG

Removing a managed version of Python is equally simple: py uninstall :

IDG

To see which versions of Python are available through the manager, use py list --online. You can also export the listed Python installations as JSON if you want to feed it to other programs: py list -f=json. (CSV and JSONL formats are also available.)

Setting the default Python

When you list the available Python installations, one will typically be marked with an asterisk:

IDG

The asterisk indicates which version of Python is the default according to the Installation Manager. Just typing py brings up that version. But if you want to change it, you can set an environment variable. As an example, to set 3.12 as the default in PowerShell, you’d type:

$Env:PYTHON_MANAGER_DEFAULT="3.12"

After you set this, Python 3.12 will be listed as the default.

IDG

The pymanager alias

It’s possible that a command like py install would clash with the name of a preconfigured command in a virtual environment, or with some other alias. To avoid that, you can use pymanager as an unambiguous name for the Python Installation Manager. All the commands remain the same; only the name of the executable is different.

IDG

Setting Python app aliases for Windows

A possible final step is to configure the Windows app execution aliases for commands like python and python3. To do that, type py install --configure. You’ll then get a prompt to modify your system’s app execution aliases:

IDG

Typing “Y” opens the app execution aliases window in Settings. From there, you can change how python and python3 behave. If you toggle them off, as shown, they will no longer launch anything at the command line, but you can use py and pymanager to launch Python.

That’s about it. One last thing worth noting is that we still have an active alias for pythonw and pyw. Those are special-case versions of the Python runtime that execute without a console session:

IDG

AI startup Mistral AI has announced Magistral, a reasoning model geared to domain-specific, transparent, and multilingual reasoning.

Announced June 10, Magistral is designed for research, strategic planning, operational optimization, and data-driven decision making, whether executing risk assessment and modeling with multiple factors, or calculating optimal delivery windows under constraints, Magistral AI said. Combining expertise across professional domains, transparent reasoning that can be followed and verified, and deep multilingual flexibility, Magistral is suited for enterprise use cases ranging from structured calculations and programmatic logic to decision trees and rule-based systems, according to the company.

Magistral is fine-tuned for multi-step logic, improving interpretability, and providing a traceable thought process in the user’s language, unlike general-purpose models, Mistral AI said. The company said the model excels in maintaining high-fidelity reasoning across numerous languages, and is particularly well-suited to reason in languages including English, French, Spanish, German, Italian, Arabic, Russian, and Simplified Chinese. It also enhances coding and development use cases, significantly improving project planning, back-end architecture, front-end design, and data engineering compared to non-reasoning models, according to the company.

Mistral is releasing Magistral in two variants. Magistral Small is a 24B parameter open-source version, downloadable from Hugging Face. Magistral Medium is a more powerful enterprise version, being previewed at Le Chat or via API on La Plateforme. Magistral Medium also is available on Amazon SageMaker. Alongside the Magistral release, Mistral has published a research paper covering its evaluations of Magistral, training infrastructure, reinforcement learning algorithm, and thoughts on training reasoning models. 

At Cisco Live 2025 in San Diego, Cisco CEO Chuck Robbins compared AI’s effect on networking to what the Internet felt like in the 1990s. Back then, the arrival of TCP/IP shattered the boundaries of closed networks, connecting individual computers to a worldwide web of information.

AI is reshaping networking in ways that demand a new degree of programmability, observability, and optimization, Robbins said. And if history is any guide, what starts as an infrastructure concern for network and platform teams will eventually trickle down to developers.

From static routers to programmable platforms

The rise of cloud-native infrastructure made containers and APIs the lingua franca of compute. Now, networking is undergoing a similar transformation. Thomas Graf, CTO of Cisco’s Isovalent and creator of Cilium, an open-source, cloud-native, eBPF-based networking, observability, and security solution, sees legacy routers and switches becoming programmable platforms in their own right.

“With the launch of the new DPU-enabled Cisco top-of-rack switch… we now have switches that not only perform traditional functions but also bring firewalling and load balancing directly into the switch,” Graf said. “This means replacing legacy firewall boxes with functionality baked into the networking fabric itself.”

Graf describes DPU-enhanced switches as programmable systems, allowing software-defined network services to be delivered from the switch itself rather than in VMs or sidecar containers. Combined with runtime protection tools like Tetragon and other kernel observability frameworks enabled by eBPF, this paves the way for classic network operations—firewalls, segmentation, even observability—to be more flexibly managed in code.

It’s a shift from “ticket ops” to GitOps for networking, Graf said.

AI agents tackle network debugging

At Cisco Live, Cisco introduced its Foundation AI Security Model, an open-source, purpose-built model for security trained on a curated set of five million security-specific tokens. The company also unveiled the Deep Network Model, optimized for network operations with an agentic UI experience called AI Canvas.

David Zacks, director of innovation, advanced technologies and AI and machine learning at Cisco, said of network domain models coming to AI systems: “The AI system isn’t smarter than the network engineer—it just has access to more data.” The ability to collect telemetry at scale, process it using machine reasoning, and surface actionable insights is rapidly becoming table stakes for operating reliable networks, he said.

As these feedback loops mature, it’s only a matter of time before developers start leveraging the same frameworks in pre-production environments, modeling how inference pipelines behave under load and automatically flagging performance cliffs or bottlenecks.

A new architecture to meet the needs of AI

A repeated theme at Cisco Live has been that the full-stack redesign necessary to support AI is collapsing the traditional boundaries between applications and infrastructure.

“Two things in parallel—the models and the silicon—are becoming more bespoke,” said Cisco’s Jeetu Patel. “Models are getting smaller, silicon more programmable, and the time to market is shrinking. The model becomes part of the application itself. Iterating the app is iterating the model.”

That compression between application logic and inference hardware is triggering an architectural rethink. For AI workloads to perform, developers need visibility into how model design, network bandwidth, and inference placement intersect. Bandwidth-heavy queries from large language models are especially sensitive to latency and congestion—issues that are invisible until they hit the network.

At Cisco Live, sessions have emphasized how AI workflows are now being mapped directly to the network topology itself. Distributing load through pipeline parallelism, optimizing inference placement based on network path characteristics, and pre-caching model shards near compute boundaries are just a few of the strategies being discussed.

This is infrastructure thinking at the developer level, because performance is no longer just about the GPU, but about where, how, and how fast the data flows.

A convergence of application logic and network control

So then, are we approaching a moment where developers will get direct programmability over the network?

“Network programmability has been a goal for years within the networking community,” said Jim Frey, principal analyst for networking at Enterprise Strategy Group. “There is even a term of art for it, NetDevOps, as well as a growing community, the Network Automation Forum, that is focused on making it a reality.”

“But achieving that goal has been fiendishly difficult due to a lack of standard interfaces and closed, proprietary equipment architectures,” Frey said. “The arrival of AI is changing the rules of the game. Network infrastructure teams, and the equipment providers that supply them, are having to fall back and regroup for this new world, and find a path to programmability that aligns with rest of infrastructure domains.”

Given this new reality, the idea that a future control plane will give AI developers declarative access to bandwidth, latency profiles, or even Layer 7 behavior is not far-fetched, according to Cisco. “We’re building for AI not as a workload, but as the platform,” said Patrick LeMaistre, technical solutions architect at Cisco. “That changes everything.”

Threat actors are increasingly targeting mobile apps, adding to the security risks for enterprises and their customers.

To help address this burgeoning issue, enterprise software delivery platform vendor Digital.ai Tuesday is expanding its Application Security suite with the addition of Quick Protect Agent to give developers a quick, no-code way to protect their enterprise apps from tampering.

While flagship apps such as client-facing mobile banking receive a lot of attention from security teams, secondary and tertiary apps such as trading apps, or apps for employees only that aren’t in public app stores, may not, noted Digital.ai CEO Derek Holt. Security teams just don’t have the resources to apply the same rigor to them. The Quick Protect Agent is designed to fill that gap.

In the 2025 version of Digital.ai’s Annual Application Security Threat Report, Holt said, “We saw that over 80% of the apps in the respective app stores are under attack, and we saw about a 20% increase year over year in the number of attacks.” When investigators dug deeper, they found that the industry has done a “pretty good job” of putting more guards and protections in place in some industry verticals and with primary apps.

“However, the threat actors are now going after secondary and tertiary apps and are starting to expand into industry verticals that maybe were previously not as much of a focus area,” he said.

That discovery led to the development of the Quick Protect Agent, with a simple interface that allows developers to drag and drop their binaries into a GUI and select the level of security required and any or all of the offered protections, including all four OWASP MASVS (Mobile Application Security Verification Standard) Resilience categories. Once the protections are approved, the tool provides a command line interface version of the configuration to include in automated pipelines for future builds.

While the full Application Security Suite gives security teams the ability to fine-tune security for flagship apps, balancing security protections and performance, Holt said, they frequently don’t have the resources to give all apps the same attention. Quick Protect Agent asks a series of questions about general areas of concern and the required balance between performance and security, and the agent then generates the security profile for the app.

In both cases, he said, detailed logs record every decision.

“This is an interesting new set of capabilities and largely aligns with what we are seeing in the devops space,” said Jason Andersen, principal analyst at Moor Insights & Strategy. “Overall, Digital.ai’s assertion that we are witnessing a significant increase in hacking activity is accurate. Companies like JFrog, who cover different aspects of the toolchain, are also seeing similar increases and it’s largely being chalked up to increased use of automation and AI technology by hackers. So, the need is certainly there, especially in mobile applications which tend to be much more frequently updated than typical enterprise web apps. That’s a crucial distinction for a set of applications that are frankly higher visibility due to customer and partner contact.”

Andersen noted that the use of agents in the development workflow accomplishes two things. First, it helps developers not well acquainted with application security to protect their apps. “I’d expect this to lead to better coverage and more frequent application of security processes,” he said.

In addition, he pointed out, the solution makes a lot of sense as the use and complexity of agents increases.

“New agent capabilities and standards, such as those seen in tools like GitHub Copilot, are pointing to a new future in the devops toolchain,” he said. “Consider agents like these engaging in some degree of cross-agent teaming, resulting in a more real-time and autonomous application security process.”

However, said David Shipley, CEO of Beauceron Security, “Obscure code helps, but it doesn’t close vulnerabilities: it makes them harder to find by, for example, old-fashioned trial and error.” This kind of intervention, he said, “is like having the forward collision alert come on to stop an accident” — it’s a good thing, but it would be better if we understood the reason so that we fixed the underlying cause, not just the symptom.

Cloud computing has significantly transformed how businesses manage their IT systems by providing scalability and flexibility, along with access to cutting-edge technology solutions. However, many companies are increasingly dissatisfied due to the rising costs of cloud services coupled with the increased use of cloud resources.

I’ve found that much of this can be attributed to unrealistic expectations or customers failing to implement the technology properly. Many enterprises lack the necessary resources or understanding of cloud resource optimization. Consequently, thousands of applications and data sets that migrated to the cloud now consume excessive resources and waste money.

How vendors price their services is another factor, but companies must also recognize their own poor management in the cloud sector. To thrive in today’s tech-savvy and AI-driven environment, they must take proactive action.

Factors driving up cloud expenses

The simplest reason for the rising expenses associated with cloud services is that major cloud service providers consistently increase their prices. Although competition among these providers helps keep prices stable to some extent, businesses now face inflation, the introduction of new premium services, and the complex nature of pricing models, which are often shrouded in mystery. All these factors complicate cost management.

Meanwhile, many businesses have inefficient usage patterns. The typical approach to adoption involves migrating existing systems to the cloud without modifying or improving their functions for cloud environments. This “lift and shift” shortcut often leads to inefficient resource allocation and unnecessary expenses. A recent analysis revealed that only 13% of CPUs and 20% of memory in Kubernetes deployments are utilized. Multicloud strategies can sometimes result in increased costs and management inefficiencies for businesses, despite their intended purpose of reducing reliance on vendors.

The cost savings and operational ease projected and promised to businesses often fail to materialize, resulting in disappointment and increased financial burdens for enterprises.

Businesses bear the responsibility

Blaming cloud providers for cost increases is a common practice. However, businesses have the ability to manage their cloud expenses more effectively. Unfortunately, many companies fail to implement cost-saving strategies and do not proactively monitor their resource usage. Why?

Most organizations today lack a practical approach to cloud management. They adopt cloud services without setting clear goals or considering how to maximize resource utilization effectively. Many organizations lack a strategy and overlook strategic initiatives such as optimizing workloads and enforcing governance, which are crucial for cost-effective cloud utilization.

Countless companies are currently considering AI and machine learning tasks. According to some projections, these tasks are expected to account for half of cloud computing resources by 2029. AI and machine learning require substantial resources, which can be more costly without carefully planned management and efficiency strategies. Delaying discussions about costs until these systems are operational will leave organizations vulnerable and without options for adjustments along the way.

Organizations need to proactively manage their cloud expenses by taking control by developing and implementing cloud strategies based on practical goals and forward-thinking planning. Here are the key steps.

First, before embracing cloud technology for its advantages, companies should develop a well-defined plan that outlines the rationale, objectives, and approach to using cloud services. Identify which tasks are suitable for cloud deployment and which are not, and assess whether a public, private, or hybrid cloud setup aligns with your business and budget objectives.

Second, before transferring data, ensure that you optimize your tasks to improve efficiency and performance. Please resist the urge to move existing systems to the cloud in their current state. Take a moment to assess workloads and make adjustments to enhance performance. This typically involves reassessing your application structure, optimizing resource usage, and eliminating any redundancy.

Third, effectively managing cloud expenses relies on implementing strong governance practices. Develop guidelines that outline the procedures and protocols for resource provisioning, monitoring, and decommissioning. Set up appropriate governance frameworks to support cost tracking and ensure that resource usage aligns with constraints.

Hone your expertise in cloud finops

Many companies lack the necessary skills to effectively assess and oversee their cloud workloads. By adopting finops—a financial management practice specifically designed for cloud environments—businesses can improve their cost monitoring, resource allocation, and overall value realization.

AI systems come with costs. Consider the needs of AI workloads from the beginning. The demand for AI and machine learning tasks is expected to increase in the future, so begin preparing now. Establishing regulations and governance tailored to AI tasks early on can help avoid exceeding budget limits. This includes outlining the computing resources needed and assessing whether the current infrastructure can efficiently meet these requirements without waste.

Be ready to continually improve. Cloud services are always evolving. It’s essential to monitor resource utilization and associated costs to ensure everything is effectively optimized over time. Utilize tools and services that provide up-to-date information to prevent situations where you‘re either overpaying for capacity or not fully utilizing the available resources.

Reclaim authority and responsibility in the realm of rising costs. Cloud service providers such as Amazon Web Services, Microsoft Azure, and Google Cloud share some of the responsibility. However, businesses should not depend solely on them to manage expenses. Instead, take charge of reducing unnecessary spending and preventing the disappointments that are common among cloud users.

Moving operations to the cloud is not merely a one-time event; it requires ongoing optimization and adjustments to keep pace with technological advancements, such as AI. Businesses that recognize this reality and respond appropriately will not only save money but also position themselves for success by adopting AI and other cutting-edge technologies that depend on cloud computing.

AI coding assistants powered by large language models (LLMs) now feel like junior pair programmers rather than autocomplete on steroids. After months of “vibe coding” with six popular tools, I’m sold on the concept, but every one of them still demands the patience you reserve for a bright but distractible intern. Here’s what each assistant gets right, where it falls short, and why I’ve started building the tool I really want.

ChatGPT: The generalist that runs out of room

OpenAI’s ChatGPT is where most developers start because it understands almost any prompt. In the macOS app, you can even send an open file and get a unified diff back, an upgrade from early cut-and-paste gymnastics. But the moment your change spans several files or a language ChatGPT can’t execute, you’re back to copy-pasting or juggling a detached “canvas” window. Long code blocks sometimes stall, and multi-turn refactors often hit token limits. There are now local plugins and extensions that are supposed to ease this, but I’ve not had much luck yet.

Strengths: Broad model quality, single-file diffs.
Limits: No real project context, external execution, occasional size limits.

GitHub Copilot: Inline speed, narrow field of view

The killer feature of GitHub Copilot is friction-free inline completion inside both Visual Studio and Visual Studio Code. Type a comment, press Tab, get a plausible snippet. Copilot Chat can rewrite multiple files, but the workflow is still tuned for single-file suggestions. Cross-file refactors or deep architectural changes remain awkward. While there is a brand new release I’ve barely tested, I’ve come to the conclusion that GitHub Copilot is where the laggards of AI-assisted development will live, not those doing it day to day.

Strengths: Seamless autocomplete, native IDE support.
Limits: Struggles with cross-file edits, context is mostly whatever’s open.

Cursor: Inline diff done right, at a price

Cursor proves how powerful inline diff review can be. Type a prompt, and it writes code, often crossing dozens of files. Being a VS Code fork, though, it loses built-in C# debugging due to licensing issues. It also enforces hard-coded limits (25 tool calls) you can’t override. Once the conversation grows, latency spikes, and you risk colliding with Cursor’s rate limits. There are frequent outages and slowdowns, sometimes bad enough that I VPN into Germany to finish a task. By the way, I dumped $500 in it this month.

Strengths: Best-in-class diff workflow, improving stability, cheapest way to try Claude 4.
Limits: Closed fork, hard caps, opaque latency.

Windsurf (formerly Codeium): Fast, generous, sometimes chaotic

Windsurf feels like Cursor with a turbocharger. The same OpenAI models return responses two to three times faster, and the free tier is unusually generous. Speed aside, multi-file edits are erratic: Windsurf sometimes wanders into unrelated files even after agreeing to a well-scoped plan. It also thrashes sometimes, a lot of repetitive file scans and tool calls. I sandbox those runs on a throw-away branch and cherry-pick what works. I’m not sure I’ll use Windsurf once it’s not free. By the way, Anthropic just pulled the rug out from under Windsurf for Claude.

Strengths: Exceptional latency, large free quota, cheapest way to use o4-mini and other OpenAI models.
Limits: Unpredictable edits, roadmap may shift after the OpenAI acquisition

RooCode: Agentic power, all-or-crawl workflow

RooCode layers an orchestrator (“Boomerang Tasks”) over its Cline legacy, splitting big requests into subtasks you approve one by one. It ships a diff view, but it’s a modal panel, not the inline experience Cursor and Windsurf provide. Roo has only two speeds: Go Fast (hands-off, great for throw-away prototypes) and Crawl (approve every micro-step). There’s no middle-ground “walk” mode, so real-world development feels either too automated or too granular. Config changes don’t always reload without a restart. Roo is also not the tool you want for AI-assisted debugging.

Strengths: Powerful task orchestration, VS Code plugin rather than fork.
Limits: Modal diff view, no balanced workflow speed, sporadic config glitches.

Claude Code: Because I’m too cool for an IDE

If you’re in a Discord channel, chatting with the in crowd, or just lurking, they aren’t talking about any of these tools. They’re talking about CLI tools. Claude Code is fun and does a good job of realizing some Python scripts and things you might want to try. However, as your project gets bigger and debugging becomes a larger part of the test, you’re going to want and IDE. It isn’t that you can’t use one, it’s just then why are you using this thing for generation and changing things instead of a tool that integrates into your IDE?

Strengths: The most stable way to use Claude.
Limits: I’m not cool enough to debug everything at the command line like I did in the 1990s.

What today’s AI coding assistants still miss

1. Plugin, not fork: Forks break debugger extensions and slow upstream updates.
2. Controlled forgetting and task-aware recall: Most tools “forget” to stay under context limits, but the pruning is blind, often chopping off the high-level why that guided the whole session. We need selective, user-editable forgetting (pin critical goals, expire trivia) and smart recall that surfaces the proper slice of history when a sub-task resumes.
3. Fine-grained control: Pick any model (local or cloud), set per-model rate limits, decide exactly what gets stored in memory and when.
4. Inline diff as table stakes: Line-by-line review is mandatory.
5. Stability first: Crashes and silent time-outs erase trust faster than bad suggestions.
6. Open source matters again: With open LLMs, you can realistically contribute fixes. Accepted pull requests prove it.
7. Deterministic guardrails: The model can be stochastic, but everything around it—config files, rate limits, memory rules—must behave predictably.
8. Optimizing debugging: I don’t want to undersell how much more productive I am since I started vibe coding. However, the makers continue to optimize generation, which is already pretty good. Then I spend a lot of time debugging and fixing my tests. That part is sometimes slower than doing it myself.

No single assistant ticks all eight boxes. The result is a mountain of custom rules and workarounds just to keep projects moving, which is why I’m writing my own tool.

Bottom line

The first wave of AI coding assistants proves the concept but also shows the cost of letting a black-box model drive your IDE. GitHub Copilot nailed autocomplete; Cursor nailed inline diff; Windsurf nailed latency; RooCode nailed orchestration. Combine those strengths with deterministic guardrails, accurate memory control, and plugin-based freedom, and we’ll have an assistant that starts to feel like a mid-level engineer instead of a gifted intern.

Until then, I’ll keep one hand on git revert and the other on the keyboard building the assistant I actually want.

Organizations find themselves navigating an environment where artificial intelligence can be a phenomenal growth engine, while simultaneously introducing unprecedented risks. This leaves executive leadership teams grappling with two critical questions: First, where should an AI cyber risk process begin and end for organizations creating and consuming AI? Second, what governance, training, and security processes should be implemented to protect people, data, and assets against vulnerabilities exposed by human error, AI system bias, and bad actors?

The answers lie in adopting a comprehensive life cycle approach to AI risk management—one that equips the C-suite, IT, AI development teams, and security leaders with the tools to navigate an ever-evolving threat landscape. 

Understanding the faces of AI cyber risk

Trustworthy AI development

Organizations developing AI models or AI applications—i.e., whether creating proprietary machine learning models or integrating AI features into existing products—must approach the process with a security-first mindset. If cyber risks and broader security risks are not properly considered at the onset, an organization is needlessly exposed to several dangers:

• Lack of security-by-design: Models developed without formal oversight or security protocols are more susceptible to data manipulation and adversarial inputs.
• Regulatory gaps: With emerging guidelines like the EU AI Act, the NIST AI Risk Management Framework, and ISO 42001, failing to comply invites legal scrutiny and reputational damage.
• Biased or corrupted data: Poor data quality can yield unreliable outputs, while malicious actors can intentionally feed incorrect data to skew results.

Responsible AI usage

Organizations not actively developing AI are still consumers of the technology—often at scale and without even realizing it. Numerous software-as-a-service (SaaS) platforms incorporate AI capabilities to process sensitive data. Employees might also experiment with generative AI tools, inputting confidential or regulated information that leaves organizational boundaries.

When AI usage is unregulated or poorly understood, organizations face several risks that can lead to serious security gaps, compliance issues, and liability concerns, including:

• Shadow AI tools: Individuals or departments may purchase, trial, and use AI-enabled apps under the radar, bypassing IT policies and creating security blind spots.
• Policy gaps: Many businesses lack a dedicated acceptable use policy (AUP) that governs how employees interact with AI tools, potentially exposing them to data leakage, privacy, and regulatory issues.
• Regional laws and regulations: Many jurisdictions are developing their own specific AI-related rules, like New York City’s Bias Act or Colorado’s AI governance guidelines. Misuse in hiring, financial decisions, or other sensitive areas can trigger liability.

Defending against malicious AI usage

As much as AI can transform legitimate business practices, it also amplifies the capabilities of cyber criminals that must be defended against. Key risks organizations face from bad actors include:

• Hyper-personalized attacks: AI models can analyze massive data sets on targets, customizing emails or phone calls to maximize credibility.
• Increasingly sophisticated deepfakes: Video and voice deepfakes have become so convincing that employees with access to corporate financial accounts and sensitive data have been tricked into paying millions to fraudsters.  
• Executive and board awareness: Senior leaders are prime targets for whaling attempts (spear-phishing cyber attacks that target high-level executives or individuals with significant authority) that leverage advanced forgery techniques.

A life-cycle approach to managing AI risk

Organizations gain a strategic advantage with a life-cycle approach to AI cyber risk that acknowledges AI technologies evolve rapidly, as do the threats and regulations associated with them.

A true life-cycle approach combines strategic governance, advanced tools, workforce engagement, and iterative improvement. This model is not linear; it forms a loop that continuously adapts to evolving threats and changes in AI capabilities. Here is how each stage contributes.

Risk assessment and governance

• Mapping AI risk: Conduct an AI usage inventory to identify and categorize existing tools and data flows. This comprehensive mapping goes beyond mere code scanning; it evaluates how in-house and third-party AI tools reshape your security posture, impacting organizational processes, data flows, and regulatory contexts.
• Formal frameworks implementation: To demonstrate due diligence and streamline audits, align with recognized standards like the EU AI Act, the NIST AI Risk Management Framework, and ISO 42001. In tandem, develop and enforce an explicit acceptable use policy (AUP) that outlines proper data handling procedures.
• Executive and board engagement: Engage key leaders, including the CFO, general counsel, and board, to ensure they comprehend the financial, legal, and governance implications of AI. This proactive involvement secures the necessary funding and oversight to manage AI risks effectively.

Technology and tools

• Advanced detection and response: AI-enabled defenses, including advanced threat detection and continuous behavioral analytics, are critical in today’s environment. By parsing massive data sets at scale, these tools monitor activity in real time for subtle anomalies—such as unusual traffic patterns or improbable access requests—that could signal an AI-enabled attack.
• Zero trust: Zero trust architecture continuously verifies the identity of every user and device at multiple checkpoints, adopting least-privilege principles and closely monitoring network interactions. This granular control limits lateral movement, making it far more difficult for intruders to access additional systems even if they breach one entry point.
• Scalable defense mechanisms: Build flexible systems capable of rapid updates to counter new AI-driven threats. By proactively adapting and fine-tuning defenses, organizations can stay ahead of emerging cyber risks.

Training and awareness

• Workforce education: Ransomware, deepfakes, and social engineering threats are often successful because employees are not primed to question unexpected messages or requests. To bolster defense readiness, offer targeted training, including simulated phishing exercises.
• Executive and board involvement: Senior leaders must understand how AI can amplify the stakes of a data breach. CFOs, CISOs, and CROs should collaborate to evaluate AI’s unique financial, operational, legal, and reputational risks.
• Culture of vigilance: Encourage employees to report suspicious activity without fear of reprisal and foster an environment where security is everyone’s responsibility.

Response and recovery

• AI-powered attack simulations: Traditional tabletop exercises take on new urgency in an era where threats materialize faster than human responders can keep pace. Scenario planning should incorporate potential deepfake calls to the CFO, AI-based ransomware, or large-scale data theft.
• Continuous improvement: After any incident, collect lessons learned. Were detection times reasonable? Did staff follow the incident response plan correctly? Update governance frameworks, technology stacks, and processes accordingly, ensuring that each incident drives smarter risk management.

Ongoing evaluation

• Regulatory and threat monitoring: Track legal updates and new attack vectors. AI evolves quickly, so remaining static is not an option.
• Metrics and continuous feedback: Measure incident response times, security control effectiveness, and training outcomes. Use this data to refine policies and reallocate resources as needed.
• Adaptation and growth: To keep pace with the changing AI landscape, evolve your technology investments, training protocols, and governance structures.

A proactive, integrated approach not only safeguards your systems but also drives continuous improvement throughout the AI life cycle.

As AI development intensifies—propelled by fierce market competition and the promise of transformative insights—leaders must move beyond questioning whether to adopt AI and focus instead on how to do so responsibly. Although AI-driven threats are becoming more complex, a life-cycle approach enables organizations to maintain their competitive edge while safeguarding trust and meeting compliance obligations.

John Verry is the managing director of CBIZ Pivot Point Security, CBIZ’s cybersecurity team, in the National Risk and Advisory Services Division. 

—

Generative AI Insights provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss the challenges and opportunities of generative artificial intelligence. The selection is wide-ranging, from technology deep dives to case studies to expert opinion, but also subjective, based on our judgment of which topics and treatments will best serve InfoWorld’s technically sophisticated audience. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Contact doug_dineley@foundryco.com.

Structured Query Language, the standard means of manipulating and querying data in relational databases since the 1980s, has dropped out of the Tiobe index top 10 in recent months and now ranks 12th, its lowest-ever position. The Tiobe index for June 2025 was published June 8.

“SQL will remain the backbone and lingua franca of databases for decades to come,” said Paul Jansen, CEO of software quality services vendor Tiobe, in the June release of the index. “However, in the booming field of AI, where data is usually unstructured, NoSQL databases are often a better fit.” Jansen likened the popularity of NoSQL to the rise of dynamically typed languages such as Python if compared to well-defined, statically typed languages such as C++ and Java.

While SQL was a serious top 10 player when the index began in 2001, it was taken from the list after someone noted in 2004 that SQL was not a  programming language. In 2018, it was pointed out that SQL is Turing-complete, which makes it a programming language. So SQL was re-added to the index.

The monthly Tiobe Programming Community Index rates the popularity of programming languages based on the number of engineers worldwide, courses, and third-party vendors pertinent to a language. The ratings are calculated using websites such as Google, Bing,  Amazon, Wikipedia, and more than 20 others.

The Tiobe index top 10 for June 2025:

1. Python, with a rating of 25.87%
2. C++, 10.68%
3. C, 9.47%
4. Java, 8.84%
5. C#, 4.69%
6. JavaScript, 3.21%
7. Go, 2.28%
8. Visual Basic, 2.2%
9. Delphi/Object Pascal, 2.15%
10.  Fortran, 1.86%

The alternative Pypl Popularity of Programming Language index assesses language popularity based on how often language tutorials are searched on in Google. The Pypl top 10 for June 2025:

1. Python, with a 30.63% share
2. Java, 15.36%
3. JavaScript, 7.78%
4. C/C++, 7.02%
5. C#, 6.02%
6. R, 4.63%
7. PHP, 3.58%
8. Rust, 2.97%
9. TypeScript, 2.81%
10. Objective-C, 2.79%

As much as we like to imagine technology repeatedly presents us with something novel, the reality is that tech history usually repeats itself. Whether mobile, cloud, or another technology trend, the platform that wins developers ends up owning the market. Microsoft learned this lesson with Windows and .NET, and AWS with cloud primitives, as detailed by Microsoft exec Scott Guthrie in a fascinating recent interview. Today we’re seeing the same dynamic in AI. Powerful models matter, sure, but the real prize will go to whoever makes AI trivial to build into everyday software.

In other words, the center of AI gravity isn’t research papers or GPUs; it’s the IDE, the API, and the open source repo. Whoever nails that workflow will end up with the largest, most loyal community—and the bank balance that goes with it. Nothing is guaranteed, but for a variety of reasons, Microsoft seems to be in the strongest position.

Microsoft: The accidental front-runner

Microsoft looks like an overnight AI sensation, but its lead has been decades in the making and originally had nothing to do with AI. It is, and was, always a matter of developers.

According to Guthrie, Microsoft’s early dominance didn’t happen because Windows was a superior operating system. Microsoft relentlessly focused on making it easy for developers to build for Windows. “No one buys a platform by itself,” Guthrie notes, “they buy it for the applications that run on top.” Microsoft’s success was built on a foundation of tools such as Quick Basic and Microsoft C, which armed developers to build the ecosystem that made Windows indispensable.

Then came Visual Basic, a tool Guthrie calls “absolutely revolutionary.” At a time when building a graphical user interface was a soul-crushing exercise in writing error-prone code, Visual Basic let developers drag and drop buttons, double-click, write a few lines of code, and run. It “transformed development” by lowering the barrier to entry, enabling a generation of programmers who were more focused on solving business problems than mastering arcane syntax.

This playbook—empower the developer, win the platform—is core to Microsoft’s DNA. It’s why the company faltered in the early 2010s when its developer story grew stale, and it’s precisely how it engineered its stunning comeback.

The masterstroke, of course, was Visual Studio Code, or VS Code.

By 2014, Microsoft was losing the hearts and minds of the next generation of web and cloud developers who lived on Macs and in open source. As Guthrie tells it, Microsoft leadership knew they were on a “slowly melting iceberg.” Their response wasn’t to build a better Azure portal. It was to make a series of bold, developer-first decisions: They open-sourced .NET and made it cross-platform, and, most critically, they launched VS Code.

VS Code was free, fast, open source, and ran everywhere. It wasn’t an explicit on-ramp to Azure; it was just a great tool that developers loved. That love rebuilt Microsoft’s credibility from the ground up and created the bridge that made the GitHub acquisition not just possible but palatable to a skeptical developer community. Today, Microsoft owns the primary editor (VS Code) and the primary collaboration platform (GitHub) preferred by developers. VS Code is used by three quarters of professional developers, and GitHub boasts more than 100 million developers. As Guthrie puts it in his interview with Gergely Orosz, “If you don’t have developers … building … applications [on your platform then] you don’t … have a business.”

It’s safe to say Microsoft now has lots (and lots) of developers building applications on its platforms.

GitHub Copilot also created a virtuous cycle for Azure. Need more model horsepower? One click in VS Code lights up an Azure OpenAI endpoint. Microsoft’s $10 billion bet on OpenAI, which at the time seemed excessive, suddenly looks cheap; the company turned bleeding-edge research into a sticky developer value proposition faster than any rival. Microsoft, weirdly, is cool again.

Is the AI war Microsoft’s to lose?

None of this guarantees Microsoft the winning position in AI, but it does make unseating Microsoft difficult. Again, the winner in AI will not be the company with the best API for a stand-alone model. The winner will be the company that seamlessly integrates AI into the developer’s existing workflow, making them more productive by orders of magnitude. Guthrie sees AI not as a replacement for developers but as the next evolution—a continuum from IntelliSense to today’s AI agents. “It’s really about … giving every developer superpowers,” he says.

Microsoft is clearly ahead with this approach. Guthrie’s vision of evolving Copilot from a code-completing assistant to an autonomous agent that can take a Figma design and build a working microservices architecture is the holy grail of developer enablement. If the tech giant can pull it off, it’ll be tough to beat.

Even so, it’s way too early to declare victory.

Take AWS, for example. AWS has a massive, entrenched developer base, roughly one-third of all cloud spend, and an extensive menu of AI services, such as Amazon Bedrock and Amazon SageMaker. On this last front, AWS has been trying to up its developer tools game. Amazon Q Developer, for example, is an IDE plug-in that promises everything GitHub Copilot does, plus deep knowledge of your AWS bill, identity and access management policies, and Kubernetes manifests. AWS has the distribution and is trying to give developers a reason to keep workloads on AWS.

And yet, AWS has never been a “tools” company. Its strength lies in providing a vast, powerful, and often bewildering array of infrastructure primitives. The developer experience can feel like assembling a car from a million different parts without a manual. AWS Cloud9 has failed to gain any meaningful traction against VS Code. AWS is powerful but has never demonstrated the product savvy to build a cohesive, beloved developer tool.

For AWS to win the AI tools race would require a fundamental shift in its corporate DNA. After all, Microsoft didn’t just integrate GPT-4; it re-thought the whole editing experience. AWS must prove it can match that polish while keeping its hallmark flexibility. If it does, its installed base all but guarantees share. If not, developers may happily write Lambda functions in VS Code—and deploy them on Azure.

What about OpenAI? It has what the others crave: unparalleled mindshare and, for now, the “hottest” models. Developers genuinely love the elegance and power of OpenAI’s APIs. OpenAI has successfully made sophisticated AI accessible to anyone with a credit card and a few lines of Python.

But OpenAI is not a platform company. OpenAI is a feature, albeit a spectacular one. It exists entirely on top of someone else’s platform (Microsoft Azure). OpenAI doesn’t own the editor, the source control, or the CI/CD pipeline. To win, the company must either build out this entire developer ecosystem themselves—a monumental task—or hope that their API-led momentum is so strong that it doesn’t matter. The risk is that OpenAI becomes a commoditized intelligence layer, with the true value accruing to the platform that integrates its APIs most effectively.

Keep an eye on Redmond

History rarely repeats itself exactly, but its lessons are potent. Just as Visual Basic transformed development by simplifying complexity, AI-powered tools will do the same on a much grander scale. For this reason, Microsoft is the clear favorite to win the largest share of the AI market.

Their victory is not guaranteed. It depends on their ability to execute on the VS Code playbook: prioritizing the developer experience above all else, even if it means building tools that help developers deploy to AWS or Google Cloud. The moment VS Code feels like a restrictive on-ramp to Azure, its magic will fade. The same is true of GitHub.

Microsoft, as Guthrie calls out, learned its lesson in the early 2010s and has kept its eye on developers. Today Microsoft starts closer to developers’ keyboards and has shown a willingness to bet the balance sheet to stay there. But AI platform cycles are measured in months not decades. AWS has the cash and OpenAI has the mindshare, and both have huge communities betting on their success. All of this is great for developers, who have never had more leverage.