Skip to content

ai engineer · redondo beach, ca

> Marcus Hobbs

#I define the AI SDLC, which is a software development lifecycle that AI agents execute, on new products first, so established products can adopt what has proven itself

I am an AI Innovation Engineer at Planet DDS, working in Team Artemis, our AI innovation lab. New products start there, so I can build the whole lifecycle without legacy constraints and measure it honestly, with people keeping the decisions and approvals at a few named gates. I work in language, so what I engineer are the prompts, workflows, and contracts the agents run under, and I leave training models to others. Then I carry what held up to the rest of engineering through an org-wide AI SDLC repository, which holds the context an engineer needs to adopt the pipeline and tailor it to their own stack, and through my talks.

  1. intake
  2. read
  3. write
  4. test
  5. deploy
  6. monitor
  7. feed back

On the largest feature so far, a 42-minute prototype walkthrough became 351 requirements and a dependency-wired ticket graph, and agent lanes merged 75 tickets in 30 waves over about four days, with a human approving every merge. See my production engineering results or how it works.

Marcus Hobbs

##how-it-works

Every stage of the AI SDLC is a prompt I engineered. Someone can arrive with a production incident, a designer's prototype, a feature request, or a security question and ask our context-ask workflow how to proceed. The repository provides the context and the established workflows, so the answer comes out of the specs, the learnings, and the code that are already there, and the work is routed into the pipeline below.

  1. [01]

    intake

    anything

    The work arrives as a prototype, a Figma file, a ticket, a production incident, a security question, a meeting transcript, or a freeform prompt, and the front door I built routes it. Small work takes a single lane to a PR and big features take the spec funnel.

    context-ask · triage⏸ human gate: scope
  2. [02]

    read

    requirements

    Parallel readers map the request against the shipped specs and the code, and they author requirements with permanent IDs before any code is written. The spec is then minted into thin tickets wired by blocked-by edges, so the loop can compute what is ready.

    spec-decompose · spec-reconcile · spec-author · spec-to-tickets⏸ human gate: accept / reject · epic approval
  3. [03]

    write

    implementation

    I make every plan survive a 5-lens reviewer panel before it runs. Then file-isolated agent teams build each ticket, and parallel lanes drain the ticket graph in dependency order.

    compound-plan · compound-debate · compound-master · compound-drain⏸ human gate: PR merge
  4. [04]

    test

    testing

    I derive the test cases before any code exists, under the same rules QA uses after merge, and anything underspecified becomes a line a human rules on. After the build the lead re-runs every gate, drives the live app in a browser, and reads the database for ground truth.

    compound-test-cases · verify · e2e⏸ human gate: spec rulings
  5. [05]

    deploy

    deployment

    The deploy stage works as an AI release engineer. I wrote it to read live production state first and build a go/no-go card from it, including a rollback answer with a named owner. On a green card it queues the pipelines, and a named human approves the gate every time, because the agent has no approve path at all.

    compound-deploy⏸ human gate: GO card · pipeline approval
  6. [06]

    monitor

    operations

    After the deploy it checks the live revisions and migrations against values written down ahead of time. Then it reads the error logs every ten minutes while people test, and every new error signature becomes a row for a human to look at.

    verify · soak · release ledger
  7. [07]

    feed back

    learning

    Learnings are captured before ship and applied automatically by future planning runs. Every run leaves code, specs, learnings, e2e tests, and a test-case ledger in the repository, and that is how the context concentrates there for the next person or agent who asks.

    learnings · spec snapshots · requirement ↔ e2e coverage

watch the whole loop run: the lane, the intake funnel, the drain replay, and the deploy →

##what makes the prompts engineering

I treat the prompts the way a team treats its code. They are versioned in the repository, and they run under contracts that make a multi-agent system something you can debug.

[a] schema

typed outputs

Every subagent fan-out defines a JSON schema and the harness retries until the output validates, so orchestration is always consuming typed data.

[b] budget

budgets and stop conditions

Spawn caps, a 3-strike rule keyed on root cause, and broken-baseline hard stops mean a run halts and escalates when it stops making progress.

[c] spec

requirements with addresses

Each requirement has a permanent, immutable ID, so an agent can go read the behavior it is building and a test can cite the row it proves.

[d] dial

autonomy with ceilings

Autonomy runs from L0 (assisted) to L3 (auto-merge), and heavy-risk changes such as migrations, auth, money, and sensitive data always cap at human-merge.

read the full method: nine principles and the five artifacts →

##proof

Production work at Planet DDS, written up in terms that travel outside the company that paid for it. Over nine months on a HIPAA-covered product, the three repositories this pipeline works in have merged 3,143 pull requests, and the repository now holds 2,087 live requirement rows and 859 learning files that every run reads before it plans.

[01] the largest feature so far

##prototype-to-drained-epic

75
tickets merged in 30 waves
~4.2d
first → last merge
6d
prototype walkthrough → last merge
351
requirements authored before the drain
17–19
tickets merged per day, four days running
75/75
merges approved by a human

This was the second full run of the pipeline, in August. A teammate walked me through his prototype for 42 minutes on an engineering sync, and I saved the transcript on purpose as spec input. Thirteen autonomous readers extracted 511 requirement candidates from it in about 25 minutes, I ruled the scope at two designed gates, and by the time the drain started the spec held 351 requirements and the dependency graph held 73 tickets.

Agent lanes then drained it in 30 waves over a little more than four days, two lanes at first and three from wave 13, merging 17 to 19 tickets a day through a model-provider outage and two nights where my machine went to sleep. I approved all 75 merges myself. The first run, a 45-ticket epic in July, is the one I presented publicly as "Agentic Loops and Graphs", and a third project began adopting the pipeline before this one had finished.

[02] a 37% re-open rate, and what I changed

##qa-reopen-rate-and-the-test-case-ledger

37%
QA re-open rate before
~15%
QA re-open rate after
7/7
reopened tickets caught in blind re-derivation
18%
the public ceiling for the next drain

That epic drained clean with every lane green, and then QA reopened 37% of its tickets, 35 of the 93 it had grown to by then, which was a real disappointment. A fix drain over those 35 came back at 37% again, and that is what sent me looking upstream. When I traced the findings back, about half of them were spec gaps and rulings rather than code defects, so I pulled QA's test-case derivation left of the build, and now the implementer, the verifier, and QA all execute from one ledger. I re-ran the derivation blind against seven reopened tickets with their inputs frozen, and it reproduced the later QA finding on all seven. The re-open rate since has been about 15%, and on stage in September I promised 18% or lower on the next full drain and said what result would prove me wrong.

[03] an AI release engineer

##production-deploy-with-a-record

4
production releases in six days
3
products shipped in one 50-minute window
58
tickets in release notes compiled from the record
0
red stages and rollbacks that night
0
production approvals an agent can grant

Until September a deploy here was a person at a keyboard with a checklist in their head. I wrote the deploy command by encoding what I had improvised by hand during one release night, and it shipped on September 14. It reads production first, derives the delta of pull requests, tickets, and migrations since the last green run, and prints a go/no-go card. On the first live window the card came back NO-GO on two checks, which was the system working, because it had named the two things only I could rule on. I typed my rulings in words, they were stored on the card with my name, and every production write still waited for a named human.

On September 18 one window shipped three products in 50 minutes with all four pipelines green, and the order mattered, because two of the products publish contracts that the third one's new endpoints consume, so its backend went first and everything else ran in parallel. The command verified by re-reading production, soaked the error logs every ten minutes while people tested, and compiled release notes that list all 58 tickets with their pull requests and authors, which I did not write by hand. Two of that night's approvals and their log watch were still done by hand, and they are rows in the ledger now, so the next window records them from the start. Each release leaves a ledger in git that the agent, the testers, and the log monitor all write to.

read the full case studies and explore the 75-ticket drain graph →

##conformance

An enterprise SDLC has to fit the enterprise it runs in, which means its regulatory requirements, its non-functional requirements, its stack, and the way its teams already write code. I build the pipeline so that it reads all of those from the repository.

[01] regulatory

##regulatory-and-non-functional

I ran a STRIDE threat model on a healthcare AI product and promoted its findings into three living spec catalogs: a security baseline, a HIPAA overlay that expresses the technical safeguards as engineering controls, and a PHI-handling catalog. The pipeline checks them at its review gates, and the gaps in our live posture became a requirement-cited backlog the agents can drain.

[02] stack

##tech-stack

I put the team's stack into the repository so the agents can learn it there. Architecture, service boundaries, and the asymmetries that bite in production live in CLAUDE.md files, skills, and the learnings catalog, and the agents verify their work against the team's real running app and real database.

[03] standards

##code-style-and-team-rules

A team's conventions become rules files, hooks, and review lenses, so they are consulted while the code is being written and checked again at review. When I have to correct an agent twice, that correction becomes a persistent rule and the next run starts with it.

I want to be modest about how far this has been proven. So far it is one company, one stack, and one regulatory regime, which is HIPAA. My evidence that the patterns travel is a survey I did of another team's prompt suite, about 6,800 lines with 21 slash commands, where five patterns carried over and were adopted into a different team's greenfield codebase. Since then I have templatized the pipeline in an org-wide repository so that teams on other stacks can adopt it, and I will know more about how well it travels as the company's established products take it up. The specs, the learnings, and the ledgers are all plain files in git, so the context belongs to the team that owns the repository.

##speaking

Talks at the Irvine AI meetup, where I am one of the hosts, held at Planet DDS headquarters. The field reports track the same arc as the work itself, running from prompt engineering to context engineering to loop and graph engineering, and in September to the whole loop, from intake through the production deploy. At the September meetup I also gave a second, lighter talk ranking the month's frontier AI news by how much it changes the work we do as engineers.

Marcus Hobbs presenting “Agentic Loops and Graphs” at the Irvine AI meetup, the title slide projected behind him
//“Agentic Loops and Graphs”— Planet DDS HQ, Irvine · jul 23, 2026
~60 attendees
[01] prompt engineering

##AI-First Engineering with Claude Code

A live demonstration of Compound Learnings, which is the recursively self-improving part of the prompt pipeline. The learnings are captured before ship and then applied automatically by future planning runs, so the debugging from one session becomes the head start for the next one.

meetup.com/irvine-ai · event organizer write-up
~50 attendees
[02] context engineering

##AI-First Engineering with Claude Code

How to get from fuzzy inputs to versioned functional requirements, and how to treat end-to-end tests as first-class artifacts that live in the repo instead of as an afterthought. This is the talk where I make the case that a requirement catalog should be infrastructure rather than documentation.

meetup.com/irvine-ai · event my write-up
~40 attendees
[03] loop & graph engineering

##Agentic Loops and Graphs

Prototype to specification to dependency graph to agent-executed tickets, walking the full drain from end to end. This is the talk about the first full run of the pipeline, a 45-ticket epic in July, which the case studies pick up from, and it covers how much engineering it actually takes to let agents ship production software, and where a human still has to decide.

meetup.com/irvine-ai · event organizer write-up
[04] whole-loop engineering

##The Whole Loop

The third field report, and the first one that reaches production. I walked the loop one level at a time, from the single-ticket lane to the intake funnel to the 75-ticket drain, and then to the part I am most excited about, which is the deploy command working as an AI release engineer. It reads production, prints a go/no-go card for a named human to rule on, runs the pipelines, verifies by re-reading production, and watches the logs while people test. I also showed how a 37% QA re-open rate traced back to the spec, and made a public promise of 18% or lower on the next drain.

meetup.com/irvine-ai · event watch the loop run on this site the deploy command
[05] reading the frontier

##29 Days at the Frontier

A countdown of the ten AI events between our August and September meetups that I think change the work of engineers the most, with every source on the last slide. My picks included the Opus 5.5 and GPT-6 price cuts, which make cost per decision the number to optimize in an agentic workflow, the sandbox escapes at every frontier lab, which mean an eval sandbox is a production security boundary, and Anthropic's R&D Automation Index at number one, because a monitor in front of every agent action, with everything reviewed again afterward, is the architecture I have been building toward with my own drains and release gates.

meetup.com/irvine-ai · event the gates and the soak in my pipeline

// attendance figures are my own estimates rather than gate counts

##experience

[2025 ─ present]

Planet DDS · AI Innovation Engineer

I work in Team Artemis, the company's AI innovation lab, where new products are built. I designed and I run the agentic SDLC described above on those products, which is 15 compound commands, 6 spec commands, and a deterministic debate engine. Much of the work crossed roles. I lifted QA's test-case rules into the pipeline so the implementer, the verifier, and QA all execute from one ledger, I turned a designer's 42-minute prototype walkthrough into 351 requirements, and I wrote the deploy command that release approvers and testers now work inside. Then I lifted the prompt pipelines out of two product repositories into an org-wide AI SDLC repository, templatized so that an engineer on any tech stack has the context to adopt the pipeline and tailor it, and that repository and my talks are how the approach is reaching the company's established products. I am also one of the hosts of the Irvine AI meetup, which is held at our headquarters.

[2020 ─ present]

Wilsonic MTS-ESP · Freelance · C++ audio plugin and agent-driven tuning research

A cross-platform JUCE plugin for microtonal scale design, and a research harness where an agent runs experiments against a frozen, hash-pinned scorer.

[2023 ─ 2024]

Brilliant · Senior Engineering Manager

I led full-stack delivery across web and mobile in React, Swift, Kotlin, Node.js, and GraphQL.

[2019 ─ 2023]

Credit Karma · Engineering Manager II

I managed full-stack teams shipping financial products, with a lot of attention going to secure auth, PII handling, and revenue tracking.

[2014 ─ 2019]

AT&T · Associate Director, Software Engineering

I led full-stack and mobile development of AT&T's streaming video service, and I led the Innovation Lab, where we built ML prototypes for sentiment analysis.

[2011 ─ 2014]

DirecTV · Senior Software Engineer

I shipped the flagship iPad and Apple TV streaming apps and migrated the codebase from Objective-C to Swift.

[path]
I managed engineering teams for about ten years, at AT&T, Credit Karma, and Brilliant, and Team Artemis is my second innovation lab, after the one I led at AT&T. I went back to building with my own hands, because agents made it possible for one engineer to design and run a whole delivery system. The management years are the reason the pipeline has named gates, ledgers, and owners, since that is where I learned what a team needs before it will trust work it did not watch being done.
[stack]
Claude Code (CLAUDE.md · Skills · Rules · Hooks · Commands · Memory) · MCP · Playwright · React · Next.js · TypeScript · FastAPI · Python · PostgreSQL · SQLAlchemy · ASP.NET Core · Swift · C++
[education]
Bachelor's degree in Mathematics and Computer Science, University of California at Riverside
[lab]
Outside the day job I apply the same discipline to a microtonal research harness, an open-source persona dialogue system with a hidden conversation director, and an interactive field atlas of Tioga Pass. see the lab →

contact Marcus Hobbs

// get in touch

I am open to Staff AI Engineer roles at AI labs and enterprise engineering teams, and to consulting engagements. I build agent-driven software delivery workflows, including requirements, testing, and release controls.

To start a conversation, email me with your team or organization, the role or problem you have in mind, and the relevant case study. For a project, include the scope and timing you are considering so I have the context for a useful reply.

[email]
marcushobbs@mac.com
[github]
github.com/marcus-w-hobbs
[linkedin]
linkedin.com/in/marcushobbs
[phone]
+1 (818) 802-4085
[loc]
Redondo Beach, CA