The Model Is the Least Interesting Part of This AI Project

A friend recently asked me to show him how I’d build him his own CRM/Application Tracking System (ATS) for his recruitment firm. It’s the system his staff will use to manage candidates, clients and the work that joins the two. There was already a prototype and a set of requirements, but the job now is to turn that into a real piece of software that the business can rely on.

The thing I didn’t spent much time thinking about was the LLM.

Claude Code is doing a great deal of the building. I’m not sitting beside it asking for isolated functions and then assembling the answers myself. I’m operating a software engineering team inside a Claude project, and I’m acting as its architect as well as its human operator.

That sounds like a claim about how capable Claude has become. In practice, most of my attention has gone somewhere else.

It has gone into the architecture, the scaffolding around the work, the ownership of decisions, the approval boundaries and the rules the team follows when something changes.

All the things I mean when I talk about the other 95%.

I gave the project an AI team-construction template. It starts off like this.

From the requirements, it created the roles needed to deliver the system: product analysis, solution architecture, engineering, security, testing and support among them.

There are ten roles in the current version. Ten sounds faintly ridiculous for a small recruitment system. If I were proposing ten full-time people, it would be.

These are decision boundaries inside the Claude Code team. They establish who owns the meaning of a requirement, who owns an architectural choice, who decides what has been tested properly and who thinks about the person who will have to support the system after I’m gone.

The roles are useful because they disagree in useful ways. The product analyst can establish what the business asked for without quietly deciding the architecture. The architect can make a technology decision, but can’t declare its own work tested. Security is present while the system is being shaped rather than appearing at the end with a list of objections.

None of this depends on Claude having a particularly good afternoon.

The responsibilities are written down. So is the route work follows: understand the requirement, consider the architectural effect, implement it, test it, check the security and operational consequences, update the documentation and identify anything that will matter when it is deployed.

Some of those stages produce a sentence saying there was no impact. That’s fine. I just don’t want the team skipping the question without saying so.

We found out quite early why the structure mattered. An assumption about the target platform changed after my buddy supplied more information. Several of the specialist roles had been constructed around the original assumption, which meant those roles were now wrong.

The quick response would have been to keep building and translate the work later. The team record did the opposite. It marked the affected roles as provisional, stopped them being used for live work and held them for reconstruction against the new architecture.

That pause didn’t come from choosing a more intelligent model. It came from having somebody (or in this case, something with an explicitly assigned responsibility) whose job was to notice that the architecture and the team no longer agreed.

Keeping the wrong team moving would have looked fast for a week or two. Then I’d have been paying to unpick its work.

Now this is the fun part, the bit that’s happening in Jira.

There are four of us in the working arrangement: me, my friend who owns the business, one member of his staff and the AI team lead.

The two people in the recruitment firm don’t need to work in a terminal or learn how a Claude project is organised. They raise and discuss work in Jira, which is already built for that sort of collaboration. The Claude Code team lead can use Jira through MCP and bring those items into the engineering work.

The AI is not impersonating me in there. It has its own account. It has an email address. Its comments and changes can be distinguished from mine, and its permissions are deliberately smaller than the permissions a human administrator would have.

It can read issues, create them, update them, comment and move work through the agreed workflow. It can’t administer the Jira project, change who has access or delete its way out of a mistake.

The available tools have been restricted so some destructive actions aren’t merely prohibited in an instruction; they aren’t exposed to the team in the first place.

There are rules for the humans too. Candidate and client personal data doesn’t belong in a ticket. Neither do credentials. The system may be about recruitment, but that doesn’t make the project board an acceptable place to scatter somebody’s CV or screening notes.

We also made a fairly ordinary decision about where information lives. Jira carries work items, priorities, discussion and status. The repository carries the reasoning: architecture decisions, requirements interpretation, standards and runbooks.

A ticket can point to an architectural decision. It doesn’t become a second, slowly decaying copy of it.

This is what working with an AI teammate looks like once the novelty wears off. The AI has its own identity, a known job and a place where the other people on the project can speak to it. Its access is broad enough to make it useful without quietly turning it into the project administrator.

There is still a human decision sitting above all of that.

The architecture and the approval boundaries are mine. So is the call on whether the team’s reasoning is good enough to act on, because I’m accountable for the result. Calling the AI a team lead doesn’t transfer that responsibility to Claude.

I’m using Claude because Claude Code is the environment I’ve chosen for this build. I can move between versions of Claude if I want to. A newer one may reason better, write a cleaner implementation or get through a difficult piece of work with fewer corrections.

I’m happy to take those improvements when they arrive. They just aren’t the organising principle of the project.

If I changed the model tomorrow, the requirements and the architecture decisions wouldn’t change with it. Security, testing and support would keep their owners. The approval boundaries would continue to stop unapproved production actions.

Work would remain in Jira, the reasoning would remain in the repository, and somebody in the business would still have to accept that the system does the job they asked for.

Remove those things and leave me the model, and I haven’t got a software team. I’ve got a highly capable model with access to a codebase.

This is the distinction I think people miss when they try to learn how to do this work. They spend a lot of time following model releases, comparing scores and learning the newest interface. That knowledge has some value. It is also the part the vendors are working hardest to make easier and more interchangeable.

A loose business requirement has to become a decision without my assumptions quietly turning into facts. I need to choose an architecture and be clear about what would make me change it. The intelligence doing the building shouldn’t also specify and approve all of its own work, and useful access doesn’t mean every permission the underlying system happens to offer.

Somewhere in there you also have to notice when apparent speed is becoming expensive. You don’t get those answers from a model selector.

The opportunity for somebody who wants to work this way isn’t to become the person who knows the most about Claude. It is to become the person who can construct and operate a delivery system around Claude (or whatever replaces it) without surrendering judgement to it.

That is the role I seem to be doing now. Part architect, part operator.

That is why I’ve barely worried about the model. I’m designing the working system around it. For this project, Claude is the team member helping me build it.

Until next time,

Chris

P.S. — The model is rarely the reason an AI project fails. It’s usually something in the work around it: a requirement nobody tested, an architecture nobody challenged or a risk somebody left until later. How AI Projects Die follows ten real projects through those decisions. Free, get your copy here.