Principal Product Engineer

The Role

We are looking for a pragmatic builder-architect — a senior engineer who ships fast without leaving a mess, and makes architectural choices that hold up as the product scales. This is a hands-on technical leadership role: roughly 40% writing code and prototyping, with the remainder spent on architecture, mentoring, and raising the engineering bar within your team.

You will embed with a product team for extended periods, owning technical direction and building AI-powered features end-to-end — from idea through production. You won’t just advise; you’ll build, and what you build will set the pattern for others. You may end up managing some engineers.

Most engineers lean one way. “Hackers” ship fast but accrue debt; “architects” build clean abstractions but stall on delivery. You are both. You know when to prototype loosely and when to invest in the durable version — and you can articulate why.

What You’ll Do

• Design and build AI-powered product features — agent architectures, RAG pipelines, model orchestration, evaluation frameworks, and guardrails — with the same engineering rigor as any production system: testable, observable, gracefully degrading.

• Own the full stack for the features you build — application code, data, infrastructure — making end-to-end decisions about deployment, observability, cost, and security.

• Make architectural choices that optimize for reversibility early and durability when the problem is actually understood.

• Mentor and coach engineers on your team, transferring judgment and mental models, not just answers. Calibrate involvement to stakes: get out of the way for cheap-to-reverse work, lean in for load-bearing decisions.

• Read existing systems as accumulated knowledge before treating them as debt. Understand why things are shaped the way they are before proposing changes.

• Identify and manage the blast radius of technical decisions — the dangerous ones at this level aren’t bad deployments, they’re bad directions.

What We’re Looking For

Engineering Judgment

• You think in failure modes and second-order effects, not happy paths and demos. “Who inherits this, and what does it cost them if I’m wrong?” is a question you ask naturally.

• You optimize for sustainability — testability, clear boundaries, sane defaults, documentation — so what you build can be owned and extended by others.

• You treat constraints as the design problem. You map what’s frozen, what’s validated, what other systems depend on, and what can’t take downtime before proposing solutions.