Many companies that come to us today already have engineers. Usually good ones. They have a product, a backlog, a deployment pipeline and a CTO who has read enough about LLMs to know that a demo is not a product. What they don’t have is someone who has already put an AI feature into production, measured it, and lived with it after launch. So the question I hear is rarely ‘can you build it for us?’. It is ‘can you work with us, inside our codebase?’.

Short answer. Yes. An external AI team can work inside your codebase (vendors call this AI team augmentation): in your repository, through your pull-request reviews and your deployment pipeline, leaving behind code, prompts and evaluation sets that your company owns. At 4xxi, such an engagement has lasted from a few days (deploy something and hand it over) to a plan of 6–8 months in several iterations, to years of ongoing work. We bill $200 an hour, one rate for engineering and for advice.

When does an in-house team need outside AI help?

An in-house team needs outside help when the gap is experience with AI in production, not headcount. In my practice, it usually looks like one of these:

  1. A pilot works in demos, and nobody can say how often it is wrong. There are no test questions, no baseline, no number to argue about.
  2. The AI part has to run in your own infrastructure. Client contracts, regulated data or simple caution mean the model calls, the index and the logs stay inside your network, and your devops team has never deployed this kind of stack.
  3. You want your developers to learn, not to watch. A vendor that delivers a black box leaves you where you started, plus a dependency.
  4. The rest of the system is already complex. Payments, publishing workflows, billing, permissions. The AI feature is one component, and it has to obey the same rules as everything around it.

There is a less obvious signal too. We have audited AI systems that other teams built, and the problems we find most often are in security and architecture: a ‘zoo’ of stacks that grew one experiment at a time, and automations that GitHub gives almost for free but nobody switched on. An outside team notices this early, simply because it has not got used to it yet. (What we check in such a review is described in auditing an existing AI system.)

Which kind of AI team augmentation fits: advise, pair or build a slice?

Pick the mode by what is missing: advice if you lack decisions, pairing if you lack skills, a built slice if you lack hands. Whatever a vendor calls it, the work comes down to three basic modes, and most real engagements move between them.

Advise Pair Build a slice
What we do Review architecture, model choice, security, cost; answer your team’s questions Build one real feature together with your developers Build or bring a whole component (sometimes our own product, Edtek) and integrate it into your platform
Who writes the code Your team Both, in the same pull requests Mostly us, reviewed by your team
What your team learns The decisions and the reasons behind them How we build, test and evaluate AI features How to operate and extend the component
Good fit when Strong team, no AI production experience You want the skill to stay in-house Time matters more than the learning curve

While the table looks tidy, real engagements rarely are. The legal publisher example below started as ‘build a slice’, and soon included advice for their developers and devops and a side project on their internal processes. Therefore, I would not choose the mode up front. Choose the first piece of work, and let the mode follow.

If you don’t know yet what that first piece is, the structured version of ‘advise’ is our AI opportunity audit: two weeks, $5–10k fixed, with a full money-back guarantee, and the fee is credited toward a project signed within 60 days.

Two other labels come up when you compare vendors. Staff augmentation means renting engineers who work under your direction: you decide what to build, they add hands. Forward-deployed engineers are a vendor’s engineers placed inside a customer, usually to make the vendor’s own product work in the customer’s environment. Our ‘pair’ mode is close to the first, and ‘build a slice’ with Edtek is close to the second. The label matters less than two questions: who is accountable for the AI feature working in production, and what your team can do once we leave.

What does working with an external AI team inside your codebase look like day to day?

It looks like having more senior engineers on your team: your repo, your PR process, your devops, your rules. In practice, it means five things:

  1. Access like a team member, not like a vendor. Accounts in your git host, your issue tracker and your chat, under the same least-privilege rules as your own engineers, removed on the day the engagement ends. Production secrets and customer data should stay with your devops. No separate ‘vendor branch’ that lives for months and then arrives as one giant merge.
  2. Every change is a pull request your engineers review. Your code owners stay code owners (on GitHub this is literally a CODEOWNERS file). If your reviewers do not understand a change, it is not ready.
  3. The AI tests run in your CI next to the ordinary ones. An evaluation set with golden questions runs on every relevant change, and a drop below the agreed threshold fails the build like any other test.
  4. Deployment goes through your devops team. If there is no deployment automation for the new component, we build it together with your devops team, so they can run it without us.
  5. Decisions are written down where your team will find them. Architecture notes and runbooks live in your repository, not in our heads.

Kickoff is typically within 3 business days of signing. The people you meet on the first call are the people who do the work, and I work on client projects myself. There is no sales layer between your CTO and the engineers.

However, one thing does not work without you. One of our clients described it this way:

The biggest challenge for me when outsourcing, was that I was outsourcing. 4xxi is not an in-house team, but they were phenomenal. I definitely needed people who could help 4xxi understand what’s going on, but there was never a question of them not being able to deliver against what was being put in front of them.”

Gayle MeyersCEO, IndustryIndex

That project was not an AI one, but the point holds even more for AI. Someone on your side has to know the domain and the ‘why’ behind the system. We bring the AI experience; we cannot bring your business context.

It looks like a product integration with a lot of engineering around it. A legal publisher we work with wanted AI features on top of its own content. Instead of building them from zero, we took Edtek, our own product for professional publishers (the same one behind the American Arbitration Association’s AAAi Chat Book), and plugged it into their world. Three people from our side worked on it:

  • we integrated Edtek with their publishing platform;
  • we deployed it in their own infrastructure;
  • we set up deployment automation for it;
  • we worked alongside their developers and devops and advised them on how to do all of this properly, so the knowledge stays with them.

The plan is about 6–8 months, in several iterations. Why iterations? Because the first version that runs in someone else’s infrastructure always teaches you things the plan did not know about, and it is cheaper to learn them in small steps.

Running in the client’s infrastructure is a hard requirement for publishers: their content is the business. Edtek can be deployed on the customer’s own infrastructure and work with the customer’s own models, so content and inference can stay inside their network. (Which model to use is a separate question; I wrote about it in commercial, open-source or small local models.)

There was a side story too. Along the way, we helped the team introduce AI into their internal processes, and this part is easy to underestimate. Buying licences for AI tools does not make a team faster by itself. In METR’s randomised study of early-2025 tools, 16 experienced open-source developers were 19% slower with AI, while believing it had sped them up by about 20%. METR’s 2026 follow-up could not produce a reliable new number, mainly because more developers did not want to work without AI, so they stayed out of the study or held back tasks. My reading: the tools are already in your team, but how they are used matters more than which ones you bought. That is learned on real work, next to someone who has done it.

What about long-running engineering, like payments?

Long-running work looks less like a project and more like being part of the team. With a payments company, our work is an ongoing engagement: complex engineering, some of it AI. The lesson from payments is simple. The AI components get no special treatment: they should go through the same reviews, tests and releases as the code that moves money. This is also our general rule: wherever a probabilistic model makes a decision, deterministic checks (scores, rules, assertions) sit next to it, so a wrong answer gets caught. In payments a wrong answer is not a typo.

Not every engagement is long, though. Sometimes a team has the component and the plan, and needs it deployed properly in their environment. That can take a few days, and then the team runs it on its own. I consider this a perfectly good outcome.

And sometimes AI arrives inside a product you have run together for a long time. For EmanuelAYCE, a law-school study platform we built in 2022 for a client we have worked with since 2013, we added an AI tutor to the existing product in 2023. Long relationships are normal for us: our average client relationship is 5+ years, and David Nadezhdin, founder of Circus Intersection, describes his experience with us as ‘I’ve been working with them for 15 years’.

What does your team keep when the work is done?

Your team keeps everything needed to run, measure and change the AI feature without us. If an engagement ends and any of the following is missing, something went wrong:

  • The code, in your repository, with its history and reviews.
  • The prompts, as versioned files in the same repository, not in someone’s dashboard.
  • The evaluation set: golden questions built from real cases of your business, with the expected answers or sources.
  • A baseline and a regression threshold, so a model change six months later cannot silently break what worked.
  • A cost budget and its monitoring: what one answer costs, and who is alerted when it grows.
  • Deployment automation and runbooks, owned by your devops.

A simple test before the engagement ends: one of your engineers changes a prompt, runs the evaluation set, compares the result with the baseline and deploys, with nobody from our side involved. If that works, the handover is done.

This is the same set we use for our own products. Edtek ships with an evaluation suite that runs golden questions through the same pipeline that serves readers, with an LLM judge, retrieval assertions, confidence checks and latency budgets, and compares every run against a baseline. If you want to understand why the evaluation set matters more than the prompt, see how to build an AI assistant that doesn’t hallucinate.

Who owns the code, prompts and evals?

In custom work, the client owns them: code, prompts and evaluation sets belong to you. A product licence is different. Edtek is a software product, and we license it non-exclusively: you get the right to use it, and we keep developing it for everyone who uses it.

Custom work Edtek
What you get Ownership of code, prompts and evaluation sets A non-exclusive licence to a software product
Integration code we write for you Yours Yours (it is custom work)
Your content and data Yours Yours, and can stay in your infrastructure
Price $200/h On request

Why write this down at all? Because the default in law is often not what people assume. In the UK, the author of a work is its first owner, and the employer rule applies to employees, not to contractors (Copyright, Designs and Patents Act 1988, s.11). In the US, a commissioned work is a ‘work made for hire’ only if it falls into one of nine listed categories and both sides sign a written agreement, so software written by an independent contractor usually isn’t one (US Copyright Office, Circular 9). In both cases the transfer has to be in the contract. I’m not a lawyer, so check the wording with yours. However, the rule I’d follow is simple: ownership of prompts and evaluation sets should be stated as explicitly as ownership of code. They are where most of the know-how of an AI feature lives.

When should you hire instead of bringing in an outside team?

You should hire when AI is the core of your product and the knowledge has to live in your company permanently. There are also cases where I’d tell you not to work with us:

  1. You need someone in every stand-up and on call, full time, for years. At $200/h, 160 hours a month is $32,000, or $384,000 a year. The median total compensation of a US machine learning engineer is $283,000 (Levels.fyi, October 2026), so at that load hiring usually wins. I compare the options in more detail in AI consultant vs agency vs fractional CTO.
  2. The feature is a plain call to a vendor API, and your team has shipped similar things. You don’t need us. The guide to integrating LLMs into existing software may be enough.
  3. You need a large team. We are a small team of senior engineers. If the plan needs twenty people next month, choose a larger partner.
  4. You want someone to close tickets without questions. We will challenge scope before we bill it. Some teams don’t want that, and it is a fair preference.

The best combination I have seen is both: hire the people who will own the AI feature, and bring in external AI engineers for the first production version, so your new hires learn on a working system rather than on a blank page. If you are choosing between several AI implementation partners, here is how a CTO can evaluate an AI development partner.

How do we start working with your team?

Start with one real piece of work, not with a framework agreement. If your team is ready to build and needs experienced hands inside the repository, book a call about ongoing engineering: tell us about the codebase, the team and the first feature, and we will tell you which mode fits and what we would do first. If you are not sure yet what to build, or you already have an AI system and doubt it, start with the audit. What each step costs, from the audit to hourly work, is in how much AI development costs.

The best result of such an engagement, in my opinion, is when your team no longer needs us for that feature. Clients still stay with us for years, but for the next problem, not because nobody else can touch the previous one.