AI-native engineering is splitting in two. On one side: builders who decide what to build and ship it fast. On the other: systems experts who make sure what's built actually works.
Two recent signals point this way. Anthropic's Claude Code engineering lead said she now hires against just two profiles. She summed up one of them in a now-quoted line: "Taste is scarce, typing is not."
Dan Shipper writes the AI newsletter Every. In a March 2026 essay, he argued that the 2026 engineering team should be just two people. He calls them "the pirate and the architect."
Both signals name the same two seats. The work between them — assembling features, debugging integrations, writing glue code — is what LLMs are absorbing.
The claim, plainly
The two seats are each defined by something specific.
The pirate is defined by judgment about what to build. The architect is defined by judgment about whether what's built holds up.
Both seats existed before this AI wave. What's new is that frontier teams now structure their engineering hiring around these two profiles specifically, instead of hiring "engineers" and slotting them in later.
The work that used to sit between the two — implementation, glue, integration — is changing fast. LLMs do more of it every quarter. The hours that used to go there are redistributing to the bookends.
This isn't yet the universal hiring shape across all of software. It's the shape at AI-native frontier companies: the AI labs and AI-first startups that hire most aggressively. Traditional companies typically copy these patterns 12–24 months later.
What the pirate seat actually is
The builder profile is defined by a single hard skill: knowing what to build.
Anthropic's lead said it bluntly: "Taste is scarce, typing is not."
Writing the code is now the easy part. Anyone with an LLM in the editor can turn a clear specification into working software in hours. What's hard is figuring out the specification — which problem to solve, which features to ship, which prototypes to throw away.
This is the work the pirate owns. The day-to-day loop:
- Watch users use the current product.
- Identify the specific small problem worth solving next.
- Prototype a solution in a day or two.
- Show it to users.
- Decide whether to invest more time or throw the prototype away.
The product surface — the thing users actually touch — is theirs end to end. They aren't owning a layer or a service. They're owning a thing the user uses.
A pirate's day looks more like a designer's day than a traditional engineer's day. Most of their time goes into looking at the product, talking to users, and judging their own work. The code is the easy part of the job.
The line between this profile and what we call AI Agent PM is thin when the product is an agent. A builder who owns the agent and a PM who owns the agent can be the same person. Both are decisions-first, code-second.
What the architect seat actually is
The systems-expert profile is defined by the inverse skill: knowing what could go wrong, and making sure it doesn't.
LLM-powered features are harder to make correct than traditional software features. They can be wrong in subtle ways that aren't visible until production traffic hits them.
They can be right today and wrong tomorrow after a model update. They can pass every test you write and still fail in ways you didn't think to test for.
This is what the architect owns. Three specific responsibilities:
- Evaluations — small test suites that score whether the AI is behaving correctly.
- Trust boundaries — drawing where the AI is allowed to decide versus where humans must approve.
- Monitoring — catching subtle drift in production before customers notice.
Where the pirate moves fast and ships rough, the architect moves carefully and ships durable. The unit of work isn't the feature. It's the system that makes the feature reliable.
Of the five role archetypes on this board, the closest match for the architect seat is AI Evaluation/QA. The architect seat is broader than that. It also pulls in infrastructure and distributed-systems work that requires substantial engineering depth. AINative.careers doesn't index on that work.
Why the middle is shrinking
Engineering work has three rough phases: decide what to build, build it, prove it works.
The first phase is the pirate's job. The third phase is the architect's job. The middle phase is implementation — writing the code, integrating libraries, debugging integrations.
The middle phase is what LLMs are mostly absorbing.
This doesn't mean engineers in the middle are out of work. It does mean the middle phase no longer requires the same number of full-time human-engineer hours it used to. Those hours are redistributing to the bookends.
What survives in the middle: situations where the implementation work is genuinely hard, novel, or requires deep domain context an LLM doesn't have. What gets absorbed: situations where the work is "I know what I want, I just need to type it out."
A useful self-test. If you'd describe most of your last sprint as "I had to figure out X," that's bookend work and it's safer. If you'd describe it as "I had to write X," that's middle work and it's not.
Pirate first, architect later
Companies don't need both profiles at the same time. Shipper's argument adds a useful timing layer on top of the role description.
Before product-market fit, a company needs pirates. They're trying to find what works. Speed of iteration matters more than reliability — most of what gets shipped will get thrown away anyway.
A pirate can prototype five things in a week. An architect would still be drawing the system diagram for the first one.
After product-market fit, the priorities flip. The company knows what works. Now they need it to keep working — reliably, at scale, without the subtle failures that erode customer trust.
This is when companies bring in architects, often fractionally. A single architect can cover several products that are all past PMF.
| dimension | pirate | architect |
|---|---|---|
| shape | full-time, product-coupled | fractional, portable |
| stage | pre-PMF, pre-launch | post-PMF, scaling |
| scope | one product, end-to-end | many products, one concern |
| cadence | hours-to-days iteration | weeks-to-quarters |
| success metric | did the right thing ship | did the system stay correct |
Two distinct career shapes fall out of this timing pattern.
The pirate career runs deep on one product at a time. You commit to one surface and ship it through PMF.
Then you either stay through scale or jump to the next pre-PMF surface. Most pirates jump — they don't enjoy the slower pace. Compensation typically tracks equity and ownership.
The architect career runs across many products. You become known for a specific kind of correctness — eval design, agent reliability, retrieval boundaries. You sell that expertise to teams.
Compensation tracks rates and reputation, more like a senior consultant than a salaried engineer.
Neither shape is better. They're different. The choice you make here shapes everything downstream: your portfolio, your résumé, your interviews, your network.
Which pole is this listing testing for?
A listing's title doesn't tell you which profile it's testing for. The responsibilities section does. Three questions to ask before spending a screen on it.
- Does the listing name one specific product surface you'd own end-to-end, including kill decisions? → pirate seat. Apply if that's where you want to be.
- Does the listing name a reliability, correctness, or eval surface that cuts across products? → architect-shaped. Apply if you want fractional or systems work.
- Does the listing say 'we need someone who can do a bit of everything'? → the squeezed middle. Read the responsibilities carefully before applying.
The third pattern is the one most candidates miss. The listing reads fine. The recruiter is enthusiastic.
But the role itself is in the middle. The description sounds like work for someone who assembles features, debugs integrations, and bridges teams between product and engineering. That work is changing fast.
Twelve months into that job, you may quietly find the team restructured around one of the two profiles — and you're trying to migrate into one of them from a standing start. Better to make the choice now.
What to ship this quarter
The portfolio gap is the same regardless of which profile you pick.
Most candidates have shipped work, but they don't have evidence of judgment. Pirate hiring managers have read fifty "I built X" résumés this month. Architect hiring managers have read fifty "I scaled Y" résumés this month. What moves either screen is evidence that's specific and rare.
If you're aiming at pirate, ship these three
- A killed-feature memo. One page on something you chose not to build, with the reasoning. Most candidates only show what they shipped. Showing what you chose to kill is a stronger signal of product judgment than another shipped feature.
- A prototype reel. Three 60-second walkthroughs of things you prototyped in under a day each. For each one, name the specific hypothesis you were testing.
- A written critique of a real product. Ranked issues, specific fixes, the redesign you'd ship if you were running it. Generic complaints don't count.
If you're aiming at architect, ship these three
- A small eval. It doesn't need to be sophisticated. Pick one prompt or one workflow you've worked with. Design a test set, score it, write up the failure analysis.
- A reliability postmortem. Something you saw break in production. What the failure mode was. What you changed. What you deliberately didn't change.
- A structured-contract writeup. One page identifying a place you'd add a verification boundary that doesn't currently exist, and why.
These artifacts should travel with your résumé. They are more convincing than a cover letter ever was, because they show judgment instead of describing it.
Pick one
The instinct when you see this map is to claim both profiles. "I can prototype fast and I think hard about correctness." Most candidates write some version of that line.
To either hiring manager, it reads as neither.
The pirate hiring manager isn't moved by your eval story. They're trying to fill a seat that ships product.
The architect hiring manager isn't moved by your prototype reel. They're trying to fill a seat that prevents production failures.
Neither is looking for a balanced engineer. They're looking for a profile.
Pick the profile that fits how you actually like to work. Think about the pace, the unit of ownership, and the kind of evidence you want to spend your time producing.
Then ship the three artifacts for that profile this quarter. Stop sending résumés that try to claim both.
If you genuinely don't know which profile fits, watch yourself for a week. Notice what you reach for at 9pm on a Saturday.
If it's a new prototype to test an idea you had on the bus, you're a pirate. If it's the failure mode you noticed on Tuesday that's still bugging you, you're an architect.
Either is a real career.