How are AI coding agents trained, and why do private engineering histories matter?

How are AI coding agents trained, stage by stage?

Most coding agents go through several rounds of training, and each round uses a different kind of data. By the end, a typical agent can be handed a real bug report and a snapshot of a repository, read the code, run commands, write a patch, and be scored on whether the project's own test suite passes and whether a reviewer would accept the change.

Developers combine these stages in different ways and rarely publish full recipes, so read this as the common shape rather than any one developer's method.

Why is public code not enough?

Public repositories show what code looks like now. They rarely show why it changed. In a commercial engineering team, a single change usually sits inside a chain: a customer complaint becomes a ticket, the ticket gets acceptance criteria, a developer opens a pull request, a reviewer asks for changes, CI fails on an edge case, the fix is merged, and occasionally it is rolled back after an incident.

That chain is the closest thing software engineering has to a recorded lesson, and most of it lives in private systems. Open-source projects also work differently from companies, with fewer customer deadlines, less legacy code, fewer compliance constraints and different review habits. The wider gap is covered in which kinds of work are missing from AI training data. Simulated repositories fill part of that gap, and the trade-offs between synthetic environments and real engineering logs are worth knowing before a client conversation.

Which engineering records are most useful?

The value sits in records that link together, so a task, its solution and its outcome can be followed end to end.

The linked-history test for CTO and MSP partners

Fractional CTOs and managed service providers see engineering habits from the inside, which makes them good judges of whether a client's history deserves a conversation. Five questions do most of the work:

• Do commit messages or branch names reference ticket IDs, so each change traces back to a request?
• Is review required before merge, and are the review comments kept?
• Has CI history been retained rather than purged after a few weeks?
• Did past migrations, for example from Bitbucket to GitHub, carry full history instead of a fresh start?
• Is the client a US business with 50+ full-time employees at peak (contractors excluded), several years of engineering history and an executive who can authorize a license?

B2B software companies, IT services firms and product teams inside larger operating businesses tend to score well. More role-specific ideas are on the fractional CTO partner page.

Which rights questions come first?

Code is licensable only if the company holds the rights. Under US copyright law, work an employee creates within the scope of employment is generally a work made for hire owned by the employer, while work from independent contractors may not be unless a qualifying signed agreement exists, as the Copyright Office's circular on works made for hire explains. Three situations deserve an early flag:

• Software agencies and dev shops often build code that their contracts assign to clients, so the agency cannot license it without consent.
• Repositories contain third-party open-source components that carry their own license terms.
• Secrets, credentials and customer data sometimes sit in code, configuration or test fixtures and must be removed before any delivery.

Licensed data is also hard to pull back out of a trained model, as explained in whether licensed data can be removed from a model, so scope decisions belong at the start. This is general information, not legal, tax or financial advice. Confirm with your own counsel before acting.

What does a CTO or MSP partner actually do?

Your part is the introduction. You do not clone repositories, take screenshots or describe code to anyone.

1. Raise the idea with the CEO or CTO and ask whether they want a screen.
2. Register, then share your referral link or submit the company through the referral form.
3. SourceX checks size, history, breadth of systems and rights with the company's sponsor.
4. The company lists its own repositories, trackers and years of history in a data inventory, and agrees redaction rules before any work starts.
5. Price and terms are agreed, buyers review, and if the company signs, the agreed scope is delivered and the company is paid.

A line that fits a quarterly technology review:

Partners earn 25% of the eligible platform fees SourceX actually collects from the referred company's licensing deals, capped at $100,000 per referred company, and the reward becomes payable only after the buyer pays and SourceX receives its fee. It never reduces what the client receives. If you advise the client under a contract, check your engagement terms and tell the client about the referral relationship.

Next step

Pick one client with a long, reviewed engineering history and run it through the company fit checker. If it passes, register as a partner and make the introduction, or read how it works first.