Nikko Dutra Bouck

Explorer

Engineering started early for me.

I grew up experimenting with gadgets, building solar-powered radios on breadboards, and working around my dad’s auto repair shop. In high school, I studied electronics through ROP, then worked at Hewlett-Packard assembling enterprise servers. Long before software architecture became my focus, I was learning to understand systems by taking them apart, building them, and seeing how the pieces fit together.

That hands-on foundation eventually carried into software, research, and field engineering.

At UC San Diego, I worked with Engineers for Exploration, where software had to interact with cameras, drones, networks, machine learning systems, robotics, and the physical environment.

I worked on mangrove monitoring using aerial imagery and machine learning, SLAM-based mapping of ancient Maya archaeological sites, hardware for real-time field visualization, and control systems for a tunnel-imaging robot used during field exploration in the Mojave Desert.

Mangrove 1 cm resolution ground truth experiment design.

Downloads: RECON 1 - Presentation Experiment Proposal rough draft full-e4e-reu-2017

Those experiences changed the way I approach technology.

A diagram is useful. A model is useful. Code is useful.

But eventually a system has to survive contact with reality.

That means imperfect networks, limited hardware, uncertain data, changing environments, human operators, and failure modes that were never visible in the original design.

The most interesting engineering begins where the abstraction meets the real world.

UC San Diego also connected my engineering work to sustainability and exploration. I received the 2018 UC San Diego Sustainability Outstanding Student Award, represented UC San Diego as a delegate at the Global Climate Action Summit, and was a National Geographic Chasing Genius finalist.

Sustainability, to me, is one of the most critical cornerstones to a healthy society.

“When I think about a business, cultural practices, or societal equilibrium, I typically ask myself how these activities will impact the world 10 years, 100 years, and 1000 years from now. Will the activities cause hardship for humanity? How will it affect the quality of life we experience as a species? How will it influence the empathy, compassion, and curiosity of humans?”

That combination of exploration, engineering, and systems thinking still shapes the work I choose today.

What happened after Operation Trash Route - RECON 1?

From Monoliths to Scalable Services

After Engineers for Exploration, I spent more time working inside growing production codebases and saw how quickly monolithic systems can become difficult to understand, change, and scale. I refined my architecture practice around C4 modeling, Architecture Decision Records (ADRs), and the Strangler Fig pattern for incrementally migrating legacy systems without requiring a disruptive rewrite. (More on legacy modernization from Martin Fowler.)

Three books became especially influential in how I approach architecture and distributed systems: Designing Data-Intensive Applications, Architecture Patterns with Python, and Fundamentals of Software Architecture. Together, they reinforced an approach centered on explicit boundaries, evolutionary architecture, testability, data-intensive system design, and making architectural decisions visible.

Software Architecture vs System Architecture

Software architecture is the structure of a single application — how its modules, classes, and layers are divided and how they're allowed to call each other.

System architecture is the structure of everything around it — how separate services, data stores, and teams communicate, fail, and recover across a distributed environment.

For the last 20 years...

My professional work has spanned startups, academic research, healthcare, financial services, and global enterprise infrastructure.

My time at Guild Mortgage, Optum, and ServiceNow gave me three different views of the same problem: what happens when software grows faster than a team’s ability to understand it.

At Guild, that meant learning how event-driven systems, migrations, and service boundaries behave under real production scale. At Optum, the focus shifted toward finding the hidden causes of performance and reliability problems inside mature systems. At ServiceNow, it became an observability problem—making distributed system behavior visible enough that engineers could reason about failures instead of reconstructing them from scattered logs and tribal knowledge.

That work culminated in an observability service that generated decision trees to help guide diagnosis and remediation across distributed services. It reinforced a principle that now carries into AtlasboxPy and my AI architecture work: complex systems become easier to operate when their relationships, state, and failure paths are made explicit.

My current work applies those lessons to software architecture and AI systems.

System Design, Observability & Regression Testing

AtlasboxPy is a shared Python controller package giving REST routes, background workers, and in-process agents one enforced call path instead of three separately-maintained ones. A base controller class wraps every public method automatically, so business-rule validation, error formatting, and response shaping stop being the HTTP layer's job by default — every caller gets the same typed error taxonomy and a structured, checkable retry signal, with MCP reserved for tools that genuinely cross an ownership boundary rather than reached for by default. More on the stack in Inside the AtlasboxPy API Stack.

UserBaseAPI is a FastAPI backend for account management, subscriptions/billing, and S3-backed file storage with a quarantine-first upload and scanning pipeline. Every architectural choice behind it — the layer stack, auth, migration strategy — is recorded as one of nineteen numbered ADRs, never edited after acceptance. See Inside the UserBaseAPI ADRs.

H-STAT is an architectural design pattern for agentic software systems:

H — Human Interface
S — System Awareness Engine
T — Telescopes
A — Agents
T — Tools

H-STAT separates system coordination, model-facing cognition, agent orchestration, and environment-facing tools so each responsibility can evolve independently. The broader Agent Operating System work extends this pattern with shared runtime management, observability, concurrency, and WorkResult reconciliation.

My patent and patent-pending work includes research related to:

• Agent Operating System Using Model-Facing Telescopes
• Systems and Methods for Risk-Aware Control and Parallelized Execution of Human-Governed Artificial Intelligence Agents
• System and Method for Autonomous Software Engineering
• Risk-Aware Runtime Control of Engineered Systems Using Executable Risk Artifacts and Evidence Binding

Some work is published openly. Some is commercial. Some remains private.

Engineering Philosophy

Good architecture makes important behavior visible.

Engineers should be able to answer:

• What calls what?
• Where does data move?
• Where are the side effects?
• Where are the system boundaries?
• What happens when something fails?
• What will a change affect?

When those answers disappear into tribal knowledge, hidden coupling, or fragmented tooling, software becomes harder to change and more expensive to operate.

My engineering approach centers on evidence before inference. Static analysis, tests, telemetry, schemas, dependency graphs, benchmarks, and runtime state provide the evidence. That discipline matters most before an LLM ever enters a system: start from the problem statement, not the model, and map out the smallest set of tools that gets a working MVP delivering real value. AI can then interpret, correlate, explain, and accelerate that evidence rather than substitute for it.

AI is shorthand for a class of algorithms — a family of tools for searching complicated, multidimensional problem spaces, not a single magic ingredient. Modern LLMs are made possible by linear algebra, and GPUs are what make that linear algebra fast: XLA, literally short for Accelerated Linear Algebra, is the compiler that turns the math into GPU kernels. Like any search, the results are only as good as the data used to train the space being searched. The analogy I keep coming back to is circuit design: a radio receiver and transmitter decode signals out of the electromagnetic spectrum using math that is decades old, refined through the shift from analog signal processing to digital sampling. Running an LLM on a GPU through XLA is the same kind of well-understood machinery under an unfamiliar name — closer to the PageRank algorithm that built Google search in the early 2000s than to anything mysterious.

I work through that PageRank-to-attention comparison in more detail — matrices, GPU parallelism, and all — in LLMs Are Linear Algebra in Motion.

Before AI... shifting back to first principals...

Let us focus on the _FULLSTACK.
Software needs to be understood across vertical slices. Users experience complete behaviors that cross interfaces, services, queues, databases, and external systems. Architecture and integration testing should follow those same paths.

Reliable systems also assume failure. Networks fail. APIs time out. Databases slow down. Server timers fall out of sync. Deployments introduce unexpected behavior. Security vulnerabilities hide in unexpected places, and risk surfaces can remain buried in dependency graphs. Models hallucinate.

The architecture should make it possible to:

detect
  ↓
contain
  ↓
explain
  ↓
recover
  ↓
learn

Strong engineering leaves behind more than working code. It leaves clearer architecture, better tests, useful measurements, operational knowledge, reusable rules, and systems that the next engineer can understand.