AI Engineer, Software Factory

Bernard runs scheduling, diagnostics, and support for appliance-repair service companies. We are a small team shipping a large surface, and we have decided that the way to keep doing that is to treat our own engineering as a factory with instrumentation: measured flow, measured quality, measured reliability, and agents doing a growing share of the bounded work inside a runtime that cannot hurt us.

The factory has a second customer inside the company: our implementation teams. They sit with accounts, tune scheduling configuration, fix playbooks, and find the one roster or dial that explains a week of held tickets. Today the fastest fix is often a script with an apply flag and a careful person. The factory should hand them that power without the risk: changes they can propose from the field, simulate against the account's own history, ship behind a version-bound approval, watch under guardrails, and roll back by receipt rather than by memory.

Every one of those field fixes should also become a measured treatment so we learn whether it worked and whether it belongs in the product.

The same machinery points outward. Because we sit inside our customers' workflow, we see the numbers that matter to a service business: qualified intents to booked jobs, bookings to resolved cases, contribution per case, where the funnel leaks. Those numbers should be goals that agents work toward, with experiments, evidence, and a human holding the approval. Engineering metrics, field changes, and customer outcomes sit on one board and run through one loop.

You will own that loop. The Software Factory board and its source adapters, the sandboxed agent runtime that produces changes with signed evidence, the authority and lease model around it, the measurement plane underneath, and the customer-facing goal and experiment runtime. This is an AI engineering role with product ownership, and most of your hardest problems will be about evidence, authority, and trust rather than prompts.

• Own the Software Factory board. Source adapters for Git Hub, Sentry, Grafana, and Linear normalize external facts into repository flow, review latency, change failure, incident load, and agent-factory health, on the same certified measurement plane as customer metrics.
• Define the engineering metrics we actually steer by, version them, and name the ways each one can lie. Lead time means nothing if half the PRs are agent noise. You will know, and the board will say so.
• Pick the bottlenecks worth an agent and the ones worth a human, and prove the difference with numbers rather than vibes.

• Give field engineers a safe path from "I see the problem at this account" to "it is fixed and measured" without a raw database session. Configuration edits, roster and capability changes, playbook tweaks, and operational repairs become reversible, versioned treatment artifacts with the account as the scope.
• Make simulation the default gate. A proposed change replays against the account's historical scheduling or the call-simulation harness before anyone can apply it, and the evidence travels with the approval request.
• Build the operator tooling itself: dry-run by default, apply behind an explicit and expiring grant, compare-and-set writes, post-write verification, a receipt for every change, and rollback that works without anyone remembering what the old value was.
• Turn field fixes into learning. When the same repair shows up across accounts, it should surface as a product hypothesis, not stay a tribal script.

• A pinned, deny-by-default sandbox receives one compiled work envelope and one disposable…