The Experience Engineer

The jobs moved

AI development is an uncertain practice right now. The tools change faster than the titles, and the work under the titles changes faster than either. What a team should hire for, and what a person is responsible for when an assistant did half the task, gets rewritten every few months.

Look across the market and the jobs have pivoted in place. Each one has taken on more responsibility than the title was built for. The marketer produces the campaign. The designer ships the interface. The engineer decides what the product should be. Scope piled onto the same people. The old boundaries were how companies kept each kind of work honest. The boundaries are gone, and the honesty did not come along with the extra scope.

Marketing is where that shows most clearly. The deliverables are subjective. A line, a landing page, a deck, a cut of a campaign. They are judged by whether they feel right to the people approving them, and they are rarely scrutinized for accuracy. The assistant is fluent at exactly that kind of work. It writes copy that sounds like the brand and claims nobody checked. When the process never asks whether something is true, or whether it does what it says, AI slop is the rational output. More of it, faster, with the same approval. I see it in the marketing work around the products I build. The pages look finished. Fewer and fewer of them had to survive a standard.

Product work gets less mercy, because someone uses it. A wrong state, a lost save, a confident answer with nothing behind it: those show up as the experience. On this side of the same pivot, a role is forming that still does not have a stable name.

A name for the work

When the title fits everyone, it describes the tools. The job is still the product.

Companies post it as a design engineer, a UX engineer, sometimes an AI experience engineer. This year Precisely asked for an Experience Engineer who would take a product from the first sketch of an interaction to a tested, shipped interface, using AI tools along the way. J.D. Power asked for an AI Experience Engineer and described a full-stack engineer who owns the human-facing layer of the product. The titles are wandering. The work is settling.

An Experience Engineer is a software engineer who develops with an AI assistant and whose output is the user experience. The person in the role is 80% engineering and 20% UX. Product design and product development are the same effort. The experience is the goal of both. The engineering share is the background, the hard layer, and the runtime. The UX share is the judgment of that experience. The extra responsibility is real. The difference from the marketing failure is the standard it answers to.

For a long time that job was split so the standard could be staffed. You were a designer who could code, or an engineer with taste, and the company still divided the work. Research became a spec. The spec became a picture. The picture became tickets. The tickets became a pull request that almost matched the picture. Each handoff was a place for the experience to thin out, and we called the distance between them process.

The distance was rational when building was the expensive part. A wrong screen cost a sprint, so teams protected the sprint with specialists and with artifacts that stood in for the product.

Building is no longer the expensive part. You can describe a screen, generate it, throw it away, and generate another before lunch. The cost that stayed is judgment. Left alone, that is the same condition marketing fell into: fluent output, light scrutiny, slop.

The assistant takes the work that can be vibecoded. Describe the outcome, take the draft, adjust the surface, move on. Screens, copy, the first shape of a flow, a component that matches a picture. That work got cheap, and it should stay with the assistant.

1. 1
   Engineer the product Still works without an assistant
2. 2
   Own the experience Design and build, one loop
3. 3
   Assistant at build time Draft the surface, then reject
4. 4
   Keep the hard layer Pay, identity, account, stream
5. 5
   Experience engineer A runtime others can trust

Intent architecture

Understanding the intent remains the most crucial part of software development, and of solving any problem. The problem is the most important piece. A screen, a platform, an assistant: each of them comes after that.

The assistant can draft a screen from a sentence. It cannot tell which sentence was the product.

Intent is what a person is trying to do, and what the product agreed to do back. Architecture is how that agreement is held. It has to survive a new draft, a rented platform, and a second person who was not in the room when the promise was made.

The role of intent architecture is to settle those promises while the product is being made. A payment happens once. The session belongs to one person. The account can be left. The stream keeps the write. The screen is allowed to say those things. It is not allowed to invent a different agreement because a draft sounded finished, or because the platform's default was close enough.

Without that structure, the build stays a conversation. The assistant fills a gap with something plausible. The platform fills a gap with something familiar. The user arrives and the product is still deciding. A fluent checkout charges twice. A personal agent stays a workshop. The experience looks complete and has no standard underneath it.

Governance, infrastructure, and the experience are the three places the intent has to hold. Governance is the promise, written so it can be checked. Infrastructure is the path that keeps the promise when the click happens again, and when more people arrive. The experience is what a person can tell from the outside. If one of them can drift, the other two are describing a product you do not have.

The work that cannot be vibecoded

The engineer focuses on the work that is no-vibecodable: reliable infrastructure, and trust. An assistant can draft the screen for each of these in an afternoon. It cannot be accountable for what happens after someone depends on it.

A payment gateway

The checkout can look finished and still be a lie. The button says the payment went through, the webhook arrives twice, and the person is charged twice. Or the charge lands and the thing they paid for never unlocks. Money is the experience telling the truth in the only unit people audit. A payment has to happen once, reach the right account, survive a retry, and be reversible when the product was wrong. That is idempotency, a ledger, and a failure the user can understand. The assistant can draw the button. The engineer keeps the path the money actually takes.

Authentication

A login form is easy. Authentication is the product knowing who is there. A session that expires when it should, a recovery flow that cannot be used by the next person, a boundary that does not confuse two users who arrived at the same screen: that is the work. People trust a product that recognizes them and does not hand their place to someone else. Looking logged in is the surface. Being logged in is infrastructure. Trust starts at that difference, because every later promise — your files, your history, your payment method — depends on the product having the right person.

Account management

An account is that person over time. What they can change. What they can export. What happens when they leave. Who else can see their work. How they get it back when the session dies. A personal agent has one account, and it is the author. A product has many, and each one has to be manageable without the author in the room. This is the part that makes sharing possible. A workspace with a login screen in front of it is still a workspace. An account someone can recover, close, and trust with their data is a product.

Scale and the stream

The experience has to hold when that person is no longer the only one. Infrastructure for scale, and for data streaming, is the work of arrival. A queue that does not drop the write. A stream of events that stays in order. A system that remains honest when a hundred people do the thing the author did once on a laptop. The demo can be vibecoded. The path the data takes as it moves, and as more people show up, cannot. This is also where token minimizing becomes physical. A runtime that asks an agent to reconsider the task for every event will not become an experience anyone can trust under load. The stream should carry what the build already decided. The model stays where a judgment is still required, and the context for that call stays small.

Trust is what that accountability feels like from the outside. People trust a product when the charge matches what they agreed to, the session is theirs, the account is recoverable, and the product still behaves when they are not the only user. You build those paths so the interface is telling the truth, and you keep them. They are the part of the experience you do not hand off.

The superplatform

Those four pieces are also the prize the major platforms are fighting over.

The trend is a superplatform: one provider where a person can do everything, and where the product behind them can do everything without leaving. The payment gateway, the authentication, the account, and the infrastructure for scale and streaming stop being four vendors and four contracts. They are folded into one service. The builder who cannot vibecode them is no longer asked to assemble them either.

Payments companies want the identity and the account, not only the card. The clouds already run the stream and the scale, and they want the login and the bill. The AI platforms want the workspace, the runtime, and a customer who never has to open another tab. Each of them is trying to become the place the no-vibecodeable layer lives. Whoever holds it holds the part of a product a weekend clone cannot fake, and the part a personal agent cannot export.

For an experience engineer this is a real change in how a product gets made. A superplatform can hand you a charge that happens once, a session that expires, an account a person can close, and a stream that survives more than the author on a laptop. A product no longer has to become a payments company, an identity company, and a data company before a stranger can rely on it. The personal agent gets a path out of the workshop. Rent the hard parts. Spend the build on the experience.

The paths can be rented. The truth of the experience stays with the product. The platform does not know what you promised. A familiar badge on a checkout, a login that looks like every other login, an account that actually lives in someone else’s system: these can make the surface look finished in the same way a generated screen does. The charge can be correct while the thing the person thought they bought never unlocks. The session can be theirs while the data inside it is not. The stream can be healthy while the product says the wrong thing on top of it. The superplatform sells the machinery. You still keep whether that machinery is telling the truth here.

That is where the fight leaves the work. The no-vibecodeable features converge. A few services will rent the same gateway, the same sign-in, the same account tools, the same stream, to almost everyone. The experience on top of them does not converge. Two products can share all of that machinery, and only one of them will deserve to be trusted. The platforms will keep trying to own that difference too, by pulling the workspace, the agent, and the runtime into the same account. The test for the person shipping the product stays put. Remove the platform’s logo: does it still behave. Remove the engineer: does anyone know when it does not.

Trust cannot be copied

The rented machinery is still something you cannot copy off a public screen.

It is encouraging to see what people are running for themselves. A highly efficient personal workspace. Custom tools. Agents that know one repo, one inbox, one way of working. Augmentation at that scale is real. The agent is fast because the context is private, and trust is easy when the only user is the person who wrote the instructions and checks the output.

Sharing that agent, and monetizing it, is a different problem from having it. The context that made it good does not travel. The tools were shaped around one machine, one set of accounts, one tolerance for mistakes. Put the same agent in front of someone else and the failures become the product: a step taken on the wrong account, a tool call the new user cannot see, a workflow that depended on taste the author never wrote down. You can export the prompts. You can publish the setup. The trust stays where it was made. A superplatform can supply the payment path, the real session, and an account designed for a second person. It cannot supply the judgment that those pieces match what this product told the user.

The same limit shows up when a product is reverse-engineered in public. The interface is visible. The flow can be cloned. With an assistant, a plausible copy of the checkout, the login, and the settings page is an afternoon, and the clone is easy to post. When those screens are backed by the same superplatform everyone else rents, the clone gets even cheaper. What the public product still does not give you is why it holds up for this user. The charge that fires once and unlocks the right thing. The session that ends at the right time. The account that can be closed. The stream that still lands when the room is full. Trust cannot be reverse-engineered. It was never on the screen, and it is not included in the platform fee.

Tokens belong at build time

Agents and AI tools are mainly used at build time. That is the right place for them to spend. While the product is being made, the assistant can wander. It can draft ten versions, call tools, throw the result away, and try again. One person is waiting. The wasted tokens are part of the cost of deciding. The flow, the refusals, the steps that can be ordinary code, the one moment that still needs a judgment: those get settled while you are building.

Runtime is a different budget. Every token is paid again, per user, inside the experience. A long context is waiting. An agent that re-plans a step you already settled is variance you could have removed before anyone arrived. On a payment, a login, or a stream, that variance is a double charge, a session that should have ended, or an event that arrived late and was treated as new. The product gets slower, more expensive, and less trustworthy in proportion to how much thinking you left until the click. A superplatform that also wants to host the agent has a reason to leave that loop running. The meter is theirs.

Token minimizing is the discipline of using less at runtime. The path that can be code, a query, a cache, or a fixed step should already be that. A model call remains where the experience still needs a judgment in the moment, and the context for that call stays small. The open loop — planning, browsing tools, talking through the task — stays in the workspace. By the time a user shows up, and by the time a second user shows up, that loop should be over.

What you can charge for

A personal agent is hard to share and hard to charge for as it stands. The workspace feels efficient to its author and expensive as a product. Ship it without a build step and every customer inherits the open loop: the tokens, the wait, the moments where the agent is still deciding things there was time to decide once. They also inherit the missing pieces, unless those pieces were rented on purpose: a gateway, a boundary between accounts, a stream that survives more than the author.

A personal agent is a workshop. It is fast because you are in it. You bring the context, you catch the mistake, you pay the tokens while the work is still being decided. Sharing the workshop hands someone your bench and your bill. They receive the prompts, the tools, and the custom setup. Selling the agent itself asks the buyer to become the author.

The product is the runtime you are willing to stand behind. The assistant already spent what it needed at build time. A superplatform may rent the gateway, the session, the account, and the stream. The experience still has to do a specific thing, for a person who was not in the room, at a cost you can repeat. That person can pay, sign in, keep an account, and trust the product while other people do the same. That is the thing that can be shared. Trust is the reason they come back. It cannot be attached to the export afterward, and it is not a line item on the platform invoice.

The day still starts with the person using the product. What they are trying to do, what they should see, what should stay quiet. The assistant writes the surface, at build time, and spends what it needs to get there. You use the result the way a user would. Then your attention goes underneath it. Does the charge match the agreement. Is this the right person. Can they get the account back. Will the write still land when the stream is busy and the model is wrong, without calling an agent back to reconsider the whole task. For a personal agent, the person in the loop is you. For a product, that person is someone who never saw the workspace. Review still happens. The standard is whether the experience is true for them, at a cost you can repeat.

Where the role starts

Nearby roles already cover part of this, and they start from different places.

A UX engineer is an engineer in service of a design decision. Prototypes, the design system, the last mile into production. The decision sits with the design team.

A design engineer starts from design and ships that decision in a pull request. The craft is making the design real without handing it to someone else to reinterpret.

An experience engineer starts from software engineering. The design decision and the implementation are one loop, and a large share of the surface is done with an assistant. The measure is the experience in production, including the part under the screen. Can someone pay, sign in, and keep what they made. Does it still hold when more people arrive. Can they trust it when something goes wrong. The machinery under those questions may come from one platform. The answers are still the job. About four fifths of the work is engineering. The remaining fifth is UX: knowing when the experience is wrong.

I have worked both sides of the old split. I studied computer science and interface design in the same stretch of school, then spent years building other people’s interfaces: global sites, design systems, clinical 3D tools. The engineering showed me where experiences actually break. Empty states. Localization. A click that takes a few hundred milliseconds too long. A flow that was clear in a deck and confusing in a browser. A payment that reported success and was not success. A session that belonged to the wrong person. The design work showed me that those breaks are the product. A correct-looking system nobody can trust is unfinished.

AI did not erase either lesson. It removed the excuse that one person cannot hold both. The assistant types faster than I do. It can produce the surface all day. It can stand up a personal workspace by the end of the week. A platform can rent the gateway, the account, and the stream. Neither of them knows which version is telling the truth for this user. Knowing the difference, spending the tokens while building, and leaving an experience someone else can pay for and rely on: that is the job.

The test

Every role that pivoted took on more responsibility. Marketing shows what that looks like when the new responsibility has no standard of accuracy. A public clone shows what it looks like when the standard is whatever could be seen from outside: a checkout, a login, a settings page. A personal agent shows what it looks like when the standard is one person’s tolerance and an open token bill. A superplatform shows what it looks like when the hard parts are for rent, and the logo is asked to stand in for the trust.

The Experience Engineer keeps a harder standard. The assistant works at build time. The platform can carry the payment, the authentication, the account, and the infrastructure that stays up as the data moves. The engineer keeps the experience those pieces make, because that is the part that still cannot be vibecoded, copied, or bought as a bundle.

The title will keep moving. The platforms will keep trying to be the only place the work happens. Take the assistant away: can this person still engineer the product? Take the platform away: do they still know which promises were theirs? Hand what they made to someone who did not build it: can that person pay once, sign in as themselves, keep their account, and trust the product while others do the same? The Experience Engineer is the person who has to answer yes.