Skip to content
Swamp Club

Product Engineer

WorldwideRemote · worldwide
FullTime · Research and Development
POSTED 29 OCTVERIFIED 1D AGO
Apply Ask
Role
10 days opentrue age
Posted 29 Oct
CompanySwamp Club →
3open roles
Opened · 30d
+0
Closed · 30d
−0
30d window
Market
37,439open · Software engineering
Opened · 7d
+1,5264% of open
All software engineering
74,997open
All tracked boards · live 9 Nov · n=37,439
Go

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

Swamp

Swamp 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 (swamp 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 Swamp

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

The Lifecycle of a Swamp Issue

Anatomy of a Swamp PR

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 Swamp 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.

Source · Swamp ClubFirst seen 7 NovOriginal ↗