Careers

Build platforms that do the work and prove it.

We are a small team building one platform and the vertical platforms on top of it. Coding agents write most of the code. People own the architecture, the controls and the tests, and read every line that ships.

There are no roles listed today. When there are, they will be on this page. Until then a short note about something you have built reaches the same inbox and gets the same reading.

How the work runs

Specify. Build. Review. Verify.

Working with coding agents does not mean less engineering. It moves the engineering to the two ends: saying precisely what must happen, and proving that it did. The middle gets faster; the ends get harder.

How we build with coding agents
  • You specify before you build

    A specification here says what the code must refuse to do, not only what it must do. An agent handed a vague specification writes plausible code that fails in exactly the case that mattered, and it fails confidently.

  • You review generated code like third-party code

    Nobody approves their own diff, and nothing ships because it looks right. The question in every review is the same: what breaks when this is wrong, and who finds out.

  • You verify with tests that fail on purpose

    A control nobody tested is a comment. Every control we write has a test that fails when the control is removed, and that test is as much the deliverable as the control is.

Who this team is built around

Three kinds of people, and a strong preference for range.

Small teams do not get to hire for one narrow shape. These are the shapes the work needs. If you are clearly one of them, or awkwardly between two, the note is worth writing.

  • Engineers who operate coding agents

    You are genuinely faster with agents than without them, and you can say exactly why a diff is wrong rather than only that it feels wrong. You have opinions about specifications, test design and what belongs in a review.

  • A controls specialist

    You have sat on the other side of the table: internal audit, financial control, risk. You know the difference between a control that reads well and a control an auditor accepts, and you can say which evidence settles an argument.

  • A designer who can draw a system

    Most of this product is a picture somebody has to understand in ten seconds: an approval bound to exact parameters, a reconciliation that did not match, a ladder of autonomy per action. You draw those, and then you help build them.

How to apply

One note. There is no form to fill in.

Write to us through the contact page, or straight to hello@ayion.ai if you would rather. Either reaches the same inbox.

  • What to send

    A link to something you built and two paragraphs on the hardest decision inside it: what you chose, what you gave up, and what you would do differently. No cover letter. A CV is welcome and is not what we read first.

  • What happens next

    A person reads it and replies. If there is something to talk about, the first conversation is with somebody who would work with you directly, and it is about the work rather than about your history.

  • Where the work happens

    The location and remote policy are not settled yet, and we would rather say that than publish one we would change in a month. Ask in your first note and we will tell you where it stands that week.

What we do not have yet

No open roles, no levelling ladder, no published benefits and no hiring pipeline worth the name. When those exist they will be written on this page rather than described in a call. Everything above is what we can commit to today.

Read how we build before you write.

The Company page has the loop every change goes through, and the one rule about shipping we will not trade away. If none of it appeals, this is not the team.