In the last two months I haven’t only built products. I’ve built the system for building them.
This is the concrete half of How I Write Code in 2026. The tokens only matter if you can point at what they produced.
I built NIS2.chat, an AI-powered evaluator that gives companies expert-level feedback on what they need to prepare for the NIS2 directive in the European Union. The directive is dense. The people implementing it are operators and engineers, not compliance lawyers. That’s the same audience I design for at work: asset owners, IT/OT engineers, CISOs, and SOC operators who don’t have time to translate a regulation into a workflow.
I built AUIUX, a multi-agent design feedback system. A UI Critic analyzes screenshots. A Design Strategist writes an improvement plan. A Visual Implementer generates a refined version. I wanted to test the limit of what an agent can critique in design work, including work that came from a human.
I also built custom internal tools and prototypes at Omny that help the team navigate OT/IT cybersecurity workflows, plus a dozen smaller experiments: task trackers, portfolio sites, pitch evaluators, and browser-based QA tools.
The system underneath
I work with a three-layer context setup:
- Global rules that apply everywhere (“always write tests, never skip error handling”).
- Project-specific instructions (“this app uses shadcn components and Tailwind”).
- Reference files I pull in on demand: API docs, design tokens, previous PRDs.
I’ve created slash commands for repeatable workflows so I’m not reinventing the wheel every time. I’ve built specialized agents: a planning agent that turns a rough idea into a structured PRD, a code-simplifier that refactors before shipping, and a verify-app agent that runs browser QA and catches visual regressions.
The “always write tests” rule earned its place the hard way. A routing refactor turned the test suite red, and the fastest path the agent found was to update the tests to match the new code. A green suite that no longer checks anything is worse than a red one, so I had it fix the code instead.
Continuous feedback has always been aligned with my work as a product experience designer. As designers, product managers, or developers, we build versions, collect feedback, and iterate to shorten the path to the most useful answer.
Translating those design and iteration principles to the work I do with agents, I learned to always create a plan and store it before building, and I end every session with a structured summary. Victories, failures, tough questions, what to improve. Patterns get codified. The system learns, and so do I.
Also in January: How I Write Code in 2026 · A New Kind of Technical Career · Learn the Loop, Not the Tool
Daniel Arevalo is Product Experience Lead at Omny Security. He builds AI-native tools and writes about design, product leadership, and what it means to direct systems that execute at a speed humans never had before.