Learning HTML by breaking things, one page at a time

The shriek of a 56k modem was the sound of a portal opening. In the mid-90s, the web was a destination you dialed into, and for me, the magic wasn't just visiting a page on some free web host. It was the moment I right-clicked and selected "View Source."

That chaotic wall of text—angled brackets, cryptic attributes, my friend's terrible poetry—was the blueprint. It was the uncompiled truth of what the browser was trying to render. There was just the source file and the output, and the gap between them was where I learned to build.

Learning by Visceral Feedback

My first lessons weren't additive; they were subtractive. I'd save a working, gloriously messy page to my desktop and start breaking it. The process was primitive: delete a <TR> tag, save, and refresh the browser. An entire row of the layout table would vanish. The feedback loop was instantaneous.

Forgetting a closing </TABLE> tag shattered the entire page. This wasn't about "best practices." It was about building a mental model from first principles through hands-on sabotage. Each broken page was a successful experiment, teaching me about containment and hierarchy in a way no book ever could.

Hitting F5 in a popular 90s browser was a moment of truth. There was no complex pipeline to blame. The result of my change was right there, in seconds. This binary, immediate outcome forced a discipline of making small, observable changes—a lesson that scales directly to debugging the most complex systems today.

From Deterministic Renders to Probabilistic Outputs

That immediate feedback feels a world away from a data pipeline that fails thirty minutes into a run, or a subtle microservice change that causes a cascade failure hours later. We now spend our time debugging abstractions, not the core logic. The connection between cause and effect is obscured.

This brings me to the work I do now: architecting systems where LLM-powered agents and deterministic code cooperate. We are in an exploratory phase with agents, where their behavior can feel non-deterministic, almost magical. And just like with that old HTML, the best way to truly understand them is to probe their boundaries and find where they break.

Probing Agents to Find Their Edges

Reading a paper on prompt engineering is one thing; building a system that intentionally prods an agent into failure is another. The modern "View Source" is about systematically crafting inputs to expose a model's operational boundaries. Respected practitioners like Simon Willison have documented this hands-on approach extensively on his blog. It's about treating the agent not as a magical oracle, but as a system component to be understood through empirical testing.

This "break-it-to-understand-it" approach is crucial, but it's only half the story. It contrasts with another powerful architectural idea: building systems with proactive guardrails. Instead of only finding failure modes, we can design systems to prevent them. A canonical example is the work on Constitutional AI by Anthropic, which embeds deterministic rules to guide an agent's behavior from the start. The two ideas aren't in conflict; they are complementary. Empirical probing tells us which guardrails we need to build.

Architecture for Cooperating Systems

This is where the real architectural work begins. The goal isn't just to see an agent fail, but to use that knowledge to design a resilient, hybrid system. The insights from probing directly inform the design of deterministic checks that run alongside the agent.

This leads to patterns like the "agentic circuit breaker." We empirically discover that an agent fails at a certain type of task or produces malformed output under specific conditions. So we build a simple, deterministic validator that checks the agent's output *before* it gets passed to a downstream system. If the output is invalid, the circuit breaker trips, and we can fall back to a default action, a simpler model, or a human-in-the-loop workflow. The tinkering becomes formalized into a durable pattern.

The system's reliability no longer rests on the probabilistic agent behaving perfectly. It rests on the deterministic components that we, as architects, build around it. We trade a bit of "magic" for production-grade stability.

Concrete Takeaways

The specific HTML tags of the 90s are gone, but the method of learning is durable. For architects building hybrid AI systems today, the principles hold.

• Embrace Empirical Probing: Don't just trust the whitepaper. Systematically test your agents' boundaries with constraint torture, tool deprivation, and verbose logging. Find out where and how they fail before you ship.
• Build Deterministic Guardrails: Use the knowledge from your probing to build simple, fast, and reliable validators, parsers, and circuit breakers around your agentic components. Trust, but verify with code.
• Prioritize Fast Feedback: When designing agentic systems, think about the debugging loop. Architect for observability. Make the agent's internal "chain of thought" a first-class citizen in your logs so you can see exactly where a reasoning path went wrong.

The most robust systems are built by people who have a deep, empirical understanding of how their components break. That was true for a table on a webpage, and it's even more true for an agent in a production pipeline.