Skip to content
jonathanhodak.com

AI systems / engineering leadership

AI systems I build, run, and improve.

I build and operate software and AI systems daily, from architecture and infrastructure to tools and products. My personal lab compresses the engineering feedback loop; firsthand results sharpen the judgment I bring to enterprise platforms.

Current platform workMission Control
  • AI engineering strategy
  • Platform architecture
  • Engineering enablement
  • Agent systems
  • Model strategy
  • Evaluation and evidence
  • Infrastructure
  • Technical execution
Operating systemFIG. 01
StrategyArchitectureEvidence
A stylized view of work moving through an AI engineering system.

Mission Control / system behavior

Watch work move through the system.

Simplified views of systems I design, build, operate, or apply in my engineering work. Most come from my own workshop; the enterprise view describes my professional architecture work across systems owned by many teams.

Selected system view: Harness engineering

Active system view

DESIGNED · BUILT · OPERATED

The model is one component in an engineered system.

01 / 06
System view
I build and use this harness daily in my personal engineering workflow: a dedicated server-side sandbox, deterministic discovery, scoped context, model choice, bounded agents, validation, review, and evidence.
Engineering value
The harness turns capable models into focused, inspectable engineering work that I can evaluate and improve.
Harness engineering — conceptual system topologyAn architectural illustration, not live telemetry: deterministic discovery narrows the task before model work, then orchestration carries it through tools, validation, review, and evidence. The specialist-model node shows a future experimental path. Execution mode: continuous. Components: Repository intelligence (Code graph · indexes); Deterministic discovery (Find relevant structure); Task-scoped context (Evidence · retrieval); Model routing (Capability · cost · risk); Local model (Private · low latency); Specialist model (Future · after evaluation); Frontier model (Harder reasoning); Bounded agent (Assigned work · tools); Defined capabilities (Scoped tool access); Workflow orchestration (Dependencies · retries); Deterministic validation (Tests · contracts · checks); Independent review (Inspect evidence); Human escalation (Resolve risk or ambiguity); Execution evidence (Context · actions · outcome); Evaluation and learning (Routing · future datasets). Ordered stages: Repository intelligence; Deterministic discovery; Task-scoped context; Model routing; Local model and Frontier model; Bounded agent; Defined capabilities; Workflow orchestration; Deterministic validation; Independent review; Execution evidence. Feedback loop: Execution evidence; Evaluation and learning; the next continuous pass explicitly revisits Task-scoped context; Model routing; Local model and Frontier model; Bounded agent; Defined capabilities; Workflow orchestration; Deterministic validation; Independent review; Execution evidence. Connections: Repository intelligence to Deterministic discovery; Deterministic discovery to Task-scoped context; Task-scoped context to Model routing; Model routing to Local model; Model routing to Specialist model (conditional); Model routing to Frontier model; Local model to Bounded agent; Specialist model to Bounded agent (conditional); Frontier model to Bounded agent; Bounded agent to Defined capabilities; Defined capabilities to Workflow orchestration; Workflow orchestration to Deterministic validation; Deterministic validation to Independent review; Independent review to Human escalation (when required) (conditional); Independent review to Execution evidence; Execution evidence to Evaluation and learning (feedback); Evaluation and learning to Model routing (feedback); Evaluation and learning to Task-scoped context (feedback); Human escalation to Execution evidence (accepted decision) (conditional). Optional conditional paths are shown but do not run in the illustrated sequence.RepositoryintelligenceCode graph · indexesDeterministicdiscoveryFind relevant structureTask-scoped contextEvidence · retrievalModel routingCapability · cost · riskLocal modelPrivate · low latencySpecialist modelFuture · after evaluationFrontier modelHarder reasoningBounded agentAssigned work · toolsDefined capabilitiesScoped tool accessWorkfloworchestrationDependencies · retriesDeterministicvalidationTests · contracts · checksIndependent reviewInspect evidenceHuman escalationResolve risk or ambiguityExecution evidenceContext · actions ·outcomeEvaluation andlearningRouting · future datasets
  • idle
  • incoming
  • active
  • outgoing
  • settled

Conceptual sequence · not live telemetry.

Execution sequence

  1. 01
    Repository intelligenceRepository intelligence → Deterministic discovery
  2. 02
    Deterministic discoveryDeterministic discovery → Task-scoped context
  3. 03
    Task-scoped contextTask-scoped context → Model routing
  4. 04
    Model routingModel routing → Local model · Model routing → Frontier model
  5. 05
    Local model + Frontier modelLocal model → Bounded agent · Frontier model → Bounded agent
  6. 06
    Bounded agentBounded agent → Defined capabilities
  7. 07
    Defined capabilitiesDefined capabilities → Workflow orchestration
  8. 08
    Workflow orchestrationWorkflow orchestration → Deterministic validation
  9. 09
    Deterministic validationDeterministic validation → Independent review
  10. 10
    Independent reviewIndependent review → Execution evidence
  11. 11
    Execution evidence

Ongoing learning loop

  1. 01
    Execution evidenceExecution evidence → Evaluation and learning
  2. 02
    Evaluation and learningEvaluation and learning → Task-scoped context · Evaluation and learning → Model routing

The next pass explicitly revisits Task-scoped context → Model routing → Local model + Frontier model → Bounded agent → Defined capabilities → Workflow orchestration → Deterministic validation → Independent review → Execution evidence for another pass.

Conditional paths

  • Model routing → Specialist model · Future · after evaluation
  • Specialist model → Bounded agent
  • Independent review → Human escalation · Resolve risk or ambiguity · when required
  • Human escalation → Execution evidence · accepted decision
Conceptual execution · explicit dependencies · not live telemetry
Illustrative architecture / grounded in engineering workExplore system

Current work / enterprise AI platform

Architecture spanning six or more engineering teams.

In my current contractor engagement in a large enterprise retail environment, I contribute architecture to an internal AI platform initiative. I help connect capabilities built by separate teams into a coherent platform and shared employee experience; those teams remain responsible for their systems.

How the scope grew

I contribute cross-team architecture and technical direction. The participating teams build and remain responsible for their systems.

Architecture focus

Connect independent capabilities into a usable platform.

  • Cross-team architectureService boundaries · Integration patterns · Common architecture
  • Application and workflow architectureApplication architecture · Navigation · Workflows
  • Shared AI platform capabilitiesPlatform consolidation · Reusable patterns · Deployment and runtime
  • Engineering enablementStandards · Developer enablement · AI-assisted practice
Explore the platform architecture

AI leadership / operating model

Enterprise AI is an engineering system.

Enterprise AI adoption depends on coordinated engineering across people, platform, models, governance, and product delivery. Model strategy sits inside that wider operating system.

  1. DOMAIN 01

    People

    Build capability and shared practice across engineering teams.

    • Training
    • Adoption
    • Engineering practices
    • Standards
  2. DOMAIN 02

    Platform

    Make useful AI capabilities available through a coherent system.

    • Context
    • Tools
    • Orchestration
    • Evaluation
    • Observability
  3. DOMAIN 03

    Models

    Match model capability to the task and its operating constraints.

    • Routing
    • Cost
    • Latency
    • Capability
    • Local and hosted
  4. DOMAIN 04

    Governance

    Make authorization, validation, and review proportional to risk.

    • Authorization
    • Validation
    • Proportional review
    • Evidence
  5. DOMAIN 05

    Product delivery

    Connect the engineering system to product work and business outcomes.

    • Build
    • Operate
    • Deliver outcomes
Evidence from delivery should shape governance, platform architecture, and model choices as the operating system evolves.

Engineering principles

Direction, expressed as practice.

A system-level approach to making AI useful, affordable, observable, and safe inside real engineering work.

  • 01

    Increase engineering leverage

    AI should increase engineering leverage without removing engineering discipline.

  • 02

    Prefer deterministic systems first

    Use a small, deterministic tool when it can do the job; reserve model reasoning, including frontier models, for work that benefits from it.

  • 03

    Match intelligence to the task

    Use the least expensive model that reliably solves the task, considering latency, privacy, and the cost of failure.

  • 04

    Share platform capabilities; keep domain ownership clear

    Centralize reusable AI capabilities while product teams continue to own their domain behavior and data.

See all eight engineering principles

Career / increasing scope

A progression from operations to AI platform architecture.

My work has moved from training and operational process through engineering, architecture, management, and founding roles to enterprise AI platform architecture.

  1. 01

    Early leadership

    Operational leadership, training, and process

  2. 02

    Engineering foundation

    Web engineering, experimentation, and systems

  3. 03

    Technical leadership

    Mentorship, standards, and platform modernization

  4. 04

    Enterprise architecture

    Front-End Architect

  5. 05

    Engineering management

    Engineering Manager

  6. 06

    Founding engineering

    Founding Engineer

  7. 07

    Current

    Architecture spanning an enterprise AI initiative

See selected leadership evidence

AI Lab / systems and experiments

Working systems and experiments.

Built work, benchmarks, active tests, and future investigations each have their own stage. Results from real use inform the next iteration and my professional judgment.

  • TOPIC 01
    Benchmarking

    Local model performance and routing

    I benchmark local inference on my AMD Strix Halo machine with 128 GB unified memory, comparing context, quantization, runtimes, latency, and task quality before changing routing.

  • TOPIC 02
    Built and used

    Deterministic code exploration

    I built and use indexes, syntax-aware analysis, repository graphs, and targeted retrieval to find relevant code before model reasoning.

  • TOPIC 03
    Testing

    Context-size experiments

    I am testing how context selection and size affect task quality, completeness, latency, and cost.

View the full AI Lab

Technical depth / supporting detail

Hands-on depth, in context.

I stay hands-on across the systems I architect. The tools matter as part of the broader engineering work, not as a list on their own.

I still build and operate across applications, APIs, data, models, and infrastructure. That firsthand work informs my architecture and leadership decisions.

Applications and services

  • TypeScript
  • React
  • React Router
  • Node.js
  • APIs
  • OAuth

Data and retrieval

  • PostgreSQL
  • Supabase
  • Vector search
  • RAG

AI systems

  • MCP
  • Local inference
  • Model orchestration
  • Agent systems
  • Evaluation
  • Observability

Platform and infrastructure

  • Linux
  • Docker
  • Vercel
  • Deployment systems

Contact

Compare notes on what’s working.

I’m glad to compare notes on AI engineering, enterprise platform architecture, or the practical work of bringing AI into engineering teams.

Contact information