SimplePie: Demo

Or try one of the following: 詹姆斯.com, adult swim, Afterdawn, Ajaxian, Andy Budd, Ask a Ninja, AtomEnabled.org, BBC News, BBC Arabic, BBC China, BBC Russia, Brent Simmons, Channel Frederator, CNN, Digg, Diggnation, Flickr, Google News, Google Video, Harvard Law, Hebrew Language, InfoWorld, iTunes, Japanese Language, Korean Language, mir.aculo.us, Movie Trailers, Newspond, Nick Bradbury, OK/Cancel, OS News, Phil Ringnalda, Photoshop Videocast, reddit, Romanian Language, Russian Language, Ryan Parman, Traditional Chinese Language, Technorati, Tim Bray, TUAW, TVgasm, UNEASYsilence, Web 2.0 Show, Windows Vista Blog, XKCD, Yahoo! News, You Tube, Zeldman

Technology insight for the enterprise

GitHub Copilot SDK allows developers to build Copilot agents into apps 23 Jan 2026, 2:24 pm

GitHub has launched a technical preview of the GitHub Copilot SDK, a tool kit for embedding the “agentic core” of the GitHub Copilot CLI into applications.

Available on GitHub, the SDK was unveiled on January 22. Initially available for Node.js/TypeScript, Python, Go, and .NET, the GitHub Copilot SDK exposes the same engine behind the GitHub Copilot CLI, a production-tested agent runtime that can be invoked programmatically. There is no need to build orchestration, according GitHub. Users define agent behavior, and Copilot handles planning, tool invocation, file edits, and more, according to GitHub. A GitHub Copilot subscription is required to use the SDK.

Developers using the SDK can take advantage of GitHub Copilot CLI’s support for multiple AI models, custom tool definitions, Model Context Protocol (MCP) server integration, GitHub authentication, and real-time streaming. GitHub teams already have used the SDK for applications such YouTube chapter generators, custom GUIs for agents, speech-to-command workflows to run apps, games in which players can compete with AI, and ummarizing tools.

“Think of the Copilot SDK as an execution platform that lets you reuse the same agentic loop behind the Copilot CLI, while GitHub handles authentication, model management, MCP servers, custom agents, and chat sessions plus streaming,” said GitHub’s Mario Rodriguez, chief product officer for the GitHub product team and the author of the January 21 blog post. “That means you are in control of what gets built on top of those building blocks.”

(image/jpeg; 22.45 MB)

Go developers meh on AI coding tools – survey 23 Jan 2026, 1:12 pm

Most Go language developers are using AI-powered software development tools, but their satisfaction with these tools is middling, according to the 2025 Go Developer Survey. The survey also found that the vast majority of Go developers—91%—were satisfied with using the language.

Results of the survey, which featured responses from 5,739 Go developers in September 2025, were published January 21 in the go.dev blog.

In the survey, 55% of respondents reported being satisfied with AI-powered development tools, but this was heavily weighted towards “Somewhat satisfied” (42%) vs. “Very satisfied” (13%). Respondents were asked to tell something good they had accomplished with these tools as well as something that did not work out. A majority said that creating non-functional code was their primary problem with AI developer tools (53%), while nearly one-third (30%) lamented that even working code was of poor quality, according to the report. The most frequently cited benefits of AI coding tools, conversely, were generating unit tests, writing boilerplate code, enhanced autocompletion, refactoring, and documentation generation.

Whereas 53% of respondents said they use AI-powered development tools daily, 29% did not use these tools at all, or only used them a few times during the past month. The most commonly used AI coding assistants were ChatGPT (45%), GitHub Copilot (31%), Claude Code (25%), Claude (23%), and Gemini (20%), the report said.

As for the language itself, almost two-thirds of respondents were very satisfied using Go, with the overall satisfaction rate hitting 91%. Developers find tremendous value in using Go as a holistic platform, said the report. “Go is by far my favorite language; other languages feel far too complex and unhelpful,” one respondent said. “The fact that Go is comparatively small, simple, with fewer bells and whistles plays a massive role in making it such a good long-lasting foundation for building programs with it.”

Other findings of the 2025 Go Developer Survey:

Command-line tools (74%) and API/RPC services (73%) were the top two types of projects respondents were building with Go. Libraries or frameworks (49%) finished third.
The top three frustrations the developers reported when building with Go were “Ensuring our Go code follows best practices / Go idioms” (33%), “A feature I value from another language isn’t part of Go” (28%), and “Finding trustworthy Go modules and packages” (26%).
Most respondents develop on macOS (60%) or Linux (58%) and deploy to Linux-based systems (96%).
Visual Studio Code was the favorite code editor cited (37%), followed by GoLand/IntelliJ (28%) and Vim/NeoVim (19%).
The most common deployment environments for Go were Amazon Web Services (46%), company-owned servers (44%), and Google Cloud Platform (26%).

(image/jpeg; 1.69 MB)

Agentic AI exposes what we’re doing wrong 23 Jan 2026, 1:00 am

We’ve spent the last decade telling ourselves that cloud computing is mostly a tool problem. Pick a provider, standardize a landing zone, automate deployments, and you’re “modern.” Agentic AI makes that comforting narrative fall apart because it behaves less like a traditional application and more like a continuously operating software workforce that can plan, decide, act, and iterate.

Agentic AI has changed cloud computing, but not in the way the hype machine wants you to believe. It hasn’t magically replaced engineering, nor has it made architecture irrelevant. It has made weak architecture, fuzzy governance, and sloppy cost controls impossible to ignore. If you are already running cloud with strong disciplines, agentic AI is an accelerant. If you aren’t, it’s a stress test you will fail, publicly and expensively.

Agentic AI is an AI system that can autonomously plan and execute multistep actions toward a goal, often by using tools and services in its environment. That’s the key difference from “chat”: An agent doesn’t just recommend what to do; it can actually do it, repeatedly, at machine speed, and it will keep doing it until you stop it or constrain it properly.

In cloud terms, AI can become a key cloud actor: provisioning resources, calling APIs, moving data, modifying configurations, opening tickets, triggering workflows, and chaining services. This means the cloud now supports autonomous decision loops, which have failure modes distinct from those of web apps with fixed request/response paths.

Adapting cloud networks to agentic AI

Traditional cloud networking assumptions are already shaky: perimeter thinking, coarse segmentation, and “allow lists” that grow without limits. Agentic AI makes those patterns actively dangerous because agents don’t just talk to one back end and one database; they discover, orchestrate, and pivot across systems as part of normal operations. The network becomes a dynamic substrate for tool use rather than a static map of application tiers.

What needs to change is the level of precision and adaptability in network controls. You need networking that supports fine-grained segmentation, short-lived connectivity, and policies that can be continuously evaluated rather than set once and forgotten. You also need to treat east-west traffic visibility as a core requirement because agents will generate many internal calls that look legitimate unless you understand intent, identity, and context.

Finally, plan for bursty, unpredictable communication patterns. Agents will fan out, call many endpoints, retry aggressively, and trigger cascades across regions and services if you let them. That pushes you toward stronger service-to-service policy, more transparent egress governance, and tighter coupling between networking telemetry and runtime controls, so you can see and stop pathological behavior before it becomes an outage or a bill.

Aligning with identity-based security

Cloud security has shifted toward identity for years, and agentic AI completes the move. When the user is an autonomous agent, control relies solely on identity: what the agent is, its permitted actions, what it can impersonate, and what it can delegate. Network location and static IP-based trust weaken when actions are initiated by software that can run anywhere, scale instantly, and change execution paths.

This is where many enterprises will stumble. They’ll give an agent broad API permissions to be helpful, then act surprised when it becomes broadly dangerous. The correct posture is to treat every agent as a privileged workload until proven otherwise because agents are effectively operators with superhuman speed. You need explicit identities for agents, tight authorization boundaries, short-lived credentials, audited tool access, and strong separation between environments and duties.

Identity-based security requires us to clearly define who did what, making it difficult to overlook details. If an agent modifies infrastructure, moves data, or grants access, you need to trace the action back to a specific identity, under a given policy, with an approval or constraint chain. Governance isn’t optional; it’s the essential control framework for autonomous operations.

Cloud finops and cultural shifts

If you think cloud bills were unpredictable before, wait until you unleash systems that can decide to use more resources in pursuit of a goal. Agentic AI changes how cloud resources are leveraged by making consumption far more elastic, exploratory, and continuous. Agents will spin up ephemeral environments, run iterative experiments, call paid APIs, generate and store large artifacts, and repeat tasks until they converge—sometimes without a natural stopping point.

The old finops playbook of tagging, showback, and monthly optimization is not enough on its own. You need near-real-time cost visibility and automated guardrails that stop waste as it happens, because “later” can mean “after the budget is gone.” Put differently, the unit economics of agentic systems must be designed, measured, and controlled like any other production system, ideally more aggressively because the feedback loop is faster.

There’s also a cultural shift here that many leaders will resist. If you cannot answer, in plain language, what value you’re getting per unit of agent activity—per workflow, per resolved ticket, or per customer outcome—then you don’t have an AI strategy; you have a spending strategy. Agentic AI will punish organizations that treat the cloud as an infinite sandbox and success metrics as a slide deck.

Good architecture is crucial

The industry’s favorite myth is that architecture slows innovation. In reality, architecture prevents innovation from turning into entropy. Agentic AI accelerates entropy by generating more actions, integrations, permissions, data movement, and operational variability than human-driven systems typically do.

Planning for agentic AI systems means designing boundaries agents cannot cross, defining tool contracts they must obey, and creating “safe failure” modes that degrade gracefully rather than improvising into catastrophe. It also means thinking through data architecture with new seriousness: where context comes from, how it is governed, how it is retained, and how to prevent agents from leaking sensitive information through perfectly reasonable tool usage. You’re not just building an app; you’re building an autonomous operating model that happens to be implemented in software.

Good architecture here is pragmatic, not academic. It focuses on reference patterns, standardized environments, consistent identity and policy enforcement, deterministic workflows when possible, and explicit exception paths when autonomy is allowed. Most importantly, it recognizes an agent as a new runtime consumer of your cloud platform, requiring a design approach that accounts for this instead of adding agents to old assumptions.

Discipline and responsibility

Agentic AI has raised the operational bar for responsible cloud computing. Networking must become more policy-driven and observable to support autonomous, tool-using traffic patterns. Security must become more identity-centric because the actor is now software that can operate like a human administrator. Finops must transition into real-time governance because agents can consume resources at machine speed. Architecture must lead, not follow, because the cost of unplanned autonomy is failure at scale.

If you want the blunt takeaway, it’s this: Agentic AI makes cloud discipline non-negotiable. The organizations that treat it as an architectural and operational shift will do well, and the ones that treat it as another feature to turn on will learn quickly how expensive improvisation can be.

(image/jpeg; 1.29 MB)

Python picks up speed with a new JIT 23 Jan 2026, 1:00 am

Faster Python is now within reach, thanks to its shiny new JIT. But we also have fast dataframes thanks to Pandas, and three slick new GUI interfaces for SQLite. And then there’s Zed, the new Rust-powered contender to VS Code’s throne. It’s a busy time in the world of Python, and we’ve got all the scoops.

Simple yet foundational for CIOs

Agent Scanners’ automated agent discovery ability, although deceptively simple, could be more foundational for CIOs trying to adopt agents in production use cases.

“For CIOs and security leaders, the biggest issue today isn’t deploying agents, it’s understanding what’s already running. Many enterprises struggle to answer basic questions like how many agents exist, where they’re deployed, which models they use, and what data they can access. Agent Scanner directly tackles that visibility gap,” said Robert Kramer, principal analyst at Moor Insights and Strategy.

CIOs can also use the tool to cut down on fragmentation, Kramer noted, adding that teams in enterprises often build agents in isolation, duplicating effort because they don’t know what already exists elsewhere internally.

Agent Scanners’ significance, however, extends beyond its appeal to CIOs and security leaders, particularly as the pace of agent creation accelerates across large enterprises.

Stephanie Walter, practice leader for the AI stack at HyperFRAME Research, said the capability is also foundational to the original goal of Agent Fabric itself: curbing agent sprawl rather than just documenting it.

“Manual tracking is already failing. I expect so many agents to be created in the near future that a manual registry would be obsolete within weeks. Without an automated scanner, an enterprise’s Agent Registry becomes a stale spreadsheet that fails to account for the shadow AI being built in various cloud silos,” Walter added.

Metadata extraction to provide more visibility

Further, analysts said Agent Scanners’ ability to automatically read and document agents’ metadata could give CIOs a more practical way to maintain visibility as agent deployments scale, since simply knowing that an agent exists does little to support governance, cost optimization, or reuse.

“The real value comes from understanding context — what the agent can do, which LLM it uses, and what data it’s authorized to touch,” Kramer said.

“Agent Scanner’s metadata extraction adds that depth, making it easier for security teams to assess risk, for architects to identify overlap or consolidation opportunities, and for developers to safely connect agents. That shifts agent management from static inventory tracking to something that supports real operational decisions,” Kramer added.

Seconding Kramer, Walter pointed out that the same metadata can then be standardized into Agent-to-Agent (A2A) card formats, making identifying and trusting agents easier.

Agent Scanners is currently in preview, and MuleSoft expects the capability to be made generally available towards the end of this month.

(image/jpeg; 6.88 MB)

AI agents and IT ops: Cowboy chaos rides again 22 Jan 2026, 1:00 am

In a traditional IT ops culture, sysadmin “cowboys” would often SSH into production boxes, wrangling systems by making a bunch of random and unrepeatable changes, and then riding off into the sunset. Enterprises have spent more than a decade recovering from cowboy chaos through the use of tools such as configuration management, immutable infrastructure, CI/CD, and strict access controls. But, now, the cowboy has ridden back into town—in the form of agentic AI.

Agentic AI promises sysadmins fewer manual tickets and on‑call fires to fight. Indeed, it’s nice to think that you can hand over the reins to a large language model (LLM), prompting it to, for example, log into a server to fix a broken app at 3 a.m. or update an aging stack while humans are having lunch. The problem is that an LLM is, by definition, non‑deterministic: Given the same exact prompts at different times, it will produce a different set of packages, configs, and/or deployment steps to perform the same tasks—even if a particular day’s run worked fine. This would hurtle enterprises back to the proverbial O.K. Corral, which is decidedly not OK.

I know, first-hand, that burning tokens is addictive. This weekend, I was troubleshooting a problem on one of my servers, and I’ll admit that I got weak, installed Claude Code, and used it to help me troubleshoot some systemd timer problems. I also used it to troubleshoot a problem I was having with a container, and with validating an application with Google. It’s so easy to become reliant on it to help us with problems on our systems. But, we have to be careful how far we take it.

Even in these relatively early days of agentic AI, sysadmins know it’s not a best practice to set an LLM off on production systems without any kind of guardrails. But, it can happen. Organizations get short-handed, people get pressured to do things faster, and then desperation sets in. Once you become reliant on an AI assistant, it’s very difficult to let go.

Rely on agentic AI for non-deterministic tasks

What sysadmins need to start thinking about is balancing their use of AI among deterministic and non-deterministic tasks—using AI for non‑deterministic work and then forcing everything important back into the deterministic world.

Non‑deterministic work is the exploratory, ambiguous, “figure it out” side of engineering—searching the Internet, reconciling docs, experimenting with different config patterns, sketching out playbooks or Dockerfiles. Deterministic work is what actually, effectively, purposely, and safely runs your business at scale—the scripts, container images, and pipelines that behave the same way every time across tens or hundreds or thousands of systems.

Retrieval-augmented generation (RAG), agent frameworks, and tool‑calling models all exist to reconnect a drifting, probabilistic model to grounded, deterministic data and systems. Whether the model is hitting a vector database, an API, a ticketing system, or a calculator, the protocol should be the same: Let the LLM reason in a fuzzy space, then anchor its output in something that behaves predictably when executed. Enterprises that blur that boundary—by letting the probabilistic part touch production directly—are inviting cowboy-level chaos.

What to build (and not to build) with agentic AI

The right pattern is not “AI builds the environment,” but “AI helps design and codify the artifact that builds the environment.” For infrastructure and platforms, that artifact might be a configuration management playbook that can install and harden a complex, multi‑tier application across different footprints, or it might be a Dockerfile, Containerfile, or image blueprint that can be committed to Git, reviewed, tested, versioned, and perfectly reconstructed weeks or months later.

What you don’t want is an LLM building servers or containers directly, with no intermediate, reviewable definition. A container image born from a chat prompt and later promoted into production is a time bomb—because, when it is time to patch or migrate, there is no deterministic recipe to rebuild it. The same is true for upgrades. Using an agent to improvise an in‑place migration on a one‑off box might feel heroic in the moment, but it guarantees that the system will drift away from everything else in your environment.

The outcomes of installs and upgrades can be different each time, even with the exact same model, but it gets a lot worse if you upgrade or switch models. If you’re supporting infrastructure for five, 10, or 20 years, you will be upgrading models. It’s hard to even imagine what the world of generative AI will look like in 10 years, but I’m sure Gemini 3 and Claude Opus 4.5 will not be around then.

The dangers of AI agents increase with complexity

Enterprise “applications” are no longer single servers. Today they are constellations of systems—web front ends, application tiers, databases, caches, message brokers, and more—often deployed in multiple copies across multiple deployment models. Even with only a handful of service types and three basic footprints (packages on a traditional server, image‑based hosts, and containers), the combinations expand into dozens of permutations before anyone has written a line of business logic. That complexity makes it even more tempting to ask an agent to “just handle it”—and even more dangerous when it does.

In cloud‑native shops, Kubernetes only amplifies this pattern. A “simple” application might span multiple namespaces, deployments, stateful sets, ingress controllers, operators, and external managed services, all stitched together through YAML and Custom Resource Definitions (CRDs). The only sane way to run that at scale is to treat the cluster as a declarative system: GitOps, immutable images, and YAML stored somewhere outside the cluster, and version controlled. In that world, the job of an agentic AI is not to hot‑patch running pods, nor the Kubernetes YAML; it is to help humans design and test the manifests, Helm charts, and pipelines which are saved in Git.

Modern practices like rebuilding servers instead of patching them in place, using golden images, and enforcing Git‑driven workflows have made some organizations very well prepared for agentic AI. Those teams can safely let models propose changes to playbooks, image definitions, or pipelines because the blast radius is constrained and every change is mediated by deterministic automation. The organizations at risk are the ones that tolerate special‑case snowflake systems and one‑off dev boxes that no one quite knows how to rebuild. The environments that still allow senior sysadins and developers to SSH into servers are exactly the environments where “just let the agent try” will be most tempting—and most catastrophic.

The quiet infrastructure advantage

The organizations that will survive the agent hype cycle are the ones that already live in a deterministic world. Their operating model assumes you do not poke at production by hand; you declare the desired state, you automate the path to get there, and you repeat it across thousands of systems without drama. In that kind of environment, AI shows up at build time and design time, not as an ungoverned runtime actor improvising in front of customers.

The real prize is not another shiny “AI agent for your infrastructure” banner. It is an opinionated stack that refuses to let AI touch production except through artifacts that can be tested, audited, and rerun on demand. That stack quietly protects enterprises from their own worst impulses: from the desperate developer at a startup who is tempted to give an LLM shell access, to the overworked sysadmin staring down a terrifying upgrade window on a legacy box. In that world, AI does what it does best—explore, analyze, propose—while the underlying platform does what it must: keep the cowboys, human or machine, out of production!

—

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.

(image/jpeg; 3.36 MB)

TypeScript levels up with type stripping 22 Jan 2026, 1:00 am

TypeScript is usually described as a superset of JavaScript, meaning all valid JavaScript is also valid TypeScript. With a few notable exceptions (like Enums and namespaces), it is possible to go through a program, delete the type information, and arrive at a perfectly legitimate JavaScript program. This is type stripping, an alternative to transpilation.

Now there’s a move to add type stripping to the core language, which would make it even easier to run your TypeScript programs as JavaScript.

Similar to type erasure in Java, type stripping would make it possible to execute a cheap text replacement of type information at runtime, rather than a heavier compile step later. Modern runtimes like Deno and Bun have supported this capability natively for some time, but type stripping really hit the enterprise mainstream in Node.js.

Starting in Node 22.6, released early last year, the JavaScript runtime can execute TypeScript directly. Node’s --experimental-strip-types flag erases, on the fly, all the parts of a TypeScript program that are not compatible with Node.

We’ll start with a look at how this feature works in Node, then discuss the ramifications of adding something similar to TypeScript.

Type stripping in Node

Consider the following TypeScript program:

// animal.ts
interface Animal {
  name: string;
  winged: boolean;
}

function move(creature: Animal): string {
  if (creature.winged) {
    return `${creature.name} takes flight.`;
  }
  return `${creature.name} walks the path.`;
}

const bat: Animal = {
  name: "Bat",
  winged: true
};

console.log(move(bat));

If we try to run this directly in Node, we get an error:

$ node animal.ts
C:\Users\matth\node\animal.ts:1
interface Animal {
          ^^^^^^

SyntaxError: Unexpected identifier 'Animal'

But if we run it with the new --experimental-strip-types flag, it works:

$ node --experimental-strip-types animal.ts
Bat takes flight.

Type stripping removes all the TypeScript-specific syntax, leaving something like the following:

// The interface is gone (replaced by whitespace)
                                  //
                                  //
                                  //

function move(creature) {         // ': Animal' and ': string' are stripped
  if (creature.winged) {
    return `${creature.name} takes flight.`;
  }
  return `${creature.name} walks the path.`;
}

const bat = {                     // ': Animal' is stripped
  name: "Bat",
  winged: true
};

console.log(move(bat));

Node’s --experimental-strip-types flag has inspired changes to the TypeScript spec itself, starting with the new erasableSyntaxOnly flag in TypeScript 5.8. Having the experimental flag available at runtime is one thing, but having it built into the language is quite another. Let’s consider the broader effects of this change.

No more source maps

For debugging purposes, it is essential that the types in our example are replaced with whitespace, not just deleted. That ensures the line numbers will naturally match-up between runtime and compile time. This preservation of whitespace is more than just a parser trick; it’s a big win for DX.

For years, TypeScript developers relied on source maps to translate the JavaScript running in the browser or server back to the TypeScript source code in their editor. While source maps generally work, they are notorious for being finicky. They can break and fail to map variables correctly, leading to problems where the line number in the stack trace doesn’t match the code on your screen.

With type stripping, the code running in Node is structurally identical to the code in your editor, line-for-line. Line 10 in your IDE is line 10 in the runtime. This eliminates the need for source maps during development, so the stack traces are always accurate, and your breakpoints always hit. Perhaps most importantly, having type stripping built into TypeScript eliminates an entire class of artifacts (source maps) from the build process.

This reinforces the realization that type information is not really a runtime factor but one that matters at development time. We want the guardrails in place while we are coding in the IDE, but after that, we can replace types with whitespace. Then the program can just run—with no build or compile step required.

What we lose to type stripping

With any change like this, there will be casualties. Other than source maps (which few will miss) type stripping in TypeScript mainly affects features that are not amenable to erasure:

Enums
Namespaces
Class parameter properties
import =

While some say these features are outside of TypeScript’s scope, they are all valid TypeScript constructs. They cannot be directly whitespaced out and require a compilation step to translate into valid JavaScript; therefore, the flag to enable only erasable syntax will throw an error when encountering them.

The TypeScript 5.8 announcement showed the following errors when using the flag:

// ❌ error: A namespace with runtime code.
namespace container {
    foo.method();

    export type Bar = string;
}

// ❌ error: An `import =` alias
import Bar = container.Bar;

class Point {
    // ❌ error: Parameter properties
    constructor(public x: number, public y: number) { }
}

// ❌ error: An enum declaration.
enum Direction {
    Up,
    Down,
    Left,
    Right,
}

Most of these are self-evident, but it’s worth noting that in parameter properties, the problem is that they require the compiler to inject actual assignment logic (this.x = x) into the constructor, which a simple “strip” operation cannot do.

The ‘Bridge of Zod’

It isn’t new for TypeScript to lose the type information by the time it’s running as JavaScript. It is either removed by the compiler or by stripping. This creates a problem if you need access to type information (for example, if you need to check that a request parameter is a string). The Zod library addresses the problem, and also provides a simple replacement for Enum.

Because type stripping aggressively removes all type information, it underscores that TypeScript cannot validate your API responses or user inputs at runtime. If you define an interface, Animal, that interface ceases to exist the moment Node runs your file.

This is where libraries like Zod can be the perfect partner to type stripping.

Since Zod schemas are defined using standard JavaScript objects and functions, they survive the stripping process completely intact. They provide the runtime safety that TypeScript “types as comments” cannot.

Also, Zod offers a direct solution to the casualties I mentioned above, particularly Enums. Since TypeScript Enums are banned in a type-stripping environment (because they generate code), developers have used Zod Enums instead. They exist as real JavaScript objects at runtime, but they can still export the static type definitions your IDE loves.

In that case, the workflow might look something like this:

Define a Zod schema (the runtime JavaScript stays).
Infer a TypeScript type from that schema (the static TypeScript is stripped).
Run the code without a build step, knowing your validation logic is still there.

Let’s run through a quick example to see how this works. In the code below, Zod “infers” the type at runtime, using JavaScript, and then exposes a TypeScript type at “type-checking time” (like in the IDE). To start, here’s a Zod schema:

const AnimalSchema = z.object({ 
  name: z.string(), 
  winged: z.boolean(), 
});

Note that the schema is just a JavaScript object with special functions used for validating instances. This object itself gives you everything you need for the runtime checks. To handle the compile-time, you add a line like so:

type Animal = z.infer;

This line will be removed by the type-stripper. This is a very clever piece of engineering; it boils down the whole role of TypeScript, enforcing the Animal type to a single line that smoothly bridges between compile time and runtime.

Type stripping and the future of JavaScript

Type stripping has all kinds of interesting ramifications, including for the future of JavaScript, as the JavaScript design team continues to contemplate absorbing type definitions (in one form or another) into the language itself.

Efforts have been underway for some time to make JavaScript do types. Most notably, the TC39 proposal, officially “Type Annotations,” also known as “Types as Comments.” The current era of type stripping is something of a bridge toward the possibility paid out by TC39. The JavaScript types proposal is still in stage 1, but changes to how we use TypeScript in practice could reawaken its ideas.

The basic idea in the type annotations proposal is very similar to type stripping (and comes with the same caveats for things like Enum), but instead of stripping, the idea is to comment out the type info. The runtime engine entirely ignores the type syntax, while the development-time engine (the IDE or linter) uses it to enforce types.

It’s worth noting that the JavaScript proposal has more than just TypeScript in mind. It also explicitly mentions the Closure compiler and Flow as targets. The end result would likely be the replacement of all three technologies with JavaScript.

As the specification correctly notes, the desire for static types in JavaScript has consistently ranked as the most in-demand “missing feature” in the annual State of JavaScript surveys.

The browser gap

Server-side runtimes like Node, Deno, and Bun are embracing type stripping but web browsers cannot yet embrace it. Both Chrome and Safari will crash the moment they encounter a type annotation.

For now, this creates a split in the ecosystem: A “no-build” utopia for the back end, but a continued reliance on build tools like Vite or webpack for the front end. This is exactly why the TC39 proposal for JavaScript is the final piece of the puzzle. Until browsers can natively ignore type syntax, universal type stripping remains out of reach. (This is a bit reminiscent of when the browser and server diverged on import syntax.)

Type stripping and the ‘no build’ future

Ultimately, type stripping is about much more than a Node flag or even a TypeScript feature. It represents a shift in how we view our tools. For a decade, developers have accepted that enterprise-grade JavaScript requires a heavy, complex build pipeline.

Features like --experimental-strip-types and the TC39 JavaScript proposal challenge that assumption. They point toward a future where the friction between writing code and running it is greatly attenuated. By treating types as useful dev-time comments, rather than compiler instructions, we get the safety we need while reducing the burden of complexity. That is a major level up for TypeScript, and for the technologies that will follow.

(image/jpeg; 14.73 MB)

jQuery 4.0.0 JavaScript library features trusted types 21 Jan 2026, 4:28 pm

Version 4.0.0 of the still-widely-used jQuery JavaScript library is now available. Celebrated as the first major release in nearly 10 years, jQuery 4.0.0 features support for trusted types and a new, slimmer build.

Announced January 17, the newest version of the jQuery JavaScript library can be downloaded from jquery.com. Trusted types in jQuery 4.0.0 ensure that HTML in the TrustedHTML interface can be input to jQuery manipulation methods in compliance with a browser’s Content Security Policy (CSP) required-trusted-types-for directive. In addition, while some AJAX requests already were using tags to maintain attributes such as crossdomain, jQuery’s builders have switched most asynchronous script requests to use to avoid any CSP errors caused by inline scripts. There still are a few cases where XHR is used for asynchronous script requests, such as when the "headers" option is passed, but tag is used whenever possible.

jQuery 4.0.0 also debuts with a slimmer build, with the removal of deferred objects and callbacks. Deferreds have long-supported the Promises A+ standard for interoperable JavaScript promises; however, in most cases, native promises, available in all jQuery-supported browsers but IE 11, can be used. And while deferred objects have some extra features that native promises do not support, most usage can be migrated to Promise methods, according to the announcement. For developers who must support IE 11, it is best to use the main build or add a polyfill for native promises. IE 10 and older versions are not supported in jQuery 4.0.0.

Now 20 years old, jQuery is still used by 70.9% of all websites, according to web technology surveyor W3Techs. Now under the jurisdiction of the OpenJS Foundation, jQuery is intended to simplify capabilities such as HTML document traversal and manipulation, event handling, and animation via an API that works across a multitude of browsers. Other highlights of jQuery 4.0.0 include the following:

Focus event order now follows the World Wide Web Consortium (W3C) specification, bringing jQuery in line with the event order supported in the latest versions of most browsers. This event order differs from the order used in older versions of jQuery, making it a breaking change. Starting with jQuery 4.0.0, the library no longer supports override native behavior, and will follow the current W3C specification: blur, focusout, focus, focusin.
Internal-only methods were removed from the jQuery prototype. This prototype had Array methods that did not behave like other jQuery methods and were intended only for internal use. Developers who were using the removed push, sort, and splice methods can replace $elems.push( elem ) with [].push.call( $elems, elem ).
With the release of jQuery 4.0.0, jQuery 3.x now will receive only critical updates.

(image/jpeg; 2.14 MB)

GitLab 2FA login protection bypass lets attackers take over accounts 21 Jan 2026, 3:59 pm

A critical two-factor authentication bypass vulnerability in the Community and Enterprise editions of the GitLab application development platform has to be patched immediately, say experts.

The hole is one of five vulnerabilities patched Wednesday as part of new versions of GitLab. Three are ranked High in severity, including the 2FA bypass issue, while the other two are ranked Medium in severity.

GitLab says the 2FA hole, CVE-2026-0723, if exploited on an unpatched system, could allow an individual with knowledge of a victim’s ID credentials to bypass two-factor authentication by submitting forged device responses.

It’s this hole that has drawn the attention of experts, because of the implications.

The goal of multifactor authentication is to protect login accounts with an extra verification step in case usernames and passwords are stolen. If a threat actor can access an account, they can do almost unlimited damage to IT systems.

In the case of GitLab, if critical code is sitting in a developer’s account, a threat actor could compromise it, notes David Shipley, head of Canadian-based security awareness training firm Beauceron Security. If that code is to be used in software that can be downloaded or sold to other organizations, then inserted malware could be spread in a supply chain attack. The latest example, Shipley said, is the Shai-Hulud worm, which is spreading because a developer’s account in the npm registry was hacked.

If the code contains cloud secrets, he added, the threat actor could gain access to cloud platforms like Azure, Amazon Web Service, or Google Cloud Platform.

Discovery of the 2FA bypass hole “is a reminder that these [security] controls are important,” Shipley said in an interview. “They absolutely help reduce a number of risks: Brute force attacks, password spraying, and so forth. But they will never be infallible.

“This is not the first time someone has found a clever way to get around 2FA challenges. We have a whole series of attacks around session cookie capture which are also designed to defeat 2FA. So it’s important to remember this when someone drops some Silver Bullet thinking that ‘This magic solution solves it [authentication]’ or ‘That’s the bad MFA. Here’s the new MFA.’ And I include [trusting only] Yubikeys,” he said. “Yubikeys are amazing. They’re the next generation of 2FA. But because they are made for humans, eventually they will have some flaws.”

Even if there weren’t flaws in these controls, employees might be tricked into giving up credentials through social engineering, he added.

It would be easier for an attacker to use techniques like phishing to collect user credentials rather than forge a device credential to exploit this particular 2FA bypass, said Johannes Ullrich, dean of research at the SANS Institute. But, he added, once the attacker has access to valid passwords, they can log in to the GitLab server and perform actions on the source code — download it, alter it or delete it — just as a legitimate user would.

What infosec leaders need to do

This is why Cybersecurity 101 — layered defense — is vital for identity and access management, Shipley said. That includes forcing employees to have long, unique login passwords, monitoring the network for unusual activity (for example, if someone gets in without an MFA challenge recorded) and, in case all fails, an incident response plan.

MFA bypass vulnerabilities are very common, noted Ullrich. “The core problem is usually that MFA was added later to an existing product,” he said, “and some features may not properly check if MFA was successfully completed.”

When testing a multifactor authentication solution, infosec leaders should always verify that an application has not marked authentication as completed after the username and password were verified. Enabling MFA should not relax password requirements, he asserted. Users must still pick unique, secure passwords and use password managers to manage them. Secure passwords will mostly mitigate any MFA failures, Ullrich said.

Any vulnerability found in GitLab is significant, he added. GitLab is typically used by organizations concerned enough about the confidentiality of their code that they want to run the platform on premises.

GitLab ‘strongly’ recommends upgrades

In describing the patches released Wednesday, GitLab said it “strongly” recommends all self managed GitLab installations be upgraded to one of the three new versions (18.8.2, 18.7.2, 18.6.4) for GitLab Community Edition (CE) and Enterprise Edition (EE). Those using GitLab.com or GitLab Dedicated – a single tenant software-as-a-service version – don’t have to take any action.

The other vulnerabilities fixed in Wednesday’s updates are:

CVE-2025-13927, a denial of service issue in Jira Connect integration. If exploited on an unpatched system, it could allow an unauthenticated user to create a denial of service condition by sending crafted requests with malformed authentication data. It carries a CVSS severity score of 7.5;
CVE-2025-13928, an incorrect authorization issue. If exploited on an unpatched system, it could allow an unauthenticated user to cause a denial of service condition by exploiting incorrect authorization validation in API endpoints. It carries a CVSS severity score of 7.5;
CVE-2025-13335, an infinite loop issue in Wiki redirects. Under certain circumstances, this hole could allow an authenticated user to create a denial of service condition by configuring malformed Wiki documents that bypass cycle detection. It has a CVSS score of 6.5;
CVE-2026-1102 – a denial of service issue in an API endpoint that could allow an unauthenticated user to create a denial of service condition by sending repeated malformed SSH authentication requests. It has a CVSS score of 5.3.

In keeping with standard GitLab practice, details of the security vulnerabilities will be made public on an issue tracker 30 days after the release in which they were patched.

The new versions also include bug fixes, some of which, GitLab said, may include database migrations. In cases of single-node instances, a patch will cause downtime during the upgrade. In the case of multi-node instances, admins who follow proper GitLab zero-downtime upgrade procedures can apply a patch without downtime.

This article originally appeared on CSOonline.

(image/jpeg; 1.19 MB)

Tailwind, AI, and building the future of software 21 Jan 2026, 1:00 am

I have had a love/hate/love relationship with Tailwind.

When Tailwind was first released, it generated a lot of buzz, and I naturally gave it a look. It was an intriguing notion—to define a multitude of tiny CSS utility classes that you embed directly in your HTML, giving you fine control over every tag. It was super cool.

However, I’m a huge believer in the separation of concerns. You shouldn’t mix your chocolate and your peanut butter, but it soon became apparent that Tailwind was asking me to do exactly that. One of the main purposes of CSS was to allow you to separate out the HTML and the code that styles that HTML. Didn’t Tailwind do the opposite? You can’t separate your concerns and have your design elements embedded in your HTML, can you? Well, no.

But the nature of web design has changed since CSS was first built. Most frameworks, whether it be Angular, React, or Astro, have become component-based. But even those components were designed to separate CSS and HTML. For instance, in Angular, a component consists of three files: a TypeScript file, an HTML file, and a CSS file.

But those components are becoming more and more granular. At the same time, the look and feel of websites have become more standardized. Button colors, for example, have standardized so that blue means “you can trust this button” and red means “be careful when pushing this one.” So the need for customized colors has been reduced.

Now here is where Tailwind shines. If you want standardized colors, Tailwind can define them. And if your colors and shapes are standardized, then Tailwind’s small utility classes that define those styles are useful. Finally, if those components are compact and self-contained, do you really need to separate your HTML and your CSS?

Ultimately, Tailwind is powerful and easy to use. Thus it has become very popular, if not a standard way to style websites.

And now Tailwind’s popularity might be its downfall.

Tailwind CSS meets AI headwind

This past week, the Tailwind team laid off 75% of their developers. Why? Well, according to Adam Wathan, the creator of Tailwind and the founder of Tailwind Labs, the layoffs were necessary because AI has caused the company’s marketing pipeline to dry up. Tailwind has that wonderful feature—the MIT License—which makes it basically free to use. Tailwind Labs depended on traffic to their website to drive “lifetime license” sales and sponsorships. But since AI now is doing more and more coding, developers don’t go to the Tailwind site and thus don’t purchase or support as much as they used to.

I kind of hate that.

Don’t get me wrong. I’ve written enough about agentic coding over the last few months to strongly support my bona fides as a vibe coder, but this is a real, live example of what can—and will—happen. We’ve seen Stack Overflow questions dwindle to practically nothing. Now AI is making it hard for Tailwind Labs to make money.

That’s the part I hate. Is AI simply going to make writing new code and frameworks not worth the effort? If so, then where will new code and frameworks come from?

I suppose that the answer to that is agentic AI itself. But only time will tell if AI can take over the task of creating better frameworks and libraries for our (its?) use, or if we will need to come up with a newer, better model for making human-generated libraries profitable.

I love Tailwind and I love agentic AI, but I hate what is happening to the former because of the latter. Who is going to build the future?

(image/jpeg; 12.74 MB)

How to use Pandas for data analysis in Python 21 Jan 2026, 1:00 am

When it comes to working with data in a tabular form, most people reach for a spreadsheet. That’s not a bad choice: Microsoft Excel and similar programs are familiar and loaded with functionality for massaging tables of data. But what if you want more control, precision, and power than Excel alone delivers?

In that case, the open source Pandas library for Python might be what you are looking for. Pandas augments Python with new data types for loading data fast from tabular sources, and for manipulating, aligning, merging, and doing other processing at scale.

Your first Pandas data set

Pandas is not part of the Python standard library. It’s a third-party project, so you’ll need to install it in your Python runtime with pip install pandas. Once installed, you can import it into Python with import pandas.

Pandas gives you two new data types: Series and DataFrame. The DataFrame represents your entire spreadsheet or rectangular data, whereas the Series is a single column of the DataFrame. In Python terms, you can think of the Pandas DataFrame as a dictionary or collection of Series objects. You’ll also find later that you can use dictionary- and list-like methods for finding elements in a DataFrame.

You typically work with Pandas by importing data from some other format. A common external tabular data format is CSV, a text file with values separated by commas. If you have a CSV handy, you can use it. For this article, we’ll be using an excerpt from the Gapminder data set prepared by Jennifer Bryan from the University of British Columbia.

To begin using Pandas, we first import the library. Note that it’s a common practice to alias the Pandas library as pd to save some typing:

import pandas as pd

To start working with the sample data in CSV format, we can load it in as a dataframe using the pd.read_csv function:

df = pd.read_csv("./gapminder/inst/extdata/gapminder.tsv", sep='t')

The sep parameter lets us specify that the file is tab-delimited rather than comma-delimited.

Once you’ve loaded the data, you can use the .head() method on the dataframe to peek at its formatting and ensure it’s loaded correctly. .head() is a convenience method used to display the first few rows of a dataframe for quick inspection. The results for the Gapminder data should look like this:

print(df.head())
       country continent  year  lifeExp       pop   gdpPercap
0  Afghanistan      Asia  1952   28.801   8425333  779.445314
1  Afghanistan      Asia  1957   30.332   9240934  820.853030
2  Afghanistan      Asia  1962   31.997  10267083  853.100710
3  Afghanistan      Asia  1967   34.020  11537966  836.197138
4  Afghanistan      Asia  1972   36.088  13079460  739.981106

Dataframe objects have a shape attribute that reports the number of rows and columns in the dataframe:

print(df.shape)
(1704, 6) # rows, cols

To list the names of the columns themselves, use .columns:

print(df.columns)
Index(['country', 'continent', 'year', 'lifeExp',
'pop', 'gdpPercap'], dtype='object')

Dataframes in Pandas work much the same way as they do in other languages, such as Julia and R. Each column, or Series, must be the same type, whereas each row can contain mixed types. For instance, in the current example, the country column will always be a string, and the year column is always an integer. We can verify this by using .dtypes to list the data type of each column:

print(df.dtypes)
country object
continent object
year int64
lifeExp float64
pop int64
gdpPercap float64
dtype: object

For an even more explicit breakdown of your dataframe’s types, you can use .info():

df.info() # information is written to console, so no print required

RangeIndex: 1704 entries, 0 to 1703
Data columns (total 6 columns):
 #   Column     Non-Null Count  Dtype
---  ------     --------------  -----
 0   country    1704 non-null   object
 1   continent  1704 non-null   object
 2   year       1704 non-null   int64
 3   lifeExp    1704 non-null   float64
 4   pop        1704 non-null   int64
 5   gdpPercap  1704 non-null   float64
dtypes: float64(2), int64(2), object(2)
memory usage: 80.0+ KB

Each Pandas data type maps to a native Python data type:

object is handled as a Python str type. (More on this below.)
int64 is handled as a Python int. Note that not all Python ints can be converted to int64 types; anything larger than (2 ** 63)-1 will not convert to int64.
float64 is handled as a Python float (which is a 64-bit float natively).
datetime64 is handled as a Python datetime.datetime object. Note that Pandas does not automatically try to convert something that looks like a date into date values; you must tell Pandas you want the conversion done for a specific column.

Any data that’s not a native Pandas type—essentially, anything that’s not a number—is stored as a generic NumPy type named object. If you have an object column in a dataframe, it’s worth making sure that data is not being used as part of any computational work, as you’ll get none of the performance benefits of using a numerical type (int64, float64, etc.).

Traditionally, strings have been represented as an object. As of Pandas 2.3 or higher, there’s an option to use a new dedicated str type, which has better Panda-native behaviors (such as a more explicit type for the data and more efficient storage). To enable this behavior, you’d use the command pd.options.future.infer_string = True at the top of your code.

Pandas columns, rows, and cells

Now that you’re able to load a simple data file, you want to be able to inspect its contents. You could print the contents of the dataframe, but most dataframes are too big to inspect by printing.

A better approach is to look at subsets of the data, as we did with df.head(), but with more control. Pandas lets you use Python’s existing syntax for indexing and creating slices to make excerpts from dataframes.

Extracting Pandas columns

To examine columns in a Pandas dataframe, you can extract them by their names, positions, or by ranges. For instance, if you want a specific column from your data, you can request it by name using square brackets:

# extract the column "country" into its own dataframe
country_df = df["country"]

# show the first five rows
print(country_df.head())
| 0 Afghanistan
| 1 Afghanistan
| 2 Afghanistan
| 3 Afghanistan
| 4 Afghanistan
Name: country, dtype: object

# show the last five rows
print(country_df.tail())
| 1699  Zimbabwe
| 1700  Zimbabwe
| 1701  Zimbabwe
| 1702  Zimbabwe
| 1703  Zimbabwe
| Name: country, dtype: object

If you want to extract multiple columns, pass a list of the column names:

# Looking at country, continent, and year
subset = df[['country', 'continent', 'year']]

print(subset.head())
       country continent  year
| 0  Afghanistan    Asia  1952
| 1  Afghanistan    Asia  1957
| 2  Afghanistan    Asia  1962
| 3  Afghanistan    Asia  1967
| 4  Afghanistan    Asia  1972

print(subset.tail())
         country continent    year
| 1699  Zimbabwe    Africa    1987
| 1700  Zimbabwe    Africa    1992
| 1701  Zimbabwe    Africa    1997
| 1702  Zimbabwe    Africa    2002
| 1703  Zimbabwe    Africa    2007

Subsetting rows

If you want to extract rows from a dataframe, you can use one of two methods.

.iloc[] is the simplest method. It extracts rows based on their position, starting at 0. For fetching the first row in the above dataframe example, you’d use df.iloc[0].

If you want to fetch a range of rows, you can use .iloc[] with Python’s slicing syntax. For instance, for the first 10 rows, you’d use df.iloc[0:10]. And if you wanted to obtain the last 10 rows in reverse order, you’d use df.iloc[::-1].

If you want to extract specific rows, you can use a list of the row IDs; for example, df.iloc[[0,1,2,5,7,10,12]]. (Note the double brackets—that means you’re providing a list as the first argument.)

Another way to extract rows is with .loc[]. This extracts a subset based on labels for rows. By default, rows are labeled with an incrementing integer value starting with 0. But data can also be labeled manually by setting the dataframe’s .index property.

For instance, if we wanted to re-index the above dataframe so that each row had an index using multiples of 100, we could use df.index = range(0, len(df)*100, 100). Then, if we used, df.loc[100], we’d get the second row.

Subsetting columns

If you want to retrieve only a certain subset of columns along with your row slices, you do this by passing a list of columns as a second argument:

df.loc[[rows], [columns]]

For instance, with the above dataset, if we want to get only the country and year columns for all rows, we’d do this:

df.loc[:, ["country","year"]]

The : in the first position means “all rows” (it’s Python’s slicing syntax). The list of columns follows after the comma.

You can also specify columns by position when using .iloc:

df.iloc[:, [0,2]]

Or, to get just the first three columns:

df.iloc[:, 0:3]

All of these approaches can be combined, as long as you remember loc is used for labels and column names, and iloc is used for numeric indexes. The following tells Pandas to extract the first 100 rows by their numeric labels, and then from that to extract the first three columns by their indexes:

df.loc[0:100].iloc[:, 0:3]

It’s generally least confusing to use actual column names when subsetting data. It makes the code easier to read, and you don’t have to refer back to the dataset to figure out which column corresponds to what index. It also protects you from mistakes if columns are re-ordered.

Grouped and aggregated calculations

Spreadsheets and number-crunching libraries all come with methods for generating statistics about data. Consider the Gapminder data again:


print(df.head(n=10))
|    country      continent  year  lifeExp  pop       gdpPercap
| 0  Afghanistan  Asia       1952  28.801    8425333  779.445314
| 1  Afghanistan  Asia       1957  30.332    9240934  820.853030
| 2  Afghanistan  Asia       1962  31.997   10267083  853.100710
| 3  Afghanistan  Asia       1967  34.020   11537966  836.197138
| 4  Afghanistan  Asia       1972  36.088   13079460  739.981106
| 5  Afghanistan  Asia       1977  38.438   14880372  786.113360
| 6  Afghanistan  Asia       1982  39.854   12881816  978.011439
| 7  Afghanistan  Asia       1987  40.822   13867957  852.395945
| 8  Afghanistan  Asia       1992  41.674   16317921  649.341395
| 9  Afghanistan  Asia       1997  41.763   22227415  635.341351

Here are some examples of questions we could ask about this data:

What’s the average life expectancy for each year in this data?
What if I want averages across the years and the continents?
How do I count how many countries in this data are in each continent?

The way to answer these questions with Pandas is to perform a grouped or aggregated calculation. We can split the data along certain lines, apply some calculation to each split segment, and then re-combine the results into a new dataframe.

Grouped means counts

The first method we’d use for this is Pandas’s df.groupby() operation. We provide a column we want to split the data by:

df.groupby("year")

This allows us to treat all rows with the same year value together, as a distinct object from the dataframe itself.

From there, we can use the “life expectancy” column and calculate its per-year mean:


print(df.groupby('year')['lifeExp'].mean())
year
1952 49.057620
1957 51.507401
1962 53.609249
1967 55.678290
1972 57.647386
1977 59.570157
1982 61.533197
1987 63.212613
1992 64.160338
1997 65.014676
2002 65.694923
2007 67.007423

This gives us the mean life expectancy for all populations, by year. We could perform the same kinds of calculations for population and GDP by year:


print(df.groupby('year')['pop'].mean())
print(df.groupby('year')['gdpPercap'].mean())

So far, so good. But what if we want to group our data by more than one column? We can do this by passing columns in lists:


print(df.groupby(['year', 'continent'])
  [['lifeExp', 'gdpPercap']].mean())
                  lifeExp     gdpPercap
year continent
1952 Africa     39.135500   1252.572466
     Americas   53.279840   4079.062552
     Asia       46.314394   5195.484004
     Europe     64.408500   5661.057435
     Oceania    69.255000  10298.085650
1957 Africa     41.266346   1385.236062
     Americas   55.960280   4616.043733
     Asia       49.318544   5787.732940
     Europe     66.703067   6963.012816
     Oceania    70.295000  11598.522455
1962 Africa     43.319442   1598.078825
     Americas   58.398760   4901.541870
     Asia       51.563223   5729.369625
     Europe     68.539233   8365.486814
     Oceania    71.085000  12696.452430

This .groupby() operation takes our data and groups it first by year, and then by continent. Then, it generates mean values from the life-expectancy and GDP columns. This way, you can create groups in your data and rank how they are to be presented and calculated.

If you want to “flatten” the results into a single, incrementally indexed frame, you can use the .reset_index() method on the results:


gb = df.groupby(['year', 'continent'])
[['lifeExp', 'gdpPercap']].mean()
flat = gb.reset_index() 
print(flat.head())
|     year  continent  lifeExp    gdpPercap
| 0   1952  Africa     39.135500   1252.572466
| 1   1952  Americas   53.279840   4079.062552
| 2   1952  Asia       46.314394   5195.484004
| 3   1952  Europe     64.408500   5661.057435
| 4   1952  Oceana     69.255000  10298.085650

Grouped frequency counts

Something else we often do with data is compute frequencies. The nunique and value_counts methods can be used to get unique values in a series, and their frequencies. For instance, here’s how to find out how many countries we have in each continent:


print(df.groupby('continent')['country'].nunique()) 
continent
Africa    52
Americas  25
Asia      33
Europe    30
Oceana     2

Basic plotting with Pandas and Matplotlib

Most of the time, when you want to visualize data, you’ll use another library such as Matplotlib to generate those graphics. However, you can use Matplotlib directly (along with some other plotting libraries) to generate visualizations from within Pandas.

To use the simple Matplotlib extension for Pandas, first make sure you’ve installed Matplotlib with pip install matplotlib.

Now let’s look at the yearly life expectancies for the world population again:


global_yearly_life_expectancy = df.groupby('year')['lifeExp'].mean() 
print(global_yearly_life_expectancy) 
| year
| 1952  49.057620
| 1957  51.507401
| 1962  53.609249
| 1967  55.678290
| 1972  57.647386
| 1977  59.570157
| 1982  61.533197
| 1987  63.212613
| 1992  64.160338
| 1997  65.014676
| 2002  65.694923
| 2007  67.007423
| Name: lifeExp, dtype: float64

To create a basic plot from this, use:


import matplotlib.pyplot as plt
global_yearly_life_expectancy = df.groupby('year')['lifeExp'].mean() 
c = global_yearly_life_expectancy.plot().get_figure()
plt.savefig("output.png")

The plot will be saved to a file in the current working directory as output.png. The axes and other labeling on the plot can all be set manually, but for quick exports this method works fine.

Conclusion

Python and Pandas offer many features you can’t get from spreadsheets. For one, they let you automate your work with data and make the results reproducible. Rather than write spreadsheet macros, which are clunky and limited, you can use Pandas to analyze, segment, and transform data—and use Python’s expressive power and package ecosystem (for instance, for graphing or rendering data to other formats) to do even more than you could with Pandas alone.

(image/jpeg; 18.27 MB)

Three vulnerabilities in Anthropic Git MCP Server could let attackers tamper with LLMs 20 Jan 2026, 7:47 pm

Threat actors could use prompt injection attacks to take advantage of three vulnerabilities in Anthropic’s official Git MCP server and cause mayhem with AI systems.

This alert comes from researchers at Israel-based Cyata, which urges infosec leaders to make sure corporate developers using the official GIT MCP server update to the latest version as soon as possible.

The risk is that an attacker could run unapproved code or tamper with a large language model (LLM), compromising its output.

While the official Git MCP server can be exploited on its own, “the toxic combination is when both the Git MCP server and a Filesystem MCP server are enabled,” Cyata CEO Shahar Tal said in an interview. “Then that [AI] agent is at critical risk. We urge people to use the latest versions [of both applications].”

At risk are developers using mcp-server-git versions prior to 2025-12.18.

The three vulnerabilities are

·CVE-2025-68143, an unrestricted git_init.
·CVE-2025-68145, a path validation bypass.
·CVE-2025-68144, an argument injection in git_diff.

Unlike other vulnerabilities in MCP servers that required specific configurations, these work on any configuration of Anthropic’s official server, out of the box, Cyata says.

Model Context Protocol (MCP) is an open standard introduced by Anthropic in 2024 to provide a unified way for AI assistants (such as Claude Desktop, Cursor, Windsurf, and others) to interact with external tools and data sources including filesystems, databases, APIs, and development tools like Git.

MCP servers expose capabilities to the AI, acting as a bridge between the LLM and external systems.

As Cyata points out in its blog, MCP servers execute actions based on LLM decisions. If an LLM can be manipulated through prompt injection, a threat actor can influence the AI’s context to trigger MCP tool calls with attacker-controlled arguments.

Since Anthropic released its model, thousands of vendors and third party providers have released official MCP servers. There are also unofficial servers for online platforms like LinkedIn. And, as might be expected, there are dodgy MCP servers circulating from crooks.

It isn’t known how many enterprise developers use mcp-server-git, the official Git MCP server maintained by Anthropic. Nor is it known how many also use Filesystem MCP Server.

Cyata researcher Yarden Porat first discovered that if a tool is called in mcp-server-git, the server will use the path it is given without validation, so an attacker could create a new git repository with malicious content that could be read by the LLM.

The second hole is in a parameter that gets passed directly to the git command line without sanitization. That means a threat actor can inject any git flag, including one that could overwrite a target file. Third, it was discovered that an attacker could also delete files. Finally, researchers found that attackers could use git’s smudge and clean filters to run code.

“All you have to know — and it depends on the agent you’re attacking — is how to get the [AI] agent to read something you control,” said Tal. “That is quite widespread. It’s a very wide attack surface.”

Related content: Top 10 MCP vulnerabilities

Cyata says defensive action not only means updating mcp-server-git to version 2025.12.18 or later, but also auditing which MCP servers run together. Combining Git + Filesystem increases the attack surface, the researchers say.

Admins should also monitor for unexpected .git directories in non-repository folders.

“Generally, it is very hard to protect against vulnerabilities in MCP servers,” said Tal. “Most assistant type agents don’t even let you sanitize parameters. Homegrown agents could include various prompt injection defenses, but none are fail-proof.”

Cyata says it informed Anthropic of the first problem through the bug reporting service HackerOne on June 24, 2025. It was marked by Anthropic as informative. After Cyata reported the prompt injection issue, Anthropic took another look, but it wasn’t until September 10 that the report was accepted. The new version of Git MCP Server was released December 18.

In an interview, Porat suggested there wasn’t much that infosec leaders or developers could have done between the discovery of the vulnerability and the release of the more secure version of Git MCP Server. A prompt injection attack would work on the unpatched version even in its most secure configuration, he said.

“You need guardrails around each [AI] agent and what it can do, what it can touch,” Tal added. “You need to also, if there is an incident, be able to look back at everything the agent did.”

The problem with MCP servers is that they give the LLM access to execute sensitive functions, commented Johannes Ullrich, dean of research at the SANS Institute. “How much of a problem this is depends on the particular features they have access to. But once an MCP server is configured, the LLM will use the content it receives to act on and execute code (in this case, in git).

“Sadly, it is very unlikely that this will be the last time we see a prompt injection in this system. There is no simple fix for prompt injections, and usually you are going to create band-aids to prevent specific exploits. For an MCP server like this, the best option is to restrict the data it operates on, so it uses only data from trusted sources, and the functionality it can access. Some fine-grained access control can be used to implement this.”

Tanya Janca, a Canadian-based secure coding trainer, said to mitigate potential issues, development teams using MCP should limit access and privileges for MCP servers — no root, read-only access, local access only — and only give users the least privileges they need. Admins should validate file paths completely, not just prefix matching, resolve symlinks properly and always perform careful input validation and use parameterized queries.

This article originally appeared on CSOonline.

(image/jpeg; 10.05 MB)

JDK 26: The new features in Java 26 20 Jan 2026, 6:00 am

Java Development Kit (JDK) 26, a planned update to standard Java due March 17, 2026, has reached a second rampdown phase for bug fixes, with the feature set having been frozen last month. The second rampdown phase was announced January 16.

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

A short-term release of Java backed by six months of Premier-level support, JDK 26 follows the September 16 release of JDK 25, which is a Long-Term Support (LTS) release backed by several years of Premier-level support. Early-access builds of JDK 26 are available at https://jdk.java.net/26/. The initial rampdown phase was unveiled in early December. Release candidates are planned for February 5 and February 19.

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

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

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

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

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

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

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

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

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

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

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

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

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

(image/jpeg; 1.93 MB)

AI is rewriting the sustainability playbook 20 Jan 2026, 1:00 am

“Greenops” didn’t emerge because enterprises suddenly had a moral awakening. Rather, cloud bills became painful, regulators got serious, and sustainability teams started asking questions IT couldn’t answer with confidence. Once companies realized that cloud consumption wasn’t only a technical concern but also a financial and reputational risk, they did what they always do: They operationalized it. Let me explain.

At first, greenops was mostly finops with a greener badge. Reduce waste, right-size instances, shut down idle resources, clean up zombie storage, and optimize data transfer. Those actions absolutely help, and many teams delivered real improvements by making energy and emissions a visible part of engineering decisions. The key innovation wasn’t adopting new technology—it was adopting a new operating model that made “doing the efficient thing” repeatable.

Greenops matters because it forces enterprises to confront the reality that the cloud is not a magical, consequence-free abstraction. Every workload maps to physical compute, power, cooling, and buildings. When greenops is healthy, it becomes a governance layer that aligns architecture, procurement, and product decisions around measurable outcomes rather than green slogans.

AI changes the math

Then AI arrived as more than a curiosity. It turned into an arms race. The difference between moving apps to the cloud and building an AI capability is the difference between renovating a house and pouring concrete for a new city. Modern AI, especially at the scale enterprises want in order to compete, demands dense compute, fast networks, accelerated hardware, and round-the-clock capacity. AI workloads are not only expensive, they are structurally predisposed to consume more power per unit of time than many traditional enterprise workloads.

Now add the accelerant: cloud AI services. Hyperscalers have made it easy to rent extreme compute with a credit card and an API call. That convenience is transformative for innovation, but it also means the gating factor is how fast you can scale rather than having to procure hardware. And when scale becomes the goal, energy intensity becomes the side effect.

The market response is visible: Data center construction is exploding. Not because enterprises suddenly love building facilities, but because the entire ecosystem is racing to stand up the physical substrate that AI requires. New sites, expansions, power purchase negotiations, grid interconnects, backup generation, liquid cooling retrofits—the less glamorous parts of digital transformation are becoming the main event.

Greenops was designed for incremental efficiency in a world where optimization could keep pace with growth. AI breaks that assumption. You can right-size your cloud instances all day long, but if your AI footprint grows by an order of magnitude, efficiency gains get swallowed by volume. It’s the classic rebound effect: When something (AI) becomes easier and more valuable, we do more of it, and total consumption climbs.

The greenops narrative

Here’s where the messaging starts to sound like it’s coming out of both sides of the corporate mouth. Many enterprises have spent the past few years promoting their greenness: carbon-neutral pledges, renewable energy claims, sustainability reports with glossy charts, and “we’re committed” language polished by PR teams. Some of it is sincere and reflects real progress, but a growing portion of it is selective accounting paired with convenient ambiguity.

The contradiction shows up in planning meetings instead of press releases. Enterprises are simultaneously declaring sustainability leadership while budgeting for dramatically more compute, storage, networking, and always-on AI services. They tell stakeholders, “We’re reducing our footprint,” while telling internal teams, “Instrument everything, vectorize everything, add copilots everywhere, train custom models, and don’t fall behind.”

This is hypocrisy and a governance failure. Most organizations still treat sustainability as a reporting function and AI as a strategic imperative. When priorities collide, AI wins—quietly, automatically, and repeatedly—because the incentives are aligned that way. Business units get rewarded for growth and speed, not for the long-term externalities of energy use, water consumption, and grid strain.

Even worse, the definitions are slippery. “Renewable-powered” can mean offsets. “Carbon-neutral” can mean accounting boundaries that exclude parts of the supply chain. “Efficient” can mean per-transaction improvements while total transactions explode. Meanwhile, the physical reality remains: More AI usage generally means more data center demand. More data center demand typically means more energy use, regardless of how compelling the sustainability narrative sounds.

AI value and carbon realities

First, enterprises should treat carbon as a primary architectural constraint, not just a retrospective report. They need to set explicit emissions or energy budgets at the product and platform levels, similar to budgets for latency, availability, and cost. If a new AI feature demands five times the compute, the decision shouldn’t be simply to ship and celebrate. Instead, organizations should consider whether they are willing to fund and publicly accept the operational and environmental costs. The old adage, “Don’t do anything you don’t want to read about in the news,” applies here as well, because, rest assured, the word will eventually get out about how much that feature costs in terms of sustainability.

Second, enterprises need to measure AI differently. Model quality alone provides an incomplete KPI (key performance indicator). The question isn’t just “Is it more accurate?” but rather “What is the carbon-adjusted value per outcome?” In practice, this pushes teams toward techniques and choices that reduce waste without killing innovation. Here are a few ideas:

Select smaller models when they work.
Use retrieval and caching instead of repeated generation.
Tune inference to avoid overprovisioning.
Schedule non-urgent training when grid intensity is lower.
Design systems to degrade gracefully rather than running at peak capacity all the time.

None of these methods prevents AI adoption; it simply forces responsible adoption.

Third, enterprises must renegotiate their relationship with cloud AI services through procurement and governance, not hope. If you buy AI the way you buy generic cloud compute, you’ll get runaway consumption with a nice dashboard. Procurement should demand transparent reporting on energy and emissions factors, region-specific intensity, and service-level controls that allow you to cap, throttle, and forecast AI usage. Governance should require that new AI initiatives justify not only ROI but also projected energy and carbon impacts, with clearly identified accountability when forecasts prove inaccurate. Without these levers, sustainability teams will remain observers as the footprint expands.

Where this lands

Greenops isn’t dead, but it is being stress-tested by a wave of AI demand that was not part of its original playbook. Optimization alone won’t save you if your consumption curve is vertical. Rather than treat greenness as just a brand attribute, enterprises that succeed will recognize greenops as an engineering and governance discipline, especially for AI, where convenience and scale can covertly increase carbon footprint.

In the end, the question isn’t whether enterprises should use AI. They will. The question is whether they can build the muscle to use AI deliberately, with a carbon-aware architecture, carbon-adjusted KPIs, and enforceable governance before their sustainability story collapses under the weight of their own compute growth.

(image/jpeg; 1.73 MB)

A first look at XAML Studio 2.0 20 Jan 2026, 1:00 am

Sometimes, if you want to get an early look at a new tool from Microsoft, you must get out your compiler and build it from source. That’s the case with the first public look at the new open source release of XAML Studio, one of its .NET UI design tools, which is transitioning to the stewardship of the .NET Foundation.

XAML Studio is a tool for prototyping .NET user interfaces. Developed in Microsoft’s Garage internal incubation program, it was initially developed to build Universal Windows Platform (UWP) applications. Since its initial launch, UWP has evolved to the more widely applicable WinUI, making XAML Studio less useful, especially when building cross-platform .NET applications.

What came before

If you downloaded the original release, you would see a basic grid view along with a code editor. Edit the code, and changes would be reflected in the grid, allowing you to quickly design new application UIs. It’s a powerful tool, bringing some of the familiar experience of tools like Adobe’s Dreamweaver to XAML and .NET. A library of controls can be dropped into the editor and configured with links to either mock data or real-time data, so you can see how your design works with the data users will be accessing.

The latest public build of XAML Studio is Version 1.1, from 2019. There’s been a lot of change in .NET during the past six years, and as updates to XAML Studio needed new WinUI components, development continued behind closed doors. With the release of essential controls in the Windows App SDK, development can now move into public view again, and the first version of XAML Studio 2.0 has appeared on GitHub.

Building XAML Studio 2.0

Getting started with the new release requires an up-to-date Windows development environment, with Visual Studio 2022 configured for building Windows applications and with a recent release of the Windows SDK. Your Windows install should have developer mode enabled so that it will run an unsigned Store application from Visual Studio.

With the prerequisites in place, you first need to clone the application repository from GitHub and then switch to the dev branch because the main branch contains the 1.1 release currently in the Microsoft Store. Once downloaded, you can open the source’s solution file in Visual Studio, making sure the XamlStudio project is set as the startup project. There are three other projects in the solution: Microsoft.Toolkit.Future, XamlStudio.Toolkit, and XamlStudio.Toolkit.UnitTests.

You can now build and run the application. This may trigger downloading additional dependencies, but once they’re in place, the application should launch. I first used the Debug option, and as I was working on an x64 system, I made sure that I was building x64 binaries and debugging on my local system. The solution should build on Arm as well, but currently there are issues, and the development team is looking for Arm expertise to help find fixes.

Trying out the new XAML Studio

The new release looks much like the current 1.1 release, but a lot of work has been done to add support for the current generation of XAML controls and components, as well as support for the latest .NET releases. You can see a lot of this from the application’s Toolbox menu, which supports controls from the Community Toolkit and from WinUI. It’s a long list of tools, with the option to favorite frequently used controls and a search option to quickly narrow down the control you need. Work is ongoing, and the team has published a road map for the release.

Each control in the menu offers a link to online documentation so you can quickly check the requisite syntax. This feature turns out to be important, as adding a control to a page only adds the XAML tag without any parameters. The Monaco-based editor will indicate errors, but there’s no autocomplete or suggested syntax, so you may want to use this in conjunction with other development tools.

It’s important to note that XAML Studio is not a full visual designer. You will do all your work in its code editor, with the just-in-time compiler rendering XAML on the fly. It would be better to have some form of two-way link between the editor and layout, but it’s still very useful to see what your XAML will look like as you write it. If you have a connection to either a mock data source or to live data, you can see how it responds to and presents the data that a full application will use.

Understanding the Properties explorer requires a bit of work. You need to switch the editor mode to Modify and select the XAML element you want to explore. The relevant properties are then displayed in the explorer, and you can see what’s currently set as well as other possible properties. There appears to be a plan to allow this to edit your XAML code, but for now only a few properties can be changed; even then, the application throws an exception and needs to be manually stepped through in the Visual Studio debugger. Nothing seems to happen when you add new properties, though they do persist in the explorer.

Despite these issues, there’s a lot to like about a tool that gives you the foundations of an interactive XAML Designer. Blend is well past its prime, so a new tool that fits into modern development toolchains is worth supporting.

Contributing to development

If you want to contribute to the project, it’s running under Microsoft’s open source code of conduct, like many others, and as well as accepting code contributions (once you’ve accepted the project’s Contributor Licence Agreement), there is a discussion forum where it’s possible to suggest and vote on features. One area that certainly needs work is providing complete documentation for the application since much of the necessary feature discovery is currently by trial and error.

As this is pre-release code you will find bugs; I tripped over more than one as I explored the application. The public 1.1 release is stable, so you can expect the final Store release of XAML Studio 2.0 to be much the same. Issues are to be expected at this stage of development, even though the internal team has worked to keep on top of the many changes to .NET and to XAML in the past six years.

As part of that process, the team has released many of its own tools to the .NET community, including a C# wrapper for the Monaco editor used in Visual Studio Code. An annual release cadence for .NET and a rapid development model for WinUI require a lot of heavy lifting from teams building development tools—another good reason for open sourcing the application.

XAML Studio in the .NET toolchain

Open sourcing a tool like this makes a lot of sense, especially as the .NET community is working with three different UI platforms: Microsoft’s own Win UI and MAUI and the third-party Avalonia and Uno platforms. By open sourcing XAML Studio, Microsoft makes it possible for both Avalonia and Uno to add their own features and tools to a common development platform or even fork their own versions as part of their own developer environments. There’s even the possibility of third-party developer tool platforms like JetBrains’ Rider working with and contributing to what is now a community tool rather than part of a competing developer ecosystem.

Certainly, I’m looking forward to seeing how XAML Studio becomes integrated into Visual Studio Code–based workflows and how it might be used as part of Uno’s Hot Design. A lot of innovation is happening in the .NET community, and bringing projects like this to the .NET Foundation should help add that innovation to the tools we use in our day-to-day application development. If this move is successful, maybe it’s time for Microsoft to open source more of its .NET development tools.

(image/jpeg; 11.59 MB)

ClickHouse buys Langfuse as data platforms race to own the AI feedback loop 19 Jan 2026, 4:20 am

ClickHouse has acquired open source LLM engineering platform, Langfuse, to add observability capabilities to its database services, which are designed for online analytical processing and AI applications.

The deal underscores ClickHouse’s push to become a more complete data and AI platform as customers try to move LLM-based applications into production, analysts say.

Langfuse’s observability capabilities, such as prompt tracing, model evaluation, and cost and latency tracking, directly complement ClickHouse’s core strength in high-performance analytics, said Akshat Tyagi, associate practice leader at HFS Research.

By bringing Langfuse in-house, ClickHouse can offer customers a native way to collect, store, and analyze large volumes of LLM telemetry alongside operational and business data, helping teams debug models faster, control costs, and run more reliable AI workloads without relying on a separate observability tool, Tyagi added.

ClickHouse is responding to where generative AI is “truly stuck” for enterprises, said Greyhound Research chief analyst Sanchit Vir Gogia. “Most companies are not failing to build AI features, rather they’re failing to explain them, trust them, or afford them. Models drift, costs spike, and business users can’t tell if decisions are defensible. ClickHouse is going after that precise blind spot,” Gogia said.

“With Langfuse in-house, it now has the tooling to convert every LLM call into a structured, queryable record,” Gogia noted.

Industry-wide shift

Analysts say that the acquisition marks a growing trend among different data warehouse and database vendors to own the AI feedback loop.

As enterprises try to move pilots into production, these vendors are trying to move “up the stack” from serving primarily as systems of record for analytics to becoming systems of action that support operational workflows, said Ishi Thakur, analyst at Everest Group.

Data warehouse and database vendors are trying to be seen as transitioning from “Can we build AI?” to “Can we run AI safely, predictably, and at scale?” said HFS Research’s Tyagi.

To that extent, Thakur drew parallels with Snowflake’s move to acquire Observe.

Both the acquisitions, the analyst said, highlight a common strategic direction across leading data platforms: pairing scalable telemetry storage with integrated observability experiences to capture a growing share of spend in operational analytics.

Seconding Thankur, Greyhound Research’s Gogia pointed out that Langfuse’s integration with ClickHouse will also help it expand its user base.

“Historically, ClickHouse served analytics and infrastructure teams. With Langfuse, it gains immediate relevance to AI engineering, prompt ops, product owners, and even risk and compliance teams. That’s a major audience expansion,” Gogia said.

Other rivals, including the likes of Databricks, too, offer observability capabilities.

Continued support for existing Langfuse customers

Other than the upside to ClickHouse, Langfuse’s existing customers are also expected to benefit from the deal.

ClickHouse plans to continue supporting Langfuse as an open source project and maintain continuity for current users, while gradually enhancing the platform through deeper integration with ClickHouse’s analytics engine and managed services, the companies said in a joint post on Langfuse’s portal.

For customers already running Langfuse in production, the acquisition is likely to add long-term stability and scale, without forcing abrupt changes to existing workflows, they added.

The startup, which is backed by Lightspeed Ventures, General Catalyst, and Y Combinator, was founded in 2023 by Clemens Rawert, Max Deichmann, and Marc Klingen. It has a team of 13 members and a second office in San Francisco dedicated to marketing and sales.

(image/jpeg; 7.73 MB)

AI coding requires developers to become better managers 19 Jan 2026, 1:00 am

No serious developer still expects AI to magically do their work for them. We’ve settled into a more pragmatic, albeit still slightly uncomfortable, consensus: AI makes a great intern, not a replacement for a senior developer. And yet, if this is true, the corollary is also true: If AI is the intern, that makes you the manager.

Unfortunately, most developers aren’t great managers.

We see this every day in how developers interact with tools like GitHub Copilot, Cursor, or ChatGPT. We toss around vague, half-baked instructions like “make the button blue” or “fix the database connection” and then act surprised when the AI hallucinates a library that has not existed since 2019 or refactors a critical authentication flow into an open security vulnerability. We blame the model. We say it is not smart enough yet.

But the problem usually is not the model’s intelligence. The problem is our lack of clarity. To get value out of these tools, we do not need better prompt engineering tricks. We need better specifications. We need to treat AI interaction less like a magic spell and more like a formal delegation process.

We need to be better managers, in other words.

The missing skill: Specification

Google Engineering Manager Addy Osmani recently published a masterclass on this exact topic, titled simply “How to write a good spec for AI agents.” It is one of the most practical blueprints I have seen for doing the job of AI manager well, and it’s a great extension on some core principles I laid out recently.

Osmani is not trying to sell you on the sci-fi future of autonomous coding. He is trying to keep your agent from wandering, forgetting, or drowning in context. His core point is simple but profound: Throwing a massive, monolithic spec at an agent often fails because context windows and the model’s attention budget get in the way.

The solution is what he calls “smart specs.” These are written to be useful to the agent, durable across sessions, and structured so the model can follow what matters most.

This is the missing skill in most “AI will 10x developers” discourse. The leverage does not come from the model. The leverage comes from the human who can translate intent into constraints and then translate output into working software. Generative AI raises the premium on being a senior engineer. It does not lower it.

From prompts to product management

If you have ever mentored a junior developer, you already know how this works. You do not simply say “Build authentication.” You lay out all the specifics: “Use OAuth, support Google and GitHub, keep session state server-side, do not touch payments, write integration tests, and document the endpoints.” You provide examples. You call out landmines. You insist on a small pull request so you can check their work.

Osmani is translating that same management discipline into an agent workflow. He suggests starting with a high-level vision, letting the model expand it into a fuller spec, and then editing that spec until it becomes the shared source of truth.

This “spec-first” approach is quickly becoming mainstream, moving from blog posts to tools. GitHub’s AI team has been advocating spec-driven development and released Spec Kit to gate agent work behind a spec, a plan, and tasks. JetBrains makes the same argument, suggesting that you need review checkpoints before the agent starts making code changes.

Even Thoughtworks’ Birgitta Böckeler has weighed in, asking an uncomfortable question that many teams are quietly dodging. She notes that spec-driven demos tend to assume the developer will do a bunch of requirements analysis work, even when the problem is unclear or large enough that product and stakeholder processes normally dominate.

Translation: If your organization already struggles to communicate requirements to humans, agents will not save you. They will amplify the confusion, just at a higher token rate.

A spec template that actually works

A good AI spec is not a request for comments (RFC). It is a tool that makes drift expensive and correctness cheap. Osmani’s recommendation is to start with a concise product brief, let the agent draft a more detailed spec, and then correct it into a living reference you can reuse across sessions. This is great, but the real value stems from the specific components you include. Based on Osmani’s work and my own observations of successful teams, a functional AI spec needs to include a few non-negotiable elements.

First, you need objectives and non-goals. It is not enough to write a paragraph for the goal. You must list what is explicitly out of scope. Non-goals prevent accidental rewrites and “helpful” scope creep where the AI decides to refactor your entire CSS framework while fixing a typo.

Second, you need context the model won’t infer. This includes architecture constraints, domain rules, security requirements, and integration points. If it matters to the business logic, you have to say it. The AI cannot guess your compliance boundaries.

Third, and perhaps most importantly, you need boundaries. You need explicit “do not touch” lists. These are the guardrails that keep the intern from deleting the production database config, committing secrets, or modifying legacy vendor directories that hold the system together.

Finally, you need acceptance criteria. What does “done” mean? This should be expressed in checks: tests, invariants, and a couple of edge cases that tend to get missed. If you are thinking that this sounds like good engineering (or even good management), you’re right. It is. We are rediscovering the discipline we had been letting slide, dressed up in new tools.

Context is a product, not a prompt

One reason developers get frustrated with agents is that we treat prompting like a one-shot activity, and it is not. It is closer to setting up a work environment. Osmani points out that large prompts often fail not only due to raw context limits but because models perform worse when you pile on too many instructions at once. Anthropic describes this same discipline as “context engineering.” You must structure background, instructions, constraints, tools, and required output so the model can reliably follow what matters most.

This shifts the developer’s job description to something like “context architects.” A developer’s value is not in knowing the syntax for a specific API call (the AI knows that better than we do), but rather in knowing which API call is relevant to the business problem and ensuring the AI knows it, too.

It is worth noting that Ethan Mollick’s post “On-boarding your AI intern” puts this in plain language. He says you have to learn where the intern is useful, where it is annoying, and where you should not delegate because the error rate is too costly. That is a fancy way of saying you need judgment. Which is another way of saying you need expertise.

The code ownership trap

There is a danger here, of course. If we offload the implementation to the AI and only focus on the spec, we risk losing touch with the reality of the software. Charity Majors, CTO of Honeycomb, has been sounding the alarm on this specific risk. She distinguishes between “code authorship” and “code ownership.” AI makes authorship cheap—near zero. But ownership (the ability to debug, maintain, and understand that code in production) is becoming expensive.

Majors argues that “when you overly rely on AI tools, when you supervise rather than doing, your own expertise decays rather rapidly.” This creates a paradox for the “developer as manager” model. To write a good spec, as Osmani advises, you need deep technical understanding. If you spend all your time writing specs and letting the AI write the code, you might slowly lose that deep technical understanding. The solution is likely a hybrid approach.

Developer Sankalp Shubham calls this “driving in lower gears.” Shubham uses the analogy of a manual transmission car. For simple, boilerplate tasks, you can shift into a high gear and let the AI drive fast (high automation, low control). But for complex, novel problems, you need to downshift. You might write the pseudocode yourself. You might write the difficult algorithm by hand and ask the AI only to write the test cases.

You remain the driver. The AI is the engine, not the chauffeur.

The future is spec-driven

The irony in all this is that many developers chose their career specifically to avoid being managers. They like code because it is deterministic. Computers do what they are told (mostly). Humans (and by extension, interns) are messy, ambiguous, and require guidance.

Now, developers’ primary tool has become messy and ambiguous.

To succeed in this new environment, developers need to develop soft skills that are actually quite hard. You need to learn how to articulate a vision clearly. You need to learn how to break complex problems into isolated, modular tasks that an AI can handle without losing context. The developers who thrive in this era won’t necessarily be the ones who can type the fastest or memorize the most standard libraries. They will be the ones who can translate business requirements into technical constraints so clearly that even a stochastic parrot cannot mess it up.

(image/jpeg; 2.76 MB)

Edge AI: The future of AI inference is smarter local compute 19 Jan 2026, 1:00 am

“The global edge AI market is on a steep upward trajectory,” says Joshua David, senior director of edge project management at Red Hat. To his point, the edge AI market is anticipated to climb to a $143 billion valuation by 2034.

The bump in edge AI goes hand in hand with a broader shift in focus from AI training, the act of preparing machine learning (ML) models with the right data, to inference, the practice of actively using models to apply knowledge or make predictions in production.

“Advancements in powerful, energy-efficient AI processors and the proliferation of IoT (internet of things) devices are also fueling this trend, enabling complex AI models to run directly on edge devices,” says Sumeet Agrawal, VP of product management at Informatica, an enterprise data management and integration company.

With that, the AI industry is entering a “new and potentially much larger phase: AI inference,” explains an article on the Morgan Stanley blog. They characterize this phase by widespread AI model adoption throughout consumer and enterprise applications.

While public clouds grant elasticity and usability, they have downsides for inference: added latency, data privacy concerns, and increased costs for processing, data ingress, and data egress.

Running AI on the edge solves many of these issues. “Edge AI provides several key benefits such as reduced latency, lower costs, enhanced security, and privacy,” says Red Hat’s David.

Amazon recently hiked prices 15% for GPUs primarily used for certain ML training jobs, signalling that cloud AI costs, particularly for centralized training, may be unpredictable. IDC predicts that by 2027, 80% of CIOs will turn to edge services from cloud providers to meet the demands of AI inference.

However, the shift won’t come without hurdles. Real-time performance demands, the large footprint of AI stacks, and a fragmented edge ecosystem remain top hurdles.

Below, we’ll look at the development progress around edge AI, explore the emerging technologies and practices for running AI on the edge, and consider how the future of computing will evolve at large in the AI age.

What’s driving edge AI growth

“The primary driver behind the edge AI boom is the critical need for real-time data processing,” says David. The ability to analyze data on the edge, rather than using centralized cloud-based AI workloads, helps direct immediate decisions at the source.

Others agree. “Interest in edge AI is experiencing massive growth,” says Informatica’s Agrawal. For him, reduced latency is a key factor, especially in industrial or automotive settings where split-second decisions are critical.

There is also the desire to feed ML models personal or proprietary context without sending such data to the cloud. “Privacy is one powerful driver,” says Johann Schleier-Smith, senior staff software engineer and AI tech lead at Temporal Technologies, provider of an open-source application platform. For heavily regulated sectors like healthcare or finance, processing such sensitive information locally becomes necessary for compliance.

“Interest in edge AI is indeed growing,” says Keith Basil, VP and GM of the edge business unit at SUSE. He points to the manufacturing sector, in which companies are exploring edge AI for various use cases, from running large servers for production lines to processing data from small sensors.

According to Rockwell Automation, 95% of manufacturers have either invested or plan to invest in AI/ML, generative AI, or causal AI in the next five years. 74% of leaders in manufacturing say AI has the potential to help them grow revenue, according to an Intel-sponsored CIO report from 2024.

The major outcome of local AI computation? Reduced cost. “This leads to significant cost and bandwidth optimization, as less data needs to be transmitted,” explains Agrawal.

Tapping the edge for certain workloads correlates with lower costs and reduced energy consumption. In a January 2025 paper published in ArXiv, Quantifying Energy and Cost Benefits of Hybrid Edge Cloud, the research determined that using hybrid edge cloud for agentic AI workloads, as opposed to pure cloud processing, can, under modeled conditions, reap energy savings of up to 75% and cost reductions exceeding 80%.

As the paper’s author, Siavash Alamouti, writes, “Edge processing directly utilizes the local context to minimize computational complexity and avoids these cloud-scale energy demands.”

The tech making local AI possible

The drivers seem clear, but what technology will it take to realize edge AI? Running AI computation on constrained edge environments will likely take a combination of smaller models, light frameworks, and optimized deployment patterns.

Smaller models

To date, most enterprises rely on large language models (LLMs) within public products, such as Anthropic’s Claude, Google’s Gemini, and OpenAI’s GPT models to centralize AI. But recent advancements in AI models are enabling localization.

Specifically, the rise of self-deployable small language models (SLMs) decreases reliance on cloud AI platforms for certain cases. “Small models are getting more powerful,” says Temporal’s Schleier-Smith. He points to OpenAI’s GPT-OSS and Hierarchical Reasoning Model as examples of recent advances.

Optimization strategies

A smaller footprint for local AI is helpful for edge devices, where resources like processing capacity and bandwidth are constrained. As such, techniques to optimize SLMs will be a key area to aid AI on the edge.

One strategy is quantization, a model compression technique that reduces model size and processing requirements. “This enables small language models to run on specialized hardware like NPUs, Google’s Edge TPU, Apple’s Neural Engine, and NVIDIA Jetson devices,” says Agrawal.

Self-contained packages could also help operationalize edge AI at scale. For Red Hat’s David, this equates to readily deployable base images that combine the OS, hardware drivers, and AI models all in one.

Edge runtimes and frameworks

New runtimes and frameworks can also help optimize edge inference. For this purpose, David highlights llama.cpp, a lightweight generative AI runtime, and frameworks like OpenVINO and LiteRT (formerly known as TensorFlow Lite) for inference using models on local hardware.

“Projects like llama.cpp, along with the GGUF model format, are enabling high-performance inference on a wide range of consumer devices,” adds Agrawal. “Similarly, MLC LLM and WebLLM are expanding possibilities for running AI directly in web browsers and on various native platforms.”

Cloud-native compatibility

There is also a big incentive for edge AI to be compatible with the cloud-native ecosystem and Kubernetes, which is increasingly deployed at the edge. For example, KServe, described as “the open-source standard for self-hosted AI,” is a framework that can aid edge inferencing on Kubernetes.

Another enabling technology is Akri, a sandbox project hosted by the Cloud Native Computing Foundation (CNCF). “Akri addresses a critical challenge at the edge: making a wide variety of dynamic and intermittently available leaf devices easily usable by Kubernetes,” SUSE’s Basil explains. By exposing IP cameras, sensors, USB devices, or other endpoints as Kubernetes resources with Akri, you could more easily deploy edge AI workloads that rely on such hardware, and monitor them in Kubernetes.

Open standards

Lastly, open industry standards will likely play a role in edge AI. “The rapidly expanding edge AI hardware and software landscape presents significant interoperability challenges,” says Basil. He believes projects like Margo, a Linux Foundation initiative, will be important for setting standards in industrial edge automation.

ONNX is another emerging standard to improve interoperability challenges among competing frameworks for on-device AI inference.

Barriers to edge AI in practice

Although the tech is available, edge practices are still emerging. It will take some effort to overcome the challenges to moving edge AI applications from a proof-of-concept stage to production reality.

“A primary limitation is the resource-constrained nature of edge devices,” says Agrawal. “Their limited memory and processing power make it difficult to deploy large, complex AI models, which often require substantial computational resources.”

Optimizing the model size for resource-constrained hardware, while still delivering the accuracy of computationally-intensive top-tier models that users have come to expect, remains another sticking point.

Practices for edge AI operation are still nascent. “A primary hurdle is the complex hardware enablement required for specialized edge devices which often don’t work out-of-the-box,” says David. For him, a lack of an end-to-end platform for deploying, monitoring, and managing models at the far edge currently forces some complex manual solutions.

“A major challenge for edge AI is the fragmented ecosystem,” adds Basil. “Unlike the standardized, mature environment of cloud computing, edge AI lacks a common framework for hardware, software, and communication protocols.” Fragmentation in the industry leads to competing device-specific software and techniques, which cause compatibility issues and custom workarounds on the edge.

Finally, managing a distributed network of AI models presents a complex logistical challenge, says Agrawal. “Securely updating, versioning, and monitoring the performance of models across countless deployed devices is a difficult task that organizations must solve to effectively scale their edge AI implementations.”

To get over some of these hurdles, experts recommend the following actions:

Adopt edge AI only where it makes sense (such as inference in low-connectivity environments).
Continually communicate business value to non-technical leadership.
Consider a hybrid cloud-edge strategy rather than fully edge or fully cloud deployments.
Abstract architectural software layers from specific hardware dependencies.
Choose models optimized for edge constraints.
Envision the full model life cycle, including updates, monitoring, and maintenance, from the outset.

From centralized to distributed intelligence

Although interest in edge AI is heating up, similar to the shift toward alternative clouds, experts don’t expect local processing to reduce reliance on centralized clouds in a meaningful way. “Edge AI will have a breakout moment, but adoption will lag that of cloud,” says Schleier-Smith.

Rather, we should expect edge AI to complement the public clouds with new edge capabilities. “Instead of replacing existing infrastructure, AI will be deployed at the edge to make it smarter, more efficient, and more responsive,” says Basil. This could equate to augmenting endpoints running legacy operating systems, or optimizing on-premises server operations, he says.

The general consensus is that edge devices will become more empowered in short order. “We will see rapid advancements in hardware, optimized models, and deployment platforms, leading to deeper integration of AI into IoT, mobile devices, and other everyday applications,” says Agrawal.

“Looking ahead, edge AI is poised for massive growth, driving a fundamental shift toward distributed, user-centric intelligence.”

(image/jpeg; 22.42 MB)

Page processed in 0.273 seconds.