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

The challenge

Our client raised a Series A, and then needed a rebuild of the internal operations platform. The new platform had to sit on a stack the team could own and scale. Operational staff built the existing system in Lovable, an AI app builder, on top of a hosted backend. The system proved the product, but it was not a base for the future. It had no test suite, no migrations, no review process, and a schema nobody fully controlled.

The obvious move was a bigger dev team and a rebuild over a year. The client wanted to avoid exactly that. A previous, larger development effort delivered little, and the Lovable system from non-developers overtook it. The client drew the correct lesson: the leverage is no longer in headcount, but in how a small team works with AI.

The team lacked the practical knowledge. The developers were capable, but they knew agentic tools only a little. They did not need an external team to build the new system for them. They needed a teacher, to learn how to build it themselves with agents, and quickly. They also needed that teacher to stay close during the work.

The engagement: teach first, then build together

We structured the engagement in two stages. The client was free to stop after the first stage.

Stage 1 was a one-week on-site workshop. It held two days of lessons and two days of hands-on work. A preparation day came first, to tailor every example to the client's chosen stack (TypeScript, NestJS, React, PostgreSQL with Prisma). We framed the week as a mutual trial: concrete upskilling for the team, and enough evidence for both sides to decide about the next stage.

Stage 2 was eight weeks of guidance and joint delivery. We worked next to the team in the new codebase, in pair sessions, code reviews, and architecture decisions. The team led the work from the first day.

Inside the workshop

The lesson days covered fourteen topics, around one conviction: agentic development is not a tool you install, but a set of disciplines you adopt. The topics:

• Basics - how an LLM works (statistical output, no explicit errors, confident wrong answers), what an agentic harness is, and why context is the central lever a developer controls
• Safe work - guardrails that machines enforce (lint rules, complexity limits, file and function size caps), the correct place for the human in the loop, review patterns that scale, and the failure modes: loss of control, wrong context, and silent failures
• The daily toolkit - a detailed look at 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 - tests as the agent's feedback loop, a debug method that investigates instead of patches, real production logs as agent input, documentation explicit enough for an agent (which is also better documentation for a human), and multiple agents in parallel with git worktrees

Live demos carried the argument. The main demo: an agent built the same small application two times. The first build had no guardrails. The second build had lint rules, complexity limits, and size limits. Side by side, the difference is obvious.

We reserved one full hands-on day for the most consequential exercise. With the ops and dev leads, we went through the existing Lovable system. We extracted the domain model, the flows, and the boundaries. We then produced 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 only notes: a functional agentic setup on every developer's machine, a guardrails configuration in the repository, 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 real work. Here they became the law of the repository. The new codebase enforces on every commit exactly what the workshop taught:

• TypeScript in strict mode across the backend, the frontend, and the shared packages, with zero lint warnings
• An explicit, written rule against silence on a lint error or a type error: no disable comments, no any casts, and no loose compiler flags. If a check fires, the team fixes the cause
• Agent instruction files at the repository root and in every major area, so every agent session starts with the project conventions in context
• Database changes only through versioned migrations
• A scripted worktree workflow. Each developer runs several isolated agent sessions in parallel, each with its own containerized stack, and no session disturbs another

The consultant did not impose any of this afterwards. The team decided to work this way, because they practised it and saw the benefit.

Why workshop-first works

Consulting engagements in AI-assisted development fail in a predictable way. An external expert builds quickly and then leaves. The team cannot hold the pace, because the capability left with the consultant. This engagement inverted the order: one intensive week of lessons and practice before any delivery work. The guidance phase then builds on the team's own capability. It does not replace it. Every pair session builds on shared vocabulary and shared habits, and the team keeps its speed after the engagement ends.

The order also reduces the risk for the client. A one-week workshop is a small, bounded commitment with immediate standalone value. A move into delivery is then a choice on evidence, not on a proposal.