What twelve focused weeks of study actually changed

For an architect, the most dangerous state is comfort. It’s the feeling that you’ve seen all the patterns, that the next challenge is just a recombination of previous solutions. I was there a few months ago. I understood the concepts of modern AI, I’d read the papers, but I hadn’t felt the friction of building with these new primitives from a blank text editor. I decided to fix that with a focused, hands-on sprint.

The goal wasn't to master any single framework, but to internalize the grain of the new material. This isn't a guide to a specific technology, but an honest reflection on how that intense period reshaped my approach to system design.

From Silos to a Single Fabric

My career has been a story of boundaries. There was the application team, the data warehouse team, and later, the machine learning team. We communicated through APIs, ETL jobs, and tickets. Architecturally, my job was to design robust contracts at these seams. I thought in terms of services, pipelines, and models as distinct components.

Twelve weeks of building one system from ingress to insight broke that model completely. The pain points weren't in the individual components; they were in the impedance mismatch between them. For instance, a seemingly innocuous change in our application—migrating primary keys from auto-incrementing integers to UUIDs—silently broke a downstream embedding pipeline. The model, trained and expecting a sequence of integers, failed with cryptic errors three steps removed from the cause.

I stopped seeing separate systems. I now see a single, interconnected fabric. The convergence of software, data, and AI isn't a headline; it’s a ground-level reality. Modern systems require data lineage to be a first-class feature of the application, not an after-the-fact cleanup job. The most important work is designing a shared, observable data flow that all three disciplines can trust.

The Deterministic Core and the Agentic Edge

The biggest conceptual change was a new pattern for where to use AI. I used to wrestle with a false binary: either a system was traditional, predictable software, or it was a magical, end-to-end AI black box. Hands-on work revealed a more durable pattern: the deterministic core and the agentic edge.

The core of any system I design now is more ruthlessly deterministic than ever. This is where business rules live, where transactions are processed, where data integrity is absolute. It is small, auditable, and covered by traditional tests. It does what computers are good at: counting, storing, and executing logic flawlessly.

The AI, specifically LLM-powered agents, lives on the edge. Its job is to handle the fuzzy, unpredictable inputs from the real world—translating natural language into structured API calls for the core, or summarizing unstructured data for a human. It suggests options, but it never executes a core business transaction on its own. This stands in contrast to the hype around all-powerful, end-to-end agents. In my experience, that approach is too brittle for production. The goal is to use probabilistic tools to make a deterministic system more powerful, not replace it.

This architecture formalizes a pattern seen in foundational research like the ReAct paper, where an LLM is used to reason and select from a set of reliable, deterministic tools—my "core"—rather than attempting to perform the actions itself. This separation of concerns makes the system resilient. When the agent hallucinates or an API is down, the core business function remains stable. The "AI features" might degrade, but the system doesn't collapse.

Cost Curves Are a Design Constraint

It’s easy to talk about token costs in the abstract. It’s another thing to watch your personal cloud bill climb after running a few poorly designed batch jobs against a flagship model. An LLM call isn't like a database query; its cost can vary by orders of magnitude based on the context. This experience made cost an architectural design constraint from day one.

My default now is to build a triage system. Can a simple string match or regex solve this? Can a small, open-source model running locally handle this classification? Can we use a cheaper model to summarize the input before sending only the critical part to the expensive, powerful model?

This triage approach, often called a "model cascade," isn't just a personal quirk. It's a recurring pattern for building cost-effective systems at scale. Practitioners like Andrej Karpathy have emphasized in talks like State of GPT that production AI is rarely a single model but a "system of models" designed to route tasks to the cheapest, fastest tool that can get the job done.

The Humility of the Empty Editor

After two decades, you get used to having the answer. You can sketch entire systems on a whiteboard from muscle memory. The most humbling part of this process was being a beginner again. I spent hours debugging simple dependency conflicts and fighting with unfamiliar library documentation.

It was frustrating, but also invaluable. It reconnected me to the craft. An architecture diagram is an elegant fiction; the reality is a thousand tiny details that determine if a system works. Experiencing that friction reminds you that the "boring" parts—observability, error handling, dependency management—are what separate a demo from a durable system that someone can maintain at 3am. It was a powerful dose of intellectual honesty.

Durable Patterns for a New Stack

This study wasn't about adding a few new tools to my belt. It was about recalibrating my intuition. What follows are the concrete takeaways that now guide my work.

• Start with the data flow, not the services. I now map the full lifecycle of information through the entire software-data-AI fabric before I draw a single microservice box.
• Treat the deterministic core as sacrosanct. Protect it from probabilistic behavior at all costs. The goal of the agentic edge is to serve the core, not to replace it.
• Architect the cost model. The triage pattern for LLM calls is a non-negotiable part of any AI-enabled system I design. We must have an answer for how the system behaves with one-tenth the budget.
• Stay hands-on. I don't need to be the best programmer in the room, but I must feel the grain of the materials. The friction is where the real learning happens.

The industry will keep evolving. But these principles feel durable. They are less about a specific technology and more about a timeless respect for craftsmanship, reliability, and building things that last.