Product Engineer

We don't write code. Agents do the implementation. But we reason about the architecture at a deep level — because the decisions we make depend on understanding how the system is built well enough to see what an agent can't. We need someone who can do that alongside us.

Reports to VP, Product and Co-Founder

The company

The company is the best way to build with AI. The architecture is a Deno-based CLI following domain-driven design across four architectural layers: CLI commands, domain logic, infrastructure, and presentation. There's also a server runtime (the company serve), a library (libswamp), and a distributed worker system. The extension system is the largest and most active domain — essentially a package manager with dependency resolution, bundle management, and a trust chain. Workflows are a DAG execution engine with guards, assertions, suspend/resume, and CEL expressions.

You'd work across the core CLI, the extensions ecosystem, and the acceptance test suite that gates every release. That last one is critical: it runs the compiled binary through real user scenarios and adversarial edge cases before anything ships. It's what makes agent-written code safe to release at this pace — and owning it means understanding how users actually use the product, not just how the code works. The expectation is true parallelization.

HOW WE BUILD the company

Seven people build it, shipping 30 releases a day. None of us manually write code. Agents do the implementation. We do the thinking: the architecture and the product decisions that shape what gets built and what doesn't.

This is the daily operating model. We built structured skill documentation for the agents to help them produce code that adheres to the architecture conventions we have built. Every PR goes through four layers of adversarial AI review. Issues get triaged, planned, and adversarially challenged before any code gets written. The system compounds: every convention we capture makes the next 500 agent sessions better.

We need another person who can work this way — someone who thinks clearly about what should exist and what shouldn't, and who can direct agents to build it when the answer is yes.

Here are 3 articles written by Paul Stack, the hiring leader for this role, that describe our approach;

• When Building Is Easy, the Danger Is Building Everything [link for members]

• The Lifecycle of the company Issue [link for members]

• Anatomy of the company PR [link for members]

WHAT YOU'D DO ON A GIVEN DAY

Make decisions agents can't. A user files an issue asking for a review workflow on extension publishing. The primitives exist. An agent could build it in an afternoon. You read the issue, understand the ask, and see that it would break the supply-chain integrity model the company is built on. You explain why, leave the door open for the future, and move on. That judgment call protected months of future work.

Review plans, not code. An agent produces an implementation plan for a new workflow feature — specific files, testing strategy, risks identified. The plan has already been adversarially reviewed. You read it and spot a coupling between two subsystems the agent missed because the constraint isn't in the code — it's a design decision you understand from studying the architecture. You reject the plan with two sentences of feedback. The agent comes back with something better in minutes.

Drive architectural evolution. A core file has grown a function with ten inline dependencies and duplicated logic. You direct agents through a multi-commit refactoring — extraction order matters, behavioral contracts need pinning as tests, and you insist on full verification after every commit because you know that's where the real bugs surface. You're not writing the code, but you're making every structural decision about where the seams go and why.

Own a domain end to end. You own extensions, or serve, or workflows — the code, the design doc, the skill references, the user-facing behavior. When an issue comes in for your domain, you triage it, decide whether it's the right thing to fix, direct the agent, review the output, update the skill so the next session is smarter. You don't wait for someone to decompose it for you.

Evolve the machine. An agent makes the same architectural mistake twice in a month. You don't just fix the plan — you ask why. A design doc doesn't cover a case. A skill reference is stale. A convention exists but was never written down. You capture it. Every agent session from that point forward gets that context. The system gets better because you made it better. In short, you must be obsessed with building the machine that builds the machine.

WHAT MATTERS / QUALIFICATIONS

What you’ll bring

• Software architecture fluency. You won't be reading diffs line by line — agents and review pipelines handle that. But you need to understand how software systems are built at a level where you can reason about architectural trade-offs, recognize when a proposed change violates a contract between subsystems, and have an informed opinion about why a system is structured the way it is. The decisions you make daily depend on that understanding. Product judgment without engineering depth is just opinion.

• Systems thinking. Can you understand why a system is built the way it is, not just how it works? When you look at a design decision, do you see the constraints it protects, the invariant that isn't in the code, the contract that breaks if you change the abstraction? Architecture is the easy part. Knowing what it's holding in place is what matters.

• Production instinct. Have you run systems and been woken up when they broke? It should shape what you design, what you test, what questions you ask before approving a plan. People who've carried a pager and have used tools like we are building, build differently from people who haven't.

• Our domain. Extensions, workflows, datastores, auth, CEL expressions, remote execution, telemetry- the company covers a lot of ground. You don't need to know all of it on day one, but you need to be someone who picks up unfamiliar territory fast and isn't fazed by the breadth.

• Product judgment. Can you tell a user no on a well-argued feature request, explain why with empathy, and keep the relationship intact? Can you see when a request conflicts with where the product is headed, even when the ask is reasonable today?

• AI fluency. Not prompting tricks — the ability to decompose work for agents, review their output critically, and build the conventions that make them better over time.

INTERVIEW PROCESS

First, on paper. Send us your resume or LinkedIn and a note about a system you've built, a hard call you made, and what you'd do differently now. We're looking for the skills in the "What You'll Bring" section above, not keywords.

Then, a conversation. An initial call with the hiring leader to see if you're a good fit for us and if we're a good fit for you. We'll talk about how you work, what you've built, and what you think about the space we're in. This goes both ways — we want you to have enough context to decide whether this is the right place for you.

Finally, the real thing. We'll hand you a real issue from our tracker — a well-structured feature request from a real user. We'll give you time with the codebase. Then we'll ask: "What would you do with this?"

We're not looking for the right answer. There may not be one. We're looking for your instinct and your thought process: do you jump to a solution, or do you ask the questions that need asking first? Do you think about what saying yes costs, not just what it delivers? Do you see the constraints the system is protecting, or just the feature the user wants?

We'll also want to hear about a time you said no to a good idea. Not a bad idea, a good one that was wrong for the moment. And we'll want to understand how you work with agents today: not which tools you use, but how you think about the system around them.

COMPENSATION AND BENEFITS

• Annual Salary: $200K - $250K in the United States

• We may adjust your salary based on your location if you reside outside the US

• You can live anywhere, as long as you work Pacific hours (8 AM to 5 PM). Life still happens during the day, like school runs, appointments and errands. Just let the team know when you're stepping away

• Up to twice a year, you'll join the team in person for Work Together Week at a location we choose

• Stock Option range: .20% - .25% Fully Diluted

• Medical, Dental, Vision, 401(k), etc. We are a small company with big company benefits provided by Deel PEO in the United States and Deel EOR outside the US

• Please request details if you would like to know more.

• A non-accrual PTO Plan, aka “unlimited”. We recommend a week off every quarter when you're completely offline

• A generous budget to meet your home office and equipment needs. Just articulate what you need, and we’ll take care of it

Elder the company, Inc., a/k/the company, is an equal opportunity workplace. We provide everyone with fair opportunities to attain their full potential. We understand, accept, and value differences amongst people, their backgrounds, and experiences. We actively promote a sense of belonging and full participation in our practices and policies for our co-workers, partners, and customers.

We make employment decisions without regard to race, color, religion, sex (including pregnancy), sexual orientation, gender identity or expression, national origin, age, disability, genetic information, veteran status, or any other characteristic protected by law. If you need a reasonable accommodation at any point in the hiring process, please let us know.