JetBrains has released a minor update to IntelliJ IDEA 2026.2, the latest edition of its IDE for Java and Kotlin. The update fixes several bugs impacting Markdown shell scripts, undo actions, terminal sessions, Java code formatting, and more.

IntelliJ IDEA 2026.2.1 was announced August 10. The most notable updates include the following:

• Markdown shell scripts now execute in the correct order.
• Undo now works correctly after applying Optimize imports on the fly.
• Dragging a terminal tab after using the Move to Editor action no longer restarts the terminal session.
• The IDE no longer throws exceptions caused by the new Resolve Conflicts mechanism for Mercurial projects.
• Java code formatting now correctly respects the Smart tabs setting.

Updating to IntelliJ IDEA 2026.2.1 can be done from inside the IDE, using the Toolbox App, or using snaps in the case of Ubuntu users. The update also can be downloaded from the JetBrains website.

Java Development Kit (JDK) 28, a non-LTS (Long-Term Support) or “feature release” of standard Java due in March 2027, continues to take shape. Features listed for JDK 28 now include a simple JSON API, which joins a preview of value objects, switching the default mode of the Shenandoah garbage collector to generational mode, and a preview of strict field initialization in the Java Virtual Machine (JVM) previously proposed to target the release.

As a non-LTS release, JDK 28 will be backed by six months of support by Oracle.

The simple JSON API proposal defines a simple, standard API for parsing and generating JSON documents so that doing so does not require an external library. The intent is to enable many JSON processing tasks to be accomplished with little coding. A standard means would be provided in the Java platform to process JSON Data Interchange Format with minimal ceremony.

The three features previously targeted to JDK 28 include the following:

• Introduce value objects, which are immutable and lack object identity. Value objects are distinguished by the values of their fields, and can be represented by the JVM in ways that improve performance. A goal of the feature is to give developers a programming model for immutable data in which the == operator, and all other operations, distinguish objects by the values of their fields rather than their identities. Value objects is a preview language and VM feature.
• Switch the default mode of the Shenandoah Garbage Collector (GC) to the generational mode and deprecate the non-generational mode, with the intent to remove it in a future release. Goals include signaling the intent that future development will focus on generational mode, and reducing the maintenance cost of supporting two different modes. However, it is not a goal to remove non-generational mode at this time.
• Introduce strictly-initialized fields in the JVM. Such fields must be initialized before they are read, thus default values such as 0 or null are never observed. For strictly-initialized fields that are final, the same value is always observed. A goal is offering designers of JVM-based programming languages a model for field initialization, which has stronger integrity guarantees than the present model. This is a preview VM feature.

The predecessor to JDK 28, JDK 27, is due September 15. JDK 27 also is a non-LTS release that will be backed by six months of support by Oracle.

Anthropic is making Claude Code’s auto mode the default for its paid and enterprise users, allowing the coding agent to execute more actions without requiring developers to approve each one.

“Starting August 14, 2026, auto mode becomes the default permission mode for new sessions on Pro, Max, and Team plans,” the company wrote in the coding agent’s documentation, adding that the same change is planned for Claude Enterprise, API, and cloud platform users within the next month.

That essentially means developers using those plans will no longer have to manually approve every tool call or action Claude Code wants to make while executing a task.

Instead, each tool call is evaluated by an automated classifier designed to determine whether the action is safe to execute. Actions considered irreversible, destructive, or outside the agent’s environment can still be blocked, with Claude Code either attempting a safer approach or asking the developer for approval, the company wrote in a blog post.

“If it can’t make progress — three blocks in a row, or twenty across a session — Claude Code falls back to manual approvals,” it explained.

This reduction in manual intervention, Anthropic further added, is intended to make the coding agent more suitable for long-running tasks as well as cut down on “permission fatigue” that it says has been threatening to reduce its security posture.

According to its internal data, Claude Code users typically approve 97% of permission prompts, while only 3% are rejected. It also found that 49.5% of active CLI users had created a Bash allow-rule by June, while 62% had used “bypassPermissions” or selected “don’t ask again” for Bash.

In contrast, the default auto mode, in an Anthropic-controlled study involving 1,053 paid professional testers, caught 89% of deliberate dangerous commands compared to just 13.6% being detected by human reviewers.

More productivity but with tradeoffs

Analysts too see auto mode as a step toward making coding agents more autonomous, but with tradeoffs.

“Developers should see fewer permission pop-ups and spend less time watching Claude, meaning they can give it larger tasks and let it edit files, run tests, and execute routine commands with fewer interruptions. That way, developers can finish and ship more work using this mode because they aren’t constantly interrupted by approval windows,” said Pareekh Jain, principal analyst at Pareekh Consulting.

However, that same classifier in auto mode that reduces permission pop-ups could also result in more latency for routine or quick tasks, as trusted workflows also pass through it, adding an extra execution step, noted Manoj Chandra Jha, principal analyst at Nord-IQ Research.

Another tradeoff of reducing real-time approvals, according to Amit Kumar Jena, AI development manager at IT consulting firm Kanerika, is that it could make it harder for enterprises to maintain effective human oversight as agents take on longer-running tasks. “Reviewing four hours of unattended agent output is a harder skill, and most teams haven’t built it,” Jena said.

Better governance for CIOs

For CIOs, though, auto mode can strengthen governance in software development.

Rather than policing individual developer actions, CIOs can define permission boundaries centrally and have the classifier enforce them across agent sessions, said Jha.

That makes the current opt-in period for Enterprise and API users particularly important, as CIOs can establish permission policies before auto mode becomes the default, Jha added.

At the same time, however, CIOs also need to understand the limits of those policies, Jena pointed out.

“Auto mode has three levels of restrictions, with hard-deny rules blocking actions unconditionally, while soft-deny rules can be overridden by a developer’s allow rule. As a result, CIOs should use hard-deny or managed-settings rules for actions that must never be permitted,” he said.

Auto mode changes the security risk profile

Those centralized policy controls, which Anthropic claims should make Claude Code more secure, according to analysts, change the security risk profile of the coding agent rather than eliminate risk.

While the classifier and the policy controls reduce the risk of human failures or everyday risks, it also creates a single point of failure, Jain said.

That means if that single point has a blind spot or an attack manages to bypass it, the agent could still execute harmful actions without human approval or recognition, Jha echoed.

That said, Anthropic is not removing developers’ ability to control how Claude Code operates.

Users who have already set a different default may receive a one-time prompt asking whether they want to move to auto mode, while those who have pinned their existing preference will see no change. The company is also making the transition easier by absorbing the small amount of additional token usage generated by the classifier for Pro, Max, and Team users, with the change effective immediately.

Many of the recent supply-chain attacks could have been caught earlier if defenders looked closely at the telemetry GitHub already provides, researchers said.

At their Black Hat USA 2026 presentation, researchers Yossi Weizman of Microsoft and Mor Weinberger of Echo argued the case, saying, “GitHub can tell you’re being hacked. You’re just not listening.”

The duo described an EDR-style detection approach built from GitHub’s own event stream rather than relying solely on conventional endpoint or network telemetry.

After studying recent supply-chain attacks, including Shai-Hulud, Trivy, and Megalodon, the researchers found that seemingly different incidents repeatedly used the same techniques, from forged commit identities and poisoned tags to workflow abuse, OpenID Connect (OIDC) theft, and attempts to erase evidence.

They said they turned those recurring techniques into behavioral detections, combining GitHub webhooks, API data, and Git repository inspection to build a historical view of activity.

Their new open-source tool, dubbed “GitHub Threat Detector,” reportedly includes 22 production detection rules and 12 beta rules, with compound detections designed to correlate individually weaker signals into high-confidence alerts.

Everything leaves evidence on GitHub

The central observation in Weizman and Weinberger’s research is that supply-chain attacks often repeat the same patterns even when the targeted projects are unrelated.

A compromised identity, for example, may not be obvious from the commit itself because Git metadata can be forged. An attacker can set the author name, email, timestamp, parent, and other metadata to make a malicious commit appear legitimate.

But GitHub separately records the authenticated user who pushed the commit.

When the commit author does not match the authenticated pusher, defenders have something worth investigating, they explained. Added to this, their analysis revealed that attackers sometimes reuse the same forged identities across multiple victims. Searching GitHub for the same author’s email can therefore help connect seemingly unrelated incidents into a broader campaign.

“Forged identities in the repo which appear in other repos as well-is a strong indication of compromise,” they said.

The research found “forged maintainer’s identity” used across many attacks, including Trivy, tj-actions, Megalodon, TanStack, and Red Hat.

Another detection pitched on the same principle included tracking “Mass tag poisoning.” Mass tag poisoning involves force-moving numerous release tags onto a malicious commit so that workflows using a version such as @v1 execute attacker-controlled code. Researchers recommended adding tracking GitHub tag history through the GitHub API and comparing old and new commit references to catch this out.

OIDC offers another signal. Attackers can modify workflows to generate short-lived identities for cloud or package registries instead of stealing long-lived credentials. Watching for new or modified workflows that enable OIDC token issuance can help, the researchers said.

Correlating weak signals for stronger detection

GitHub Threat Detector follows an EDR-like pipeline: collect activity, enrich it with context, detect suspicious behavior, and then investigate or respond. The signals it ingests include live GitHub webhooks, API events, commits, tags, and Actions activity, while Git inspection provides additional context such as tag provenance.

Additionally, a PostgreSQL-backed activity store keeps the history needed to correlate events over time.

The tool took over 30 detection rules and tested them against 52 attack simulations, including reproduction of Trivy, TanStack, Megalodon, and Bitwarden CLI incidents. A separate “noise lab” helped researchers measure detection prevalence and recall, while tuning rules through allowlisting and severity adjustments.

The system, however, is not without drawbacks. Some of the trade-offs it carries include possibly disabled webhooks, rate-limited APIs, and Git inspection not being real-time.

The article originally appeared on CSO.

Back in 2023 and into 2024, as the hyperscalers announced massive data center expansions and plans for gigawatt-scale facilities, I was in boardrooms explaining why these timelines were unrealistic. The response was often a polite dismissal. The vendors were confident. The press was enthusiastic. And I was, well, the guy asking uncomfortable questions about power grids and infrastructure realities.

Now, in 2026, articles are confirming exactly what I and others who understand infrastructure have been saying all along. These massive data center projects are being delayed or canceled. Power shortages are creating bottlenecks across the industry. The grid simply cannot support the ambitions announced with such fanfare just a few years ago.

It wasn’t a mysterious formula to crack. It was simple math. And the math said the timeline was impossible.

Enterprises left holding the bag

If your AI road map relies on the abundant cloud capacity vendors promised, you’re likely facing tough conversations right now, and your AI growth plans are feeling pain. The promised compute doesn’t exist as advertised, and you’re scrambling to decide next steps. Looking inward is the only option at this point.

The vendors had every incentive to sell their vision with confidence and enthusiasm. When you’re a hyperscaler announcing a 10-billion-dollar data center campus, you’re in the business of capturing mindshare and customer commitment. While this strategy boosts sales, it fosters dangerous assumptions from customers. The enterprises that are struggling right now relied on vendor promises without doing their own analysis. They trusted the vendors to be right or, at least, close enough. They built their plans around the promises. When reality doesn’t match up, they are left holding the bag.

I speak frankly with my clients, and I’ll say it plainly here. You must do your own analysis. Vendors aren’t malicious, but their incentives don’t perfectly align with yours. They want your business, which means painting rosy pictures of capacity and timelines. You need someone to look out for your interests, and that person must be internal or a trusted advisor without a stake in selling you cloud services.

Two years ago, I was warning clients that the promised AI capacity was a fantasy for most organizations within the stated time frames. My advice was to plan for constraints, to build flexibility into infrastructure strategy, and to assume that the needed compute would be harder to get than the vendors suggested. Many clients nodded politely and went back to assuming the vendors would deliver. Some suggested I was too pessimistic.

The enterprises that took my advice seriously are in a much better position today. They planned for constraints. They chose hybrid strategies. They didn’t bet everything on hyperscaler promises that were never realistic. They’re not happy with the situation, but they’re not panicking either. For enterprises still scrambling, the first step is to admit that the old plan is dead. You cannot execute an infrastructure strategy built on vendor promises that never materialized. You need a new plan that accounts for real power constraints, real timeline challenges, and real competition for limited compute resources.

The grid isn’t expanding fast enough. Nearly half of all new US data center builds are being delayed or canceled. Yet AI demand continues to grow. These realities don’t care about your road map or your executive commitments.

Three realities to plan for

So, how should enterprises plan for future infrastructure growth? Let me offer three realities that need to be part of your planning process going forward.

1. First, assume constraints. Every infrastructure plan should assume you won’t get the power, space, or compute you want within the time frame you need. Build your strategies around limitations, not abundance. This isn’t pessimism; it’s realism. If the limitations hit, you’re ahead of the game. If they don’t materialize, you’ve simply over-engineered your solution and you can scale back.
2. Second, build for flexibility. The days of locking into single-vendor strategies based on promised capacity are over. You need infrastructure strategies that can adapt as reality unfolds. That means maintaining options, keeping relationships with multiple providers, and building architectures that can shift workloads as conditions change. The enterprises that will succeed aren’t the ones who picked the right hyperscaler. They’re the ones who didn’t put all their eggs in one basket.
3. Third, do the math yourself. When a vendor shares future capacity plans, analyze whether they’re realistic. Review power infrastructure constraints. Review construction timelines. Review historical patterns of delivery versus promises. Make vendors substantiate their commitments in writing with enforceable accountability clauses. Protect your organization from optimistic sales projections that don’t align with operational realities.

Hype never stops

The AI capacity crisis we’re living through was predictable. Those who predicted it were largely ignored because the message wasn’t what people wanted to hear. But that’s always the way infrastructure reality works. The grid can only expand so fast. Power capacity has real limits. Massive new demands create real bottlenecks.

The vendors will keep selling the vision. The press will keep covering the announcements. And the hype will continue to outpace reality. Your job is to be skeptical. Your job is to build infrastructure strategies that work in the world that actually exists, not the world that vendors are selling.

My warnings two years ago about the data center capacity crisis were right. I expect to continue being right. The question is whether enterprises will finally start listening before the next wave of unrealistic vendor and media promises leads to the next round of painful corrections.

As always, the choice is yours.

My current model-selection strategy is embarrassingly simple… and wrong: I choose the most capable (expensive) model because I’m worried the cheaper one might get something wrong. That makes me spend too much, of course, which is why I (like you, perhaps?) continue to struggle with one of the most fundamental challenges in AI: How can I know when a cheaper model is sufficient for a task? Or, really, which model should I use at all?

I asked a friend, Leo Zheng, who leads marketing for Fireworks AI, an AI infrastructure company that runs and improves open-weight models. Surely it was his job to know? His answer surprised me. I thought the answer would come down to models, but it doesn’t. Fireworks, he said, wants to “enable every company to own the continual learning loop within their four walls.” The idea is to abstract away model updates while companies feed the system new signals as customer behavior changes.

That’s when it clicked. I was asking how to automate model choice, but the harder problem is building a feedback loop that tells a company what worked. Model choice then becomes simply one important action the system can take, not the be-all and end-all decision a developer must get right in advance. Arguably, the more important component is integrating enterprise data into that continual learning loop that Zheng describes.

I’ve made that argument before, and I was right. Sort of. Proprietary data doesn’t automatically guarantee AI success. Neither does dumping that data into a retrieval-augmented generation (RAG) system. Your competitors can do the same. The more durable advantage comes from outcome data: traces that connect what the system saw, what it did, and whether the business result was acceptable. Those traces become valuable when a company uses them to improve the system and carry the learning to the next model.

Make the data earn its keep

Public benchmarks are useful, but they only tell you how a model performed on someone else’s test. They can’t tell a bank whether a fraud alert was correct, inform a retailer whether an AI agent resolved a return, or tell a software company whether AI-generated code survived review. Enterprises already have pieces of those answers buried in support transcripts, accepted patches, abandoned carts, etc. The trick is turning that mess into something a system can learn from.

Think about a software company. It already collects product analytics to improve its product. AI can extend that flywheel. Application signals can improve the system powering the product. How? By capturing user intent, engagement, and preferences.

This isn’t foolproof, however. A fast learning loop built on a weak proxy is simply a fast way to make the system worse. For example, suppose Toni in customer support accepts a suggested response. Was it good? Maybe. But what if Toni was rushing (as she is prone to do) and the customer reopened the ticket the next day? It’s not enough to act on inputs alone; a company needs to connect the suggestion to the eventual outcome or risk rewarding the wrong behavior.

Acceptable or ideal outcomes must be defined by the enterprise. A platform like Fireworks can optimize through learning loops, but only if desired outcomes are defined. This changes the cost calculation. After all, the cheapest model by token can be the most expensive model by outcome if people must review, retry, and repair its work. A company can be hemorrhaging money on AI failures while congratulating itself for lowering inference costs.

Open weights get useful

None of this requires open weights, of course. A company can own its evaluations, improve prompts and retrieval, and route among closed APIs and open models without changing a single parameter. For many workloads, that will be enough.

This generally won’t start with reinforcement learning, either. It starts by picking one workflow with an observable outcome and logging the request, model, cost, answer, and what happened next. Do that for a quarter and patterns should emerge. A cheaper model will be good enough for some work, while a proprietary frontier model will earn its price elsewhere. However, in a third category, every model may fail in the same repeatable way, and it’s this last category that makes the serious case for changing the weights.

A few years ago, I argued that open source succeeds when it makes developers’ lives easier, not when it wins an ideological purity contest. The same applies to open weights. The importance of open weights isn’t that they’re a cheaper facsimile of whatever OpenAI and Anthropic are shipping. Instead, they matter because they shift leverage away from the models and toward users with proprietary outcome data. They let enterprises turn what they learn into something they can shape, keep, and carry forward as models change.

Open weights turn model renters into model owners. That’s a very big deal.

For Cursor’s Composer 2, the company started with the open-weight Kimi K2.5 model, then specialized it through continued pretraining and reinforcement learning in environments built to resemble Cursor itself. The interesting thing isn’t that Cursor picked the “right” model, but rather that Cursor can use what it learns from developers to keep making that model more “right” for them. In this case, Fireworks ran the reinforcement learning inference, while Cursor supplied what only Cursor could: its product environment and definition of good. Cursor subsequently built Composer 2.5 on the same Kimi K2.5 checkpoint and says 85% of its compute went into additional training and reinforcement learning.

The base model was the starting point, not the finished product.

This is why open weights matter. They turn the model from a finished product into raw material. The foundation labs have broad knowledge, far more than any normal company could hope to collect. What they don’t know is whether your patch shipped, your fraud was stopped, your customer stayed, or Toni’s response made matters worse. You do.

RAG lets a model consult your data. A learning loop lets the system learn from it. One helps answer today’s question, but the other helps the company answer tomorrow’s question better.

Control must be convenient

Raw weights alone won’t deliver that control. Open source didn’t take over the enterprise because CIOs wanted tarballs. It won because Red Hat, and especially cloud providers, turned theoretical control into everyday convenience. Open-weight AI needs the same translation.

Enterprises want the convenience of a closed API without surrendering control over the intelligence their data creates. That’s the real Fireworks opportunity. Not faster tokens, but a shorter distance between learning something about your customers and making the product smarter because of it. Fireworks CEO Lin Qiao calls this “application-specific intelligence,” and that’s exactly right. Enterprises don’t need to outbuild OpenAI or Anthropic. Even if they wanted to, they couldn’t. Instead, they need to turn what they know about their customers and workflows into intelligence those labs can’t supply.

Fireworks isn’t alone. Together AI also spans training, evaluation, and serving, while Baseten now talks about connecting production feedback to model training. This is becoming a category, not simply a Fireworks feature. Fireworks’ particular bet is that the entire learning loop should belong to the customer.

So, back to the question I was asking Zheng: How do I pick the right model in advance? By now it’s clear: I can’t. Neither can you, and that’s fine, because it’s not really the right question.

Once the enterprise owns the test, it no longer has to trust a vendor’s benchmark or brand. New models must prove themselves against the work that matters to that company, then be promoted, specialized, or discarded accordingly. Model choice becomes a consequence of learning, not an act of faith. In effect, the models audition for the enterprise, not the other way around.

No one can predict whether OpenAI, Anthropic, Google, or the open-weight community will lead six months from now. The sensible response is to stop making that prediction central to the strategy. The enterprise’s own data should decide which model to pick. That’s the bet I find compelling in Fireworks: Make open-weight models as easy to improve as APIs are to call, so enterprises can stop treating their data as context for somebody else’s model and start using it to build intelligence they control.

MATLAB, a programming and numeric computation environment for engineers and scientists is sinking in popularity, according to the latest edition of the Tiobe index of programming language popularity.

In the Tiobe index for August 2026, published August 8, MATLAB is ranked 25th, having fallen out of the top 20 for the first time in more than 10 years. “Is this just a temporary dip, or is it the beginning of a more permanent decline? Personally, I believe MATLAB’s days are numbered,”  said Paul Jansen, CEO at Tiobe. One important reason for the decline may be MATLAB’s licensing model. “In a world where most programming languages are freely available, having to pay for a MATLAB license is becoming an increasingly significant disadvantage,” Jansen said.

Another reason for MATLAB’s decline is that the language has not evolved as much as other mainstream programming languages, according to Tiobe. “While languages such as Python, C++, Rust, and even newer languages continue to introduce modern language features and programming paradigms, MATLAB can increasingly feel like a language from another era,” Jansen said.

The Tiobe Programming Community index is an indicator of the popularity of programming languages. Ratings are based on the number of skilled engineers world-wide, courses, and third-party vendors. Popular websites including Google, Amazon, Wikipedia, Bing, and more than 20 others are used to calculate the ratings. 

The Tiobe index top 10 for August 2026:

1. Python, 18.53%
2. C, 11.10%
3. C++, 8.62%
4. Java, 8.25%
5. C#, 4.09%
6. JavaScript, 2.63%
7. Visual Basic, 2.18%
8. SQL, 1.88%
9. R, 1.56%
10. Rust, 1.45%

The Pypl Popularity of Language Index is an alternative measure of language popularity based on how often languages are searched on Google.

The Pypl index top 10 for August 2026:

1. Python, 50.00%
2. Java, 12.8%
3. C/C++, 8.57%
4. R, 4.18%
5. JavaScript, 3.52%
6. Objective-C, 3.01%
7. PHP, 2.06%
8. Rust, 1.86%
9. C#, 1.74%
10. Swift, 1.68%

Four months ago, a front-end engineer on my team looking to make upgrades to a product or feature would have filed a ticket and waited for the infrastructure group to unblock them. They might have lost a day, sometimes a week. Today, that same engineer makes changes themselves. The code is occasionally brittle, but it works, and the end result ships in a fraction of the time it used to take.

That small story is unfolding inside nearly every engineering organization right now. While some celebrate the sudden fact that one person can do the work of five, others are focused entirely on tech industry layoffs. Both perspectives skip the question I find more interesting: What happens to mastery when every engineer can suddenly do everything?

For two decades, we have described strong engineers as T-shaped. The horizontal bar represents breadth, which is a working familiarity across many areas. The vertical bar represents depth, the real command of one domain earned over years. Agent tooling has stretched that horizontal bar wider than ever before. My concern is the vertical bar, which is quietly getting shorter.

Consider what is now possible in a single quarter. With the right agent harness, one engineer can stand up a billing system, a data connector framework, regional and organizational tenancy infrastructure, or a consumption-based pricing implementation. The pull requests pass review. The tests are green. All looks good. But green tests cannot tell you if the person who shipped that work understood why the system needs redundancy in one specific place, where its failure modes are hiding, or which trade-offs the model made silently on their behalf. The pattern recognition that comes from watching systems fail over many years is suddenly weighted differently than it was even 12 months ago. Our industry has not caught up to that shift.

When the interview stops measuring judgment

The first place this surfaces is hiring, a trend that should concern anyone who has built a team. Traditional coding interviews were always an imperfect proxy for engineering judgment, but agent tooling completely obliterates them. If a candidate can produce a working solution in 20 minutes that would have taken two hours a year ago, the exercise no longer measures technical competence. It just measures how well a coder can prompt an agent.

At Thread AI, we have responded by widening what we look at when we interview job candidates. Our process moves across coding exercises, problem decomposition, system architecture, and behavioral components, with the weighting shifting by role. We allow AI assistance only in specific sections because our engineers still need to be able to operate without it. Some of our work happens in secure environments where you cannot lean on an agent to debug for you. What we’re really testing for now is judgment under ambiguity — the ability to notice when an agent’s output is confidently wrong — and the depth to predict where a system will break before it breaks.

Hiring teams that fail to make this shift will fill their rosters with false positives. They will hire people who interview like experts but struggle the first time a system behaves in a way the model did not anticipate. Ultimately, these companies will miss out on top-tier talent, and they won’t discover the misstep until it’s too late.

Confusing velocity with understanding

That brings me to a larger risk: the rise of false expertise as a category of its own. Historically, the reasoning has gone, “I built a proof of concept, therefore I am an expert.” I have watched versions of this appear in technical leadership, in investment decisions, and in policy conversations about AI. It travels well because the artifact looks real. A working demo is highly persuasive, even when the person behind it only half-understands how it functions.

The problem is bigger than one false expert shipping one bad product; an organization can absorb that. The real risk is a generation of consequential decisions being made by people who have confused velocity with understanding. You can already see the cultural scaffolding being built around this with the celebration of the “idea guy,” and the sudden fashion for invoking “taste” as a substitute for knowing how a system actually works. Those of us shaping tooling, hiring norms, and regulations have a narrow window to set better defaults before this pattern hardens into the way the industry operates.

Depth and breadth, held together

This is the path we’ve been walking at Thread AI since before the latest wave of tooling arrived.

To ground this in a specific example: I have spent 15 years building complex systems. I worked at Goldman Sachs through the financial crisis and the early Dodd-Frank infrastructure, moved critical payment systems into the cloud at The New York Times when that ground was still new, and built the system of record for model training and evaluation at Palantir across highly regulated environments in defense, health, and finance. This experience is the superpower that lets me course-correct an agent when it produces confident-but-wrong output.

I felt this sharply not long ago while scoping consumption-based pricing in a single quarter. The agents did an enormous amount of the heavy lifting, and at some point, I realized that my largest contributions to the effort were knowing where the system would fail and steering around it before we got there. I have also seen how organizations have built large teams around efforts like these in the past. Someone earlier in their career or relying purely on AI guidance would not have had that instinct to draw on. That is the part the public conversation keeps missing.

Every engineer at Thread AI, regardless of seniority, is expected to be a builder at heart. Our people own outcomes across compute, data, and the organizational and identity primitives that hold the product together, all without the traditional product-manager and project-manager scaffolding around them. Our model works only because the people in those seats have the depth to know what they do not know, and the breadth to fill the gaps with agents. They use the tooling instead of being used by it.

AI doesn’t replace deep understanding

The core issue facing organizations today is not whether AI will replace engineers. That question has been answered dozens of times this year with varying degrees of nuance, and it has stopped being interesting. The more useful question for anyone running a company is whether we are protecting the people who understand our systems deeply enough to recognize when the machines are wrong.

In our company, the answers have been to move toward explicit end-to-end ownership, and to hire for depth and breadth together rather than treating them as a trade-off. Layoffs dominate the headlines because they are an easy narrative, but they describe a symptom rather than the actual choice in front of us. The real choice is whether we let breadth quietly stand in for mastery, or whether we build organizations that keep human judgment in the loop on purpose.

In an era when software can be generated faster than it can be understood, the companies that hold onto what is human, verifiable, and deeply understood will be the ones still standing when the brittle parts give way.

—

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.

Microsoft is betting that the integration of HorizonDB, the cloud-native PostgreSQL alternative it is developing, with Azure will attract more enterprise AI and agentic workloads to its cloud services.

Enterprises may not be willing to take that bet.

It’s been nine months since Microsoft unveiled HorizonDB, but the service remains in public preview with no announced general availability date. Why put AI projects on hold waiting for HorizonDB to arrive, when AWS, Google, Databricks, Snowflake, and others already have production-ready PostgreSQL services positioned for the same AI workloads that Microsoft says it is building HorizonDB to handle?

AWS has had the longest head start. Aurora PostgreSQL became generally available in 2017 and has since evolved from a cloud-native PostgreSQL database into an AI-ready service with vector search and integrations with Amazon Bedrock. Similarly, Google’s AlloyDB, which followed in 2022, now includes AlloyDB AI with vector search, embeddings and model interaction for generative AI and agentic applications.

Databricks and Snowflake, too, have their own platform-centric services in the form of Lakebase, which became generally available on AWS and Azure this year, and Snowflake Postgres, which was made generally available in February 2026.

As the latecomer, when Microsoft pitched HorizonDB at Ignite in November 2025 it talked up its new architectural approach to cloud-native PostgreSQL, built around disaggregated compute and storage and a database-as-log design. The hyperscaler also positioned native vector search and deep integration with Foundry and Fabric as key differentiators for AI-heavy workloads.

No reason to wait

Those architectural differences may not be compelling enough for CIOs to wait for HorizonDB to become generally available, though.

“Most enterprises with urgent needs will not wait. A long preview window creates uncertainty around SLAs, pricing, operational maturity, and roadmap confidence,” said David Linthicum, an independent cloud consultant.

And, said Stephanie Walter, practice lead of AI stack at Hyperframe Research, enterprises cannot build mission-critical production plans around an undefined GA date, regional footprint or support commitment.

Given the difficulty of unwinding a poor database choice, enterprises will approach unknown quantities with caution.

“Database platforms eventually become sticky control points. Once the database is connected to the rest of the application, analytics, AI, and governance stack, switching becomes a business transformation rather than just an infrastructure swap,” said Michael Ni, principal analyst at Constellation Research.

In the case of a cloud database, there’s also the unwelcome possibility of “huge egress fees” in case of change, said Bradley Shimmin, lead of the data and analytics practice at The Futurum Group.

All that uncertainty is likely to lead enterprises to restrict HorizonDB to experimental use cases for now, Shimmin added.

Performance anxiety

Analysts also questioned whether HorizonDB’s technical differences will show up in performance benchmarks.

Microsoft has said HorizonDB can deliver up to three times the throughput of open-source PostgreSQL, but makes no comparisons with rival offerings such as Aurora or AlloyDB that it will compete with, Walter said.

The bigger question, according to Igor Ikonnikov, advisory fellow at Info-Tech Research Group, is whether those performance advantages, still largely on paper, translate into a meaningful difference in production.

“A database with a better compute benchmark can still be more expensive once resilience and ecosystem costs are included,” Ikonnikov said.

The economics also point to another HorizonDB limitation, particularly for workloads that are not continuously running, said Advait Patel, senior site reliability engineer at Broadcom.

HorizonDB currently uses provisioned compute rather than a serverless, scale-to-zero model, meaning customers continue to incur compute charges while an instance is provisioned, even if its workload is intermittent or idle, Patel said.

There are developer considerations too.

HorizonDB’s PostgreSQL compatibility does not necessarily mean every existing PostgreSQL application will move cleanly as in its current form the database supports only an approved set of PostgreSQL extensions rather than arbitrary ones, Walter said.

Who should wait?

For enterprises already deeply invested in Microsoft’s Azure ecosystem, those limitations may not be enough to rule out waiting for HorizonDB, Patel said: The chance to integrate the database with AI services and the wider Microsoft stack may outweigh immediate availability, he added.

That calculus also reflects how enterprises typically make database decisions in the first place: not by comparing databases in isolation, but by weighing how well they fit into the broader technology stack, including the cloud platform they have standardized on, Ikonnikov said.

For Azure shops, the choice may therefore be less about moving an existing workload away from Aurora or AlloyDB and more about whether a new Azure workload should start on Azure Database for PostgreSQL today or wait for HorizonDB when it becomes available, he said.

That may be an open question for some enterprises, said Devin Pratt, research director at IDC. “Plenty of organizations are still mid-decision, not locked in,” he said.

Microsoft finally offers a timeframe

Microsoft still won’t say exactly when HorizonDB will launch, with Shireesh Thota, corporate vice president for Azure Databases at Microsoft, saying only, “General availability for Azure HorizonDB is currently targeted for the second half of 2026.”

That narrows it down to a period of a little over four months, including Microsoft’s FabCon and Ignite conferences — an eternity in AI.

Python 3.15 is one of the most feature-packed Python releases in many a moon, and the first release candidate has just arrived. Here’s a rundown of the biggest, boldest, and most important innovations, changes, and fixes.

Lazy imports

A long-asked for feature, lazy imports allow imports to be processed only when they’re actually used by the program. For slow-importing modules that impose a large cost on a program’s startup time, you can defer that cost to when the code of that module will actually be executed.

You can use lazy imports explicitly using the new lazy import syntax, but you can also force code with conventional imports to behave lazily, either programmatically or by using an environment variable. This makes it easy to make existing code take advantage of this feature without tons of rewriting. Best of all, there’s no drawback to making imports lazy: they otherwise behave exactly as intended.

The frozendict built-in type

Only rarely does Python add a new data type, but this is a long-debated and long-desired addition: the frozen dictionary. The frozendict behaves like a regular dictionary, except that it’s immutable (you can’t add, remove, or change elements) and it’s hashable (so you can use it as a key in another dictionary, for instance).

The sentinel() built-in type

Another new addition to the language is intended to replace a common and problematic Python pattern: creating a unique sentinel object (as an alternative to None where None could be a valid value, for example) by using object(). The new syntax ,sentinel("NAME"), creates unique objects that compare only to themselves via the is operator. These objects can be type-checked properly, and they have an informative representation instead of just a random object descriptor.

Tachyon, a statistical sampling profiler

The long-standing cProfile module profiles Python code deterministically—that is, it tracks and records every single call. That makes it precise, but it also means a cProfile-tracked program runs far slower than normal. A new profiling module in Python 3.15, profiling.sampling, uses statistical sampling methods to garner useful information about performance at a fraction of the impact on the program’s speed. The existing cProfile profiler is still available—it’s not going away—but has a new alternate name, profiling.tracing.

An upgraded JIT

CPython’s built-in just-in-time (JIT) compiler debuted in Python 3.13. Its long-term goals are to make Python programs run faster without any changes to code, in something of the same way the alternate Python runtime PyPy can speed things up. And it comes without the cost of changing to a totally different interpreter with some of its own limitations.

The first couple of revisions of the JIT didn’t promise, or deliver, a great deal of additional speed, as they were more about laying a foundation for future improvements. With Python 3.15, though, the JIT is now showing an 8% to 13% geometric mean performance improvement over standard CPython, depending on the platform and workload. The biggest changes include a new tracing front end (to enable more speedups on more kinds of code), the use of register allocation for faster and more memory-efficient work, better machine code generated by the JIT, and additional optimizations such as eliminating reference counts for some classes of objects.

It’s worth experimenting with enabling the JIT for workloads to see if there’s any measurable difference. But note that further development on the JIT is now subject to some firmly laid-out guidelines regarding the performance improvement it needs to provide before it can be considered a fully supported part of Python, and not just an experimental sideline.

Better error messages

Error messages in Python have been made more precise, detailed, and useful over the last couple of versions, and Python 3.15 continues that work. The highlights:

• Suggestions for missing names (“x has no attribute ‘y‘. Did you mean ‘xyz‘?”) now include suggestions from the members of a given object, and not just the object itself.
• Suggestions now also cover checks for deleting attributes, not just accessing them.
• If the interpreter can’t come up with a suggestion for a method based on fuzzy name matching via Levenshtein distance, it consults a list of names commonly used in other languages for such methods. For example, if you attempt to use list.push() (a JavaScript method), the interpreter suggests .append(), the proper method for Python lists.

Type system improvements

The TypedDict class, which lets you create dictionaries with predefined keys and type-hinted keys and values, adds support for two new arguments in its definition. The closed argument lets you specify if only the keys specified can be used at runtime. The extra_items argument lets you specify additional keys at runtime, but only keys with a value of a specified type.

The TypeForm type definition lets you represent the value that results from evaluating a type expression. With this, type annotations can be used in places where the type itself is being used as a value—for instance, variations on operations like typing.cast or even isinstance, or as part of how a third-party type-checking tool works.

Unpacking in comprehensions

This is another long-requested feature. If you wanted to completely unpack or “flatten” a nested object using a comprehension, you used to need a function like itertools.chain() or you would have to write a nested comprehension with an ugly syntax:

x = [[1,2,3],[4,5],[6]]
y = [a for b in x for a in b]
>>> [1, 2, 3, 4, 5, 6] # y

Unpacking in comprehensions using the star operator lets you save yourself a step:

x = [[1,2,3],[4,5],[6]]
y = [*a for a in x]
>>> [1, 2, 3, 4, 5, 6] # y

Unpacking with ** also works, for instance as a way to flatten and combine dictionaries:

dicts = [{'a': 1}, {'b': 2}, {'a': 3}]
y = {**d for d in dicts}
>>> {'a': 3, 'b': 2}

Finally, this kind of unpacking can also be used to form generator expressions:

(*x for x in ["ab","cd","ef"])

The expression above creates a generator that yields:

['a', 'b', 'c', 'd', 'e', 'f']

Reverting the incremental garbage collector

Finally, Python 3.15 takes an important U-turn. Python 3.14 featured a major change to its garbage collection system—an incremental garbage collector intended to reduce the amount of program-stopping time needed to collect garbage. Unfortunately, many users reported the new garbage collector increases process memory usage, sometimes dramatically. Python 3.15 will revert back to the older generational garbage collector used in Python 3.13 and before. The incremental collector may return in a future version, but not without additional work done on it to keep this problem from resurfacing.

Other changes

• A new math module, math.integer, gives you functions for integer-specific math such as greatest common divisor or integer square root.
• The Stable ABI was created to make it easier to write CPython extensions that didn’t have to be recompiled to be compatible with multiple point revisions of Python. With Python 3.15, developers writing extensions that use the free-threaded (aka “no-GIL”) build of Python can now use the Stable ABI. This will require some rewriting of extensions that use the Stable ABI; it isn’t something you can accomplish simply by recompiling code with different headers.
• CPython builds now have frame pointers enabled by default where supported. This makes it easier and faster for the stack to unwind, so that CPython can be analyzed more reliably by system-level profiling and debugging tools.
• UTF-8 is now the default encoding for Python globally. You no longer need to specify UTF-8 as an encoding when, for instance, reading text from files. You can disable this behavior using a command-line flag or environment variable.

It used to be that the value and reputation of coding contest winners was very high. That’s no longer the case. Who cares how fast you can produce code that implements an algorithm or solves a problem? Your competition is no longer other people, at least not by themselves, but AI combined with insightful prompting and good taste.

Historically we wrote all our code ourselves and then we tested it ourselves. Yes, there was a period when we outsourced punching our cards to what was essentially a secretarial pool, but we were still writing out the code and doing all the thinking involved in the programming. Over the years we outsourced some of the testing to a QA department, allowed software to guess at what we were typing and complete it, and allowed code-checking software to run in the background as we typed.

Allowing software to help us by guessing what we mean advanced from word completion to line completion to function completion to program generation over a matter of about a decade. Currently a good model running in a good agent harness or IDE can look at your code, suggest improvements, compile and test the improved code, iterate on that, and then come up with something better, faster, more efficient, and more solid.

That shifts the burden from actually programming to reviewing and testing the code. If you don’t even review and test the code, then what you’re doing is vibe coding. Vibe coding doesn’t give you a lot of control over the end product. It is only really efficient at generating quick prototypes and creating technical debt. It’s just not enough structure.

One attempt to add more structure and to control what the model actually generates is specification-driven development (SDD). SDD works, because a spec grounds the model in a single source of truth. However, SDD often comes at the expense of taking too much effort and really being overkill for what you usually need.

Developers are still floundering, wondering how to strike a balance between vibe coding and spec-driven development. One possible approach is behavior-driven development. Another is a variation on test-driven development, sometimes called “facts first.” A fact in this context is an executable invariant tested by a machine. Finally, there’s intent-driven software development (IDSD), which is a new take on the old craft of intent, context, and expectations (ICE).

Meanwhile, we have perhaps a dozen options for IDEs and another dozen options for agent harnesses and many dozens of models that do a good job of generating code. Here I’ll provide a brief tour of six of them: GitHub Copilot, Google Antigravity, JetBrains Air, Kiro, Zed, and Zenflow.

GitHub Copilot

First offered as a plug-in to Visual Studio Code in 2021, GitHub Copilot was one of the first AI plug-ins for coding assistance. Today, you can use GitHub Copilot in a slew of IDEs for code completion, generation, explanation, and debugging. In addition to VS Code, GitHub Copilot is available for Visual Studio, Vim, Neovim, and the JetBrains suite of IDEs. You can also use Copilot on the command line, both through the GitHub Copilot CLI and as an extension to the GitHub CLI. You can also use it directly on the GitHub website.

Currently there are about two dozen supported AI models in GitHub Copilot, including models from OpenAI, Anthropic, and Google. In Visual Studio Code you can add more models than the ones available by default with your Copilot subscription. For example, if you open the Manage Language Models panel in VS Code, you can select models from Foundry Local via AI Toolkit, GitHub Models via AI Toolkit, Microsoft Foundry via AI Toolkit, and, at least in my case, local models via Ollama. Local Ollama models don’t count against your Copilot plan, but they do occupy GPU or unified memory, depending on your hardware configuration.

GitHub Copilot currently has three default operating modes: Plan, Ask, and Agent. Plan mode researches and outlines multi-step plans. Ask mode chats with you without making changes. And Agent mode edits files in your workspace. You may also have custom modes, some of which are supplied by plug-ins; I have 16 of these. You can create your own custom modes if you wish.

GitHub Copilot currently has nine categories of default tools used by agents; each category may have many actual tools listed. Additional tools come from connected Model Context Protocol (MCP) servers and installed plug-ins. My installation currently has 346 tools available, which is nuts. At one point VS Code would warn you if you had too many tools active, but that doesn’t seem to be happening anymore.

AI agents are autonomous helpers that perceive their environment, decide on a course of action, and execute it. They break large tasks into smaller steps, draw on available tools and resources, reason about approach, and adjust their plans on the fly, all while following user directives until the goal is met. While most agentic code edits complete in seconds or minutes, some can run for hours with only a few requests for permission.

In light of that, it’s not surprising that GitHub switched to usage-based billing for GitHub Copilot. Effective June 1, 2026, GitHub tracks your token consumption rather than your Premium Request Units. Code completions and next edit suggestions are exempt from token limits.

Foundry

Google Antigravity

The original Google Antigravity (from way back in November 2025) was built as an agentic development platform, essentially a version of the VS Code “Code – OSS” IDE that Google developers use internally, which was repurposed for the sorts of repositories that mere mortals work with on normal-sized products. (Google’s internal software mono-repository is so large and complex that ordinary software tools can’t work with it; Googlers use Piper, an internal tool for version control, rather than Git.)

On May 19, 2026, Antigravity became the basis for a new ecosystem. Google Antigravity 2.0 is a standalone desktop application that is an independent, agent-focused surface, evolved from Antigravity’s Agent Manager. The new Google Antigravity IDE is a separate download that looks similar to the previous Antigravity. The Google Antigravity CLI is a way to invoke, monitor, and interact with Antigravity agents from your terminal. In addition, the Google Antigravity SDK is available to build custom agents.

Google Gemini 3.6 Flash is the default model on Google Antigravity. According to Google it’s their strongest agentic and coding model yet, as well as being faster than other frontier models on Antigravity. Gemini 3.6 Flash can be selected at three effort levels: low, medium, and high. Antigravity also supports Gemini 3.5 at low, medium, and high levels; Gemini 3.1 Pro at two effort levels; Anthropic’s Claude Sonnet 4.6 and Opus 4.6 with thinking enabled; and GPT-OSS-120B at medium effort. The general guidance is to use the lowest level of effort that will successfully execute your task to minimize token use.

The “+” dropdown in the prompt box allows you to add context to the prompt. Both Antigravity 2.0 and Antigravity IDE allow you to add media, mentions, and actions. Antigravity 2.0 also allows you to enable the browser from the “+” dropdown; it simply adds the /browser slash command to the prompt.

The Antigravity browser subagent is the rough equivalent of Playwright or the Microsoft Foundry Browser Automation tool. It can click, scroll, type, read console logs, capture the DOM, take screenshots, and record video. The browser subagent also integrates natively with the Chrome DevTools MCP.

The other internal slash commands for both SKUs are /goal, which means to run until the specified task is completely finished, not asking for intermediate input from the user; /grill-me, which means to ask questions back to align on the specific details of the plan before implementing it; and /schedule, which means to run an instruction as a one-time timer in the future or on some recurring schedule (via Scheduled Tasks). Any skills provided by plug-ins or by installed Model Context Protocol servers can also be selected by typing a slash into the prompt box.

Antigravity 2.0 and Antigravity IDE support skills both at the workspace and global levels. A skill requires a SKILL.md file with YAML frontmatter at the top, and supports optional scripts, examples, and resources. The YAML description field is key to allowing an agent to recognize when the skill is relevant. Skills that come with MCPs or plug-ins take no effort to install. Creating custom skills requires you to add a named skill directory and the SKILL.md file.

Foundry

Foundry

Foundry

JetBrains Air

JetBrains Air is an agentic development environment that allows you to delegate coding tasks to AI agents. It supports four agent providers: OpenAI Codex, Anthropic Claude, Google Gemini, and JetBrains’ own Junie. You can provide your own subscriptions or API keys for OpenAI, Anthropic, and Google to Air, or rely on JetBrains’ hosting via a subscription.

When you create a new task for JetBrains Air, it can run in a local workspace, a Git worktree, or an isolated Docker container. Once you have set it up properly, you can also run a new task in the cloud, starting either from your local machine or from a browser.

You can select an agent provider and model at this time. You can switch the agent only when you create a new task; you can change models within an agent at any time. There are four levels of permissions ranging from plan first to full access. For some agents you can select an effort level. You can provide context to the chat from a number of sources, including files and folders, documentation, Git branches, and several others.

To test Air, I gave it the prompt “try to improve on the performance of this pi calculator. Do your work in a new directory called air.” I used Claude Sonnet 4.6 (1M context window) and high effort with Ask permissions, running the task locally. It did a rather good job, although I got further optimizations later on with other environments.

Foundry

Kiro

Developed by “a small, opinionated team within AWS” and described as an autonomous agent or virtual developer that learns over time while working independently, Kiro is available both as an IDE (based on Code OSS) and as a CLI tool. Kiro CLI (kiro-cli) doesn’t deal with specs at this point, although it does have a planner agent and agent steering. Kiro IDE (kiro) explicitly supports both vibe coding and spec-driven development (SDD). (See screenshot below.)

Kiro SDD generates three markdown files that together comprise the specification: requirements.md, which captures user stories and acceptance criteria in structured EARS (Easy Approach to Requirements Syntax) notation; design.md, which documents technical architecture, sequence diagrams, and implementation considerations; and tasks.md, which provides a detailed implementation plan with discrete, trackable tasks.

You can also import specs from other systems and iterate on your specs. You can even generate specs based on a vibe-coding session. Ideally, you would create a spec for each project feature.

EARS notation captures user stories and follows the pattern:

WHEN [condition/event]
THE SYSTEM SHALL [expected behavior]

This format is clear and testable. Kiro can generate property-based tests (PBT) based on your EARS-formatted requirements. These are more comprehensive than the usual unit tests.

In addition, Kiro SDD can generate three markdown files that together define the steering for the agents. Steering gives Kiro persistent knowledge about your workspace and its conventions.

A product overview file (product.md) defines the purpose, target users, key features, and business objectives of your project. A technology stack file (tech.md) specifies your chosen frameworks, libraries, development tools, and technical constraints. And a project structure file (structure.md) documents your file organization, naming conventions, import patterns, and architectural decisions.

With my free plan, Kiro IDE currently supports two Anthropic Claude models, Sonnet 4.5 and Sonnet 4.0, plus five open-weight models. It can automatically select models if you wish. The documentation also lists OpenAI’s GPT-5.6 Sol, Terra, and Luna, Claude Opus 4.5, 4.6, 4.7, 4.8, and 5.0, and Claude Haiku 4.5, all of which can be activated with a Pro ($20/month) or better plan.

Kiro IDE supports over a dozen context providers for chat requests, including generic context such as #codebase and #spec and specific context such as #code (snippets). It supports skills that follow the open Agent Skills standard, and Model Context Protocol servers that follow the MCP standard.

Foundry

Zed

Over the last few years my colleague Serdar Yegulalp and I have both reviewed Zed favorably, citing both its raw speed (it was written in Rust) and its integration with a flock of language models, mostly using a “bring your own key” paradigm. You need to subscribe if you want to use a Zed-hosted model.

The team behind Zed previously created the hackable text editor, Atom, and the software platform for building JavaScript-based desktop apps, Electron, both for GitHub. They also built Tree-sitter, an advanced syntax parsing framework that has become the standard mechanism for code analysis and syntax highlighting across modern code editors. While Atom has been discontinued, both Electron and Tree-sitter are still active.

It’s Wednesday so there’s a new release of Zed out; the current version (as I write) is v1.13.2. Recent milestones include support for Anthropic’s Claude Opus 5, OpenAI’s GPT-5.6, llama.cpp as a model provider, and automatic agent context compaction. Some older major features include support for skills, collaboration, and remote development. If you’re interested in particular features, read the Zed documentation or the Zed GitHub Repository.

To test Zed’s agentic capabilities, I pointed it at the C++ π calculation program I’ve been using to test agentic development tools, then used Zed’s new code-review skill to evaluate the program. After thoroughly reviewing Zed’s proposed changes, I gave it the go-ahead to implement and test them. I used the recommended model at the time, Claude Sonnet 4.6.

Foundry

Foundry

Zenflow

Zenflow is a free platform that coordinates AI agents to build software using spec-driven development (SDD) workflows. Another term for coordination is orchestration, hence Zenflow is also described as an orchestration layer.

Zenflow was developed by the Zencoder team. Thus Zencoder plug-ins work in Zenflow, and features from Zenflow (such as guided workflows) have been added to Zencoder. The CEO of Zencoder, Andrew Filev, told me that his team of experienced engineers had been using Zenflow for their own product development for over a year when I questioned whether it is ready for production code.

The high-level description of the relationship between Zencoder and Zenflow is that Zenflow is the workflow brain and Zencoder executes the work. You may have noticed some naming confusion: Zencoder is not only the name of the company and of its AI plug-in for IDEs, but it is also the name of its in-house coding agent, which is one of four options for Zenflow (the others are Claude Code, Codex, and Gemini) and one of about nine models available to the Zencoder plug-in.

When you start a Zenflow project, you’re offered a choice of standard workflows: Quick Change, Fix Bug, Spec and Build, or Full SDD Workflow, depending on scope. The wider the scope, the more structure you need in the workflow to keep the implementation from drifting away from the requirements. You can also define your own custom workflows, perhaps to conform to your shop’s standards.

Zenflow can run multiple tasks in parallel in isolated environments. The agents coordinate within workflows without corrupting your codebase.

Zenflow also automates verification of its changes. Every workflow runs automated tests and cross-agent code review. Failed tests trigger automatic fixes. Your code ships only after passing all the verification gates.

Zenflow projects are broken down into tasks, and those are divided into subtasks and chats. Each task runs inside its own isolated Git worktree. You can view the status of all tasks in Kanban boards or stacked list views.

Foundry

Choosing an AI coding environment

Which AI-supported development environment should you choose? As we’ve seen, there are plenty of good options.

GitHub Copilot is one of the most mature AI coding plug-ins for VS Code, and it supports a wide range of AI models.

Google Antigravity 2.0 is a standalone desktop application that is an independent, agent-focused surface. Antigravity IDE is a separate download that looks and feels similar to the original Antigravity. Antigravity CLI is a way to invoke, monitor, and interact with Antigravity agents from your terminal. These tools are among the best ways to take advantage of Gemini models.

JetBrains Air is a relatively new agentic development environment that allows you to provide your own subscriptions or API keys for OpenAI, Anthropic, and Google models.

Kiro IDE supports both vibe-coding and spec-driven development flows. With my free plan, Kiro IDE currently supports two Claude models.

Zed is about the fastest IDE I have used, and it integrates with a flock of language models, mostly using a “bring your own key” paradigm. Its advanced features include collaborative coding and remote development.

Zenflow supports multiple workflows, from quick changes all the way up to full spec-driven development. You can also define custom workflows. Zenflow works with the Zencoder coding agent as well as Claude Code, Codex, and Gemini.

There is no winner: It’s really a matter of which tool fits your use case and makes you happy. If I could have everything I wanted in one tool, I would take the speed and power of Zed, the spec-driven development capabilities of Kiro and Zenflow, and the agentic capabilities of GitHub Copilot, Google Antigravity 2.0, and JetBrains Air.

For years, AI progress was measured by scale: more data, larger models, and more compute. That formula produced real breakthroughs, but autonomous mobility was one of the first industries to discover its limits.

On the road, AI does not fail quietly. A misread scene, an ambiguous gesture from a pedestrian, or a construction zone that does not match prior examples can create immediate and visible risk. That pressure forced autonomous mobility teams to confront a reality the rest of enterprise AI is now beginning to face: the hardest problem is not access to models. It is reliable ground truth.

As AI moves from pilots into production systems, organizations are discovering that performance depends not only on model capability but on the quality, consistency, and defensibility of the data used to train, evaluate, and improve those systems.

The scaling myth is breaking in production

Early autonomous vehicle development followed a familiar playbook: collect more data, train larger models, and improve performance over time. That approach worked to a point. But real-world driving data does not behave like benchmark data. Road environments are messy and unpredictable. Human behavior is inconsistent. Context changes quickly. Many situations are ambiguous even to trained human observers.

As datasets grew, teams often discovered that they were not simply collecting more signal. They were also collecting more contradictions. Different teams interpreted the same scenes differently. Edge cases accumulated, and ambiguity multiplied. Instead of producing clarity, scale sometimes introduced confusion.

The same pattern is now repeating across enterprise AI. Organizations have access to increasingly capable foundation models, but many AI initiatives still struggle when deployed into production environments. Production exposes weaknesses that benchmarks rarely capture: inconsistent data, ambiguous edge cases, shifting context, and gaps between model behavior and human expectations.

The result is a growing gap between model access and operational reliability. More data is still valuable, but only when it is curated, consistently interpreted, and tied to clear operational definitions. In many production settings, low-quality or inconsistently interpreted data introduces noise faster than models can resolve it.

Real-world AI is multimodal by nature

Autonomous mobility also exposed another reality that is now spreading across AI: real-world intelligence is multimodal. A vehicle does not understand the road through images alone. It must reconcile camera feeds, LiDAR, radar, maps, localization signals, motion history, weather conditions, and human behavior into one coherent interpretation of the scene.

The same requirement is emerging across other high-consequence AI domains. In healthcare, systems may need to connect medical imaging, clinical notes, lab results, and patient history. In agriculture, models may combine satellite imagery, drone footage, soil data, weather patterns, and field observations. In manufacturing and robotics, AI systems increasingly need to reason across video, sensor telemetry, 3D spatial data, maintenance logs, and human instructions.

This raises the standard for ground truth. The question is no longer simply whether an object is correctly labeled in an image or whether a text response is accurate. The harder question is whether the system correctly understands a situation across multiple signals, some of which may be incomplete, noisy, contradictory, or changing over time.

Multimodal AI does not just need aligned datasets. It needs aligned interpretation, and that cannot be engineered into the model after the fact.

Edge cases are not the exception

One of the most important lessons from autonomy is that edge cases are not a small part of the problem. In high-stakes AI, they are the problem.

AI systems often perform well on averages, but real-world systems fail on exceptions. In autonomy, those exceptions may include a pedestrian behaving unpredictably, a construction zone that does not match prior examples, a partially occluded object, unusual road geometry, or an interaction where human intent is unclear. These situations represent a small fraction of total driving events, but they dominate risk.

The same principle applies beyond mobility. In healthcare, it may be a rare presentation of disease. In finance, it may be an unusual transaction pattern. In manufacturing, it may be a combination of operating conditions never previously encountered. In robotics, it may be a physical interaction that looks simple in simulation but behaves differently in the real world.

Organizations often discover that the final increments of reliability require dramatically more effort than the first 90% of performance improvement. This final gap is why many teams find themselves stuck in “hill climbing” — expending enormous effort for increasingly marginal gains.

In multimodal systems, this effect compounds. Each additional sensor stream introduces new edge-case permutations, and reconciling conflicting signals requires expert judgment.

Ground truth must be defensible, not just labeled

Autonomous-vehicle programs that got this right learned that ground truth cannot be treated as static input: a label, a bounding box, or a classification. In the scenarios that mattered, the correct interpretation of a scene had to be reasoned about, reconciled across sensor streams, and defended against alternative readings.

The same standard now applies in other critical settings. A medical annotation may require reconciling imaging findings with clinical context. A financial model’s training data may need to account for regulatory intent, not just transactional patterns. A robotics system operating in an unstructured environment may need ground truth that captures not just what happened, but the chain of causation leading to that moment.

In these cases, ground truth is not simply data that has been labeled. It is data that has been structured, reviewed, and validated through expert judgment. It needs to explain not only what the correct answer is, but why that answer is correct.

This distinction matters because AI systems increasingly operate in environments where being approximately right is not enough. The more consequential the use case, the more important it becomes to create ground truth that is consistent, auditable, and operationally meaningful.

The shift from annotation to judgment

Perhaps the most significant transformation happening in AI today is the evolution of human involvement. The data labeling industry is moving away from simple, crowd-sourced annotation toward more specialized work: scenario design, failure analysis, model evaluation, red teaming, reasoning validation, and edge-case identification.

This work requires people who understand context, ambiguity, intent, and risk. In high-stakes environments, the key questions are not simply whether a system reached the correct answer. Organizations also need to understand why the system behaved the way it did, whether that behavior can be explained, and how to prevent similar failures in the future.

Trust cannot be added through marketing, interface design, or post-hoc explanation alone. It needs to be engineered upstream, embedded throughout the life cycle from data creation to training, evaluation, monitoring, and auditing.

The difference between a model that looks correct and a model that behaves reliably often comes down to whether expert judgment has been systematically incorporated into development.

Software provides scale, and expertise provides judgment. Reliable AI needs both.

What autonomous mobility teaches the rest of AI

Autonomous mobility is often treated as a specialized vertical. It should be treated as an early warning system.

It showed what happens when AI enters environments where the cost of error is high, edge cases dominate risk, multimodal evidence must be interpreted correctly, and opaque decisions are unacceptable. That is exactly where enterprise AI is now heading in healthcare, finance, critical infrastructure, robotics, agriculture, and other high-consequence domains.

The lesson from autonomy is not limited to vehicles. It is that real-world AI must handle ambiguity, edge cases, and multimodal evidence at the same time. Models can generate outputs, but defining what is acceptable remains a human and operational decision.

The next major leap in applied AI will not come from model size alone. It will come from the systems that create, validate, and continuously refine defensible ground truth.

Those systems depend on three things: high-quality data, expert human judgment, and disciplined operational processes. The organizations that recognize this early will have a significant advantage as AI moves from impressive demonstrations to dependable real-world systems.

Autonomous mobility learned this first.

—

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.

I’ve had a version of the same conversation probably 30 times in the past year. A VP of engineering or a senior SRE describes their observability stack — the dashboards they’ve built, the alerting they’ve tuned, the Datadog or Grafana setup they’ve spent months getting right. And then they describe the last major incident. How the alert fired in seconds. How the dashboard showed exactly where the degradation was. And how their team still spent two to three hours figuring out what caused it before they could fix anything.

The framing I hear most often goes something like this: “We can see everything. We just can’t explain it.”

That gap between seeing and explaining is worth digging into, because it’s quietly become one of the more expensive problems in operations.

What observability was built to answer

Observability tools are excellent at what they were designed for. They surface what is happening inside systems — latency spikes, error rates, resource exhaustion, dependency failures — and they do so at scale, in real time. That capability is foundational. Without it, you wouldn’t know something broke until a customer told you.

But observability was built around a specific question, what is happening inside the system right now? It answers that question well. A different question, why is this happening and what triggered it, sits mostly outside its reach.

Those sound similar. They are not the same question.

“What is happening” lives in the infrastructure layer: metrics, traces, logs. The observability stack captures it. “Why is it happening” often lives outside the infrastructure entirely, in a deployment that went out two days ago, in a support queue that started spiking before the alert fired, in a change record that engineering approved last sprint. That context isn’t in the telemetry because it was never meant to be.

The investigation that precedes the fix

When a customer-facing incident occurs, the information that would explain it is rarely concentrated in one place.

Engineering is looking at the infrastructure signal. They know what the system is doing, but not which customers are affected or what those customers reported before the monitoring alert fired.

Support has the cases, the complaints written in plain language by people describing symptoms they can’t name technically. Support often knows something is wrong before engineering does, but the deployment history isn’t a system they can search.

Somewhere in Jira or a CI/CD pipeline is a record of what changed and when, with a timestamp, an author, and a scope. That record doesn’t know about the support cases or the anomaly.

So somebody has to connect all of it by hand. That means reading the customer complaints, cross-referencing the deployment history, holding multiple systems in their head simultaneously until the pattern surfaces. That is what the investigation actually is; not problem-solving, but reconstruction.

It takes hours. And it runs entirely before the resolution process can begin. Mean time to resolution (MTTR), the metric most teams are tracking and trying to improve, measures what happens after the investigation ends. The investigation itself is outside the frame.

Who actually does this work

This is the part I think gets systematically under-reported.

The manual correlation work does not fall to anyone with spare capacity. It routes to whoever knows the system well enough to read across these different views simultaneously. The engineer who remembers what shipped last week and why it was unusual. The support lead who can translate a customer’s description of a problem into a technical hypothesis. The person who has been around long enough to recognize the pattern.

That person gets pulled from whatever they were doing. Not because they are available, but because the investigation requires them specifically.

In my experience this is not an edge case. It is a structural feature of how incident response works when the relevant signals are distributed across systems that do not talk to each other. The investigation always finds the person with the most context. And that person is never the most available; they are the most consequential.

The hours they spend reconstructing a timeline are hours they are not doing the other things only they can do. That cost is real and it compounds. It shows up in velocity. In recurrence. In the quiet attrition of senior people who have been in the war room one too many times. It does not show up in MTTR or any incident metric most organizations track.

Two kinds of work

There is a distinction that rarely gets made in incident response conversations: the difference between investigation work that requires human judgment and investigation work that is, at its core, data assembly.

Deciding whether to patch or roll back requires judgment. So does knowing which customers are actually affected and which alerts are noise. These are high-context calls that require judgment that takes years to develop.

Cross-referencing timestamps across Jira, Salesforce, and a deployment dashboard to determine which change shipped before which customer complaint started; that is data assembly. It is tedious and time-consuming. It is what consumes the first two to three hours of almost every serious incident.

The problem is these two types of work have always arrived bundled together. The person who can make the judgment call also has to do the assembly, because no system was built to do the assembly for them. So your most experienced engineer — the one whose judgment you actually need — spends the majority of the investigation doing work that is far below their capability. Work that is numbing, not demanding. Work that clears their day and produces, at the end of it, a starting point for the actual decision.

That’s the waste that rarely gets named. Not the hours themselves, but the quality of what those hours contain.

What changes when they’re separated

The signals that would explain why an incident happened are already sitting in your systems. The customer cases, the deployment records, the infrastructure signals. They were there before the alert fired.

The investigation cost is a correlation problem, not a data problem. The data exists. It has just never been assembled automatically.

This is where a newer category of tooling is starting to take shape, sometimes described as operational intelligence: software that sits across observability, ticketing, and deployment systems and does the cross-referencing automatically, before a human ever opens a second tab.

When that assembly work is separated from the judgment work, the picture changes. The engineer in the war room arrives with a structured view of what happened, the deployment, the cases, the timeline. Their job becomes confirming it, refining it, and deciding what to do next. That’s the work they’re actually good at, and the reason they became engineers in the first place.

The organizations that get ahead of this won’t necessarily have better engineers or better observability stacks. They’ll have recognized that the investigation itself is a workflow, not an inevitability, and that data assembly and human judgment are separable. As AI-driven correlation tools mature, that separation is where the real leverage in incident response is likely to come from.

The observability stack tells you an incident is happening. What teams need next is the context that explains why. One of those capabilities has matured significantly over the past decade. The other is where the work is now.

—

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.

The Rust team has announced that it is enabling the Polonius Alpha borrow checker on nightly releases for testing. The team expects to fully stabilize Polonius Alpha later in the year.

The announcement was made in a blog post on August 4. In the blog post, Rust team member Jack Huey said there are no known remaining issues with Polonius Alpha and performance is generally acceptable for stabilization.

Enabling the Polonius Alpha borrow checker on nightly for testing is being done to help find serious performance regressions, unsoundness in the formulation, and diagnostic issues that need to be improved, Huey said. Issues can be reported in GitHub or Zulip.

Developers can disable Polonius Alpha and use the stable NLL borrow checker by passing -Zpolonius=off to rustc , using RUSTFLAGS=-Zpolonius=off, or including the following in a project’s .cargo/config.toml configuration file:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-Zpolonius=off"]

The Polonius borrow checker has been in the works since 2018. In 2023, a new formulation of a the Polonius borrow checker was proposed that required a minimal re-architecture of the existing NLL (non-lexical lifetime) implementation and could be extended to allow more sound code to compile, according to Huey. Stabilization of that implementation has been delayed until now.

The borrow checker is a component of the Rust compiler that enforces strict rules on references, or borrowing. These include ensuring that all variables are initialized before they are used, that the same value isn’t moved twice, that a value isn’t moved while it is borrowed, that a place isn’t accessed while it is mutably borrowed (except through the reference), and that a place isn’t mutated while it is immutably borrowed, according to the Rust documentation.

Yet another AI model has escaped from a cybersecurity test lab: This time, it’s the Chinese company Moonshot’s Kimi K3 model on the run.

Frontier Security spotted that Kimi K3 had found a loophole in the UK AI Safety Institute’s test environment for AI models performing cybersecurity tasks. The news follows similar exploits by models from OpenAI, which attacked Hugging Face, Anthropic, and most recently Meta.

Frontier revealed how the fault came about. AI models are routinely tested to examine how they perform offensive and defensive cybersecurity tasks, typically in isolated test environments or sandboxes that severely limit their internet access. Frontier reported that Kimi K3 model had found a break in the sandbox it was being tested in, enabling it to reach out to the live github.com website and clone the official repository for the benchmark problem it was supposed to be solving, reading the solution directly off the disk rather than solving the problem for itself.

Frontier warned companies testing AI models to be aware of the dangers such loopholes pose and offered some guidelines.

Companies should restrict outbound DNS and HTTPS traffic from AI models to an explicit allowlist and test those controls from inside the same environment available to the model, Frontier said. They should also audit traces for any suspicious activity and not rely solely on final answers. Companies should also treat a model’s score on benchmarks as meaningful only when the model doesn’t have access to reference implementations and other shortcuts.

Frontier also advised testers to be suspicious of unexpectedly high pass rates, as these may reveal a shared environmental flaw.

Perhaps most importantly of all: They should assume agents will find the worst paths to a solution, including probing a test environment for loopholes, and won’t always follow the path that they are expected to.

As Frontier write in its blog: “Models optimize for the objective function (getting the correct flag/answer), not the human intent behind the benchmark. If a network path to the solution exists, a sufficiently capable agent will find it.”

This article first appeared on CSO.

Bending Spoons has snapped up Airtable to add to its portfolio of software companies, alongside AOL, Evernote, WeTransfer, Brightcove and Vimeo

Airtable made its name as a builder of low/no code database services, aimed particularly at non-technical staff, but is now one of many vendors facing financial difficulties in the face of the SaaS/AIpocalypse. The arrival of AI coding tools, which offer non-technical employees more flexible ways to build business applications, has hit demand for its services.

Bending Spoons bought Airtable in a deal it valued at just $1.285 billion, a far cry from the $11.7 billion Airtable was worth at its peak.

Bending Spoons has built its portfolio by buying once-successful companies like Airtable that have struggled to cope with newer, nimbler competitors or failed to adapt to emerging technologies. Bending Spoons takes these companies, cuts costs and markets them aggressively with the goal of returning them to profitability.

“Airtable is a pioneering brand reshaping how teams organize data and manage critical workflows. We’re committed to investing in Airtable for the long run, and doubling down on its core strength: bringing teams and workflows together in one flexible workspace. We plan to expand what can be done across the full spectrum of work and make Airtable even more valuable to customers at every scale,” said Luca Ferrari, Bending Spoons CEO and co-founder.

A Canadian hacker has admitted being part of a group responsible for several major cyberattacks. Connor Riley Moucka pleaded guilty to being part of a coterie of hackers that hit 165 organizations, resulting in the theft of customer records and the extortion of millions of dollars.

Industry sources have identified Moucka as one of the main players in attacks on data hosted by cloud data warehouse Snowflake. Companies affected by the hacks include the likes of AT&T, Ticketmaster and the Neiman Marcus Group.

He worked with two other hackers: John Edward Binns and Cameron John Wagenius. Binns was not in US custody as of April 2026, while Wagenius, going by the name of Kiberphant0m, was arrested in January 2025 and pleaded guilty in July that year

Moucka and other members of the group used stolen login credentials to compromise data belonging to at least 165 customers of a US-based software-as-a-service company. This unauthorized access was used to steal billions of sensitive customer records and download terabytes of information,

“Connor Moucka hacked over 150 companies and organizations, obtained extremely sensitive information, and extorted the victims for millions of dollars. Today’s guilty plea serves as a reminder to all cybercriminals, regardless of where they live, that they cannot hide behind a wall of anonymity. You will be found and brought to justice,” said assistant attorney general A. Tysen Duva of the Justice Department’s Criminal Division

The trial is the result of a coordinated worldwide action against the Snowflake group. The investigation was led by the FBI but benefited from contributions from the Royal Canadian Mounted Police, the Australian Federal Police, Spain’s Guardia Civil, the Security Service of Ukraine and the Turkish National Police.

This article first appeared on CSO.

Demis Hassabis, the driving force behind Google DeepMind, is ascending to the role of chief scientist at Alphabet, Google’s parent company, replacing Jeff Dean who is leaving to work at a start-up.

The role will enable Hassabis to “put his full attention on actively shaping the future of AGI,” or artificial general intelligence, Alphabet CEO Sundar Pichai wrote on the company’s Inside Google blog.

Hassabis’ attention will still be divided, however: He will continue to lead research at Google spin-off Isomorphic Labs, which works on drug discovery, and although he will no longer be CEO of DeepMind, he will be its chair. Koray Kavukcuoglu will take over DeepMind, reporting directly to Pichai. He is currently its CTO.

Hassabis has been a strong promoter of AGI, defined by Google as the “hypothetical intelligence of a machine that possesses the ability to understand or learn any intellectual task that a human being can.”

He has a long career in AI, having helped found DeepMind in 2010. He has been a prominent figure in the AGI field, prophesying in May that it will be a viable technology within three years. He has been keen to tackle any barriers in the way of developing the technology; just last month, he called for greater self-regulation in the market, arguing that it would help drive the technology forward.

Hassabis welcomed the chance to focus on AGI development. “We have arrived at a pivotal moment in human history. I’ve been working towards AGI my whole life, and now, I feel it is close at hand. It’s critical that we collectively get the next steps right to ensure this all goes well for humanity and we usher in an incredible new age of discovery and wonder” he wrote in the Inside Google blog post.

This article first appeared on Computerworld.

After two decades of cloud architecture consulting, I see an unchanging pattern in enterprise deployments. Organizations approach me with unexpectedly high cloud bills, operational chaos, and architectures that look good on paper but cause headaches in production. The common thread is almost always the same. Fundamental concepts that should be foundational to any cloud deployment are treated as optional or ignored altogether.

I’m not talking about exotic requirements, bleeding-edge technologies, or vendor-specific best practices. Basic engineering principles are somehow getting lost amid the excitement of cloud adoption. I wish I could say it’s rare, but after working with organizations across industries and geographies for years, I can confirm that missing these fundamentals is more common than most people realize. The results are predictable. Bills grow faster than business value, architectures require constant firefighting, and teams are stretched too thin to optimize anything.

The good news? You don’t have to start over, but you do have to go back to basics. Here are three concepts most cloud architects overlook that will make your architecture dramatically more valuable and efficient.

Identifying common ground

When deploying heterogeneous architecture, especially in multicloud environments, organizations must aggressively reduce silos. This means establishing common control planes for security, governance, and operations. You won’t get there by relying on whatever proprietary technology each cloud provider offers out of the box. Each provider wants you locked into their way of managing things. That is fine for simple deployments, but when you are running across multiple clouds and on-premises systems, proprietary control planes introduce redundancy, complexity, and cost.

You need a single control layer that spans your entire environment. Instead of managing 10 different security solutions from 10 different providers, you have one. Instead of separate identity management systems for each cloud, you need one that works everywhere. This eliminates the need to change security parameters in five different consoles, maintain five different skill sets for five different operational models, and reconcile five different governance frameworks. The common control plane ties everything together.

This might sound hard, but it’s not as bad as you think. (I will cover the specific patterns in a future article.) The real issue is that most architects have never been trained to think this way. They were taught to select the best services from each provider rather than abstract away the differences. This fundamental gap costs organizations real money every single day.

Cost observability and optimization

Most architects treat cost visibility and optimization as afterthoughts, things that can be bolted on after the architecture is in place. That backward approach shows up in the results. Without cost observability and optimization baked into your architecture from day one, you cannot understand where your money is going, where waste is accumulating, or where you should make changes to align expenses with delivered value.

The more complex and heterogeneous your environment, the more critical this becomes. You need a unified cost observability layer that spans public and private clouds and your own infrastructure. This is about building a layer that aggregates cost data from everywhere, provides a single source of truth for spending, and delivers the insights needed to actively optimize. Without this, you are flying blind, making decisions based on incomplete data and discovering problems only after the invoice arrives.

Too many organizations fail to gain control of their cloud spending because their billing data is scattered across multiple consoles, with no way to correlate usage across providers. They cannot see which teams, projects, or services are driving costs. They miss opportunities to right-size, consolidate, or eliminate waste. You cannot improve what you cannot measure. Without a common cost observability and optimization layer built into your architecture, you will never achieve the efficiency the cloud was supposed to deliver.

Consider the human element

Here is an uncomfortable truth most architects do not want to discuss: The more complex your architecture is, the broader the range of skills you will need to keep it running. Complexity requires expertise, and expertise requires hiring, training, and retention. If your architecture demands 15 different skill sets to operate, you’d better have a plan for finding and retaining the people with those skills.

I have seen beautifully designed architectures fail because the organization could not meet hiring requirements. They compromised by hiring underqualified individuals, which led to operational failures, security gaps, and mounting technical debt. The architecture itself was sound. The human infrastructure around it was not. This is a solvable problem. It starts with acknowledging that you are not designing for yourself. You are designing for the team that will inherit this system after you have moved on to your next assignment or promotion.

The solution isn’t just simplifying architecture, though that should be a goal. The key is to consider human factors in your design. What skills are required? How can you find and train people? What cultural changes are necessary for effective operation? These questions are essential; ignoring them risks failure.

The simple bottom line

I understand why most cloud architects miss these basic principles. No single course or book brings all of this together in one place. Cloud architecture has become a collection of best practices, vendor recommendations, and conference talking points, rather than a disciplined engineering discipline focused on business value.

As a result, architectures end up optimized in the wrong places, if they are optimized at all. They are expensive to run, difficult to secure, and nearly impossible to operate at scale without constant intervention. The cloud promises efficiency, yet we are not delivering it because we have lost sight of the fundamentals.

It’s time to go back to basics. Commonality, human factors, and cost observability and optimization are the three things that separate architectures that create value from those that create cost. Incorporate these concepts into your architecture and you’ll get ahead of most production systems in use today.

Microsoft has released code-testing-generator, an open-source agent for generating unit tests in any programming language, according to the company.

Released July 31, the code-testing-generator agent learns from the user’s repository, then plans, writes, and checks the tests to prove that they work. Currently the agent writes unit tests only. Integration tests, end-to-end tests, browser tests, and performance tests are outside its current scope, Microsoft said.

The agent coordinates test generation using the “research-plan-implement” (RPI) pipeline. First the agent searches the repository for the code that needs tests, detecting the language and test framework and looking for existing tests to guide its work, and finding the correct commands for building and running the tests.

Next the agent chooses the right amount of work from three paths:

• Direct: Read the relevant code, write the tests, and validate the result.
• Single pass: Research and plan once, then implement that plan.
• Iterative: Repeat the cycle to cover a large request or reach a coverage goal.

The agent then plans and writes the tests It starts with simple code and then moves to code with more dependencies, mapping each behavior to a test file. The agent then checks that the generated tests are useful. According to Microsoft, it checks for the following problems before it finishes:

• It considers small code changes that should make the tests fail.
• It looks for weak or missing assertions.
• It checks that every requested scenario has a matching test.
• It builds the full workspace and runs the full test suite.
• It confirms that the repository’s test command can find the new tests.

The code-testing-generator agent is available in the dotnet-test plugin in the dotnet/skills repository on GitHub. The plugin can be used in GitHub Copilot CLI and is also available in Visual Studio Code and VS Code Insiders through plugin support, which is a preview feature.