Principle 01 · Featured
Solve the system before the code
Most bugs are architectural bugs in disguise. The cheapest fix is a decision made two layers up, before the first file is opened.
How I think
I solve the system
before I solve the code.
How I frame a problem, name the risk, weigh the tradeoff, and use AI without giving up engineering judgment.
Fig. 01 · The Operating System
Inputs in.
Production out.
Product intent, users, constraints, and the systems already in the ground, all of it passes through the same axis before it becomes architecture, interfaces, accessibility, and performance.
Engineering judgment isn't a step in the process. It's the thing the process turns on.
Fig. 01 · Product SystemTokens · Components · Code
Product intent becomes reusable decisions, then working software a team can inspect, maintain, and ship.
- 01
- Tokens, shared visual decisions
- 02
- Components, reusable interface contracts
- 03
- Code, the production implementation
From Frontend to AI Product Engineering
The same foundation,
a larger product surface.
Reusable component APIs, design systems, platform standards, documentation systems, cross-team adoption workflows, accessibility, scalable frontend architecture, and server integrations are the same muscles required for trustworthy AI-powered applications.
My CDW and Legato work shows that I can lead enterprise initiatives, coordinate across product, design, QA, and engineering, and build reusable platforms. Ask A.J. applies that foundation to a working AI product.
Chapter · Principles
Six rules
I keep coming back to.
Working principles shaped by more than twenty years of design and engineering work.
Principle 02
Composition over configuration
Fewer props, sharper primitives. A component with slots outlives a component with thirty flags, and every layer above it stays honest.
Principle 03
Data shape decides everything
The interface, the API, the failure modes, the analytics, all of them inherit from the shape of the data. Get that wrong and no framework saves you.
Principle 04 · Risk
Name the risk before the plan
Every meaningful decision has a thing that could quietly go wrong. Marking it in the margin, in oxblood, not in a Slack thread, is what separates a plan from a wish.
Principle 05
Accessibility is product quality
WCAG 2.2 AA and Section 508 requirements guide the implementation. Keyboard flow, focus visibility, and reduced motion are part of product quality.
Principle 06
The paved road is the product
Developer experience isn't a nice-to-have. Fast local loops, sharp types, and high-signal docs are what make quality inevitable at the tenth engineer, not the first.
Principle 07
AI expands, engineers decide
AI widens the surface I can hold at once. Architecture, tradeoffs, the last read before ship, those stay human. Leverage, not authorship.
Chapter · Accessibility
Accessibility is not compliance.
It's product quality.
WCAG 2.2 AA and Section 508 requirements shape how I design and build. Automated results are useful evidence, but they are not a conformance claim.
The ceiling is quality: keyboard-first flows, visible focus states, semantic HTML, reduced-motion parity, screen-reader announcements that match the visual truth, and contrast that holds up in real lighting.
Every accessibility investment pays back somewhere else, tighter component APIs, better test coverage, faster onboarding. Quality compounds because the constraints force clarity.
Field note
“The accessibility investment pays back somewhere else. Every time.”
Keyboard-first
Every path reachable without a mouse.
Semantic HTML
Landmarks, headings, roles by default.
Focus management
Visible, predictable, trapped when it should be.
Screen-reader parity
Announcements match the visual truth.
Reduced motion
Motion is a feature, not a mandate.
Colour contrast
AA minimum, AAA where it counts.
Chapter · AI-Assisted Engineering
AI accelerates me.
It does not replace me.
AI belongs inside a deliberate engineering loop: exploration, scaffolding, review, documentation, and product reasoning. Each tool has a role, and the engineer stays at the centre.
Fig. 04 · AI ProductInterface · Stream · Safeguards
A useful AI product combines a clear interface with server-side model access, streamed feedback, citations, and graceful fallbacks.
- 01
- Interface, a focused question-and-answer flow
- 02
- Stream, progress the user can see
- 03
- Safeguards, validation, limits, and fallbacks
Where AI helps
- Widening the option space before a decision
- Repeatable setup, migrations, and refactors at scale
- Test scaffolding and edge-case enumeration
- Documentation and changelog drafting
- Onboarding into unfamiliar codebases
Where judgment stays
- System architecture and long-term tradeoffs
- Product framing and outcome definition
- Accessibility, security, and compliance calls
- Team communication and stakeholder trust
- The final read on quality before ship
Chapter · Mental Models
Models before
implementation.
Three of the pictures I draw before I write anything down. The code exists to make one of these true, nothing more.
Fig. 05 · Platform ModelData · Interface · Trust
Strong platforms make complex data understandable while keeping the boundaries, permissions, and user trust visible in the experience.
- 01
- Data, the shape behind the product
- 02
- Interface, the decisions users can see
- 03
- Trust, reliability, access, and clarity
End of Chapter Three