30 posts tagged with "AI"

On March 11, 2025, Anders Hejlsberg published a post titled A 10x Faster TypeScript: Microsoft was porting the TypeScript compiler to Go.

For most readers this was performance news. For me it was three old blog posts colliding. In 2021 I wrote, within the space of a few months, a piece asking whether Go was really a panacea for backend development, a piece arguing that TypeScript was indispensable for large frontend projects, and a piece praising C#'s developer experience — where I pointed out, almost as trivia, that TypeScript and C# share the same creator. Five years later, all three protagonists converged in a single repository: the compiler of the language I called indispensable, rewritten in the language I interrogated, led by the man who fathered both TypeScript and C#. I knew those articles were connected. I did not expect the connection to close like this.

The collision is worth more than nostalgia, because it exposes what has changed underneath the argument. In 2021, we debated which language was better for humans: which syntax was cleaner, which learning curve was gentler, which type system annoyed you least. The debate never ended. But the referee changed. Since then, AI coding agents have become some of the highest-frequency authors — and the very first readers — of production code. An agent does not care that Go's error handling is tedious or that TypeScript's annotations are verbose. It cares about two things: how fast it gets feedback, and whether that feedback can be trusted.

That observation is the candidate thesis of this article, stated deliberately in its modest form: when agents join the authorship of your codebase, two criteria get promoted to first class in stack selection — agent loop latency (how long one edit-to-trusted-feedback cycle takes) and the density of machine-decidable verification signals (how much of your correctness can be checked automatically, deterministically, per cycle). These criteria do not replace the human ones. They re-rank them. And under the new ranking, some of 2021's verdicts get crowned while others get overturned.

To make that case honestly, I will first excavate what we actually argued about in 2021, then define the two new criteria precisely, then examine three bodies of evidence from 2025–2026, then give the strongest counterarguments their own section, and finally propose a small selection framework you can disagree with productively.

The AWS Summit in Shanghai, 23–24 June 2026.

In June 2026, I gave what was almost certainly the least glamorous talk at the AWS Summit in Shanghai. I opened with a disclaimer: our Nova is not the Nova from Amazon. The Nova on my slides is an internal platform my team builds at HP; the Nova everyone else kept name-dropping is Amazon's frontier model. The room laughed at the collision — and then I spent the session on something no keynote would touch: how we moved a reporting stack off Power BI and onto Amazon Athena and Apache Iceberg. It was a thirty-minute, 300-level breakout, upstairs on the sixth floor, well away from the crowds.

The floor guide: breakout talks — mine among them — on the sixth floor, the keynote on the fifth, the expo downstairs.

Down on the ground floor, the expo hall was selling the opposite of unglamorous. Unitree humanoids reached for objects under hot lights. A dexterous robotic hand, priced at ¥9,999, flashed a peace sign for the cameras. On one screen, a swarm of coding agents shipped software with no human in the loop; on another, an AI turned footage of a football match into tactics and player metrics. The spotlight was on intelligence learning to perceive the world, to make things, and to act in it.

Down on the ground floor: the expo, where the crowds were.

That contrast is the argument of this piece. For two centuries, output scaled with headcount: more work meant more hands. AI is breaking that link — output is starting to scale with infrastructure (models, compute, and data) rather than people. This is the industrialization of intelligence, and like the first industrial revolution, it will be won not by whoever owns the flashiest machine but by whoever builds the floor those machines stand on. My boring migration is the proof in miniature: what made our reports better was not a smarter model but a new foundation underneath them — a refresh that once took four to six hours now finishes in one, and a report you could once only read became data anyone can now question in plain language.

So this article works from the floor up. First, the three frontiers the show floor was celebrating — machines that perceive, create, and act. Then the layer beneath all three, the one I went to Shanghai to talk about: the data foundation that decides how high any of them can climb.

Every AI keynote in 2026 opens with the same three slides: a bigger model, a faster chip, a smarter agent. The fourth slide — the one about how any of that actually reaches a user in production — is usually missing. That missing slide is where the next decade of value will be created, and it will not be created by another round of model fine-tuning. It will be created by the most unglamorous layer in our stack: infrastructure.

The numbers back the hunch. MIT's 2025 "State of AI in Business" report found that 95% of generative-AI pilots fail to reach production. Gartner found that only 15% of IT application leaders are even piloting fully autonomous agents, despite the agent market projected to grow from $7.8B in 2025 to $52.6B by 2030. The bottleneck is not intelligence. Frontier models cluster around 70–75% on SWE-bench Verified. The bottleneck is everything between a model that can write code and an organization that can ship it — and that everything is infrastructure.

Here is the hot take, stated plainly: as coding gets cheap, infrastructure gets scarce. The DevOps, CI/CD, container, Kubernetes, and cloud-architecture knowledge that the AI narrative treats as "solved plumbing" is about to become the single biggest lever for turning AI capability into shipped product. The reason is simple. Agents can now write code. They cannot, by themselves, run a build, own a deploy, route a rollback, or provision a region. They need a substrate that does those things for them — and that substrate is the accumulated, low-cost, battle-tested output of two decades of DevOps work.

Six protocols. Six automation levels. Seventeen tools. Twelve predictions. One interactive map that ties them all together.

The AI Agent Interaction Landscape is an open-source, bilingual SPA I built to make sense of how AI agents interact with developers, editors, tools, and each other in 2026. This article walks through the key frameworks it introduces—and the insights that emerged from building it.

When SWE-bench scores improved 50% in just 14 months—from Claude 3.5 Sonnet's 49% in October 2024 to Claude 4.5 Opus's 74.4% in January 2026—you'd think AI agents had conquered software engineering. Yet companies deploying these agents at scale tell a different story. Triple Whale's CEO described their production journey: "GPT-5.2 unlocked a complete architecture shift for us. We collapsed a fragile, multi-agent system into a single mega-agent with 20+ tools... The mega-agent is faster, smarter, and 100x easier to maintain."

Earlier this year, I was amazed by agentic AI coding with Claude Sonnet 3.7. The term "vibe coding" hadn't been coined yet, but that's exactly what I was doing—letting AI generate code while I steered the conversation. It felt magical. Until it didn't.

After a few weeks, I noticed patterns: code redundancy creeping in, intentions drifting from my original vision, and increasing rework as the AI forgot context between sessions. The honeymoon was over. I needed structure, but not the heavyweight processes that would kill the speed I'd gained.

Introduction: The Industrial Revolution of AI-Assisted Development​

25% of Y Combinator's 2025 cohort now ships codebases that are 95% AI-generated. The difference between those who succeed and those who drown in technical debt? Specifications. While "vibe coding"—the ad-hoc, prompt-driven approach to AI development—might produce impressive demos, it falls apart at production scale. Context loss, architectural drift, and maintainability nightmares plague teams that treat AI assistants like enhanced search engines.

2025 marks the tipping point. What started as experimental tooling has matured into production-ready frameworks backed by both open-source momentum and substantial enterprise investment. GitHub's Spec Kit has become the de facto standard for open-source SDD adoption. Amazon launched Kiro, an IDE with SDD built into its core. Tessl, founded by Snyk's creator, raised $125M at a $500M+ valuation to pioneer "spec-as-source" development. The industry signal is clear: systematic specification-driven development (SDD) isn't optional anymore—it's becoming table stakes for AI-augmented engineering.

If you're a technical lead evaluating how to harness AI development without sacrificing code quality, this comprehensive guide maps the entire SDD landscape. You'll understand the ecosystem of 6 major tools and frameworks, learn industry best practices from real production deployments, and get actionable frameworks for choosing and implementing the right approach for your team.

The first time an AI system disagreed with my architectural decision and turned out to be right, I realized something fundamental had changed—not about AI, but about what leadership means. This wasn't a story about better technology; it was about how my role as a leader needed to evolve. The skills that made me effective in leading human teams weren't suddenly obsolete, but they required significant adaptation when AI became part of the equation.

If you're a tech leader today, you've likely felt this tension. As research shows, AI's impact on productivity is real but nuanced—it's not a silver bullet that solves all problems automatically. You know the traditional leadership skills that matter: technical depth, business domain knowledge, interpersonal skills, and political navigation. These haven't disappeared. But AI introduces a new dimension where these skills must expand and adapt. You're no longer just leading people or directing tools; you're orchestrating a hybrid environment where human judgment, traditional management wisdom, and AI capabilities need to work in harmony.

Introduction: The Impossible Dream of Perfect Testing​

"Testing shows the presence, not the absence of bugs." When Dutch computer scientist Edsger Dijkstra made this observation in 1970, he was articulating a fundamental truth about software testing that remains relevant today. Yet despite this wisdom, the software industry continues to pursue an elusive goal: comprehensive automated testing that can guarantee software correctness.

If you're a developer who has ever wondered why achieving 100% test coverage still doesn't guarantee bug-free code, or why your carefully crafted test suite occasionally misses critical issues, you're confronting a deeper reality. The limitations of automated testing aren't merely engineering challenges to be overcome with better tools or techniques—they're rooted in fundamental mathematical impossibilities.

The current wave of AI-powered testing tools promises to revolutionize quality assurance. Marketing materials tout intelligent test generation, autonomous bug detection, and unprecedented coverage. While these tools offer genuine improvements, they cannot escape a theoretical constraint established over seventy years ago by mathematician Henry Gordon Rice. His theorem proves that certain questions about program behavior simply cannot be answered algorithmically, regardless of computational power or ingenuity.

This isn't a pessimistic view—it's a realistic one. Understanding why complete test automation is mathematically impossible helps us make better decisions about where to invest testing efforts and how to leverage modern tools effectively. Rather than chasing an unattainable goal of perfect automation, we can adopt pragmatic approaches that acknowledge these limits while maximizing practical effectiveness.

This article explores Rice's Theorem and its profound implications for software testing. We'll examine what this mathematical result actually proves, understand how it constrains automated testing, and discover how combining formal specifications with AI-driven test generation offers a practical path forward. You'll learn why knowing the boundaries of what's possible makes you a more effective engineer, not a defeated one.

The journey ahead takes us from theoretical computer science to everyday development practices, showing how deep principles inform better engineering. Whether you're writing unit tests, designing test strategies, or evaluating new testing tools, understanding these fundamentals will sharpen your judgment and improve your results.

Picture this: It's Monday morning, and you're sitting in yet another meeting about why your company's LLM application can't seem to move beyond the demo stage. Your team has built a sophisticated GPT-4o-powered agent that handles complex customer inquiries, orchestrates with internal systems through function calls, and even manages multi-step workflows with impressive intelligence. Leadership is excited, budget approved. But six months later, you're still trapped in what industry veterans call "demo purgatory"—that endless cycle of promising LLM applications that never quite achieve reliable production deployment.

If this scenario sounds familiar, you're not alone. Whether organizations are building with hosted APIs like GPT-4o, Claude Sonnet 4, and Gemini 2.5 Pro, or deploying self-hosted models like DeepSeek-R1, QwQ, Gemma 3, and Phi 4, the vast majority struggle to move beyond experimental pilots. Recent research shows that AI's productivity benefits are highly contextual, with structured approaches significantly outperforming ad-hoc usage. The bottleneck isn't the sophistication of your LLM integration, the choice between hosted versus self-hosted models, or the talent of your AI development team. It's something more fundamental: the data foundation underlying your LLM applications.

The uncomfortable truth is this: Whether you're using GPT-4o APIs or self-hosted DeepSeek-R1, the real challenge isn't model selection—it's feeding these models the right data at the right time. Your sophisticated AI agent is only as intelligent as your data infrastructure allows it to be.

If you've ever tried to transform an impressive AI demo into a production system only to hit a wall of fragmented systems, inconsistent APIs, missing lineage, and unreliable retrieval—this article is for you. We argue that successful enterprise LLM applications are built on robust data infrastructure, not just clever prompting or agent frameworks.

Here's what we'll cover: how data accessibility challenges constrain even the most capable models, the infrastructure patterns that enable reliable tool use and context management, governance frameworks designed for LLM-specific risks, and concrete implementation strategies for building production-ready systems that scale.

The solution isn't better prompts or bigger models—it's better data foundations. Let's start with why.