Week one on a live product is not a notebook.

The product already has users. The model might not, or it does and nobody can name who is on the hook when it is wrong. You hired an AI engineer onto that team. The first meeting is a kickoff. Someone will ask for a demo by Friday.

That request is how week one gets wasted. A notebook can look finished by Thursday and still have no owner for data access, no definition of better, and no way to turn the thing off in production. The team you joined already ships. They have an API, a database, an on-call rotation, and a release process. Your job in the first week is to learn which of those you now share, and to write down the ones you do not.

I am not writing a hiring-market survey, and I am not ranking tools. Copilot, Cursor, and Claude Code are already in a lot of these repos. Using an assistant to write code is not the same job as putting a model in front of customers. If the tree already has a year of assistant output and nobody has read it, that is what Copilot and Cursor leave in a production repo. If the team has no written rules for those tools, start with an AI coding policy engineers will follow. This post is the seat you take when the product is live and you are the person who just joined.

A greenfield demo hides the work. There is no pager, no tenant boundary, and no customer who will see a bad answer at 9am. An existing product has all three. Week one is the map of that path. It is not the quarter's roadmap. If you are still testing whether the idea can work at all, that is an AI proof of concept, and it should finish before you staff someone onto production.

The live path is the job

An AI engineer joining an existing product team owns the seam between a model and a path users already take. Not a side project. Not a slide. The seam is specific: which request, which data, which failure, which person gets paged.

The rest of the team already owns pieces of that path. Product owns the job the user is trying to finish. The API owner owns the contract. Data or security owns what may leave the system. On-call owns the night. Week one is the handoff list, written while everyone is still in the room. If those names are missing, you do not have an AI project. You have a person with a laptop and a hope that Friday's demo will substitute for a decision.

Production risk shows up in ordinary places. Latency on a request that used to be a database read. An answer that is confident and wrong, in front of a real account. A prompt that includes a customer record because the engineer needed "realistic" context. A shadow job that writes back to the same table the product uses. None of those are research problems. They are release problems. Treat them that way from the first day, or you will discover them from a ticket.

What week-one ownership actually is

Week-one ownership is a short, dated note of the live path you will touch, the data you may read, how you will tell better from worse, who reviews a change before users see it, and how the change turns off. It is written for the people who already ship the product. It is not a model-vendor comparison, and it is not a six-month roadmap.

It is also not a proof of concept. A proof of concept answers whether a risky assumption survives contact with reality, then it is allowed to die. We wrote that down in what a proof of concept is. Week one on a live product assumes the product stays up. The notebook is allowed to die. The map is not.

If you cannot attach the note to an email by Friday, you did not finish the week. You attended meetings.

The map you should be able to send on Friday

Six questions. One name each. If a cell says "the team," it is blank.

Question	What good looks like	Not good enough
Where does the model sit on a request users already make?	A written path, reviewed by the person who owns that API	"We will figure out the integration later"
What data may be read, and what must never enter a prompt?	Named access, redacted or synthetic fixtures, a written ban on dumps	A production password in Slack, "just this CSV"
What does better mean on this product?	One metric the product already trusts, plus the failure you will not ship	A vibe, or a score that exists only in a notebook
Who reviews a prompt or model change before users can see it?	A named reviewer who already owns the feature	The same person who wrote the prompt, approving themselves
How does it turn on, and who can turn it off?	A flag, a shadow or small percent, and a person on the on-call list	A deploy that is the rollout
What happens when it is wrong at 2am?	A page path and a human fallback that already exists	A notebook nobody else can run

Put the note in the handbook the same day, next to the new-hire checklist. If a contractor cannot find it in five minutes, it does not exist. The same is true of the coding-tool rules. A policy in a shared drive does not help the person who just got repo access.

Data access, evaluation, and the first rollout

Data access is the first argument worth having. Least privilege, not a copy of production "so the eval is realistic." Names of fields are fine. Customer values, secrets, and live dumps are an incident if they land in a chat window. Copilot, Cursor, Claude Code, and a consumer chatbot are all the same rule here: if the tool is not approved for that data, it does not get the paste. Synthetic or redacted fixtures are how you learn the shape of the data without borrowing a customer's record.

Healthcare is stricter. If the path can see PHI, week one does not include an export to a laptop. Clinical systems and BAA-capable architecture live at Maxiom Labs. Say PHI on day one so nobody treats a generic SaaS login as good enough.

Evaluation is the second argument. "Better" has to be a sentence the product owner will repeat. Use a metric the product already trusts: task completion, a support deflection you can audit, a latency budget on the existing request. Add the failure you refuse to ship, in plain language. An offline score you invented on Tuesday is not that sentence. It can be a lab note. It cannot be the release bar. If you have no labeled set, say so. Do not pretend a handful of hand-picked examples is a harness.

Rollout is the third. The first change users can hit should be reversible by someone who is not you. Shadow or read-only when the model must not write. A small percent when it must. A flag the on-call already knows how to flip. A human fallback that is the old path, still working. If turning it off means a revert and a redeploy at 2am, you do not have a rollout. You have a launch.

Handoffs are the point of all three. The API owner signs the path. Security or data signs the access. The feature owner signs the "better" sentence. On-call signs the kill switch. You can draft the page. You cannot be the only signature.

What you do not own yet

Week one is not a vendor selection. You can name the constraint (data residency, latency, what must stay in your environment). You should not sign a contract because a demo looked fluent. You also do not own a rewrite of the product, a new design system, or the team's coding-assistant rollout. Those are different jobs. Platform defaults for Copilot, Cursor, and Claude Code are platform governance. A written snapshot of what already merged is an AI code audit. Mixing "who we hire" with "what is in the repo" in one Slack thread is how both get skipped.

You do not own a greenfield demo track in parallel with the live path. One of them will win the week, and it will be the one with no pager. Park the demo. Finish the map.

Staff the seat, or write the map yourself

Write it internally this week when a staff engineer already knows the API, the data classification, and the on-call rotation, and the new person can sit with them. One page. Names. Flag. Kill switch. That is the whole job.

Staff a senior engineer when you need someone inside your process who has shipped into a product that already has users, and the people you have can prompt an assistant but have not owned evaluation, data access, or a rollback. That is staff augmentation at Maxiom Dev. Say so. Do not ask for a build and hope a person shows up inside your standup.

Scope a build when you want a defined slice delivered on the product you already run: the integration, the evaluation set, the flag. That work is AI development, with a named engineer and a written scope. App-shaped product work also lives at Maxiom Apps. If you are still arguing which shape fits, use the engagement model picker or read how Maxiom scopes work. If the idea has not survived a real constraint yet, go back to an AI proof of concept. Do not hire a production owner for a question you have not asked.

We have been shipping software since 2002. Assistants changed how code gets written. They did not change the fact that a live product needs a name on the path, the data, the release bar, and the off switch.

FAQ: an AI engineer's first week on a live product

What should an AI engineer own in the first week?

A written map: the live request the model will touch, what data they may read, how "better" will be judged, who reviews a change, how it turns on, and who can turn it off. Names, not "the team."

Is week one a proof of concept?

No. A proof of concept is allowed to die after it answers one question. Week one on a live product assumes the product stays up. If you still do not know whether the idea can work, run the proof of concept first.

Who owns evaluation?

The new engineer drafts it. The person who owns the feature signs the sentence that defines better, using a metric the product already trusts, plus the failure you will not ship. An offline score nobody else uses is a lab note.

What data should they have on day one?

The minimum they need, with a named grant. Redacted or synthetic fixtures for anything that would be a customer record, a secret, or PHI. No production dump in a prompt. If access takes longer than the demo someone wanted, the demo waits.

What does a safe first rollout look like?

Reversible by on-call. Shadow or read-only when the model must not write. A small percent when it must. A flag, and the old path still working as the fallback. A deploy that cannot be undone without you is not a rollout.

Should they pick the model vendor in week one?

No. They should name the constraints: latency on the existing request, where data is allowed to go, what must stay in your environment. A fluent demo is not a selection process.

How is this different from hiring someone who uses Copilot?

Copilot, Cursor, and Claude Code help people write code. They do not own your evaluation, your data boundary, or your kill switch. A generalist who can prompt an assistant is useful. The seat in this post is the person accountable for the model on a path users already take.

When do you staff someone instead of scoping a build?

Staff when you own the process and need a senior person in your standup. Scope a build when you want a defined slice delivered. Those are different asks. Maxiom Dev is the staffing path. AI development is the build. The engagement model picker is there if the room is still arguing.

We handle PHI. Does week one change?

The map stays. The access model does not. No export to a laptop, no paste into an unapproved tool, no "orientation" dump. Product work on clinical systems goes through Maxiom Labs.

If you need a senior engineer inside the team that already ships, start at Maxiom Dev. If you need a defined slice on the live product, start with AI development or request a scoping call. Thirty minutes is enough to pick a shape, or to hear that we are not the fit.

I write from the seat of a working engineering company, not a tool vendor. More at antoniochagoury.com.