# Johnny Leek > Software engineer · product-minded builder · systems thinker I build systems that make themselves understandable. Explore how I use AI agents, data systems, and product judgment to make complex workflows more reliable, accessible, and easier for the people who use and operate them. ## About ### I make complex systems easier to trust. I'm a Software Engineer II on Microsoft's Dynamics 365 Finance Reporting Hub team. I work where product design, engineering, and operations meet, starting with the people living with a workflow and following their friction through the system until the safer path is also the simpler one. - **Current work:** Finance Reporting Hub · Microsoft - **Education:** M.S. + B.S. Computer Science · Central Michigan University - **Working range:** React · TypeScript · Python · C# · SQL · AI Tooling · CI/CD · Azure DevOps ### Working areas #### Agent systems. I develop AI-assisted coding workflows and automations, and I've contributed to patent-pending agent sandboxing that makes expert context reusable. #### Data and operations. I move between Dataverse, Legacy systems, SQL investigations, incident management, and cross-repository integration to make failure legible. #### Product design and access. I learn from end users, admins, operators, and support engineers, then shape accessible React experiences around the decisions and recovery paths they actually need. #### Away from the keyboard. I enjoy off-roading and restoring classic cars, usually another form of understanding a system by taking it apart. ## Engineering philosophy ### AI-first engineering: Use AI ambitiously. Trust it conditionally. I adopt an AI-first mindset, but never a context-free one. I still need to understand the system, orient the work, bound what an agent can decide, and ask independent evidence to validate the result. The goal is not a one-shot answer. It is a capable system that knows when it has proved enough to proceed and when it needs human judgment. #### System orientation: Understand before you delegate. AI inherits both power and blind spots from its context. I orient it in the architecture, constraints, history, and customer consequences before asking it to act. #### Bounded autonomy: Give autonomy a boundary. Agents should have room to work without pretending every decision is safe to automate. Authority, retries, persistent state, and escalation paths make autonomy useful rather than reckless. #### Independent validation: Trust evidence, not confidence. A fluent answer is not proof. Plans are challenged before code, implementations are checked against requirements, and external build evidence must agree before the system can call itself complete. #### Learning loop: Make every run improve the next. Retries, bottlenecks, requested help, and retrospective evidence should change the workflow itself, so the next run needs less intervention without lowering its quality bar. #### Evidence: Make autonomy prove its own work. A multi-agent delivery system that researches, plans, challenges, implements, validates, ships, self-heals, and learns instead of asking one prompt to generate code and trust its own answer. ##### A pipeline designed to challenge its own work. This is one way I put the philosophy into practice. Specialized agents research, plan, challenge, implement, validate, ship, self-heal, and improve the workflow itself, returning to human judgment when ambiguity, authority, or exhausted retries make guessing unsafe. ###### 01. Orient the run Resolve the work item and repository, establish an isolated worktree, register the pipeline, and persist enough state for every specialist to resume from evidence instead of memory. - **Owner:** PR orchestrator - **Autonomy:** Sets up the run, checks concurrency, advances the work item, and records stage state automatically. - **Quality gate:** Refuses to touch code until the target repository and work item are unambiguous. - **Human checkpoint:** Only when the request cannot be resolved safely or authentication blocks the run. - **Output:** Isolated worktree + registered pipeline ###### 02. Research the system Inspect architecture, conventions, dependencies, history, and likely failure modes before a solution is allowed to narrow the field. - **Owner:** pr-researcher - **Autonomy:** Explores the codebase and writes a durable report for every downstream agent. - **Quality gate:** Separates evidence from assumptions and records unresolved risks before planning. - **Human checkpoint:** None unless required context is inaccessible or contradictory. - **Output:** Research report ###### 03. Plan the change Turn the research into a concrete sequence of files, behavioral contracts, tests, migration risks, and completion criteria. - **Owner:** pr-planner - **Autonomy:** Consumes the research report and produces an implementation-ready contract. - **Quality gate:** The plan must be specific enough for a different agent to implement without inventing missing behavior. - **Human checkpoint:** None while the plan remains internally resolvable. - **Output:** Implementation plan ###### 04. Verify before code An independent agent attacks the plan against the research and source, looking for missing surfaces, false assumptions, hidden coupling, and unverifiable steps. - **Owner:** pr-verifier - **Autonomy:** Rejects weak plans and returns precise feedback to the planner for another pass. - **Quality gate:** Planning and verification can iterate up to three times before code is written. - **Human checkpoint:** Escalates only after three rejected plans leave the system unable to converge safely. - **Output:** Verified plan ###### 05. Implement in isolation Execute the verified plan inside the isolated worktree, follow repository conventions, keep the change coherent, and leave a report that makes validation evidence-based. - **Owner:** pr-implementer - **Autonomy:** Writes the code and records significant actions in persistent agent state. - **Quality gate:** Implementation is constrained by the verified plan rather than improvising a new design mid-run. - **Human checkpoint:** Only for blocked permissions, unsafe ambiguity, or missing authority. - **Output:** Implementation report ###### 06. Validate and repair Check the implementation against the plan and research with tests, static analysis, diff review, and requirement-level validation rather than accepting a successful build as proof. - **Owner:** pr-validator - **Autonomy:** Returns failures to the implementer and can drive two focused repair attempts. - **Quality gate:** Critical gaps block PR creation even when the code appears locally complete. - **Human checkpoint:** Escalates when critical issues remain after the bounded repair loop. - **Output:** Validation report ###### 07. Ship and self-heal Create and link the pull request, publish the run evidence, then watch CI. Build failures are diagnosed from logs and repaired automatically instead of being handed back immediately. - **Owner:** PR orchestrator + pr-build-watcher - **Autonomy:** The build watcher can diagnose, patch, and retry failures up to three times. - **Quality gate:** A PR is not treated as complete until its external build evidence is healthy. - **Human checkpoint:** Escalates after three failed self-heal attempts or when credentials prevent diagnosis. - **Output:** Pull request + Craft report + green build ###### 08. Retrospect and improve Analyze stage durations, retry counts, research misses, missing context, and every place the run needed help, then convert those patterns into concrete improvements for future agents and skills. - **Owner:** retrospective-writer - **Autonomy:** Runs after success or failure and feeds the next improvement cycle with evidence from the full pipeline. - **Quality gate:** Recommendations must name the bottleneck and propose specific prompt or workflow diffs, not generic lessons. - **Human checkpoint:** Durable changes that alter policy or safety boundaries remain reviewable before adoption. - **Output:** Retrospective + skill improvement diffs ### Reliability: Systems should explain their own failure. I treat reliability as a product property. State, ownership, and a safe path forward should be legible before an incident forces someone to reconstruct the system under pressure. #### Visible state: Expose the state. Good systems make transitions, dependencies, and ownership visible enough that responders can move from symptoms to the responsible boundary. #### Recovery design: Design the recovery. Detection is incomplete without a safe, repeatable response. Recovery paths should be idempotent, observable, and built into the operating model. #### Evidence: Tracing 80 paths to corruption. I extended Finance and Operations SQL diagnostics for Dataverse compatibility, mapped 80 distinct corruption paths, and built idempotent resolution scripts that resolved severe blockers for thousands of active users. - **Who it served:** Enterprise tenants, finance analysts, and the responders supporting them - **Product decision:** Treat diagnosis and safe recovery as one continuous customer journey instead of stopping at detection. - **What changed:** 80 corruption paths mapped · 800+ enterprise tenants unblocked ### Product judgment: Confidence is part of the product. I start with the lived workflow, not the architecture behind it. The hidden product inside a complicated system is often confidence: knowing what happened, what is safe, and what comes next. #### Customer reality: Start with the lived workflow. End users, admins, operators, and support engineers each experience a different edge of the same system. Product judgment begins by understanding the whole journey they share. #### Consequential clarity: Hide complexity, not consequences. A simpler interface should still expose the state and decisions that matter. Compression is useful only when it preserves trust. #### Inclusive access: Accessibility is architecture. Access cannot be a finishing pass. Interaction, state management, semantics, and recovery all need to support the full range of people using the system. #### Evidence: Turning hours into two clicks. I engineered a focused React experience for a multi-environment Dataverse import and export flow, then drove WCAG and UX improvements that made the operation both simpler and independently validated for accessibility. - **Who it served:** Finance administrators moving configuration safely across environments - **Product decision:** Compress a fragile, multi-hour process into a guided two-click path without hiding consequential state. - **What changed:** Multi-hour workflow reduced to two clicks · accessibility Gold ### Team leverage: Expertise should survive the expert. The strongest engineering improvement is one the next person receives without needing its original author in the room. I move context and judgment into defaults, tools, feedback loops, and release paths that help the team ship without waiting on ceremony. #### Durable context: Encode the context. Repository maps, generated documentation, agent workflows, and durable handoffs turn scattered knowledge into an operating system the team can share. #### Better defaults: Improve the default path. Leverage compounds when the reliable and efficient path is also the easiest one to follow, from local testing through release. #### Release flow: Make shipping routine. CI/CD should empower a team to release often, not leave it stuck behind ceremony. I remove checks that add delay without useful signal, preserve the gates that protect customers, and make the release path fast, stable, and predictable. #### Evidence: Making the fast path reliable. I architected scheduled Azure Foundry agents to make repository context reusable, then applied the same default-path thinking to delivery: parallelizing tests, replacing unstable external dependencies, and inverting a legacy two-repository relationship so releases were faster and less brittle. - **Who it served:** Engineers shipping fixes and features, plus customers waiting on dependable delivery - **Product decision:** Remove ceremony and unstable checks that do not improve confidence, then invest in the fast, reliable gates that let the team release often. - **What changed:** 7 days removed from release cycles · pipelines 40% faster ## Contact Have a complex product, engineering, or AI systems problem? Tell me what you're trying to make clearer, safer, or easier to ship. - **Email:** [johnny@johnnyleek.dev](mailto:johnny@johnnyleek.dev) ## Editions - [Accessible reading view](https://johnnyleek.dev/#/read) - [Interactive Curiosity Engine](https://johnnyleek.dev/) - [LLM discovery file](https://johnnyleek.dev/llms.txt)