标签：#Architecture

Cursor's Developer Habits Report is one of the clearest signals yet that AI coding has crossed from individual productivity into software-delivery infrastructure. The headline numbers read as a story about speed: more code per week, larger PRs, deeper agent sessions, more changes committing without manual review. The deeper implication is governance -- whether teams can preserve architectural intent while generation, review, automation, and commit flows all accelerate at once. The velocity curve is now measured, not anecdotal. For two years the claim that AI coding is accelerating rested mostly on vibes and vendor decks. Cursor's data turns it into telemetry. And read as an operations document rather than a marketing one, that telemetry describes a structural shift: software delivery is getting harder to govern, not just faster to produce. This is not a critique of Cursor. The report is strong validation. Cursor proves the velocity curve with numbers most of the industry only gestured at. The point of this essay is what sits on the other side of that curve. What the Cursor Developer Habits Report Shows The inaugural Cursor Developer Habits Report (Spring 2026 edition), published by Cursor (Anysphere, Inc.), draws on Cursor usage data rather than survey responses. It captures the transformation across five themes -- developer acceleration, the economics of intelligence, the power user gap, the rise of context, and the shift to automation. The headline figures: 3.6K -> 8.6K lines added per developer per week -- the per-developer code volume rose from 3.6K (Jan 2025) to 8.6K (May 2026), with growth accelerating since the start of 2026. 125.86 -> 345.02 lines per PR at p75 -- lines added per pull request at the 75th percentile rose roughly 2.5x year over year (Jan 2025 to May 2026). Developers are taking on larger units of work in a single PR. 8% -> 13.8% mega PRs -- the share of PRs with at least 1,000 changed lines grew from 8% (Jan 2025) to 13.8% (May 2026). ~30% mor

Microsoft's Agentic Transformation Patterns Playbook is a useful signal because it does not treat AI agents as another productivity tool. It frames agentic AI as an enterprise operating-model shift: agents are moving from assisting humans to executing work across processes, systems, and teams. The implication for software teams is sharper than it looks -- coding agents are on the same trajectory, and architectural governance becomes part of the infrastructure stack the moment agents start executing. Microsoft's playbook describes six transformation patterns and emphasizes that each pattern requires different ownership, governance, and operating discipline. That is the move worth paying attention to. It reframes agentic AI from a model question into an enterprise operating-model question. That shift matters for software teams because coding agents are following the same path. They are moving from autocomplete to execution. Once agents edit files, open PRs, modify infrastructure, or coordinate multi-step changes, architectural governance becomes infrastructure. What is Microsoft's Agentic Transformation Playbook? Microsoft's playbook is a practical guide for choosing, scaling, and operating AI agents across the enterprise. Public summaries describe it as a 52-slide guide covering six transformation patterns, from employee productivity to core business processes and customer-facing agents. The throughline is that agents are not a single category -- they are a family of patterns with different ownership models, different risk surfaces, and different requirements for governance. That framing matters because it cuts against the dominant adoption narrative. Most enterprises are still treating AI as a per-team productivity story: this team gets Copilot, that team gets an internal assistant, another team is piloting an agent for support tickets. Microsoft is arguing that the pattern of deployment determines the operating discipline required, and that ad-hoc deployment does n

Google's Managed Agents announcement is one of the clearest signals yet that the AI industry is moving beyond stateless tool calling toward persistent execution environments and long-running agent systems. That shift expands what models can do. It also expands the governance surface -- from prompt and PR review into the runtime itself. We spent two years building brains in jars For most of the current AI cycle, the system around the model has been thin. Models could reason, propose commands, and orchestrate small tool calls. But they ran in short sessions, against narrow APIs, under human supervision, with ephemeral state. The model was a brain; the body was a few HTTP requests and a JSON tool schema. That assumption is ending. The frontier is not just better reasoning. It is a body for the brain. The brain finally has a body. Now it needs governance. The runtime layer for AI agents is arriving Google Managed Agents (and the parallel motion across the ecosystem -- OpenAI's containerized execution work, Claude Code's persistent sessions, MCP-based tool ecosystems, hosted agent harnesses) formalizes the runtime as a product: Sandboxed execution Persistent state across sessions Orchestration loops Infrastructure-native agents Agent-as-a-service lifecycle Long-running sessions Mid-session tool injection Managed runtime lifecycle This resembles the transition from scripts -> applications -> cloud platforms. Agents are no longer just calling tools. They are beginning to inhabit programmable environments . Why persistent agent systems change governance Once agents can continuously modify filesystems, maintain state across sessions, autonomously remediate, inject tools dynamically, operate against production systems, and coordinate across workflows, governance failures stop being one-off review misses. They compound over time . What that compounding looks like: Architectural drift -- small deviations accumulate across long-running sessions Policy propagation failures -- con

The Faros AI Engineering Report 2026 is not a survey of developer sentiment. It is two years of telemetry from 22,000 developers across 4,000 teams, measuring what AI adoption actually produces downstream. The findings have a name: the Acceleration Whiplash. The structural explanation has one too. What the telemetry actually shows The output numbers in the Faros report are real and worth stating plainly. Epics completed per developer are up 66.2%. Task throughput per developer is up 33.7%. PR merge rate per developer is up 16.2%. These represent genuine delivery acceleration, and dismissing them would be dishonest. AI coding tools are producing real productivity gains at the business level. The production quality numbers are also real: Metric Change Incidents per PR under high AI adoption +242.7% Median time in code review +441.5% Code churn (lines deleted to lines added) +861% PRs merged with no review at all 31.3% Source: Faros AI Engineering Report 2026: The Acceleration Whiplash . Telemetry from 22,000 developers across 4,000+ teams. Figures represent metric change from lowest to highest AI adoption periods within each organization. Both sets of numbers are true simultaneously. That is the whiplash. Throughput accelerated. The downstream systems built to validate that throughput did not. Plotted together, generation throughput rises steeply while control capacity stays nearly flat -- and the gap between the two curves is the governance debt. Why the systems did not scale Code review, incident response, and architectural validation were all designed for a world where development velocity was human-paced. A senior engineer could review the meaningful PRs in a sprint. An incident postmortem could trace a failure to a specific change and a specific decision gap. Architectural drift was visible because it moved slowly enough to catch. AI-generated code broke these assumptions quietly. Not because the code was obviously bad, but because it was often superficially conv

Most API teams treat the contract as an afterthought: write code, generate a spec, then watch the two drift apart. Git-native API design reverses that flow. You treat the API contract as source code, version it in Git, and review every change the same way you review application logic. Try Apidog today This guide focuses on implementation discipline, not a single tool. You’ll design contracts in branches, review them in pull requests, and turn a committed spec into mocks, tests, and docs. The goal is simple: your Git history should also be your API history. If you already know what Spec-First tooling looks like and want the product walkthrough, read the companion piece on the git-native API workflow . This article stays focused on practice. What “git-native” means for API work Git-native means your API definition lives in your repository as a plain text file. Not in a proprietary cloud database. Not behind a vendor login. A .yaml or .json file sits next to your code and is tracked by the same version control system your team already uses. In many cloud-locked API design tools, the contract lives in the vendor’s backend. You edit through a web UI, and your repository only contains an export. That export can become stale, and your Git history no longer explains how the API evolved. The git-native model inverts that relationship: The file in main is the contract. Any GUI is a view onto that file. Branches, commits, pull requests, blame, and rollback all apply to your API surface. Mocks, docs, tests, and generated clients derive from the committed spec. A git-native setup has three core properties: The spec is a text file in the repo. Changes flow through normal Git operations: branch, commit, PR, merge. Downstream artifacts derive from the committed file, not from a separate database. Why design and develop APIs in Git You already trust Git with your code. Your API contract deserves the same treatment. 1. History When someone asks, “When did we add the cursor pagination

TL;DR Day 2 of AI Native DevCon shifted from agent capability to operating discipline. The strongest sessions focused on how teams can run AI-native delivery with clearer context pipelines, measurable agent behavior, safer execution boundaries, and better organizational ownership. The scale showed up in the numbers too. Across the two days, DevCon brought together 650+ in-person registrations, around 2,000 online registrations, and a packed mix of sessions, workshops, hallway conversations, and practical lessons. Day 2 leaned into workshops. That shift mattered because the second day was less about proving agents can do useful work and more about showing how teams can make that work repeatable. Hey there, welcome back. Rohan Sharma here again continuing the devcon series. Day 1 gave us the framing, including Guy Podjarny ’s core point that skills should be treated like real software assets. Day 2 picked up from there and moved into the operating details. Once agents are inside daily engineering work, platform and product teams need to decide what changes first, who owns those changes, and how the results are measured. Talks that shaped Day 2 Harness engineering beyond code Marc Sloan from Tessl focused on the next gap many teams are hitting. Code context is increasingly structured, but product and design context still lives in external systems such as Figma, Notion, and Linear. Pulling that context live can reduce staleness, but it introduces drift in evals, versioning, and reproducibility. The practical lesson was to stop treating external product and design context as random reference material. Teams need a defined layer between the repository and those external systems, with clear versioning so evaluations can be replayed against known context snapshots. Without that, agents can produce work that looks technically correct while missing the product constraint that actually mattered. That is a very expensive kind of almost-right. From vibes to metrics Simon Obstbau

pluckmd exists so an agent can pull blog posts into markdown, index them into a wiki, and generate interactive HTML to learn from. This post is about the first step, the part with no per-site code, because the design is the interesting bit. If you want the practical side, how I actually use it day to day, I wrote that up separately: https://dev.to/taisei_ide/how-i-use-pluckmd-to-read-blogs-with-an-ai-agent-1jpe It downloads articles from a blog without any per-site code. No handler for Medium, no handler for Substack, nothing keyed on a domain. Here's how that works. The core idea: treat extraction as data, not code. AdapterSpec Instead of branching on which site you're on, pluckmd resolves an AdapterSpec . It's a plain object that says which selector finds article links, what the URL pattern looks like, and how pagination behaves. interface AdapterSpec { listing : ListingExtractionSpec ; // how to find article links article : ArticleExtractionSpec ; // how to pull the body pagination : PaginationSpec ; // none | scroll | button-click | next-url | auto evidence : string ; } Because it's data, the same shape can come from a heuristic, an LLM, an agent, or a person typing it by hand. They all produce the same thing, and they all go through the same checks. Resolving it, cheapest path first cache -> heuristics (local, free) -> LLM (only if needed) Cache first, rechecked against today's DOM so a stale entry can't sneak through. Then local heuristics. The LLM only gets called when the heuristics aren't sure. Every result that works gets written back, so the second run on a site is basically instant. How the heuristics find an article list This part has no idea what site it's looking at. It takes every link, normalizes the path, and collapses the parts that vary into wildcards. / blog / my - first - post -> / blog /* / blog / another - article -> / blog /* / about -> / about Group by that shape. Any group with the same pattern repeated three or more times is a candidate f

Welcome to another post in the "Under the Hood" series. The power of Redis lies in its simplicity. One thread, one event loop, zero locks . Single-threaded execution eliminates the "lock contention" that slows down traditional databases. Limitation : A single process can only utilise one CPU core. On a 64-core server, 98% of your hardware sits idle. Redis Core Design To scale, Redis Enterprise doesn't make the engine "bigger"; it makes the fleet smarter. Key Design Decisions One Core to Many (Multi-Tenancy) Instead of one massive process, Enterprise runs multiple Redis Cores (shards) on a single node. From Gossip to Proxy Standard Redis Clusters use a Gossip Protocol. The client must "know" the cluster topology and handle redirections. Solution : The Zero-Latency Proxy acts as the "Front Desk". The client talks to one endpoint; the proxy handles the complexity. It is multi-threaded and uses cut-through routing to ensure the "hop" is sub-millisecond. Separation of Concerns (Control Plane) Distributed Cluster Watchdogs oversees failovers and promotions. By separating the Data Path (Redis shards) from the Control Plane (watchdogs), the database can heal itself without interrupting traffic. Note : In the diagram, it may seem the watchdogs are coupled with the Redis shards, but in reality, they just share the hardware space for resource efficiency. Redis Cluster Architecture

Building a Thriving Package Marketplace: The Complete MarketHub Guide Introduction If you're building a platform where developers can discover, share, and monetize packages, you're tackling one of the most complex problems in the software ecosystem. From managing publisher reputations to handling analytics at scale, marketplace dynamics require careful orchestration across multiple user roles. Enter MarketHub — a comprehensive three-app marketplace system designed to handle exactly this challenge. Whether you're creating a plugin ecosystem, SaaS integrations hub, or package distribution platform, MarketHub provides a battle-tested architecture for managing the complete marketplace lifecycle. The Problem: Why Marketplaces Are Hard Building a marketplace isn't just about creating a catalog. You need to solve several interconnected problems simultaneously: Discovery : How do users find quality packages in a sea of options? Trust : How do you build confidence in unfamiliar publishers? Quality Control : How do you maintain standards without stifling innovation? Incentives : How do you motivate publishers to create excellent packages? Scale : How do you manage analytics, reputation, and community as the ecosystem grows? Most teams try to bolt these features onto a basic catalog — resulting in fragmented systems where reputation tracking doesn't align with analytics, and community features feel disconnected from the review process. MarketHub Architecture: A Three-App Approach MarketHub solves this by separating concerns into three distinct applications, each optimized for its audience: 1. Public Discovery App — The Storefront This is where users find packages. The discovery app features: Intelligent Search & Filtering : Search across package names, descriptions, and tags with category-based filtering Featured Packages : Curated collections to highlight quality and trending packages Smart Ranking Algorithm : Packages rank based on quality signals — not just download counts

There are only 3 LLM API protocols, but unlimited providers running the same protocol. Separate protocol from identity — protocol is code, provider is data — and complexity drops from N×M to N+M. 300 lines of TypeScript. Zero dependencies. The problem isn't "it doesn't work." It's "it won't tell you it broke." In May, I built a Claude Code skill called unblind . I use DeepSeek as my daily driver, but it can't see images. So unblind forwards images to Mimo and OpenAI's vision APIs. The MVP had two providers. A few dozen lines of if-else. It worked. Then I noticed something more unsettling: an expired API key — no warning. A network hiccup — no retry. A missing permission — silently skipped. This tool didn't fail. It quietly stopped working without telling you. I added Phase 0 self-healing, circuit breakers, persistent caching, and a security sandbox. Now unblind wouldn't fail silently. But then I noticed something else. The circuit breaker doesn't care if you're calling a vision API or a translation API. The cache doesn't care if the response is an image description or OCR text. The error normalization doesn't care whether the other end is Mimo or OpenAI. A universal provider infrastructure, trapped inside a vision skill. First attempt: follow the ecosystem, hit the ceiling The largest similar project in the ecosystem is vision-support, with 19 providers. The pattern is standard—base class + subclasses, GoF Template Method. I followed it for v2.0. class BaseProvider { async analyzeImage ({ image , prompt , options }) { const { url , body , headers } = this . _buildRequest ( image , prompt , options ); const res = await apiRequest ( url , { body , headers }); return { content : await this . _parseResponse ( res ), model : this . _model }; } } class MimoProvider extends BaseProvider { ... } // 54 lines class OpenAIProvider extends BaseProvider { ... } // 45 lines class GeminiProvider extends BaseProvider { ... } // ~50 lines One subclass per provider. I expanded unblin

At Twio we picked pg-boss for our job queue, ran into trouble when we went serverless, looked at Pub/Sub, and ended up on Google Cloud Tasks. This is what each queue got right, what it got wrong for our workload, and the rule we landed on for choosing between them. The workload Twio is an AI SaaS for loan brokers. The piece that needs a job queue is email processing: download an email, parse the body and attachments, OCR, classify with an LLM, write structured data, and index for RAG. One email with five attachments easily becomes 30+ background jobs. A batch upload becomes hundreds. Why pg-boss worked — until it didn't Our database was Postgres on Neon, so pg-boss was the obvious starting point. No extra infrastructure, and one feature we genuinely loved: transactional enqueue . Because jobs live in the same database as business data, you can create a job in the same transaction as the row that triggered it. No dual-write problem, no "DB succeeded but the queue API failed" inconsistency. It also gave us retries, delayed jobs, dead-letter queues, dedup keys, and full SQL visibility into stuck or failed jobs. For a Postgres-first app on always-on infra, it's an excellent tool. Then we moved heavy processing to Cloud Run, and the cracks showed up. pg-boss polls. Neon suspends. They want opposite things. pg-boss runs a query roughly every 1–2 seconds to look for the next job, plus maintenance queries. Neon autosuspends compute when nothing touches the database. If the queue is polling every second, Neon's idle timer never expires — you pay for always-on compute even when the queue is empty. Worse, when Neon did manage to suspend, the next poll had to wake it. That wake-up takes hundreds of ms to a few seconds, and queries that triggered it would fail with Connection terminated , ECONNRESET , or timeouts. Pooled connections made it worse: the pool kept sockets that the server had already closed during suspend, and the next polling cycle picked one up and broke. This isn

TL;DR Day 1 of AI Native DevCon was a practical reality check for AI-native software...

Introduction In contemporary research, the volume of biological data deposited in public repositories is growing exponentially. The Gene Expression Omnibus (GEO), NCBI Gene, PubMed, and UniProt accumulate thousands of new records daily, including sequences, expression profiles, scientific articles, and functional annotations. On the one hand, this scenario represents a unique opportunity for biomedical research. On the other hand, the diversity of data formats, access protocols, and metadata models creates a significant barrier: each source requires a specific collector, distinct rate-limiting strategies, and its own validation logic. Above all, the lack of standardization in data storage compromises the reproducibility of scientific studies. The need for integrated tools capable of unifying data extraction, curation, and persistence has been widely discussed. In practice, ad hoc solutions such as isolated scripts for individual repositories generate redundant work and make maintenance difficult. First and foremost, it is necessary to establish an architecture that treats data collection as a service rather than a collection of scattered artifacts. This work presents Project 1 of the Integrated Bioinformatics Platform: a containerized Biomedical Data Collector coupled with a Data Lake. Its objective is to provide a REST API capable of triggering asynchronous data collections from the four aforementioned sources, storing immutable raw data in MinIO, and persisting metadata in PostgreSQL, all while ensuring traceability and resilience. Development The system architecture is divided into three main layers. The first is the API and orchestration layer , implemented using FastAPI. Its five endpoints — POST /collections , GET /collections , GET /collections/{id} , GET /collections/{id}/download/{dataset_id} , and GET /health — expose a clean interface for initiating and monitoring collection processes. The second layer is the collector engine , composed of abstract classe

Shopify Staff Engineer Guilherme Carreiro discusses building and scaling highly customizable platforms. Using Shopify’s Liquid theme system as a case study, he explains how to balance extreme design flexibility with low-latency performance under massive traffic. He shares insights on implementing secure domain-specific languages, native code extensions, and resilient developer tooling. By Guilherme Carreiro

Michael Stiefel spoke to Sonya Natanzon, about the intersection of technical and social aspects of software architecture. Understanding the business and how a company operates is more important than the specific technologies used. Effective requirements analysis requires focusing on problems to be solved that describe good and bad outcomes, rather than statements of need or solution statements. By Sonya Natanzon

I run Sola, a travel app for people who move differently from the traveller the industry was built for. While building it, I kept hitting the same wall. The data I wanted to query did not exist. Not because nobody collected it, but because the schema underneath the whole industry never had a field for it. So on 27 May 2026 I sat down and audited Booking.com. The homepage form, the currency selector, a Bangkok search results page. I wrote down what it accepts and what it refuses. Then I looked at the new AI travel agents shipping on top of it. Here is what I found, and why it matters to anyone building in this space right now. The form is the spec Booking.com's homepage search bar accepts exactly four inputs: A destination, as a single text field A check-in date and check-out date, as one range An occupancy counter, defaulting to "2 adults · 0 children · 1 room" A search button That is the spec. An online travel agency (OTA) is a CRUD app over this spec, and Expedia, Agoda, and Hotels.com run the same four fields. Airbnb lets you skip the dates. The destination stays a single field everywhere. Think about what a spec encodes. The default occupancy is a couple. Not a solo traveller, not a parent with one child, not three generations, not seven people eating from one host's kitchen. The form cannot accept a circuit ("Bangkok, then Hanoi, then Jakarta" forces three separate searches). It cannot accept an open date ("October, not sure which week"). It has no field for the part of a trip where you sleep at family but spend money in restaurants. When you fill that form, you have not searched. You have submitted to a schema. Most of the world's travellers fail the schema before they fail the search. The data receipts I am a builder, so I went for counts, not adjectives. Everything below rendered on the platform on 27 May 2026. Currencies: 52 offered, about 180 in circulation. Eight currencies sit featured at the top of the dropdown. On the day I ran it the order was EUR, US

You've seen the developer. Maybe you are the developer. They discover DRY — ✨ Don't Repeat Yourself...

Stepping up to give my first-ever presentation at UbuCon 2026 was a massive milestone, and honestly, it was pretty intimidating. The stakes felt high, especially with the live demo. It was a race against the clock to get everything running, and it only finally came together exactly ten minutes before I went on stage. Talk about a close call. While I am proud of what I delivered, I originally wanted to pack even more into the session. I had planned to showcase a simulated mission, Gazebo visualizations and RViz path simulations. While time caught up with me for the presentation, these features are still actively in the works over at the aeronix project. My goal is to have the entire end-to-end setup completed and ready by the end of the year. I connected with some incredible engineers and industry peers and I am looking forward to building on those conversations for future professional collaborations. This experience proved that the best way to grow is to just put yourself out there. Moving forward, I plan to keep speaking on topics that challenge me. It is the ultimate way to deepen my own technical understanding share what I have learned with the community and grow professionally.

A year ago, I wrote about our first year with micro-frontends . It was a frank retrospective: the win was framework autonomy and independent deploys, the cost was 20 GB of RAM during local dev, 15–20 minute deploy cycles, and a monorepo that became its own coordination tax. The closing line was the honest one — if I could choose again, I would think carefully about using Microfrontend or not. This article is the follow-up the previous one didn't write: what we actually built around Single-SPA to make it work. Not the architecture diagram. The workarounds. The dead code that's not really dead. The regexes we wish we didn't need. The .NET app no Single-SPA tutorial mentions. The browser-side singletons we use as message buses. The dev experience we documented and the parts we didn't. If you're evaluating Single-SPA in 2026, this is the article I wish I'd had a year ago. Where we left off The platform is a Single-SPA monorepo with seven in-repo apps and five shared packages. On top of that sit roughly ten standalone repositories for newer features, loaded at runtime via SystemJS import maps. Shared dependencies — React 18.2, ReactDOM, axios, react-bootstrap, single-spa 5.9.5 — are served from CDN and externalized in every webpack config. The architecture is textbook. The reality, a year in, is that the textbook stops where the workarounds start. The shell isn't where you think it is If you read our frontend repo you'd conclude the shell is whatever directory has single-spa in its package.json . That's where Single-SPA gets configured. That's where start() is called. There's even a webpack entry that, until recently, was producing an index.ejs HTML template. That HTML template is dead code. The real shell — the HTML the browser actually receives, in every environment — is rendered by an ASP.NET MVC application, in a Razor view. The frontend repo ships JavaScript modules. The .NET host ships the page that loads them. That's the unlock. Once you see this, every other work

The Theorem That Changed How We Think About Databases In 2000, Eric Brewer stood at a conference and proposed a conjecture that would reshape distributed systems forever: "You can only guarantee two of these three properties at the same time: Consistency, Availability, and Partition Tolerance." Two years later, Seth Gilbert and Nancy Lynch proved it mathematically. It became known as the CAP Theorem — and every distributed system architect since has had to wrestle with it. It sounds abstract. But once you understand it, you'll never look at a database choice the same way again. You'll understand why Amazon DynamoDB and Google Spanner make opposite architectural choices. You'll know why your bank uses PostgreSQL while Twitter uses Cassandra. Let's break it down from first principles. The Three Properties C — Consistency Every read receives the most recent write, or an error. There's only one version of the truth — all nodes agree. Not the same consistency as ACID . CAP consistency (linearizability) means every read reflects the latest write across all nodes. ACID consistency means transactions don't violate database constraints. Different concepts, same confusing word. A — Availability Every request receives a non-error response — though it might not be the most recent data. The system is always up and answering. Note: "Available" in CAP doesn't mean "fast." It means "responds without error." A system that always returns a (possibly stale) answer is Available. P — Partition Tolerance The system continues operating even when network messages between nodes are lost or delayed. A partition is when part of your distributed system can't communicate with another part. The Unavoidable Truth: P Is Not Optional Here's the insight that makes CAP actually useful: In any real distributed system, partitions will happen. Networks fail. Cables get cut. Data centers lose connectivity. AWS regions go down. Since you must tolerate partitions (or have a single-server system, which does