A newly arrived sixth preview of Microsoft’s planned .NET 10 application development platform touts improved JIT code generation for struct arguments, one-shot tool execution, and other enhancements in the .NET libraries, runtime, and SDK, as well as the ASP.NET Core, Blazor, and .NET MAUI frameworks.

.NET 10 Preview 6 was announced July 15. The production release is expected in November. Developers can download Preview 6 at dotnet.microsoft.com.

With improved code generation for struct arguments, .NET 10 Preview 6 has the JIT compiler now able to place promoted members of struct arguments into shared registers. The compiler also offers improved loop inversion in the preview, a transformation that moves the condition to the bottom of the loop to improve code layout. Numerous optimizations like loop cloning and loop unrolling depend on loop inversion, Microsoft said.

With one-shot tool exaction, developers now can use the dotnet tool exec command to execute a .NET tool without installing it locally or globally. This is especially valuable for CI/CD or ephemeral usage, according to Microsoft.

Also featured in .NET 10 Preview 6 is an option to disallow JSON properties, tending to an issue in which the JSON specification does not specify how to handle duplicate properties when deserializing a JSON payload, which can lead to security vulnerabilities and unexpected results.

.NET 10 Preview 6 follows .NET 10 Preview 5, which was unveiled June 10 and featured C# 14 and runtime enhancements. The first preview was announced February 25, followed by a second preview on March 18, a third preview on April 10, and a fourth preview on May 13.

Other improvements in .NET 10 Preview 6:

• .NET tools now can be published with support for multiple RuntimeIdentifiers (RIDs) in a single package. Tool authors can bundle binaries for supported platforms, and the .NET CLI will select the correct one at install or run time. This makes cross-platform tool authoring and distribution much easier, Microsoft said.
• A new option, --cli-schema, is available on CLI commands. When used, the option outputs a JSON representation of the CLI command tree for the invoked command or subcommand. This is useful for shell integration, tool authors, and advanced scripting.
• File-based apps now support being published to native executables via the dotnet publish app.cs command. This makes it easier to create simple apps that can be redistributed as native executables.
• Blazor now provides a component that generates link tags for preloading framework assets instead of using link headers. This offers better control over WebAssembly preloading behavior and correctly identifies the application’s base URL. Also, Blazor now supports validating nested objects and collection items in forms.
• For Windows Presentation Foundation (WPF), the Fluent theme has been improved, with capabilities such as a Fluent style for GridView.
• Quality improvements were made to Entity Framework, along with a focus on build performance.
• Windows Forms has improvements to dark mode support such as ListView ColumnHeaders now rendering correctly in dark mode.
• New security APIs were introduced to protect forms containing sensitive information from the usual screen capture approaches.

Qdrant has launched Qdrant Cloud Inference, a managed service that allows developers to generate, store, and index text and image embeddings in the Qdrant Cloud. The service, which uses integrated models within a managed vector search engine, is designed to simplify building applications with multimodal search, retrieval-augmented generation, and hybrid search, according to the company.

Announced July 15, Qdrant Cloud Inference is a managed vector database offering multimodal inference and using separate image and text embedding models, natively integrated in Qdrant Cloud. The service combines dense, sparse, and image embeddings with vector search in one managed environment. Users can generate, store, and index embeddings in a single API call, turning unstructured text and images into search-ready vectors in a single environment, Qdrant said. 

Directly integrating model inference into Qdrant Cloud removes the need for separate inference infrastructure, manual pipelines, and redundant data transfers, simplifying workflows, accelerating development cycles, and eliminating unnecessary network hops for developers, according to Qdrant. “Traditionally, embedding generation and vector search have been handled separately in developer workflows,” said André Zayarni, CEO and co-founder of Qdrant. “With Qdrant Cloud Inference, it feels like a single tool: one API call with optimal resources for each component.”

Supported models in Qdrant Cloud Inference include MiniLM, SPLADE, BM25, Mixedbread Embed-Large, and CLIP for both image and text. Additional models will become available over time. The new offering includes as much as five million free tokens per model each month, with unlimited tokens for BM25. Qdrant Cloud Inference is currently only available in US regions for paid clusters. Support for inference in other regions is coming soon, Qdrant said.

Seeking to ease web and mobile app testing by leveraging AI, Perforce Software has unveiled Perfecto AI, an agentic AI testing tool that removes the need for test scripts, frameworks, or maintenance and streamlines testing workflows, according to the company.

Announced July 15 as part of the Perforce Continuous Testing Platform, the AI-powered testing tool enables teams to generate execution-ready test actions from plain language, validating apps across the web, Android, and iOS without having to write any code. Perfecto AI adapts in real time to changing user flows, UI updates, and test failures, marking a shift from script generation to true script elimination, according to Perforce.

Customers of Perforce already have reported efficiency gains of 50% to 70% in test creation and triage, along with reductions in manual validation and maintenance work, the company said. Integration with existing CI/CD pipelines by Perfecto AI enables new testing powered by AI, with no maintenance across web, desktop, and mobile. And unlike AI-only startups, Perforce still supports teams running legacy frameworks while enabling full AI-driven automation, Perforce said.

AWS is previewing a specialized storage offering, Amazon S3 Vectors, that it claims can cut the cost of uploading, storing, and querying vectors by up to 90% compared to using a vector database, a move likely to be of interest to those running generative AI or agentic AI applications in the cloud.

Machine learning models typically represent data as vectors — groups of parameters describing an object — and AI systems use these vector embeddings to efficiently search and reason between different pieces of data.

The vectors are typically stored in specialty vector databases or databases with vector capabilities for similarity search and retrieval at scale.

In contrast, AWS is proposing that enterprises use a new type of S3 bucket purpose-built for storing and querying vector data via a dedicated set of APIs, Amazon S3 Vector, that it says eliminates the need for provisioning infrastructure for a vector database.

Raya Mukherjee, senior analyst at Everest Group, said Amazon S3 or any other cloud-based object storage is cheaper to run and maintain compared to vector databases due to differences in their structure and hardware requirements and thus will help enterprises simplify architecture, reduce operational overhead and decrease cost, said.

While object storage is designed to handle vast volumes of unstructured data using a flat architecture that minimizes overhead and supports efficient retrieval of individual files, vector databases are engineered for high-performance similarity search across complex, high-dimensional data and often rely on specialized indexing methods and hardware acceleration that can drive up infrastructure and operational expenses.

Each Amazon S3 Vectors bucket can support up to 10,000 individual vector indexes, and each index is capable of storing tens of millions of vectors, automatically optimizing storage for performance and cost as vectors are written, updated, or deleted, according to AWS.

Additionally, AWS has integrated S3 Vectors with Amazon Bedrock Knowledge Bases, Amazon SageMaker Unified Studio, and Amazon OpenSearch Service.

This should ensure efficient use of resources even as datasets grow and evolve, Mukherjee said.

While the integration with Bedrock Knowledge Bases and SageMaker Unified Studio will help developers to build RAG applications that ensures cost efficiency of fine-tuning LLMs and reduces hallucinations, the OpenSearch integration will provide flexibility for enterprises to store rarely accessed vectors to save costs.

When these vectors are needed, developers can dynamically shift them to OpenSearch for real-time, low-latency search, the company said.

Enterprises and developers can try out Amazon S3 Vectors, and its integrations with Amazon Bedrock, Amazon OpenSearch Service, and Amazon SageMaker across the US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Frankfurt), and Asia Pacific (Sydney) regions.

It is a universal truth that everything in software eventually rots. Things slowly get worse. What starts out as cool and clean becomes “what the hell were they thinking” before you know it.

But that doesn’t mean we sit back and let it happen. We should fight code rot like a cat that just realized it has socks on. 

One area of code rot that doesn’t get enough attention is database design. Now, there are some big and important rules for designing databases, but I’m not talking about those here. Here I’ll focus on some lesser database design tips that might not be on your radar. Let’s call them small and important rules.

However, I will say this about those big rules: If you are designing a database and you don’t know what database normalization is, stop right now and go learn. Don’t even consider designing a database until you understand second normal form and third normal form. And try for third normal form.

Every table has an ID field

I know this is debatable, but I believe that every single table in your database should have a primary key named ID. That’s it, just ID. Not CustomerID, not OrderID, just ID. 

It should be an auto-incremented integer value (or maybe a UUID if you have a really, really good reason, like a distributed system). There should, of course, be an index on the ID field. 

It should be a very, very rare case that you would need a multiple-field key for a table that isn’t a cross-reference for a many-to-many relationship.

Never put spaces in table or field names

I hereby heap eternal scorn and shame upon the person who thought it would be a good idea to include spaces in table or field names. Just don’t. Spaces in names make you use quotation marks, which you forget, and they make you ask, “Is that with or without spaces?” when you are writing a query. It’s a pain in the ass. Never use spaces and you’ll never have to wonder about it again.

And for the sake of sweet baby Elvis, please don’t use underscores in names, either. I have no idea how people can stand typing names_like_this. My pinky wants to file a workman’s comp claim just thinking about it.

Table names are plural

Again, this is a great debate, but I believe that tables represent many things, not one thing. Thus, table names should always be plural. Customers, not Customer. This way, when you see the word Orders, you know it is referring to the table. If you name the table Order, you create an ambiguity around the word “order.” Are you talking about the table or a row in the table?

I know a lot of ink has been spilled on this topic. I strongly prefer plural names. Whatever you do, pick one system and stick with it.

Foreign keys should be clearly labeled

Remember what I said above about the ID field? Here’s where it comes into play. If you have a row in the Orders table that references a customer (i.e., a foreign key), give it the name CustomerID. Any field named ID will always be a foreign key to the table. Do this consistently throughout your schema, and it will always be clear which fields are foreign keys and which table those fields refer back to.

Index what you query

Put an index on every field that shows up in a WHERE, JOIN, or ORDER BY clause. Do this religiously and you’ll avoid many performance problems down the road. There may be exceptions, but you should find them by over-indexing, not under-indexing. Assume an index is needed and then let your query analyzer convince you to remove any indices that are causing problems. 

Referential integrity is not optional

Ensuring that the relations between tables remain intact and that there are no orphaned records in your database is essential for data integrity. All modern relational databases have referential integrity. Use it and enforce it ruthlessly from the very start. Do not rely on your code to maintain those relationships. The database has the capability, and you should employ it.

Don’t embed SQL in your code

If you ever embed SQL in your code, even “just this one time,” you will live to regret it. Never mind that it opens the door for “just one more time.” Embedded SQL tangles your code and couples it to your database in ways that will result in a huge pile of spaghetti. Remember, let the database do the work. 

If you need to use SQL in your code, maintain it apart from the code, and don’t require the compiler to process it. Store it in separate files that can be embedded or used outside of the code and can be updated without altering code logic.

Some additional thoughts

As a general rule, if the database can do it for you, let the database do it for you. Databases know how to handle data about 453.7 times better than you do. Don’t try to do their job. 

If you ever feel like adding fields ending in 1, 2, 3, etc., don’t. Read up on normalization.

Use the correct data type for a column. Don’t use a number for a boolean or a string for a date.

Strongly consider adding CreatedAt and UpdatedAt timestamp fields to every table. You’ll be surprised at how often you end up being glad that you did. Automate these timestamps with triggers, and they will become useful and painless.

Parameterized stored procedures are your friends. Use them as much as you can.

Your query analyzer is an order of magnitude better at deciding what is the best way to query data than you are.

Beware of booleans. Null turns booleans into quantum states—neither true nor false until someone runs a query. Don’t use a boolean unless you know exactly what null means in that context.

Don’t depend on string values to define state. Use an enumerated value instead, ensuring that the data is never wrong. Don’t let status = 'bananna' cause an error because someone fat-fingered a field.

It is a universal truth that everything in software eventually rots. Things slowly get worse. What starts out as cool and clean becomes “what the hell were they thinking” before you know it.

But that doesn’t mean we sit back and let it happen. We should fight code rot like a cat that just realized it has socks on. 

One area of code rot that doesn’t get enough attention is database design. Now, there are some big and important rules for designing databases, but I’m not talking about those here. Here I’ll focus on some lesser database design tips that might not be on your radar. Let’s call them small and important rules.

However, I will say this about those big rules: If you are designing a database and you don’t know what database normalization is, stop right now and go learn. Don’t even consider designing a database until you understand second normal form and third normal form. And try for third normal form.

Every table has an ID field

I know this is debatable, but I believe that every single table in your database should have a primary key named ID. That’s it, just ID. Not CustomerID, not OrderID, just ID. 

It should be an auto-incremented integer value (or maybe a UUID if you have a really, really good reason, like a distributed system). There should, of course, be an index on the ID field. 

It should be a very, very rare case that you would need a multiple-field key for a table that isn’t a cross-reference for a many-to-many relationship.

Never put spaces in table or field names

I hereby heap eternal scorn and shame upon the person who thought it would be a good idea to include spaces in table or field names. Just don’t. Spaces in names make you use quotation marks, which you forget, and they make you ask, “Is that with or without spaces?” when you are writing a query. It’s a pain in the ass. Never use spaces and you’ll never have to wonder about it again.

And for the sake of sweet baby Elvis, please don’t use underscores in names, either. I have no idea how people can stand typing names_like_this. My pinky wants to file a workman’s comp claim just thinking about it.

Table names are plural

Again, this is a great debate, but I believe that tables represent many things, not one thing. Thus, table names should always be plural. Customers, not Customer. This way, when you see the word Orders, you know it is referring to the table. If you name the table Order, you create an ambiguity around the word “order.” Are you talking about the table or a row in the table?

I know a lot of ink has been spilled on this topic. I strongly prefer plural names. Whatever you do, pick one system and stick with it.

Foreign keys should be clearly labeled

Remember what I said above about the ID field? Here’s where it comes into play. If you have a row in the Orders table that references a customer (i.e., a foreign key), give it the name CustomerID. Any field named ID will always be a foreign key to the table. Do this consistently throughout your schema, and it will always be clear which fields are foreign keys and which table those fields refer back to.

Index what you query

Put an index on every field that shows up in a WHERE, JOIN, or ORDER BY clause. Do this religiously and you’ll avoid many performance problems down the road. There may be exceptions, but you should find them by over-indexing, not under-indexing. Assume an index is needed and then let your query analyzer convince you to remove any indices that are causing problems. 

Referential integrity is not optional

Ensuring that the relations between tables remain intact and that there are no orphaned records in your database is essential for data integrity. All modern relational databases have referential integrity. Use it and enforce it ruthlessly from the very start. Do not rely on your code to maintain those relationships. The database has the capability, and you should employ it.

Don’t embed SQL in your code

If you ever embed SQL in your code, even “just this one time,” you will live to regret it. Never mind that it opens the door for “just one more time.” Embedded SQL tangles your code and couples it to your database in ways that will result in a huge pile of spaghetti. Remember, let the database do the work. 

If you need to use SQL in your code, maintain it apart from the code, and don’t require the compiler to process it. Store it in separate files that can be embedded or used outside of the code and can be updated without altering code logic.

Some additional thoughts

As a general rule, if the database can do it for you, let the database do it for you. Databases know how to handle data about 453.7 times better than you do. Don’t try to do their job. 

If you ever feel like adding fields ending in 1, 2, 3, etc., don’t. Read up on normalization.

Use the correct data type for a column. Don’t use a number for a boolean or a string for a date.

Strongly consider adding CreatedAt and UpdatedAt timestamp fields to every table. You’ll be surprised at how often you end up being glad that you did. Automate these timestamps with triggers, and they will become useful and painless.

Parameterized stored procedures are your friends. Use them as much as you can.

Your query analyzer is an order of magnitude better at deciding what is the best way to query data than you are.

Beware of booleans. Null turns booleans into quantum states—neither true nor false until someone runs a query. Don’t use a boolean unless you know exactly what null means in that context.

Don’t depend on string values to define state. Use an enumerated value instead, ensuring that the data is never wrong. Don’t let status = 'bananna' cause an error because someone fat-fingered a field.

I’ve left you with a lot of dos and don’ts here. Again, the most important takeaway is to pick a set of rules and enforce them ruthlessly. Do that today, and you’ll save yourself many headaches down the road. Future you will thank you, believe me.

This year’s update to the JavaScript specification covers a lot of ground. The headline addition is the new built-in Iterator object and its functional operators. Other updates include new Set methods, a direct JSON module import, improvements to regular expressions, a new Promise.try method for streamlining Promise chains, and a new Float16Array typed array.

Let’s take a tour of JavaScript’s newest features and what you can do with them.

The Iterator object

We’ll start with the most far-reaching addition, which the spec describes as “a new Iterator global with associated static and prototype methods for working with iterators.”

Everything here begins with the built-in global Iterator. (If you hit F12 and open the JavaScript console in Devtools, you can see the object is there.) This object lets you wrap existing iterable objects in a new interface that provides functional operators like map and filter.

The most exciting part of this wrapper is twofold: It gives a syntax improvement by providing functional operators on iterables that don’t have them, and its implementation of these is lazy, with in-line evaluation of elements. This yields performance benefits, especially for large or streaming collections.

The new Iterator also lets you wrap simple iterators that don’t have functional operators, like function generators. That means Array and other iterables can be handled within the same consistent API, benefiting from better performance.

I should emphasize that JavaScript’s Arrays, while they do have built-in functional operators, work by eagerly evaluating the entire array and producing intermediate “working arrays” at each stage of the operation. So, any time you call map or filter, you are implying the background creation of a subarray. Iterator works like other functional programming-style APIs (Java Streams, for example), where each operator is processed element-wise and a new collection is only created when a terminal operator is reached.

A couple of short examples will demonstrate how this works. First, say we have an array of smart people:

let smarties = ["Plato","Lao Tzu","St. Augustine","Ibn Arabi","Max Planck","David Bohm"];

If we wanted to convert this array to use Iterator’s improved map function, we could do this:

Iterator.from(smarties).map(x => x.length).toArray();  // [5, 7, 13, 9, 10, 10]

We use the from() to create the Iterator object, while toArray is the terminal operator. As a reminder, you could also do this with Array.map, but the implementation of Iterator.map() is lazy under the hood. To see this in action, let’s say we were filtering on length:

Iterator.from(smarties).map(x => x.length).filter(x => x < 10).toArray(); // [5, 7, 9]

Adding the take() operator “short circuits” this process by indicating we are only interested in the first two elements that meet our criteria. This means only the part of the source array needed to fulfill the criteria will be processed:

Iterator.from(smarties).map(x => x.length).filter(x => x < 10).take(2).toArray() // [5, 7]

Next, we want to see how Iterator wraps a non-array iterator. We’ll start with a simple generator that produces the same output:

function* getSmartiesNames() {
    yield "Plato";
    yield "Lao Tzu";
    yield "St. Augustine";
    yield "Ibn Arabi";
    yield "Max Planck";
    yield "David Bohm";
}

Now we wrap that in an Iterator:

terator.from(getSmartiesNames()) 
    .map(name => name.length)                            
    .filter(length => length < 10) 
    .take(2)
    .toArray();   

Notice the Array and generator now have the same functional API, and both benefit from the underlying optimization. (Of course, these examples are intentionally very simple.)

New Set methods

The Set class isn’t as often used in JavaScript as other languages because it was a later addition, and because the Array object is so ubiquitous and flexible. However, Set offers a guaranteed unique, unsorted collection that preserves insertion order and linear time for the has and delete operations. The addition of new methods derived from set theory makes it even more useful.

These methods are easy to understand, especially if you’ve already used them in a language like SQL. They’re also very handy.

Set.intersection finds the elements that are the same in two sets:

let set =new Set(["A","B","C"]);
let set2 = new Set(["C","D","E"]);

set.intersection(set2); // yields {‘C’}

Notice that here the ‘C’ element is only present once in the resulting Set because sets do not hold duplicates.

Set.difference “subtracts” the right set from the left:

set.difference(set2); // yields {“A”,”B”}

This leaves us with whatever was in the first set but not in the second:

set.symetricDifference(set2); // yields {'A', 'B', 'D', 'E'}

Notice the ‘C’ element was dropped in this sample, because it was the only one shared by both sets.

The spec also includes three new methods for checking set relationships. These are fairly self-explanatory:

• isSubsetOf checks whether the first set is entirely contained by the second.
• isSupersetOf checks whether the first set entirely contains the second.
• isDisjointFrom checks whether the two sets are entirely different.

Import JSON as a module

ES2025 standardizes the ability to import JSON directly as a module. This avoids the need to manually import JSON files or use a build step for that purpose. It makes importing JSON about as simple as you could hope:

import appConfig from './data.json' with { type: 'json' };

The contents of appConfig are now the actual JSON-parsed object of the file (not a string). This only works for local files, not remote locations.

The with keyword points to the module attributes the spec is referring to. Right now, this keyword is used only to specify a JSON module’s type as JSON (it was added to avoid the possibility of interpreting the contents as JavaScript). In the future, with could be used to designate other module attributes.

Improvements to regular expressions

The new RegExp.escape static method lets you prevent injection attacks on regular expression strings. It will escape any characters with special meaning in a regex context, analogous to similar functions that prevent SQL injection on arbitrary SQL strings. This lets you safely consume untrusted regex strings.

Imagine if you have a part of your system that takes user input and combines it with regular expressions. A malicious (or puckish) user could add regex expressions that would throw syntax errors. Just run RexExp.escape(userInput) first, though, and that problem is prevented.

Another improvement is noted in the spec as: “added syntax for enabling and disabling modifier flags inline within regular expressions.”

If you are an aficionado of regular expressions, this is a bread-and-butter kind of improvement. For the rest of us, it might be a tad esoteric. The essence is to allow you to apply flags to only small internal sections of an expression. In the past, flags (like case sensitivity) applied to the whole expression. There was no way to make a flag apply to only a subsection of the expression without either a convoluted workaround or breaking it into multiple regular expressions and executions.

Now you can define subsections that apply their own flags. Let’s imagine we have these snippets from some famous Beatles’ songs:

const beatlesLyrics = [ 
"All You Need Is Love", 
"Can't Buy Me Love", 
"A Hard Day's Night",
"Eight Days a Week", 
"Yesterday, all my troubles seemed so far away.",
"Love Me Do"
 ];

What we want is to match “love” case-insensitive, but “Day” case-sensitive.  There was no good way to do that before, but now it’s pretty easy:

const beatlesSearchRegex = /(?i:Love)|(?-i:Day)/;

This tells us to match the two parenthetical parts (the question mark indicates it is a non-capturing group; one that does not maintain a reference) with independant flags applied. In this case, we apply case insensitivity (i) to Love, but not to Day. Because the day is lowercase, we do not match on the “Yesterday” in this set of strings.

The new Promise.try method

According to the spec, the new Promise.try method is for “calling functions which may or may not return a Promise and ensuring the result is always a Promise.”

This is a slick addition. It lets you wrap a promise chain in Promise.try() so that any synchronous errors that bubble out will be handled by the chained .catch(). That means you can skip the extra try{} block and use your catch() to handle both asynchronous and synchronous errors:

Promise.try(() => thisMightThrowSyncError("foobar")) 
  .then(val => console.log("All is well", val)) 
  .catch(err => console.error("Error:", err.message));

Promise.try will also handle all errors, synchronous or asynchronous, for the operations that are chained within, so you can chain promises without breaking them up for try blocks:

Promise.try(() => possibleSyncError("foo"))
  .then(processedStep1 => possibleAsyncError("bar"))   
  .then(processedStep2 => fanotherPossibleAssyncError("baz"))
  .then(finalResult => console.log("Success", finalResult)) 
  .catch(error => console.error("All errors arrive here", 
error.message, "I am an error"));

Another power of Promise.try is that it intelligently handles operations that return simple values or a Promise. Imagine you have a function that may return a cache value if it hits, or a Promise if it makes a network call:

function fetchData(key) { 
  if (cache[key]) { 
    return cache[key]; 
  } else { 
    return new Promise(resolve => { 
      setTimeout(() => { data = { id: key, name: `New Item ${key}`, source: "DB" }; 
        cache[key] = data; 
      }, 500);
    }); 
  } 
}

Whether that hits or not, Promise.try will accept the call and route all errors to the catch block:

Promise.try(() => fetchData("user:1")) 
  .then(data => console.log("Result 1 (from cache):", data))
  .catch(error => console.error("Error 1:", error.message));

Float16Array TypedArray

This update is described in the spec as “added a new Float16Array TypedArray kind as well as the related DataView.prototype.getFloat16, DataView.prototype.setFloat16, and Math.f16round methods.”

The Float16 type is used in high-performance computing, where the application needs to maximize the memory usage by trading footprint for precision. This includes machine learning, which is probably the driver for this addition.

JavaScript has not added a new scalar numeric type. It still only has Number, but it now has Float16Array for holding collections of this type. JavaScript Number uses double precision 64-bit floating point format; however, in cases where you are using large amounts of numbers, where less precision is acceptable (as in neural network weights and biases), using 16-bit can be a big optimization.

The added methods are all for taking raw binary data buffers and working with Float16Array:

• DataView.prototype.getFloat16 allows you to read a Float16 off the dataview (it will be returned as its 64 bit representation):
  • newView.getFloat16(0, true);
• DataView.prototype.setFloat16 allows you to write a Float16 to the dataview:
  • view.setFloat16(0, 3.14159, true);
• Math.f16round checks if a Number will suffer a loss of precision when converted to Float16.

Conclusion

JavaScript’s stewards have kept up the effort to deliver useful and relevant new language features to the specification. This set of new standardized features feels well-considered and balanced, and it invites a range of uses showcased here.

Until recently, Python threads ran without true parallelism, as threads yielded to each other for CPU-bound operations. The introduction of free-threaded or ‘no-GIL’ builds in Python 3.13 was one of the biggest architectural changes to the CPython interpreter since its creation. Python threads were finally free to run side by side, at full speed. The availability of a free-threaded build is also one of the most potentially disruptive changes to Python, throwing many assumptions about how Python programs handle threading out the window.

Fee-threaded Python was experimental until recently, but with the release of Python 3.14 beta 3, it is officially supported. The free-threaded build is still optional, so now is a good time to start experimenting with true parallelism in Python. Here are four tips to help you get started.

Ask yourself how Python threading can help

Python threading has long been unsuited for true parallelism, so until now, you might not have considered it as a possibility. Now that free-threaded Python is officially supported, you can start seriously considering it for your use cases.

Threads in any language take a divide-and-conquer approach to any task. Anything that is “embarrassingly parallel” is a good fit for threads. That said, not every problem splits evenly across threads; some problems may simply lose in another way whatever they gained from threading.

As an example, if you have a job that writes a lot of files, having each job in its own thread is less effective if each job also writes the file. This is because writing files is an inherently serial operation. A better approach would be to divide jobs across threads and use one thread for writing to disk. As each job finishes, it sends work to the disk-writing job. This way, jobs don’t block each other and aren’t themselves blocked by file writing.

Use the highest-level abstraction available for threads

There are several layers of abstraction available in Python threading:

• You can create threads directly and manage them using threading.Thread. However, you’re responsible for the lifetime of each thread, and you also have to manage waiting for threads to finish and getting results from them. This is okay for programs where other operations block until the threads finish running, but not good for more advanced tasks.
• The concurrent.futures.ThreadPoolExecutor is a higher-level abstraction. This creates a pool of threads—you can set how many—to respond to incoming requests. You can submit jobs to the pool and get results back at your leisure, so your program doesn’t block on waiting for jobs to finish.
• Both of these are abstractions over a much lower-level _thread module, which in turn is an abstraction for operating system-level thread handling. The higher the level of abstraction you use, the more likely free-threaded Python will behave as expected.

As a general rule, any threads you use in Python (as opposed to somewhere external like an extension module) should be created in Python. You can, in theory, create a thread in a CPython extension and register it with the interpreter, but there’s not much point in duplicating the work the interpreter is meant to do and already does well.

If you’re already using the ProcessPoolExecutor as an abstraction, you can swap that for a ThreadPoolExcecutor in the free-threaded build quite easily. The two have the same interfaces, so it amounts to little more than editing an import.

Make sure Cython modules are thread-safe

Easily the biggest stumbling block for free-threaded Python is ensuring CPython extensions, written in C (or something with a C-compatible interface), respect the new free-threaded design.

A key tool for authoring C extensions in Python, Cython, closely tracks changes to the CPython runtime. Recently, Cython’s maintainers added support for CPython’s free-threaded builds, but you still have to ensure your code is thread-safe. Specifically, it needs to be thread-safe when you interact with Python objects.

If you’re already confident your code is thread-safe, you can add a directive to your Cython module and test it out in free-threaded builds:

# cython: freethreading_compatible = True

This marks the module as being compatible with free-threaded builds. If you run the free-threaded build and import a module that isn’t marked this way, the interpreter will automatically re-enable the GIL for safety’s sake.

To add more thread safety to an existing Cython module, you can use a couple of tools added to Cython to make the job easier:

• Critical sections: This context manager takes some Python object and creates for it a CPython critical section, or local lock, for the duration of the context block. It can also be used as a function decorator, typically for class methods (with the lock applied to the class instance). Critical sections automatically prevent deadlocks, but at the cost of not providing guarantees that the lock will be held continuously through the critical section—it might be released and then reacquired if some other object needs it more.
• PyMutex locks: These are more robust locks, which you acquire and release explicitly. Note that if you use them in non-free-threaded builds (such as for backward compatibility), reacquiring the GIL during a PyMutex lock entails the risk of a deadlock.

Don’t share iterators or frame objects between threads

Some objects should never be shared between threads because they have internal state that isn’t thread-safe. Two common examples are iterators and frame objects.

An iterator object in Python yields a stream of objects based on some internal state. A generator, for instance, is a common way to create an iterator object.

If you create an iterator, don’t attempt to pass it between threads. You can share the objects yielded by an iterator, as long as they’re thread-safe, but don’t share the iterator itself across thread boundaries. For instance, to create an iterator that produces the letters from a string one after the other, you could do this:

data = "abcdefg"
d_iter = iter(data)
item = next(d_iter)
item2 = next(d_iter)
# ... etc.

In this example, d_iter is the iterator object. You could share data and item (or item2, etc.) between threads, but you can’t share d_iter itself between threads, as that’s likely to corrupt its internal state.

Python frame objects contain information about the state of a program at a particular point in its execution. Among other things, they’re used by Python’s debugging mechanisms to produce details about the program when an error condition arises.

Frame objects also aren’t thread-safe. If you access frame objects from within your Python program, via sys.current_frames(), you’re likely to experience problems in the free-threaded build. However, if you use inspect.currentframe() or sys._getframe(), those are safer as long as you don’t share them between threads.

Nearly 8 in 10 organizations are moving away from Oracle Java, driven by rising costs and frustration over the company’s shift to employee-based pricing, according to a research report based on the ITAM & SAM Survey 2025.

The survey, which was jointly conducted by Azul — a firm that provides open source Java alternatives, and the ITAM Forum — a non-profit membership association for IT Asset Management (ITAM) professionals, assessed responses from 500 participants who are ITAM or software asset management (SAM) professionals who use Java.

Oracle, according to the report, introduced four licensing and pricing policy changes between 2020 and 2023, specifically the employee-based pricing, forcing enterprises to start looking at alternatives.

Oracle’s pricing change: Targeted licensing to blanket fee

In January 2023, Oracle overhauled its Java licensing model by launching the Java SE Universal Subscription, shifting from traditional per-device or per-processor metrics to a per-employee pricing structure.

This new approach mandates that any organization using Oracle Java beyond its free-use allowances must license the software for every employee, regardless of how many actually use Java.

Oracle’s definition of “employee” is expansive, encompassing not only full-time and part-time staff but also contractors, temporary workers, and agents involved in internal operations.

As a result, even minimal Java usage within an enterprise — such as a few developers or isolated applications — can trigger licensing obligations for the entire workforce, increasing the risk of inflated Java licensing costs with limited deployment.

Before 2023, the Java SE licenses for desktops and servers were priced at roughly $2.50 per user and $25 per processor core per month, respectively. With the introduction of the Java SE Universal Subscription, rates now start at $15 per employee per month for enterprises with fewer than 1,000 employees, decreasing incrementally for larger companies, dropping to $12 at 1,000 employees, and as low as $5.25 for enterprises with over 40,000 staff.

Oracle did not immediate respond to a request for comment.

Oracle’s blanket fee is driving discomfort for enterprises

The blanket fee, according to the report, has significantly increased discomfort for enterprises in the form of adding new budgets for increased costs for Java licensing, investing in new Java usage monitoring systems, conducting internal audits, and facing audits from Oracle itself.

While 29% of respondents said that their enterprise faced issues around budgeting for Oracle Java licensing, 27% of respondents complained about experiencing difficulties in interpreting Oracle’s “often opaque” licensing terms.

Another issue, at least for 28% of respondents, was around ensuring compliance, especially managing Java licenses across hybrid and multi-cloud environments.

With Java embedded in countless enterprise applications, tracking usage across diverse infrastructures has proven difficult, especially without robust automation tools, the report concluded.

Further, respondents pointed out that Oracle conducting audits on Java licensing and usage has been a major challenge.

A staggering 73% of respondents reported undergoing an Oracle Java audit within the past three years. These audits, according to the respondents, are not only frequent but also disruptive, with many citing operational slowdowns, unexpected budget hits, and even stalled projects as consequences.

As a countermeasure to audits from Oracle, 76% of respondents said that their enterprises now conduct internal audits for Java compliance at least twice a year, with a quarter doing so continuously, as even a single unlicensed Java instance can trigger costly penalties.

The pressure doesn’t stop at audits. Respondents also pointed to Oracle’s assertive sales tactics as a source of frustration, with 21% specifically citing it as an issue.

The slow but steady shift toward Oracle Java alternatives

For most of the respondents, the burden of staying compliant under Oracle’s evolving rules has become too great, prompting a shift toward open-source Java alternatives that offer greater cost savings, security, reliability, transparency, and flexibility.

Nearly 51% of respondents in the survey cited security and reliability as the primary consideration when deciding to move off Oracle Java, followed by 42% citing cost reduction including audits, and 40% citing simpler compliance.

Out of the 500 respondents, 15% said that they had already completed their migration off Oracle Java, 22% said that they had started their migration journey with 25% actively planning a migration.

Another 17% said that they wanted to move off Oracle Java but have not started planning their migration yet. A separate research report from Azul based on the 2025 State of Java Survey and Report — that surveyed over 2,000 Java users globally, points out that respondents cited software quality, keeping software current, flexibility to update software, cost savings, visibility into the source code, and alignment with open standards as the primary reasons behind opting for open source alternatives to Oracle Java.

AI builders are starving for agentic integrated development environments (IDEs), which help developers code more efficiently and thus, ideally, speed up production. And nowhere has this been more apparent than in the tug-of-war over Windsurf.

In the latest development, AI coding startup Cognition has signed a definitive agreement to acquire the rival platform, giving it access to Windsurf’s product, brand, and remaining employees. This comes after Google pulled Windsurf CEO Varun Mohan, cofounder Douglas Chen, and several R&D employees into its Google DeepMind team in a $2.4 billion talent and licensing grab.

It also follows the surprise termination of the expected $3 billion purchase of Windsurf by OpenAI that had seemed all but a done deal, but didn’t materialize due to intellectual property (IP) tensions with Microsoft, a key OpenAI partner and investor. Over a period of 72 hours, OpenAI’s purchase offer expired, Google hired away Windsurf’s top leaders and team members, and Cognition swooped in to snap up the remaining assets.

What Cognition gains from Windsurf

“As far as the market implications go, we’re seeing agentic IDEs become the next competitive space,” observed Wyatt Mayham of Northwest AI Consulting.

Cognition’s flagship product is Devin, an autonomous AI software engineer that completes various development tasks. The company says it has been deployed in production-grade codebases at enterprises around the world.

With the Windsurf acquisition, Cognition will enhance its offering as it gains ownership of:

• The Windsurf IDE, with full access to the latest Anthropic Claude models;
• Windsurf’s IP, including trademark and brand;
• A user base of more than 350 enterprise customers and “hundreds of thousands” of daily active users.

The combined platforms will allow engineering teams to plan a task in Windsurf using Devin’s deep codebase understanding, and to delegate work to teams of AI agents so that they can tackle more difficult tasks in Windsurf via features such as Tab (code completion) and Cascade (multi-step code edits). “Then it seamlessly gets stitched back together all within the same environment,” Windsurf’s CEO Jeff Wang wrote in a blog post. He said the Cognition-Windsurf combo will allow for a “combined agent + IDE” that can lead to “breakthrough developer experiences.”

Mayham noted that, while Devin had strong autonomous capabilities, it lacked a practical interface for daily development. With Windsurf, Cognition will now have an enterprise-ready IDE where “autonomous workflows can live,” giving developers tools to manage higher-level architecture while delegating routine work to AI.

“The reason why Windsurf was attractive was because they moved beyond autocomplete and built a true agentic IDE,” said Mayham. “Their agent, Cascade, could refactor across multiple files, understand project architecture, run tests, and handle linting errors.”

An increasingly competitive market

IDEs have gained prominence in recent months thanks to the “vibe coding” trend in which AI is used to automate tasks throughout the coding pipeline. Windsurf is considered one of the top IDE tools, along with Cursor, Replit, Lovable, Bolt, and Aider, and others.

Bigger players are getting into the game, too: This week, AWS announced Kiro, a free-to-use (for now) agentic IDE that helps developers move from concept to production. It uses a “spec-driven development” approach with an “agent hooks” feature, according to AWS.

Specs are artifacts that help developers refactor work or understand system behavior, while hooks help catch things they miss or perform boilerplate tasks in the background. Kiro also provides support for Model Context Protocol (MCP), an open-source framework that is quickly becoming the accepted standard for connecting AI tools with data sources.

Mayham underscored Kiro’s unique approach to enforcing spec-first development. When choosing platforms, “enterprises will have to choose between flexible, agent-driven models and more structured workflows,” he noted. “Either way, AI-assisted development is moving from code suggestions to full-context project collaboration.”

It’s not surprising that there’s been so much interest in Windsurf, said Rob Garmaise, VP of AI research at Info-Tech Research Group. He called it “a step up for Cognition and Google,” and said his firm is expecting to see more counter moves from Microsoft and Amazon.

However, “the bottom line is that Cursor is dominating this market right now with its agent-based IDE approach,” he said.

He said that, in an internal challenge, Info-Tech’s development team adopted and tested various coding tools, then ranked the results. Cursor came out on top by far, followed by GitHub, but “most other competitors aren’t even close,” Garmaise noted. Windsurf placed fourth in their evaluation.

That being said, Garmaise pointed out, it’s still early in the game, and everyone is still vying for position.

“Our view is that these tools (especially Cursor) are now ready for enterprise adoption,” he said. “We don’t think we’re at the point where these tools are replacing developers quite yet, but they certainly provide an important productivity boost for new and established developers alike across a wide variety of use cases.”

Google’s Firebase Studio, an AI-powered development workspace hosted in the Google Cloud, has added new AI-assisted development tools including an autonomous agent mode, foundational support for MCP (Model Context Protocol), and Gemini CLI integration.

The improvements were announced July 10. Three distinct modes now are available for interacting with Google’s Gemini AI model:

• Ask – a mode used for discussion and planning with Gemini and geared toward planning code, brainstorming, and discussing complex problems collaboratively.
• Agent – a mode in which Gemini can propose changes to an app, but the proposed changes must be approved by the developer before any files are modified.
• Agent (Auto run) – a mode in which Gemini can autonomously reason, generate entire apps, and add features to existing apps without explicit developer approval. However, developer permission is required before deleting files, running terminal commands, or using external tools.

The Agent and Agent (Auto-run) modes can leverage personalized guidance from a variety of project-level rule files to ensure Gemini adheres to specific design patterns and preferences, Google said. Gemini automatically detects and loads instructions from files like .idx/airules.md, GEMINI.md, or .cursorrules at the project root.

In addition to the Agent modes, Google is previewing foundational support for MCP in Firebase Studio. Developers can add MCP servers to a workspace to connect to external tools and data sources, “supercharging” workflows with Gemini in Firebase, Google said. For example, developers could use the Firebase MCP server to explore data in Cloud Firestore using natural language while building or debugging an application.

Recently launched Gemini CLI, now directly integrated in Firebase Studio, provides a tool for tasks beyond code, such as content generation and research. It offers usage tiers, advanced AI features, and integration with Google Search. Google said the combination of the Agent modes, MCP support, and Gemini CLI in Firebase Studio are designed to redefine AI-assisted development and integrate powerful AI capabilities directly into a developer’s workflow.

Akka, provider of a popular framework for building reactive, distributed applications on the JVM, has introduced the Akka Agentic Platform, an integrated suite of offerings for building, operating, and evaluating agentic AI systems.

Announced July 14, Akka Agentic Platform includes capabilities for orchestrating long-running systems, building agents, providing in-memory context to agents, and providing high-performance stream processing. “These integrated offerings deliver 3x the velocity, 1/3rd the compute, and any SLA for every agentic system whether autonomous, adaptive, real-time, transactional or edge,” Akka CEO Tyler Jewel said in the announcement.

In explaining the needs the platform is intended to fill, Jewel said the prospect of uncertainty in agentic AI challenges how IT systems are designed and maintained. Unlike traditional deterministic systems, agentic AI introduces emergent behaviors, non-deterministic decision-making, and context-sensitive reasoning. All of these bring new dimensions of unpredictability into enterprise environments, limiting the ability to deploy these systems for large-scale, business-critical use cases, Jewel stressed.

The Akka Agentic Platform gives IT leaders the certainty to meet operational SLAs for availability and recovery, and behavioral SLAs for safety and accuracy, Akka said. In addition, these new capabilities are comprehensive and unique in that they enable enterprise teams to create any kind of agentic system, whether autonomous, adaptive, real-time, or edge.

The components of the Akka Agentic Platform include:

• Akka Orchestration – Control long-running, multi-agent systems even across crashes, delays, or infrastructure failures with sequential, parallel, hierarchical, and human-in-the-loop workflows. Embed a registry for agent, tool, API, and resource governance.
• Akka Agents – Create goal-directed agents, MCP tools, and HTTP or gRPC APIs that reason, act, and analyze. Integrate any third-party broker, agent or system.
• Akka Memory – Durable, in-memory, and sharded data for agent context, history retention, and personalized behavior. Supports short-term and long-term memory.
• Akka Streaming – High-performance stream processing for ambient, adaptive, and real-time AI. Continuous processing, aggregation, and augmentation of live data, metrics, audio, and video.

The Akka Agentic Platform is available now. Alongside the Akka Agentic Platform release, Akka also introduced an AI-assisted developer experience, which leverages the power of LLMs to accelerate the development of Akka systems with agents that create, modify, test, and evaluate Akka services built with the Akka SDK.

JavaScript was the most-used language and MacOS the most-used desktop OS in a recent survey of nearly 9,000 developers worldwide that asked about technology usage as well as about demographics, income, and workplace.

The findings of The State of Devs 2025 report, released June 15 by Devographics, are based on a developer survey of 8,717 total respondents this past spring, although not all respondents participated in every question.

When asked which languages they code in, 83% of respondents reported using JavaScript, while 75% reported using TypeScript. Python came in fifth place, at 31%, behind third-place CSS (70%) and fourth-place HTML (69%). Java was the eighth most-used language among respondents, at 17%, trailing sixth-place PHP (25%) and seventh-place Bash (20%). MacOS proved to be the most-used desktop OS, at 57%, followed by Windows at 28% and Linux at 15%.

Asked which productivity apps they were using regularly, 56% of respondents used Jira, 30% used Notion, 21% used GitHub Projects, and 12% used Trello. Among messaging apps, Slack led the way, with 63% regularly using it, followed by WhatsApp (50%), Discord (39%), and Microsoft Teams (38%).

Other findings in The State of Devs 2025 report:

• 82% of the respondents identified as men, 15% as women, and 3% as non-binary or gender non-conforming.
• Average yearly income was highest for developers in the US, at $143,646, followed by developers in Israel, at $128,611. The average yearly income among all respondents was $91,553.
• Despite talks of an industry downturn, only 9% of respondents reported a decrease in income in the past year.
• 44% of developers reported being happy in their jobs, including 18% who reported being very happy.
• The most commonly reported factor in discrimination was age, with 12% reporting this, followed by 11% reporting gender or gender identity.
• 53% said that Android was the mobile OS they used most, while 47% said iOS.
• 64% of respondents reported having no children, while 15% reported one, 16% reported two, 4% reported three, and 1% reported four or more.

Many first-generation mobile applications were direct adaptations of their web equivalents. Poor user experiences, slow performance, and low adoption forced organizations to rethink their business objectives and implementation strategies. As development tools improved, organizations adopted a “mobile first” mindset and designed phone and tablet apps for specific user personas and job contexts.

[ Related: Agentic AI – Ongoing news and insights ]

Flash-forward to today, and we see a similar trend. As agentic AI capabilities are adopted, they will usher in new mobile AI experiences. Construction, manufacturing, healthcare, and other industries with significant field operations will benefit from mobile AI agents and the resulting operational agility. 

Are you ready for mobile AI agents?

Digital trailblazers should review their current mobile applications and sprawl of SaaS tools to determine which ones might benefit the most from AI capabilities and agentic AI experiences. Considerations include;

• The overall business value of the application supporting primary field-operation workflows.
• The number of field operators and touchpoints with back-office staff.
• The data volumes and timeliness factors in field-operation decision-making.

Mission-critical workflows performed by more people, in real-time, and with higher data volumes are indicators of where AI can provide business value. A second opportunity is to consider the graywork and operations that lack digitized workflows and tools to connect field and back-office operations.

“If you are considering adding AI to your field operations workflows, you should first make sure you can connect field teams to the office and vice versa,” says Matthew Frye, FastField account director at Quickbase. “Fixing that connection and centralizing data in one operations platform is critical if you’re introducing AI, providing a solid foundation of shared information to empower smarter decision-making onsite.”

Technology leaders should also review their architecture and assess their technical debt and readiness for integrating AI capabilities. Recent research shows that 92% of manufacturers say outdated infrastructure critically hinders their generative AI initiatives, and fewer than half have conducted a full-scale infrastructure readiness assessment.

“Legacy systems, cybersecurity vulnerabilities, and the lack of structured governance can hinder progress,” says Prasoon Saxena, co-head of products industries of NTT DATA. “Organizations can unlock genAI’s transformative potential while protecting operations and security by focusing on infrastructure readiness, upskilling, and ethical AI practices.”

How mobile AI agents will redefine the user experience

Mobile apps for the field usually consist of forms, checklists, access to information, dashboards, and reports. They can inform field operations about work that needs to be done, answer implementation questions, and provide information to planning and scheduling teams working at the office.

“Mobile UX is entering a new era—one where we don’t navigate software, we collaborate with it,” says Christian Buckner, SVP of analytics and IoT, Altair. “Forms, buttons, and static menus were built for users to adapt to machines, and AI assistants flip that by adapting to us.”

Instead of menus and structured workflows, mobile AI apps will include prompt interfaces and personalized data visualizations. AI will forecast what the end-user needs to know based on their current job, and prompt interfaces will simplify both querying for information and providing job updates.  

“As assistants become the front door to software, field apps must stop mimicking desktops and start acting like teammates,” adds Buckner. “These assistants won’t just fetch data—they’ll help people think, summarize complex technical manuals, hypothesize root causes, suggest next-best actions, and even brainstorm fixes. In the field, that means fewer calls back to headquarters, less time searching for answers, and more informed decisions made on the spot.”

Use cases for agentic AI in field operations

Forrest Zeisler, co-founder & CTO of Jobber, says, “AI agents can’t cut down a tree or fix your plumbing, but they can answer a phone, prepare a quote, follow up on outstanding invoices, and do most admin work so field workers can focus on what they do best.”

While one use case for agentic AI aims to reduce administrative work, others will help field operations shift from reactive to more proactive types of work.

“Capabilities like real-time contextual guidance, predictive task sequencing, and language processing for multilingual support now make it possible for mobile apps to offer proactive and personalized support to workers on the ground,” says Paul Wnek, CEO and founder of ExpandAP. “These genAI-based applications aren’t just reactive—they’re anticipatory for workers to see the full picture of what’s happening in real-time to make the most informed decisions they can at a time. Mobile apps must now offer dynamic workflows that adjust based on conditions and user input in real-time, delivering a higher-value CX that boosts decision-making and productivity.”

Swapnil Jain, co-founder and CEO at Observe.AI, says one of the most powerful capabilities lies in predictive assistance driven by geo-contextual data, historical records, and sensor inputs. “Imagine a utility technician approaching a remote site and using AI to develop a predictive user experience. A genAI-powered mobile agent can proactively surface known issues in the area, recommend the safest route based on weather and terrain, pull up relevant maintenance history, and guide inspection procedures before the worker asks.”

Other use cases focus on the need for speed and the impact of making the wrong decisions. These agents require comprehensive knowledge bases and testing to ensure that they lead to valid and better decision-making.

“In high-stakes industries such as healthcare or financial services, where seconds matter, genAI raises safety standards and operational speed, leading to fewer mistakes and faster decisions,” says John S. Kim, CEO and co-founder of Sendbird. “But to avoid ungrounded or inaccurate responses, it’s important to pair genAI with domain-specific data and enterprise-grade transparency.”

Advanced capabilities with AI agents, wearables, and 5G

Some field operations perform a set of common tasks at different locations and must adapt to local conditions and requirements. For field operations that perform a wider variety of work types in highly differentiated conditions, AI agentic experiences partner with field engineers to provide real-time information and guidance. 

“We’re seeing a rise in agentic AI being used for troubleshooting, whereby the agent is guiding the user to a resolution and instantly surfacing relevant information and operational recommendations for the field worker to implement,” says Francois Laborie, EVP of strategic projects at Cognite. “We’ve also seen a rise in ambient agents, working quietly in the background, performing checks and evaluations, alerting the user when appropriate. This enables heavy industries to predict equipment failures, optimize maintenance schedules, and manage risk.”

Learning and knowledge management applications go from feasible to operational differentiators when field operators have higher-functioning tablets, connect to 5G networks, and utilize AR/VR and other wearable devices.

“GenAI-powered agents will elevate the capabilities of field technicians by providing multimodal guidance through text, voice, video tutorials, and AR overlays directly on equipment,” says Artem Kroupenev, VP of strategy at Augury. “By democratizing expertise and seamlessly transferring knowledge, these agents enable every technician to operate at expert-level proficiency. Despite early adoption risks like reliability and dependency, the benefits of dramatically reduced downtime, improved safety, and lower operational costs make these agents essential for competitive field operations.”

Risks in rolling out AI agents

While genAI, virtual assistants, and AI agents generate significant excitement, IT leaders must have a pragmatic approach when transforming mobile field applications into agentic future of work experiences. Areas like time tracking, communications, and job reporting with minimal industry-specific business needs are early use cases that will appear in vendor applications.

Even when SaaS platforms announce agentic experiences, data teams should evaluate whether data volume and quality on the platform are sufficient to support the AI models.

“Without complete, accurate data, agents can produce unreliable outputs, and their out-of-the-box capabilities rarely align with the demands of complex environments that require contextual models tailored to specific workflows and operational needs,” says Ramprakash Ramamoorthy, director of AI research at ManageEngine.

Additional review is needed when there are data privacy and regulatory concerns. IT leaders should update their data and AI governance frameworks to cover field operations use cases that require sharing sensitive data with third-party LLMs and AI agents.

“Feeding sensitive data into genAI applications can lead to leaks, licensing conflicts, IP exposure, and regulatory violations,” says Viswesh Ananthakrishnan, co-founder and VP of product at Aurascape. “The stakes are high for companies that handle sensitive customer data in industries such as healthcare, where they have the most to lose, and the results could have paramount negative CX repercussions if data is mishandled. Critical infrastructure like construction and energy facilities are further examples where the room for error is slim.”

Information security and infrastructure teams should also reassess vendors and review their internal infrastructure to support agentic capabilities, especially those requiring access to more sensitive information.

“Early adoption carries data security risks and infrastructure challenges,” says Luiz Domingos, CTO and head of large enterprise R&D at Mitel. “To minimize disruption, organizations must invest in cybersecurity, scalable systems, governance frameworks, and phased rollouts.”

Industry-specific agentic AI mobile experiences require more data, testing, and investment. Nicholas Muy, CISO of Scrut Automation, says, “Vertical AI agents unlock massive efficiency but need context and structure to unlock them, otherwise, you have agents that will get in the way and slow you down.”

To gain significant value with industry-specific capabilities, experts suggest blue-sky thinking new mobile AI experiences rather than just bolting AI on existing mobile applications.

“Agentic AI in industries like manufacturing, construction, healthcare, and energy will enhance decisions, boost safety, and streamline tasks, but early adopters must be cautious because AI errors and security gaps are real risks,” says Anand Subbaraj, CEO of Zuper. “Winners will rethink workflows, combining human expertise with AI autonomy to build smarter, safer, and stronger operations.”

The best place to start is to walk in the shoes of a field engineer. Observe their work and how they use mobile applications today. Buy them lunch and come prepared with questions. Ask about how AI can provide value, then learn how to present the concepts without drumming up fears of job loss. The most promising opportunities should simplify work for field engineers while allowing them to deliver more value to customers.

In today’s rapidly changing digital landscape, artificial intelligence remains the most transformative technology on the horizon. As organizations seek to integrate AI into mission-critical operations, the question of where to run these workloads is becoming increasingly consequential. The placement of an organization’s AI isn’t just about performance but also the bottom line.

Based on the latest research and decades of hands-on observation, the message is clear: On-premises infrastructure—whether in your data center or a colocation facility—now offers the best value for building and scaling AI initiatives. This shift is driven by the rapid decline in hardware prices during the past decade while public cloud cost structures have remained largely unchanged.

The cloud cost cliff

Deloitte’s recent findings identify the “public cloud cost cliff” as one of the most pressing issues for enterprises running AI at scale. They reveal a crucial inflection point: When cloud expenses for AI workloads hit 60% to 70% of the cost of dedicated infrastructure, the numbers begin to favor private infrastructure sharply.

Initially, the promise of the cloud is compelling, offering immediate scalability, rapid provisioning, and managed services. However, as organizations transition from pilots and proofs of concept to production-grade, steady-state AI, cloud costs can escalate rapidly, sometimes far exceeding initial forecasts.

Resource-intensive AI training or inference jobs in the cloud can trigger unexpected, fluctuating bills, often leaving finance teams scrambling for answers. Moreover, AI workloads tend to be “sticky,” consuming large volumes of compute that require specialized GPUs or accelerators, which come at premium prices in the cloud. Today, those same components are much cheaper to buy directly than they were 10 years ago, essentially reversing the previous equation.

The economics of hardware costs

A decade ago, acquiring advanced hardware for AI was costly, complex, and risky. Organizations faced long procurement cycles, supply chain volatility, and the daunting challenge of maintaining bleeding-edge gear. Public cloud was the solution, offering pay-as-you-go access to the latest GPUs and accelerators, with none of the upfront costs.

Today, the situation has flipped. Hardware costs have plummeted, thanks to advances in manufacturing and fierce competition. Modern GPUs, storage, networking, and even advanced AI chips are now widely available, and their cost per unit of performance has dropped dramatically. For the price of a few months’ worth of cloud bills, enterprises can now purchase, rack, and operate high-performance AI infrastructure suited exactly to their unique workloads.

Deloitte’s research confirms what many IT leaders have long suspected: The impact of lower hardware prices is not offset by corresponding drops in public cloud pricing. For all but the most minor or transient workloads, maintaining cloud AI infrastructure cannot compete with the value and long-term financial predictability of on-premises or colocation options.

In addition to cost savings, recent research shows several operational and strategic benefits of on-prem infrastructure:

• Workload customization: Enterprises can precisely tailor hardware and update it as needed to match specific AI demands, creating tightly optimized, high-throughput environments that are not possible in generic public cloud setups.
• Edge computing and latency: Many AI applications, particularly those requiring real-time insights or operating at the edge (factories, healthcare, autonomous vehicles), cannot tolerate the latency of shuttling data to remote cloud data centers. On-premises and colocation solutions positioned closer to the physical point of action deliver those crucial milliseconds.
• Data sovereignty and security: Keeping sensitive information within your own controlled environment simplifies compliance with regulatory mandates, reduces exposure to external threats, and provides security teams with greater peace of mind.
• Operational predictability: By avoiding the phenomenon of “surprise cloud bills,” enterprises gain a clear, multiyear view of total cost of ownership (TCO).

Define value and TCO early

Failing to define TCO rigorously can mean the difference between success and avoidable mistakes with costly repercussions. AI infrastructure decisions often involve millions or even tens of millions of dollars. Too often, rushed or incomplete analysis causes enterprises to over-commit to the cloud, only to face spiraling costs and subpar performance down the road.

A comprehensive TCO analysis must include not only hardware and data center costs, but also power, cooling, administrative overhead, refresh cycles, and support costs over the infrastructure’s lifespan. It’s crucial to account for the cost of data gravity and migrations. Moving petabytes between cloud and on-prem environments can be both technically complex and financially overwhelming.

The cost of getting the equation wrong is significant. Deloitte’s analysis—and the experience of many CIOs—show that poor platform choices can lead to overspending by millions of dollars, weakening competitive advantage, and trapping enterprises in rigid operational models. When you see a platform decision as a one-time cost rather than a long-term, multifaceted investment, you risk overlooking its full impact on the business.

AI infrastructure is more than just a background element; it is the driving force of innovation and efficiency. It will influence how fast you can train models, how securely you handle proprietary data, and how cost-effectively you expand new applications. The public cloud still plays a crucial role, particularly for early-stage development and unpredictable workloads; however, the era of one-size-fits-all cloud solutions for AI is coming to an end. Thanks to falling hardware costs and growing operational maturity in private and colocated deployments, enterprises now have more control and can achieve better returns by investing in infrastructure they own and customize.

Before you make your next big AI platform decision, take a step back to look at the big picture. Define what long-term value means for your organization. Run the numbers and test the scenarios. In today’s environment, tens of millions of dollars are on the line. With the right strategy, you can ensure your AI endeavor is powerful, sustainable, predictable, and a valid driver of enterprise value.

Large language models (LLMs) have quickly evolved from novelty chatbots to sophisticated agentic AI systems that act on our behalf. Unlike traditional software, these AI agents don’t follow rigid, predefined instructions. They interpret our intent and make autonomous decisions. That elasticity lets enterprises automate everything from support tickets to code reviews, but it also multiplies risk. If an AI agent misinterprets intent or gets manipulated by malicious input, it could access or reveal data it shouldn’t.

Mitigating these risks requires rethinking how we enforce security and authorization in AI-driven applications. Today’s authorization is based on humans clicking well-defined routes, not bots improvising at runtime. We need something better, something that travels with every vector search, API call, and database query an agent makes. One emergent answer is Oso, an authorization engine already powering Duolingo, Intercom, and PagerDuty. Oso isn’t the only answer to AI’s security issues, but it’s increasingly an essential part.

Off-piste and off-script: New risks of agentic systems

Researchers recently hid instructions inside a harmless-looking email. Microsoft 365 Copilot, which auto-summarizes messages, obeyed and leaked internal data—no clicks required. The takeaway is brutal: Give an LLM broad access to data and it becomes the perfect insider threat, operating at machine speed and without human judgment.

Traditional security controls weren’t designed for scenarios like this.

We’ve historically handled security by authenticating the user and then checking what actions or data the user is allowed to access. We might use OAuth scopes or role-based access control (RBAC) to guard each API endpoint. But LLM-powered systems break this model. LLM agents still call ordinary APIs, but they decide the sequence, parameters, and data scope at run time. Because you don’t know that exact combination beforehand, traditional endpoint or scope-based controls alone can’t guarantee that every generated request is authorized. You need authorization that travels with each query and data fetch and is evaluated at the moment the agent generates the request.

Even new AI-specific frameworks haven’t solved this fully. Consider Anthropic’s Model Context Protocol (MCP), which standardizes how AI agents invoke tools. It cleanly separates the “agent” from the tools it can call. But MCP only lets you permit or deny tool usage at a broad level. If you expose a delete_record function, MCP can gate whether an agent may call delete_record at all, not whether it can delete this particular record. As Oso’s Greg Sarjeant points out, this leaves us no better off than with basic OAuth. To enforce true resource-level authorization, the logic has to live closer to the data and action in question.

The guardrails approach

Faced with these challenges, developers have turned to a variety of stopgap measures. One approach is to add guardrails on the AI’s inputs and outputs—essentially, trying to sanitize what goes in and monitor what comes out. These guardrails come in roughly three flavors:

• Prompt injection filters (Rebuff, PromptGuard). These try to detect suspicious strings and embeddings before they hit the model. They are effective against known jailbreaks, but prompt-based exploits are endlessly adaptable. A clever attacker might slip in a new form of jailbreak that the filters don’t recognize.
• Output content filters (Guardrails AI, NeMo Guardrails). These inspect what the LLM is about to output and filter or refuse disallowed content. Output guardrails are great for stopping toxic language or obvious policy violations, but they’re not a foolproof shield against data leakage. If the model was never supposed to have certain data, we’d rather it never be in the output in the first place.
• Controlled tool use and sandboxing (LangChain). This strategy limits what an AI agent is allowed to do in the first place, such as giving an agent access to only a carefully curated set of tools or APIs and then running those in sandboxed environments. While sensible, LangChain punts on data-level filtering; you must hand-roll per-user vector searches and hope you didn’t miss one.

Each of these approaches is useful but insufficient. None ensures that the data an AI is using or the actions it attempts are authorized for that specific user and context. In other words, the AI might still be operating on an honor system, which is a really bad security posture to bet enterprise data on.

This is where fine-grained authorization comes in. Instead of just slapping guards around the AI, we need to weave permission checks into the AI’s decision loop. The ideal solution would automatically enforce “who can see what” every time the AI tries to access some data or perform an operation. That’s exactly the approach Oso takes.

Bringing fine-grained permissions to LLMs

The core idea behind Oso’s methods is simple: An AI agent should be treated like any other user, subject to all the same permissions. So, for example, Oso provides a drop-in solution for secure retrieval-augmented generation (RAG) workflows, which are a common way LLMs are used in enterprise apps. In a RAG setup, when a user asks a question, the system will retrieve chunks of internal data (documents, records, etc.) to feed into the LLM as context so it can give an informed answer. Those chunks might live in a vector database as embeddings. Oso’s new integration with Python’s SQLAlchemy ORM essentially applies your permission rules to that retrieval query automatically.

In practice, that means you define your authorization policy (who can see what) once in Oso’s policy language, Polar, and Oso will ensure every vector similarity search or database lookup is filtered to only return chunks the current user is allowed to see. In other words, you write one Polar rule (“managers can view tickets in their department; creators can view their own”) and Oso rewrites the SQL or vector search so the LLM only sees authorized chunks. No exposure means no leak. This is the same least-privilege doctrine you (hopefully) use for humans, but it’s extended to agents.

Under the hood, Oso compiles policy into query fragments at the ORM layer, so enforcement remains consistent across microservices. Update the rule once and every AI workflow inherits the change. It’s a simple yet powerful approach to AI security.

Balancing innovation and security

There is so much incredible promise in AI right now but also incredible peril. Users and enterprises need to trust that the AI dream won’t become a security nightmare. As I’ve noted, we often sideline security in the rush to innovate. We can’t do that with AI. The cost of getting it wrong is colossally high.

The good news is that practical solutions are emerging. Oso’s permissions model for AI is one such solution, turning the theory of “least privilege” into actionable reality for LLM apps. By baking authorization into the DNA of AI systems, we can prevent many of the worst-case scenarios, like an AI that cheerfully serves up private customer data to a stranger.

Of course, Oso isn’t the only player. Pieces of the puzzle come from the broader ecosystem, from LangChain to guardrail libraries to LLM security testing tools. Developers should take a holistic view: Use prompt hygiene, limit the AI’s capabilities, monitor its outputs, and enforce tight authorization on data and actions. The agentic nature of LLMs means they’ll always have some unpredictability, but with layered defenses we can reduce that risk to an acceptable level.

If a vendor tells you it can enable zero CVEs (Common Vulnerabilities and Exposures), you should run, not walk, away. Not only is it impossible to get to zero CVEs, there’s really no need to even try. In fact, the very act of trying to achieve zero CVEs could actually increase vulnerability if the security big picture is ignored.

“Zero CVEs” is a term being bandied about as cybersecurity nirvana — the notion that software has no identified security vulnerabilities. Setting a goal of zero CVEs has gained traction lately, in part because of a trend toward stricter regulations like FEDramp and in part because some technology providers are saying they can achieve it.

You may be reading this and thinking, “What’s wrong with at least trying to eliminate CVEs? If it’s a known vulnerability, shouldn’t we always try to remediate?”

Yes and no, because engineering is a zero-sum game. There are always tradeoffs.

Chasing CVEs

There are always tradeoffs because, according to the CVE Numbering Authority operational rules, a CVE ID indicates that a software or hardware vendor has acknowledged a bug’s existence and confirms that the bug negatively impacts security. It can also indicate that the reporter of the flaw has a shared vulnerability report that demonstrates both the negative impact of the bug and that it violates the security policy of the affected system.

In other words, the bug is real and recognized, so, in theory, it would make sense to patch it.

However, there is a fundamental problem with the zero CVEs concept in practice. Namely, the only way to get close to zero CVEs at scale is to always upgrade to the latest upstream code. This gets you the latest security patches, but also brings with it new features, new bugs, new regressions, new incompatibilities, configuration changes, etc. In other words, we have to recognize that any code change can further introduce new vulnerabilities (or instabilities) that may be worse than the vulnerability corrected.

The issue is that not every single software flaw is a threat (or a serious threat) to security, especially given the rising tide of CVEs. For example, there were about 30,000 CVEs recorded in 2023, but nearly 40,000 in 2024.

There are many variables feeding this CVE inflation. The list includes increases in the number of programmers writing code, AI code generators helping them, the sheer amount of new code being written, an increase in the complexity of that code, and incentives for both security researchers as well as hackers. For example, students and security researchers are incentivized to find and report CVEs by financial, academic, and personal-brand-based rewards. Worse, with the AI wars coming, we can expect discovery of new CVEs to increase rapidly. An arms race is coming where AI will assist in discovery of new CVEs as well as patching them. The ultimate outcome could be absurd code churn. Some upstream projects even refuse to accept bugs found by AI, effectively creating a denial of service attack on developers.

Add to all of this the strong incentive for security scanning software vendors to show “something wrong” (e.g. CVEs) with the software they’re scanning when they’re selling their products to prospective customers. If the scanner reveals more problems, it must be better software, right? Obviously, that’s not true. It’s a perverse demonstration of value.

The entire ecosystem is driven to discover and highlight more CVEs, even when risk might be very low.

An exercise in futility

There are other issues that make CVE chasing an unproductive endeavor. CVEs sometimes lack sufficient detail or are based on incomplete information, which can lead to inaccurate scoring or misinterpretation of the risk. CVE risk also changes over time. For example, when active exploitation becomes known, other vulnerabilities may exist that make exploiting another flaw easier. On the flip side, many CVEs are impossible to exploit remotely, and sometimes software can be configured to make the CVE irrelevant.

In addition, CVEs don’t account for how impactful a flaw may be based on the type of code being exploited. Shell programs, daemons, or libraries each incur different risk to an organization, and they’re not equal. CVEs also don’t figure in the presence of compensating controls (defense in depth), the criticality of affected systems, or exploitability in a specific environment.

All of this is not to underestimate the importance of CVEs. Indeed, CVE-2021-44228 was a doozy — the dreaded Log4j bug had been lurking in the code since 2013, but wasn’t discovered until 2021. During this eight year period, susceptible versions of Log4j became ubiquitous, making the logging library a tempting target for exploitation. And, of course, many other CVEs are indicators of similarly high risk, considering all factors.

But… with all of this security infrastructure and industry inertia to discover and highlight new CVEs, not a single vendor found the Log4j vulnerability for years and years. It’s a perfect example of how the concept of zero CVEs provides a false sense of security. There are always undiscovered CVEs lurking in your environment. Getting distracted by low priority CVEs while not implementing defense in depth is a huge mistake.

Focus on the broader defense

So, yes, patching reported vulnerabilities is important, but no single security policy or technical control can protect against the diverse threats facing organizations today. Patching is just one layer in a broader defense architecture.

Rather than chasing low priority CVEs, which can’t be exploited, organizations should focus on defense in depth. Organizations should ensure that their infrastructure is set up so that undiscovered vulnerabilities that create real risk cannot be exploited — and so that, if they are exploited, the damage will be minimized or mitigated by other technical controls.

Indeed, chasing and fixing CVEs is not what “hardening” means. True hardening means implementing a set of security controls to minimize or eliminate risk. Controls like SELinux, hardened binaries (RELRO, PIE, etc.), and kernel security features can mitigate the impact of vulnerabilities, sometimes rendering exploits ineffective. For example, exploitation of a runc vulnerability (CVE-2019-5736) which could compromise entire systems was blocked by SELinux.

Best practices are key. For example, with containers specifically, you have to account for the platform and best practices for containerized deployments. Don’t run distinct services (ticket system, DNS, public web server, and wiki) in a single container. Don’t run SSHD to allow shell access. Ensure the platform is hardened to prevent shell access coming from the platform. Consider, for example, whether a vulnerability in Python really matters if your sole application is a Java-based web stack.

There’s also the fact that identity-based and social engineering attacks can bypass technical vulnerabilities entirely. Attackers commonly target account credentials, API keys, session cookies, and tokens, exploiting weak authentication or tricking insiders into granting access. And then there’s the threat of malicious insiders using legitimate access to steal data or otherwise compromise systems and the organization.

Attackers also target associated systems and infrastructure, such as network-attached storage, backup systems, managed endpoints, domain controllers, or even software at end of life. These systems can serve as entry or pivot points that enable attackers to gain entry into otherwise secure environments. Misconfigurations are another leading cause of breaches that can provide access to even the best-patched systems.

Develop a security plan

No amount of CVE chasing or patching — or even getting to zero CVEs — will prevent compromise due to these threats. In fact, software and container images can still be insecure even if your dashboard shows that there are zero CVEs. Worse, zero CVEs could provide you with a false sense of security that results in less vigilance or under-investment in more practical areas. There are always undiscovered vulnerabilities and some of them are worse than the ones you know about.

The zero CVEs promise is about chasing upstream patches as quickly as possible, not about fundamentally eliminating risk. Counting CVEs alone is naive and leads to “bike shedding.” It’s easy to count things, and then get obsessed with that process. Risk-based security, instead of checking boxes on a security policy document, is much more effective, balancing “getting stuff done” with mitigating risk.

The time and money organizations dedicate to achieving zero CVEs would be better spent in developing a security plan that is about prioritization and context. Defense in depth, robust identity and access management, secure configurations, and runtime protections are all critical components. Chasing the goal of zero CVEs may tick off some compliance check boxes, but it will not fully address the evolving and holistic threats to enterprise security.

—

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

Let’s face it. Devops hasn’t seen much innovation in recent years, particularly in infrastructure automation.

Despite radical shifts in technology, infrastructure automation has remained largely unchanged. Sure, it’s evolved — from on-prem configurations to cloud and containers — with tools like Terraform and OpenTofu. But the basic premise of declarative configuration management has been around since the 1990s.

“While the tech landscape has changed, the way we think about building automation has not,” says Adam Jacob, CEO and co-founder at System Initiative. “It’s had an incredible run, but we’ve taken that idea as far as it can go.”

Infrastructure as code (IaC) isn’t wrong, but it’s struggling to keep pace with multicloud and scaled devops collaboration. Tools like Terraform rarely offer a one-size-fits-all approach, making configs hard to version and maintain.

“The traditional Terraform or OpenTofu model is very declarative,” says Ryan Ryke, CEO of Cloud Life. “You think, ‘I’m going to build my castle!’ But on Day Two, your castle is falling apart because some developer went in and made some changes.”

At the end of the day, IaC is still just static config files sitting in GitHub repositories that either get stale, or must be regularly reviewed, tested, and updated, becoming a maintenance burden at scale. And because environments always change, mismatches between configs and actual infrastructure are a constant worry.

“Paradigm shift” is a phrase that shouldn’t be used lightly — but that’s the promise of System Initiative. “System Initiative comes closest to a single pane of glass I’ve seen,” says Neil Hanlon, founder and infrastructure lead at Rocky Linux. “Instead of cutting you when you break through, it flexes with you.”

The trouble with infrastructure as code  

As it stands today, implementing infrastructure as code typically involves a learning curve. “You have to understand all of the technology before you even think about how you can automate it,” says System Initiative’s Jacob.

Engineers typically use tools like Terraform, Pulumi, AWS CloudFormation, or Azure Resource Manager to define and manage infrastructure, versioning configurations in Git alongside application code. But unlike application code, small changes in infrastructure config can ripple across teams — breaking deployments, introducing regressions, and slowing collaboration.

“Configuration programming is worse than application programming, because, if you get it wrong, by definition it doesn’t work,” says Jacob. “You wind up with big, long-running conversations with yourself, the machine, and team members where you’re just trying to figure out how to make it all work.”

Ryke agrees that IaC often leads to toil. “What ends up happening is you spend a lot of time updating Terraform for the sake of updating Terraform,” he says. “We need some sort of tool to rule them all.”

According to Jacob, the deeper problem is that the industry hasn’t treated infrastructure automation as its own domain. Architects have AutoCAD. Game developers have Unity. But devops lacks a comparable standard.

System Initiative aims to change that, as an engine for engineers to build and maintain infrastructure as a living model. “Once you have that engine, you worry less about how to put together the low-level pieces, and more about how to interact with the engine.”

How System Initiative works

System Initiative turns traditional devops on its head. It translates what would normally be infrastructure configuration code into data, creating digital twins that model the infrastructure. Actions like restarting servers or running complex deployments are expressed as functions, then chained together in a dynamic, graphical UI. A living diagram of your infrastructure refreshes with your changes.

Digital twins allow the system to automatically infer workflows and changes of state. “We’re modeling the world as it is,” says Jacob. For example, when you connect a Docker container to a new Amazon Elastic Container Service instance, System Initiative recognizes the relationship and updates the model accordingly.

Developers can turn workflows — like deploying a container on AWS — into reusable models with just a few clicks, improving speed. The GUI-driven platform auto-generates API calls to cloud infrastructure under the hood.

Infrastructure varies widely by company, with bespoke needs for security, compliance, and deployment. An abstraction like System Initiative could embrace this flexibility while bringing uniformity to how infrastructure is modeled and operated across clouds.

The multicloud implications are especially intriguing, given the rise in adoption of multiple clouds and the scarcity of strong cross-cloud management tools. A visual model of the environment makes it easier for devops teams to collaborate based on a shared understanding, says Jacob — removing bottlenecks, speeding feedback loops, and accelerating time to value.

Examples of System Initiative in practice

Aiding community development at Rocky Linux

One System Initiative user is the Rocky Linux project, maker of a free replacement for CentOS, which shifted to CentOS Stream (upstream from Red Hat Enterprise Linux) in late 2020. They’re using System Initiative to build new infrastructure for Rocky Linux’s MirrorManager, a service every Rocky installation uses to find geographically close package mirrors.

Rocky Linux’s community engineers were previously using Terraform, Ansible, and other tools to manage infrastructure piecemeal. But this approach lacked extensibility and posed a high barrier to anyone without deep familiarity. “It made it very difficult to allow other teams to own their applications,” says founder and infrastructure lead Hanlon.

Though still mid-adoption, they’re already seeing collaboration wins. “System Initiative represents a really unique answer to problems faced by open-source organizations like ours, which have fairly decentralized leadership and organization, but where oversight is crucial,” Hanlon says.

Hanlon views System Initiative as a huge force multiplier. “Having a centralized location to manage, inspect, and mutate our infrastructure across any number of clouds or services is an incredibly powerful tool,” he says. “System Initiative will allow our security, infrastructure, and release teams to sleep a bit easier.”

Hanlon especially values how infrastructure is documented as a living diagram, which is malleable to changes and queryable for historical context. For this reason, and others, he believes System Initiative represents the future of devops.

IaC democratization at Cloud Life

Cloud Life, another System Initiative user, is a cloud consultancy supporting 20 to 30 clients with AWS migrations and IaC. With work highly tailored to each client, they’ve spent years hacking Terraform modules to meet specific project constraints.

“There was never a one-size-fits-all module,” says CEO Ryke. “You could spend a lot of time trying to get everything into a single module, but it was never exactly what we needed for the next customer.”

Terraform adoption has been messy, says Ryke — from public forks to proprietary private modules. Some clients even embed Terraform within source code, requiring hours of updates for small changes.

“Then, you need tooling, and pipelines, and now, the Terraform ecosystem is enormous,” he says. “All to replace a five-minute click if I went into the console.” He’s had enough — battling version changes, back-and-forth with clients, and high project bids for devops maintenance no one wants to pay for. “It’s infuriating as a business owner.”

“The paradigm shift is that System Initiative manages the real world, not just a declarative state — that’s the big change for me.” As a result, Cloud Life made System Initiative the default — bundling it into AWS services, with six new projects last quarter spanning greenfield and migration work.

At the end of the day, end users don’t care about infrastructure maintenance. “Customers can’t give a shit less about Terraform,” says Ryke. “They care about the application and where it runs.” Without a steep Terraform hill to die on, Cloud Life now can hand off a visual model of infrastructure to customers to maintain.

A major technology shift

Introducing a new way of working is no quick fix. “We’re fundamentally trying to transform some of the hardest problems,” says Jacob. “It’s not going to happen overnight.”

Because System Initiative is a fundamentally new model, migrations will be challenging for teams with large, prebuilt automations. As with any major technology shift, the transition will involve significant upfront work and gradual progress.

As such, Jacob recommends testing iteratively, observing workflow changes, and replacing parts over time. For now, lower-hanging fruit includes greenfield apps or large-scale deployments that never implemented IaC in the first place.

Preconceptions are another barrier. “A lot of hardcore people are very put off by it,” admits Ryke, comparing it to the original hesitancy about moving into the cloud. “It will upset the ecosystem.”

Jacob is sympathetic, acknowledging that “ClickOps” — i.e., provisioning infrastructure by clicking through GUIs — had its faults. Those paradigms failed because they sacrificed power and completeness for usability, he says. “But if you don’t sacrifice anything, they can accelerate you dramatically.”

For Cloud Life’s purposes, Ryke doesn’t see any sacrifices moving to the System Initiative model. That said, it might be overkill for more predictable, repeatable infrastructure. “When you do the exact same thing every day, the programmatic nature of IaC makes a lot of sense.”

To his point, some teams thrive with Terraform, especially those with stable infrastructure patterns. Meanwhile, other tools are also pushing to modernize IaC — like Crossplane, CDK for Terraform, and OpenTofu modules. Some platform engineering solutions are going further, abstracting infrastructure management altogether.

System Initiative still shows signs of a product in early growth, adds Ryke: some friction points here and there, but a team eager to respond to fixes. He’s hoping for better information retrieval capabilities and broader OS support over time. Jacob adds that cloud support beyond AWS (for Google Cloud Platform and Microsoft Azure) is still on the horizon.

Finally, costs and openness could be potential drawbacks. Although the code that powers System Initiative is completely open source, the product itself is priced. “There is no free distribution of System Initiative,” clarifies Jacob.

The future of devops

Software trends have shifted dramatically — languages have come and gone, release cycles have shrunk from months to hours, architectures have evolved, and AI has taken the industry by storm. Yet the code that automates software deployment and infrastructure has remained largely unchanged.

“The state of infrastructure automation right now is roughly equivalent to the way the world looked before the CRM was invented,” says Jacob.

A skeptic might ask, why not use generative AI to do IaC? Well, according to Jacob, the issue is data — or rather, the lack of it. “Most people think LLMs are magic. They’re not. It’s a technology like anything else.”

LLM-powered agents need structured, relationally rich data to act — something traditional infrastructure tools don’t typically expose. System Initiative provides the high-fidelity substrate those models need, says Jacob. Therefore, System Initiative and LLMs could be highly complementary, bringing more AI into devops over time. “If we want that magical future, this is a prerequisite.”

System Initiative proposes a major overhaul to infrastructure automation. By replacing difficult-to-maintain configuration code with a data-driven digital model, System Initiative promises to both streamline devops and eliminate IaC-related headaches. But it still has gaps, like minimal cloud support, and few proven case studies.

There’s also the risk of locking into a proprietary execution model that replaces traditional IaC, which will be a hard pill for many organizations to swallow.

Still, that might not matter. If System Initiative succeeds, the use cases grow, and the digital-twin approach delivers the results, a new day may well dawn for devops.

The latest update to Visual Studio Code, Microsoft’s mostly-open-source code editor, brings several new capabilities to GitHub Copilot Chat and puts the finishing touches on support for the Model Context Protocol (MCP). Alongside the VS Code update, Microsoft has open-sourced the GitHub Copilot Chat extension.

Released July 9, Visual Studio Code 1.102, also known as the June 2025 version, can be downloaded for Windows, Linux, and Mac from code.visualstudio.com.

In this release, support for MCP, a protocol that standardizes how applications provide context to large language models, now is generally available. VS Code 1.102 users can leverage authorization, prompts, sampling, and resources. These additions transform MCP from a set of individual tools into a comprehensive standard for AI agent integrations, Microsoft said. Developers can manage and install MCP servers with the MCP view and gallery. MCP servers now are treated as first-class resources in profiles and Settings Sync, similar to user tasks and other profile-specific configurations.

In an effort to make VS Code an open-source AI editor, the GitHub Copilot Chat extension source code now is available on GitHub under an MIT license. The open-sourcing not only allows developers to explore and contribute to the project, but also enables understanding of the implementation of chat modes, custom instructions, and AI integrations, as well as the creation of improved AI tools, Microsoft said. The effort also enables participation in the future of AI-assisted coding, according to the company.

VS Code 1.102 also brings several chat mode improvements. Developers can specify which language model should be used for a chat mode, use custom modes to tailor chat for specific tasks, automatically approve selected terminal commands, and edit and resubmit previous chat requests. Also, the editor for chat modes, prompts, and instruction files now supports completions, validation, and hovers for all supported metadata properties.

Finally, as for the editor experience, VS Code on Windows now supports using the accent color as the window frame border if enabled in Windows settings. The sparkle toggle in the Settings editor has been modified to act as a toggle between the AI and non-AI search results. And a new “Tasks: Rerun All Running Tasks” command allows developers to quickly rerun all currently running tasks. This is useful for workflows involving multiple concurrent tasks, allowing developers to restart them all at once without stopping and rerunning each individually, Microsoft said.

TypeScript 5.9, an update to Microsoft’s JavaScript superset with syntax for types, has arrived in beta, bringing support for the ECMAScript 2005’s deferred module evaluation.

Announced July 8, TypeScript 5.9 also offers capabilities such as a preview of expandable hovers, allowing developers to more easily view the details of variable types. Current users who want to update to TypeScript 5.9 can use the NPM command npm install -D typescript@beta.

With backing for ECMAScript’s deferred module evaluation, TypeScript 5.9 uses the new import defer syntax, allowing developers to import a module without immediately executing the module and its dependencies. This provides better control over when work and side effects occur, according to Microsoft. The key benefit of import defer is the module only will be evaluated on the first use. This feature is viewed as particularly useful for conditionally loading modules with expensive or platform-specific initialization. It also can improve startup performance by deferring module evaluation for app features until they are actually needed.

The preview of the expandable hovers feature, meanwhile, offers “quick info verbosity.” Developers using an editor like Visual Studio Code now will now see + and – buttons on the left of these hover tooltips. Clicking on the + button will expand out types more deeply, while clicking on the – button will return to the previous view, according to Microsoft.

Also in TypeScript 5.9, the language server supports a configurable hover length, which can be configured in VS Code via the js/ts.hover.maximumLength setting. This addresses a situation in which quick info tooltips become so long that TypeScript will truncate them to make them more readable.

Other features in TypeScript 5.9:

• TypeScript 5.9 can cache many intermediate instantiations when work has already begun on a specific type instantiation, avoiding unnecessary work and allocations.
• Support for --module node20 gives developers a setting intended to model Node.js 20. Specifying --module node20 implies --target es2023 , whereas --module nodenext implies --target esnext, Microsoft said.
• An updated, minimal tsc --init command results in a leaner tsconfig.json file, which now omits commented-out settings and their descriptions.

TypeScript 5.9’s beta arrives nearly after two months following the release of TypeScript Native Previews, which preview versions of a planned native TypeScript compiler based on the Go language. The intent is to speed up TypeScript and reduce build times and memory usage. That project will come to fruition in a planned TypeScript 7 release.

Experienced developers can take 19% longer to complete tasks when using popular AI assistants like Cursor Pro and Claude, challenging the tech industry’s prevailing narrative about AI coding tools, according to a comprehensive new study.

The research, conducted by Model Evaluation & Threat Research (METR), tracked 16 seasoned open-source developers as they completed 246 real-world coding tasks on mature repositories averaging over one million lines of code.

“We conduct a randomized controlled trial (RCT) to understand how early-2025 AI tools affect the productivity of experienced open-source developers working on their own repositories,” the study said. “Surprisingly, we find that when developers use AI tools, they take 19% longer than without — AI makes them slower.”

The perception gap runs deep

Perhaps most striking is the disconnect between perception and reality. Before starting the study, developers predicted AI tools would reduce their completion time by 24%. Even after experiencing the actual slowdown, participants estimated that AI had improved their productivity by 20%.

“When people report that AI has accelerated their work, they might be wrong,” the researchers added in their analysis of the perception gap.

This misperception extends beyond individual developers, with economics experts predicting AI would improve productivity by 39% and machine learning experts forecasting 38% gains, all dramatically overestimating the actual impact.

Sanchit Vir Gogia, chief analyst and CEO at Greyhound Research, warned that organizations risk “mistaking developer satisfaction for developer productivity,” noting that most AI tools improve the coding experience through reduced cognitive load but don’t always translate to faster output, especially for experienced professionals.

Controlled real-world testing

The study employed randomized controlled trial methodology, rare in AI productivity research. “To directly measure the real-world impact of AI tools on software development, we recruited 16 experienced developers from large open-source repositories (averaging 22k+ stars and 1M+ lines of code) that they’ve contributed to for multiple years,” the researchers explained.

Tasks were randomly assigned to either allow or prohibit AI tool usage, with developers using primarily Cursor Pro with Claude 3.5 and 3.7 Sonnet during the February-June 2025 study period. All participants recorded their screens, providing insight into actual usage patterns, with tasks averaging two hours to complete, the study paper added.

Gogia argued this represents “a vital corrective to the overly simplistic assumption that AI-assisted coding automatically boosts developer productivity,” suggesting enterprises must “elevate the rigour of their evaluation frameworks” and develop “structured test-and-learn models that go beyond vendor-led benchmarks.”

Understanding the productivity paradox

The research identified several interconnected factors contributing to the observed slowdown. Despite instructions to use AI tools only when helpful, some developers reported experimenting beyond what was productive. The study participants averaged five years of experience and 1,500 commits on their repositories, with researchers finding greater slowdowns on tasks where developers had high prior experience.

Most tellingly, developers accepted less than 44% of AI-generated code suggestions, with 75% reporting they read every line of AI output and 56% making major modifications to clean up AI-generated code. Working on large, mature codebases with intricate dependencies and coding standards proved particularly challenging for AI tools lacking deep contextual understanding.

“The 19% slowdown observed among experienced developers is not an indictment of AI as a whole, but a reflection of the real-world friction of integrating probabilistic suggestions into deterministic workflows,” Gogia explained, emphasizing that measurement should include “downstream rework, code churn, and peer review cycles—not just time-to-code.”

Broader industry evidence

The METR findings align with concerning trends identified in Google’s 2024 DevOps Research and Assessment (DORA) report, based on responses from over 39,000 professionals. While 75% of developers reported feeling more productive with AI tools, the data tells a different story: every 25% increase in AI adoption showed a 1.5% dip in delivery speed and a 7.2% drop in system stability. Additionally, 39% of respondents reported having little or no trust in AI-generated code.

These results contradict earlier optimistic studies. Research from MIT, Princeton, and the University of Pennsylvania, analyzing data from over 4,800 developers at Microsoft, Accenture, and another Fortune 100 company, found that developers using GitHub Copilot completed 26% more tasks on average. A separate controlled experiment found developers completed coding tasks 55.8% faster with GitHub Copilot. However, these studies typically used simpler, more isolated tasks compared to the complex, real-world scenarios examined in the METR research.

The findings arrive as enterprises pour billions into AI coding tools, with the METR study noting that GitHub reports 41% of new code is now AI-generated. Yet the research reveals a fundamental trust deficit that may be undermining effectiveness.

According to the DORA report, one participant described evaluating AI code as being “like the early days of StackOverflow, [when] you always thought people on StackOverflow are really experienced… And then, you just copy and paste the stuff, and things explode.”

A strategic path forward

Despite the productivity setbacks, 69% of study participants continued using Cursor after the experiment ended, suggesting developers value aspects beyond pure speed. The METR study noted that “the results don’t necessarily spell doom for AI coding tools” as several factors specific to their study setting may not apply broadly.

Gogia recommended enterprises adopt a “portfolio mindset: deploying AI copilots where they augment cognition (documentation, boilerplate, tests), while holding back in areas where expertise and codebase familiarity outweigh automation.” He advocated treating AI tools “not as a universal accelerator but as a contextual co-pilot” that requires governance and measurement.

Related reading:

• Why AI-generated code isn’t good enough (and how it will get better)
• 7 ways to improve your AI coding results
• What the AI coding assistants get right, and where they go wrong
• The tough task of making AI code production-ready
• Sizing up the AI code generators