Teaching a team to build with agents: one workshop week, then a production port at startup speed

The challenge

Our client had just raised a Series A and needed their internal operations platform rebuilt on a stack they could own and scale. The existing system had been built by operational staff in Lovable, an AI app builder, on top of a hosted backend. It proved the product, but it was not a foundation: no test suite, no migrations, no review process, and a schema nobody fully controlled.

The obvious move - hire a bigger dev team and rebuild for a year - was exactly what they wanted to avoid. A previous, larger development effort had shipped little, and the Lovable system built by non-developers had quietly outpaced it. The lesson the client drew was the right one: the leverage is no longer in headcount, it is in how a small team works with AI.

What they were missing was the working knowledge. The existing developers were capable but only lightly familiar with agentic tools. They did not need someone to build the new system for them. They needed someone to teach them how to build it themselves, with agents, fast - and then stay close while they did it.

The engagement: teach first, then build together

We structured the engagement in two stages, with the client free to stop after the first.

Stage 1 was a one-week on-site workshop: two days of teaching, two days of hands-on work, preceded by a preparation day to tailor every example to the client's chosen stack (TypeScript, NestJS, React, PostgreSQL with Prisma). The week was explicitly framed as a mutual trial - concrete upskilling for the team, and enough signal on both sides to decide whether to continue.

Stage 2 was eight weeks of guidance and joint delivery: working alongside the team in the new codebase, pairing sessions, code review, and architecture decisions, with the team in the driver's seat from day one.

Inside the workshop

The teaching days covered fourteen topics, built around one conviction: agentic development is not a tool you install, it is a set of disciplines you adopt. The arc:

• Foundations - how LLMs actually work (statistical outputs, no explicit errors, confidently wrong answers), what an agentic harness is, and why context is the central lever a developer controls
• Working safely - guardrails enforced by machines (linting, complexity limits, file and function size caps), where the human belongs in the loop, review patterns that scale, and the failure modes: losing control, wrong context, silent failures
• The daily toolkit - a deep dive into Claude Code as a harness (instruction files, slash commands, hooks, settings, MCP), project setup for AI-native work, and why strict types matter more with agents, not less
• Disciplines that compound - testing as the agent's feedback loop, debugging by investigation rather than patching, feeding real production logs to agents, writing documentation explicit enough for agents (which turns out to be better documentation for humans too), and running multiple agents in parallel with git worktrees

Live demos carried the argument. The centerpiece: the same small application built twice by an agent, once with no guardrails and once with linting, complexity, and size limits enforced - side by side, the difference needs no slide.

One full hands-on day was reserved for the most consequential exercise: walking through the existing Lovable system with the ops and dev leads, extracting the domain model, flows, and boundaries, and producing the first round of written specifications for the port. The team left the room with an agreed first implementation slice, not a vague intention.

The workshop ended with concrete artifacts, not just notes: a working agentic setup on every developer's machine, a guardrails configuration checked into the repo, a practised review rhythm, a documented multi-agent worktree workflow, and the written specifications to build against.

From slides to repository

The clearest measure of an upskilling engagement is whether the practices survive contact with real work. Here, they became the repository's law. The new codebase the team built enforces, on every commit, exactly what the workshop taught:

• TypeScript in strict mode across backend, frontend, and shared packages, with zero lint warnings tolerated
• An explicit, written rule that lint and type errors are never silenced - no disable comments, no any casts, no loosened compiler flags; if a check fires, the underlying cause gets fixed
• Agent instruction files at the repository root and in every major area, so every agent session starts with the project's conventions loaded
• Database changes only through versioned migrations
• A scripted worktree workflow where each developer can run several isolated agent sessions in parallel, each with its own containerized stack, without stepping on each other

None of this was imposed afterwards by the consultant. It is how the team decided to work, because they had practised it and seen why it pays.

Why workshop-first works

Consulting engagements in AI-assisted development fail in a predictable way: an external expert builds quickly, leaves, and the team cannot sustain the pace because the capability left with the consultant. Inverting the order - one intensive week of teaching and practice before any delivery work - means the guidance phase compounds instead of substitutes. Every pairing session lands on shared vocabulary and shared habits, and the team's speed survives the engagement's end.

It also de-risks the decision for the client. A one-week workshop is a small, bounded commitment with immediate standalone value. Continuing into delivery is a choice made on evidence, not on a proposal.