6 posts tagged with "Architecture"

A team of eight engineers has wired AI coding agents into their development pipeline. The agents take tickets off the top of the queue and ship pull requests faster than humans can review them. Six months in, the dashboards look enviable. Test coverage sits at 84%. The p99 latency on every changed endpoint stays under 100 ms. Merge throughput is up 3× since the agents went live. The Friday retrospective is short, because there is little to retrospect on.

Then a competitor ships a feature. It is not a clever feature. Their users had been asking for it on a public forum for six months, and the team's own users had been asking for it on the team's own forum for almost as long. No one on the team noticed. The competitor's launch lands in Slack on a Tuesday, and the room goes quiet, because everyone is asking the same question at once: which part of our system was supposed to catch this?

The honest answer is: no part. Not because someone forgot to build it, but because the team's architecture vocabulary has no word for it.

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."

Introduction​

Complexity is an eternal challenge in software engineering. As project scale grows, complexity increases exponentially, and if left uncontrolled, it can ultimately lead to project failure.

In the world of software development, complexity is everywhere. From simple "Hello World" programs to large-scale distributed systems, complexity always accompanies our development process. As software architects and technical leaders, understanding the nature of complexity, its sources, and how to manage it is a core skill we must master.

Introduction​

"Architecture is about the important stuff... whatever it is." -- Ralph Johnson

Architect is a position with powerfulness and respect. When you hear that someone is an architect of a company, will you feel a sense of awe? Architects are usually believed to be relevant to system design, technical strength, leadership and influence. It is precisely for this reason that many of the positions of architects in the enterprise are held by experienced and skilled senior software engineers. However, the definition of an architect in the software industry is not quite clear: cloud service providers such as Amazon and Alibaba Cloud have their own teams of architects, but most of them provide after-sales service to customers under the name "architect"; Some architects are nothing more than using his rich experience and excellent strength to solve technical problems, which is equivalent to what a senior software engineer can do. These are very different from the omniscient architect who designs the architecture diagram.

The concepts related to architects in this article mainly come from a book Fundamentals of Software Architecture (authored by Mark Richards, Neal Ford) that I have been reading recently. This article will briefly introduce about what a pragmatic architect should do and required skills.

Chief Engineer​

First of all, an architect should be a chief engineer of the entire software project, who is responsible for the overall design, implementation and quality of the software project. Therefore, for software architects, they need to have excellent programming skills, good understanding of the software project development process, and a certain breadth and depth in various technical areas. Not only that, because the architect is the chief person in charge of the technology side, he (or she) usually needs to think it through, from a perspective of the system as a whole, about how the various modules interact, whether the division of functional services is reasonable, where the bottleneck of the whole system will be, and so on. These are all in the technical area.