Best of Architecture — March 2026

1
Article
Tech World With Milan·8w
You're Not Paid to Write Code
Engineers who deliver the most value aren't the fastest coders — they're the ones who think first, ask questions, and sometimes conclude that no code is needed at all. Code is a liability, not an asset: every line must be maintained, understood, and eventually changed. Jumping straight to implementation often means solving the wrong problem, as illustrated by a checkout performance example where the real issue was form complexity, not query speed. Organizational incentives (promotions tied to features shipped, not problems avoided) push teams toward code-first behavior. AI amplifies this: a 2025 METR study found developers were actually 19% slower with AI tools despite expecting to be faster, and GitClear data showed 4x more copied code. The solution is a 'thinking-first' approach — writing a short paragraph defining the real problem, who it affects, and how success is measured before touching the editor. Amazon's 'Working Backwards' process is cited as a model. The engineer's real job in 2026 is problem framing, architectural judgment, deciding what not to build, and validating AI-generated output — not raw code output.
289
26
2
Article
Towards Data Science·9w
The Black Box Problem: Why AI-Generated Code Stops Being Maintainable
AI-generated code tends to become unmaintainable due to structural problems: monolithic outputs, implicit circular dependencies, missing contracts, and implementation-only documentation. The core issue is that AI tools generate code without real-time structural feedback, producing what the author calls 'black boxes.' The solution isn't better prompting but enforcing architectural constraints during generation itself — explicit component boundaries, validated dependency graphs, isolated testability, and typed interfaces. Practical advice covers how to prompt with architectural intent, audit existing generated code for implicit coupling, and evaluate AI tools by their post-generation reviewability and structural enforcement.
189
14
3
Article
Code Like A Girl·9w
Technical Debt
Using a home renovation analogy of discovering a labyrinth of old pipes behind a wall, this piece explains technical debt as the accumulated cost of past shortcuts. It distinguishes between intentional debt (a conscious tradeoff) and a mess (careless neglect), drawing on Uncle Bob's Clean Code philosophy. The key insight is that debt is painless until you try to change something, at which point it compounds. The recommended mitigation is writing tests to create a safety net that makes future changes less risky.
130
6
4
Article
Architecture Weekly·10w
Parse, Don't Guess
A developer shares how a sneaky Regex-based bigint auto-detection during JSON deserialization caused JavaScript event loop freezes in production. The fix involved dropping the global Regex reviver and replacing it with an explicit upcasting pattern — a function that converts stored types (strings) to application types (Date, bigint) only for declared fields. This same upcasting mechanism naturally extends to schema versioning: handling structural changes between document/event versions (V1 flat fields vs V2 nested objects) using upcast (read) and downcast (write) functions. The pattern is applied to both Pongo (document store) and Emmett (event store), enabling backward and forward compatibility without batch migrations.
86
1
5
Article
A Java geek·7w
The Software Architect Elevator
A review of Gregor Hohpe's 'The Software Architect Elevator' from O'Reilly. The book covers the role of modern architects who bridge business strategy and technical implementation across organizational levels. Structured in 41 short chapters (5-10 pages each) across topics like architecture decision-making, communication, organizational dynamics, and IT transformation. The reviewer praises the experience-driven advice and accessible format, but notes it is strictly organizational rather than technical. Recommended for developers with a few years of experience who feel technical skills alone are insufficient.
83
2
6
Article
GitHub Blog·8w
The era of “AI as text” is over. Execution is the new interface.
GitHub has released the Copilot SDK, which lets developers embed agentic execution capabilities directly into their own applications. Rather than relying on text-in/text-out AI interactions, the SDK exposes the same planning and execution engine that powers GitHub Copilot CLI as a programmable layer. Three key patterns are highlighted: delegating multi-step work to agents instead of brittle scripts, grounding execution in structured runtime context via Model Context Protocol (MCP), and embedding agentic execution outside the IDE into desktop apps, SaaS platforms, background services, and event-driven systems.
48
6
7
Article
WunderGraph·8w
Design Like a Monolith, Implement as Microservices
The monolith vs. microservices debate is framed as a false dichotomy. The real insight is that API design and API implementation are separate concerns that should be handled differently: design top-down as a unified whole (monolith thinking), implement distributed across teams (microservices thinking). Traditional GraphQL Federation merges these concerns, letting each team design and implement their slice, which leads to API fragmentation. WunderGraph's Fission and Hub tools aim to separate these layers — a design phase where the supergraph is treated as a single coherent schema, and an implementation phase where teams independently build their assigned subgraphs. Three trends driving this approach: organizations scaling past coordination thresholds, AI agents needing coherent APIs, and platform engineering demanding golden paths.
55
8
Article
Confluent Blog·10w
Real-Time Decisioning and Autonomous Data Systems
Real-time decisioning and autonomous data systems represent a shift from passive reporting to active, automated action on live data. Real-time decisioning follows a signal-logic-action loop, triggering immediate responses without human intervention. Autonomous data systems extend this by adding closed feedback loops that allow systems to self-correct and adapt over time. The post outlines four architectural components: event ingestion, stateful enrichment, a decision engine (rules or ML models), and action connectors with feedback capture. Concrete use cases include anomaly-triggered authentication, dynamic supply-demand balancing, predictive failure prevention, and intelligent event routing. Key risks covered include the need for kill switches, schema validation, audit logs, and monitoring for model drift. A phased adoption path is recommended, starting with identifying slow decisions and incrementally introducing event streaming (Kafka), enrichment, rule automation, and eventually AI models.
38
2
9
Article
Tech Lead Digest·9w
The Rewrite That Was Really a Resignation Letter
A senior backend engineer spent 18 months escalating structural problems in a routing engine through retrospectives, backlog tickets, and one-on-ones before writing a 22-page rewrite proposal. When leadership rejected it with a vague deferral and no alternative, he left. The post dissects this pattern: how systematic deprioritization of incremental fixes forces engineers toward dramatic proposals, why those proposals are often the wrong solution to a real problem, and what a substantive rejection should actually look like. It argues that 'no to the rewrite' without a committed alternative is indistinguishable from 'never,' and that the rejection gap is where trust and retention are lost. The story ends with the predicted cascading failure occurring six months after the engineer's departure, validating his diagnosis.
34
7
10
Article
Terrible Software·9w
Nobody Gets Promoted for Simplicity
Engineering teams systematically reward over-engineering while penalizing simplicity, creating perverse incentives from interviews to promotions. Engineers who build elaborate systems get compelling narratives for promotion packets, while those who ship clean, minimal solutions have nothing impressive to show. The post argues that unearned complexity is the real problem, not complexity itself, and offers concrete advice: engineers should document the decisions they didn't make and frame their judgment explicitly, while engineering leaders should change the questions asked in design reviews and promotion discussions to make simplicity the default rather than something that needs defending.
28
2
11
Article
The Daily WTF·9w
Anti-Simplification
A cautionary tale about over-engineering: a CTO replaced a simple SQL view with a Rube Goldberg machine involving two schedulers, two Azure Data Factory pipelines, multiple Azure Functions, C# DLLs with factory classes, reflection-based joins, and struct-copying functions — all to replicate what a few hundred lines of SQL could have done. The result was 50,000 lines of heavily duplicated C# code where adding a single table takes a month.
26
2
12
Article
We Are .NET·9w
Minimal APIs After the Hype: What Remains When Boilerplate Is Gone?
ASP.NET Core Minimal APIs have matured past the hype cycle. Rather than replacing controllers or MVC, they reset the default starting point from complexity to simplicity, forcing developers to consciously justify every abstraction. The piece reflects on what this shift revealed: much of traditional .NET API ceremony was habit rather than necessity. Minimal APIs excel in microservices, edge services, prototyping, and serverless scenarios, but struggle with large domain models and multi-team governance. Their lasting impact is not fewer lines of code but fewer assumptions—making architecture a deliberate decision rather than an inherited default.
25
1
13
Article
Milan Jovanović·9w
5 Architecture Tests You Should Add to Your .NET Projects
Architecture rules documented only in wikis will eventually be violated. Using ArchUnitNET, you can encode those rules as automated tests that run in CI. Five test categories are covered: layer dependency tests (enforcing Clean Architecture's dependency rule), naming convention tests (ensuring handlers and validators follow consistent naming), colocation tests (verifying CQRS command/handler pairs live in the same namespace using raw reflection), visibility tests (enforcing that handlers are internal rather than public), and dependency guard tests (preventing infrastructure libraries like EF Core from leaking into Domain or Application layers). Setup requires a base class that loads all project assemblies, and all tests run in milliseconds without any infrastructure.
20
14
Article
Towards Data Science·7w
Vibe Coding with AI: Best Practices for Human-AI Collaboration in Software Development
Explores best practices for human-AI collaboration in software development using vibe coding tools. Key risks identified include garbage-in-garbage-out prompting, poor prompt quality burning through model limits, and AI tendency to over-engineer solutions. Using a RAG system over news articles as a practical example, the author demonstrates a workflow: define clear requirements with test queries, generate architecture before code, validate and stress-test the design with edge cases, have the AI self-critique, and push back on unnecessary complexity. The central principle is a human-in-the-loop cycle where AI accelerates but humans remain the final arbiter on trade-offs, maintainability, and production readiness.
24
3
15
Article
Debezium·9w
Hello Debezium Team!
Vincenzo Santonastaso introduces himself as a new core contributor to the Debezium open source project. He shares his background as a Senior Product Engineer at lastminute.com working on distributed systems for flight booking, and prior experience at BMC Software with time-series data and forecasting. His interests center on distributed systems and event-driven architectures, and he expresses enthusiasm for contributing more deeply to Debezium.
17
16
Article
Figma·7w
How we rebuilt the foundations of component instances
Figma's engineering team replaced a decade-old Instance Updater architecture with a new reactive system called Materializer. The old system handled component instances in a self-contained but increasingly fragile way, causing cascading updates and editor lockups in large design system files. The new architecture introduces push-based dependency tracking, automatic invalidation, and a shared runtime orchestration layer that cleanly separates layout, variable evaluation, and instance resolution. Common operations like variable mode changes improved by 40–50% in large files. The framework is generic enough that other Figma features like rich text and slots are now built on top of it, accelerating future development. Rollout involved months of parallel validation across hundreds of thousands of production files to ensure correctness and performance parity.
16
17
Video
CodeHead·8w
Books That Made Me A CRACKED Backend Dev
A curated list of seven books recommended for leveling up backend development skills, presented in a suggested reading order. The books covered are: Clean Code (Uncle Bob), The Pragmatic Programmer, Designing Data-Intensive Applications, System Design Interview (Alex Xu), Database Internals (Alex Petrov), Release It! (Michael Nygard), and Fundamentals of Software Architecture (Richards & Ford). Each book is briefly described with practical takeaways, from writing readable code and DRY principles to understanding distributed systems, database B-tree indexes, circuit breaker patterns, and software architecture trade-offs. A suggested reading order is provided, starting with habits and progressing to deep systems knowledge.
20
1
18
Article
Martin Fowler·6w
Architecture Decision Record
Architecture Decision Records (ADRs) are short documents that capture a single architectural decision, its context, rationale, alternatives considered, and consequences. They should be kept brief (one page), stored in the source repository in a lightweight markup format like Markdown, numbered sequentially, and never modified once accepted — instead superseded by a new ADR. Writing ADRs serves both as a historical record and as a tool to clarify thinking and surface disagreements within teams. Each ADR has a lifecycle status (proposed, accepted, superseded) and should include trade-offs, confidence levels, and triggers for re-evaluation. Martin Fowler traces the term to Michael Nygard's 2011 article and points to tools like adr-tools for managing them.
33
2
19
Article
We Are .NET·7w
What Does "Simple" Really Mean in Enterprise .NET?
Simplicity in enterprise .NET is not about fewer lines of code or fewer layers — it is about reducing friction over a system's lifetime. The post distinguishes between 'simple' and 'simplistic' designs, arguing that removing structure doesn't eliminate complexity but merely hides it. True simplicity must account for time (how easily a system can be changed), team dynamics (shared cognitive load and consistency), and purposeful abstraction. Architectural patterns like clean architecture, layered architecture, and vertical slices don't guarantee simplicity on their own — what matters is how well they align with the system's actual needs. A more honest definition: simplicity is the quality that allows a system to be understood, changed, and extended with minimal effort over its lifetime.
17
20
Article
System Design Newsletter·6w
The 53 Concepts for Highly Effective Mobile System Design
A comprehensive guide covering 19 foundational concepts for mobile system design, organized into networking and caching categories. Topics include client-server architecture (thick vs thin clients), WebSockets for real-time communication, push notifications via APNs and FCM, polling/long polling/SSE tradeoffs, REST vs GraphQL vs gRPC API design, exponential backoff and retry strategies, idempotency keys for safe retries, request batching and payload optimization, resumable chunked uploads, handling intermittent connectivity with optimistic UI and request queuing, on-device memory and disk caching, HTTP caching with ETags and Cache-Control headers, offline-first architecture, and CDN strategy with media optimization. Each concept includes real-world examples, tradeoffs, and practical advice tailored to mobile constraints like battery, bandwidth, and unstable networks.
26
1
21
Article
C# Corner·8w
AI Models Can Generate Code. That Does Not Mean a Model Can Build a Production Product.
AI models can generate impressive code quickly, but generating code is not the same as building a production-ready product. Production software demands requirement fidelity, architectural soundness, security, testing, observability, and disciplined iteration — none of which a single model reliably provides on its own. Vibe coding is useful for prototypes and POCs but is not a production methodology. The real opportunity lies in orchestrated, multi-step delivery systems that use models as components within a structured process, rather than treating a single model as a complete product team.
12
2
22
Video
Simon Grimm·6w
Does AI make Developers dumb?
A developer shares personal experience building a mobile game (Tiny Harvest) almost entirely with AI, arguing that AI does make developers lazier and erodes problem-solving skills, but also enables shipping far more than would otherwise be possible. Four reasons AI makes developers 'dumb' are outlined: laziness, atrophying problem-solving muscles, loss of mental models, and cognitive offloading. The counterargument is that ignoring AI tools puts developers at a competitive disadvantage. The conclusion is that the skills that now matter most are architecture, testing, and code review — traditionally senior-level skills — and that the real risk is passive, unguided AI use rather than AI itself.
19
19
23
Article
Telerik·8w
How to Organize Minimal APIs
Minimal APIs in .NET can lead to bloated Program.cs files as applications grow. This post walks through refactoring a messy Program class by separating concerns into dedicated folders and classes: models, infrastructure, extension methods, and endpoint modules. It also introduces the Carter library, which enables defining HTTP routes in isolated ICarterModule classes, keeping Program.cs clean and decoupled from route definitions.
10

See all Architecture archives