There's a category of architectural decisions that don't feel like decisions at all. They don't come with a board presentation, they don't require budget approval, and they never show up on the roadmap. They happen quietly - inside a PR, during a team chat, in the choice of communication format between two services.
But these are exactly the decisions that determine whether you've built a stable product or a fragile toy.
This article looks at two such examples: choosing a communication format in AI systems, and the approach to data duplication. Both seem like narrow technical concerns, but both return to the same fundamental question that defines good architecture.
Ask Who the User Is - First
Last week Anthropic published a blog post about the advantages of HTML over Markdown, and it sparked a heated community debate. But once the dust settled, it's worth noticing a detail many people missed: every single example they gave involved output intended for humans.
That brings us back to the most basic question in architecture: who is the user? Who consumes the output?
When the answer is machines and agents, Markdown and JSON are king. They save on token costs, they're perfectly suited for LLM attention mechanisms, and they produce clean, predictable communication. When the answer is humans who need a rich interface, HTML is the right call - but with serious caution.
Why caution? Even if we set aside the danger of LLM-generated JavaScript inside HTML - which is a reliable path to data leaks and XSS vulnerabilities, with real risk of reputation damage - the core principle still holds: a communication format is an architectural decision, not a personal preference.
This isn't just about efficiency or saving money. It's about building a product - something stable - not a fragile toy. As explored in Who's the User? The Question That Defines Good Architecture, this choice ripples through operational costs, security posture, and the system's ability to scale without breaking.
The practical takeaway: Markdown for AI-to-AI communication, carefully managed HTML for user interfaces. Simple - but only if you ask the right question first.
Stop Being Afraid of Duplication
There's a principle taught early in every engineer's career that sticks a little too hard: DRY - Don't Repeat Yourself. It becomes sacred, and then teams start avoiding all duplication as if it were a sin.
But hold on. Netflix stores the show you're watching across 15,000+ servers around the world. Virtually every website you visit caches static files as close to you as possible. In DVD-era games like GTA, the same tree textures were stored in multiple locations on the same disc - the same disc.
That's not negligence. That's architecture.
The problem starts when teams fail to distinguish between two completely different types of duplication.
Bad duplication happens when you produce twice. It's like buying tissues one box at a time from the store instead of getting a bulk pack once. This kind of duplication turns maintenance into a nightmare - every small fix requires syncing two sources of truth, over and over again.
Smart duplication happens when you enable consumption twice. It's like placing tissue boxes around the house - one by the bed, one in the living room, one on the desk. Same product, accessible wherever the consumer needs it.
The difference isn't technical. It's conceptual.
Recognize When a Principle Becomes a Prison
I recently visited a team that refused at all costs to add another database to their product, just to avoid duplication. They could recite DRY in their sleep, but they never asked themselves one simple question: where should we use duplication to better serve the consumer?
The result? Users waiting. Latency climbing. Experience degrading. All in the name of a principle that had gone from useful guideline to architectural prison.
This is a pattern that repeats itself: teams treat engineering principles as sacred without re-examining them in the context of their specific product and user. DRY is a tool, not a commandment carved in stone. When it leads you to build a system that serves the code instead of the user - it's time to start asking questions.
Think About the Consumer, Not the Code
What do communication format choices and data duplication approaches have in common? Both are decisions that teams tend to make out of habit or ideology - instead of thinking about who actually consumes the output.
A team that picks HTML for agent-to-agent communication because "it's what we know" pays the price in tokens, security exposure, and stability. A team that avoids data duplication because "DRY is sacred" pays the price in latency and user experience.
In both cases, the business risk is real: the opportunity cost of architecture that isn't aligned with the consumer compounds into technical debt that's very hard to pay down later.
Good architecture doesn't start with technology. It starts with a question: who is the user, and what do they need?
Takeaways
The architectural decisions that truly shape a product's fate are rarely the ones that come with a big price tag. They're the quiet ones - format, duplication, service structure - that compound over time.
Three things worth taking from this discussion:
Before any architectural decision, ask who the consumer is - human, machine, or both. The answer changes everything. Re-examine principles that have become dogma - DRY, KISS, YAGNI - in the context of your specific product. A principle that goes unquestioned becomes technical debt. And smart duplication is a legitimate architectural tool, not a sign of sloppiness. Netflix does it, and you should know when it's the right call too.
Think twice, build once. But make sure you're thinking about the right thing.