News and Tech Update

Anthropic has introduced dynamic workflows in Claude Code, and the feature addresses a problem that most development teams know well: some engineering tasks are simply too large and complex for a single AI agent to handle in a single pass. With dynamic workflows, Claude Code can now write its own orchestration scripts and spin up tens to hundreds of parallel subagents within a single session. Those subagents divide the work, check each other’s findings, and hand you a single coordinated result — without requiring you to build out a full agent pipeline yourself. The feature is available today in research preview across the Claude Code CLI, Desktop and VS Code extension for Max, Team and Enterprise plans. It’s also accessible through the Claude API, Amazon Bedrock, Vertex AI and Microsoft Foundry. What it’s Built For Dynamic workflows are designed for tasks where scope is the limiting factor. Think about a bug hunt across an entire service, a migration that touches h...

Microsoft has added a new set of Model Context Protocol tools to the VS Code Marketplace, and they’re aimed squarely at developers and data engineers working with geospatial data. The Microsoft Planetary Computer Pro MCP Tools extension provides natural-language-driven access to geospatial workflows directly in Visual Studio Code — no context switching, no custom scripts, no specialized API knowledge required. The extension is now available on the VS Code Marketplace, and it marks a meaningful step in how teams interact with large-scale environmental and geospatial datasets. What It Does The extension integrates directly with GitHub Copilot in VS Code, exposing 35+ tools that connect to both Microsoft Planetary Computer and Planetary Computer Pro. Through those tools, users can perform data ingestion, STAC search, GeoCatalog management, visualization, and ingestion monitoring — all through natural language prompts. In practice, that means a developer can type a request like ...

Our latest State of Software Delivery report analyzed more than 28 million CI workflows and found a pattern that should give engineering leaders pause. Average throughput grew 59% year over year. Main branch activity for the median team declined 7%. Teams are generating more code than ever before. Less of it is reaching production. The cost of poor validation used to show up mostly in developer hours: debugging, blocked deployments, context switching. That cost hasn’t gone away. But there is a second bill now. Every failed build means agent retries. Every slow pipeline is compute burning while an agent waits. Main branch success rates have fallen to a five-year low of 70.8% against a 90% benchmark, and the AI spend attached to every failed cycle is climbing alongside it. The teams doing well are catching failures earlier and keeping their pipelines healthier. They are running the same tools as everyone else. What they have structured differently is where and when validation ha...

Most enterprise AI projects start with retrieval. You connect Jira, Confluence, SharePoint, and Slack. Maybe a few internal databases nobody has touched in five years. You tune embeddings, optimize chunking, wire up a vector database, and convince yourself you’ve built an AI-powered knowledge system. Then the model server crashes. And suddenly, you discover the uncomfortable truth about enterprise AI: The hard part was never retrieval. It was infrastructure. For the past two years, the industry has treated LLM deployment like a feature integration problem. In reality, it is rapidly becoming a platform engineering problem, one involving GPU orchestration, scaling economics, governance boundaries, workload scheduling, observability, and operational resilience. The moment organizations move beyond prototypes, the conversation changes fast.   Search Was Never the Product Enterprise search already exists. Most organizations have had it for years. But what teams actually want is synthe...

Over the past year, AI has fundamentally changed how software is written. Infrastructure code is no exception. Tasks that once required deep familiarity with tools, syntax, and workflows can now be handled through natural language. Engineers are no longer starting from a blank file. In many cases, reviewing and modifying code generated for them has become the norm. At a high level, this looks like progress, and in many ways, it is. Teams can move faster, the barrier to entry is lower, and experimentation is easier. But there is a growing gap that many organizations are only beginning to recognize: AI is accelerating how infrastructure is created, but it is not solving how infrastructure is understood, controlled, or governed. The Shift from Writing to Generating Traditionally, infrastructure as code assumed that the person writing the configuration understood what it would do. That assumption no longer holds. Today, it is increasingly common for infrastructure definitions to be gen...

You built the agent. It works in testing. Then it hits production and starts giving wrong answers, timing out or burning through your token budget, and you have no idea why. This is when developers discover that print statements and log files weren’t designed for this.    LLM applications fail in ways that traditional tooling can’t see. A hallucination doesn’t throw an exception. A slow retrieval step doesn’t show up in CPU metrics. A prompt that worked yesterday silently degrades today.   The fix is observability, and the standard for doing it right is OpenTelemetry (OTel).   What OpenTelemetry Actually Is   OTel isn’t a monitoring product; it’s a vendor-neutral specification under the CNCF that defines a standard way to collect observability data: What gets collected, what it’s called and how it’s shipped. You instrument your application once and can send that data to Grafana, Datadog, Jaeger or a purpose-built LLM platform without rewriting your instrumentation.   That portabil...