AI-Native Software Engineer

About the role

Most engineering teams have added AI to their workflow. A few have rebuilt their workflow around it. We are moving to the second group, and we are hiring engineers to build it with us.

This is not a role where you build LLM products. This is a role where you build our product with agents.

You will work inside a real, high-traffic production codebase: the platform that 2,000+ brands use to engage customers across channels, processing 2.2 billion requests and delivering nearly 2 billion notifications every day. You will plan, implement, test, review, debug and ship features with coding agents doing most of the writing, while you set the intent and own the outcome.

You are not expected to arrive with a company-wide standard in your head. You are expected to already work this way every day, and to leave the team with better prompts, skills, agents and guardrails than it had before you.

If your first reaction to a repetitive workflow is "this should be an agent," we should probably talk.

Why this role exists

We looked at how our engineers work today. Some of them use AI to finish a line of code faster. That is autocomplete, and it is not what we mean.

We mean the full loop: you scope a change, an agent reads the codebase and writes a plan, you correct the plan, the agent implements across many files, runs the tests, fixes what it broke, and opens a pull request. You review the output like a senior engineer reviews a junior — because that is exactly what it is.

Some people already work like this every day. We want more of them on the team, and we want them building the tooling that makes it easy for everyone else.

Must have

• Daily use of coding agents on real work. Not a course, not a demo. Code with users, where the agent did a large share of the writing and you owned the result.
• At least one project you can walk us through end to end with these tools: what you delegated, what you kept, where it failed you, and how you caught it.
• Agentic experience: tool and function calling, multi-step workflows, state, error recovery, human-in-the-loop.
• Context discipline. You can show how you set an agent up to succeed — project files, standards, examples, scoped tasks — and how that cut your rework.
• Solid engineering fundamentals. Clean code, testing, error handling, security, performance. Agents make weak fundamentals more expensive, not less.
• The judgment to know when the agent is wrong. Speed is easy to fake. Judgment is not, and it is what we will test.
• Willingness to share it. You do not need to have run a training program. You do need to be the kind of person who shows a teammate the setup instead of keeping it.

Language is not a filter. Go and PHP/Laravel are preferred because that is what we run; Python, TypeScript or anything else is fine if the rest is there.

Nice to have

• Team-level tooling you built and other people used: shared skills, sub-agents, MCP servers, slash commands, or a review or test agent running in CI (Continuous Integration).
• Security habits around agents: forbidden patterns, least privilege on the tools and credentials an agent can reach, secrets kept out of AI context, AI-suggested packages verified before they are merged.
• Test and debugging depth with AI: coverage gap analysis, regression tests written from production incidents, root-cause work using observability data.
• LLM work: prompt engineering, agent SDKs, or orchestration frameworks such as Strands Agents, LangChain or LlamaIndex.
• Agentic patterns beyond the basics: RAG, MCP, skills, hooks, plugins.
• Experience designing scalable, highly available systems, ideally in Go.
• Curiosity about how these systems actually work under the hood: benchmarking them, breaking them, improving them.

On seniority

We are open on seniority. Mid-level and senior candidates are both evaluated, and your level comes from what you have shipped, not from the number on your CV. The one thing we do not flex on: agents are already how you work, not something you are planning to try.