Integration engineer

Context

I maintain and extend a traceability system I didn't write. It records every seat that leaves the line.

Constraint

The codebase is legacy and shared between two developers. Changes can't break the running line or the audit trail Stellantis depends on.

Technical decision

I work additively: new features hang off the existing data model instead of rewriting it, and I read current behavior from the schema before touching code.

Trade-off

Additive changes keep the line safe but accumulate around an aging design — I trade architectural purity for continuity of production.

Result

Each seat stays traceable end to end while the system keeps growing, without a rewrite.

Context

Traceability and the Nodum ERP each hold half the truth about a seat. They have to stay in sync.

Constraint

The ERP is a system I don't control and can't change. It exposes SOAP and REST endpoints with its own rules and failure modes.

Technical decision

I integrate against its contract, not its internals, and instrument every call so a failure points to a cause instead of a generic error.

Trade-off

Defensive integration and logging look like overhead — until the ERP misbehaves, when they're the only thing that tells you where the problem is.

Result

The two systems stay consistent, and when a sync fails I can attribute it to the ERP's state — a closed accounting period, out-of-stock — instead of guessing.

Context

Operations needs to see the line's state in terms it acts on, not raw tables.

Constraint

The rules that matter live in plant procedure and people's heads, not in the schema — and there's no dedicated analytics backend to lean on.

Technical decision

I translate plant rules into SQL and expose them as Metabase dashboards, keeping the logic in queries close to the data instead of a separate service.

Trade-off

SQL-in-dashboards is fast to ship and easy to change, but pushes complexity into queries that take discipline to keep readable.

Result

Operations uses these dashboards every day to run the line.

Context

Missing parts on a finished seat are expensive to catch late. A camera on the line can flag them before the seat moves on.

Constraint

Inference has to run on a Jetson Nano at line speed — limited compute, no cloud round-trip — and hold up on the real, messy dataset, not a clean benchmark.

Technical decision

My part: training and iterating the detector, redesigning the class taxonomy against the real dataset, exporting to ONNX/TensorRT for the Jetson, deploying on the line, and integrating detections with traceability.

Trade-off

TensorRT on edge hardware buys the latency the line needs but costs portability — the model is tuned to that device and pipeline.

Result

Missing-part detection runs on the line and feeds back into traceability.

Team project. The orientation CNN classifier was a colleague's work; my contribution is the detector, its taxonomy, the edge deployment and the traceability integration.

Context

The systems I work on already exist and are messy. AI is useful here only if it operates on that reality, not on a clean demo.

Constraint

Output that feeds real systems can't be trusted blindly — every datum has to be accountable to a source.

Technical decision

I build agents and automations with the Anthropic API and Claude Code, with source traceability baked into the pipeline: everything that comes out either traces to a real source or is flagged as an assumption.

Trade-off

Demanding provenance on every field slows the pipeline and rules out some fully-automatic shortcuts, in exchange for output I can defend.

Result

AI tooling that plugs into systems already in production, where a wrong value has consequences.