Six-week programme for development teams
Get more work out of AI, spend fewer tokens and be able to show it
Six weeks with Claude Code and GitHub Copilot: I measure where you are, we run the workshop, I review your pull requests and I measure again. At the end you have a shared method and two measurements you can compare.
On-site at your company and remote follow-up. For teams that already use Claude Code or GitHub Copilot every day. I close the proposal after a call.
Can be subsidised through FUNDAE (Spanish training credit).
The problem you already have
The team uses AI every day, each one in their own way, and nobody knows if it pays off
One person uses the most expensive model to rename a variable. Another has had a session open since Monday that resends its whole history with every message. Another leaves the agent looping all afternoon. And pull requests arrive green because the same agent that wrote the code decided it was fine.
The token bill keeps growing and everyone feels faster, but nobody has measured anything. Claude Code’s cost documentation gives an average of about 13 dollars per developer per active day, and the first step is knowing where your team stands.
That’s why I won’t promise you a number. I measure the before and the after, with indicators we pick together on the call, and whatever changes, or doesn’t, gets written down.
What the programme delivers
What the team has after six weeks
Each result can be checked against something you can show management, and not against a hunch.
- 01
More work finished with the same team
A model per round, agents working in parallel on disjoint briefs and sessions with turn and spending limits that finish on their own.
Evidence: the same task with one model for everything and with a model per round, with the cost of each. - 02
Fewer tokens per finished task
A cache that doesn't break, context loaded on demand and output filtered before it reaches the model.
Evidence: tokens per task measured at the start and at the end, with the same method. - 03
Confidence in what goes to production
The AI tests its own code: a test that fails first, protected tests and a suite that runs before anything is declared finished. A reviewer in a clean context looks for what the author considered fine.
Evidence: written comments on two or three of your agent-made pull requests. - 04
One way of working across teams
Instructions, permissions, skills, hooks and agents set up in your repositories and agreed by the team.
Evidence: configurations on a branch of your repository, reviewed by the team. - 05
Five prioritised actions for management
A three-to-five-page report with what I saw, what we worked on and what to do next, with one owner per action.
Evidence: the report, delivered in week 2.
How it works
What happens each week and who does it
I do almost all the work. From the team I ask for time for the survey, the workshop day and passing me the pull requests.
Diagnosis and first measurement
The team answers a 10-minute survey about tools, habits and frustrations. I look at your instruction files and permissions, and with you I work out the baseline for the indicators we choose.
Deliverable: A written baseline and labs adapted to your stack.The workshop
Between five and eight hours in person on a model per round, cache, context on demand, finite execution, orchestration and verification, with the last block on each participant's own repository. I leave the configurations on a branch of your repository.
Deliverable: Configurations on a branch and a labs repository.Management report
I prepare the three-to-five-page report with what I saw in the diagnosis, what we worked on, risks in the configurations (without auditing anything) and five prioritised actions.
Deliverable: Management report.Q&A channel and pull request review
A channel with you, open until the end of week 5, for configuration and usage questions. I review in writing two or three pull requests that you point me to.
Deliverable: Written answers and comments on the pull requests.Review and second measurement
We repeat the week 0 measurements with the same method and spend 90 minutes remotely looking at what has changed, what has stalled and what is still missing.
Deliverable: A before-and-after comparison and an agreed next step.
Week 1 is the full workshop, with its syllabus and labs: Getting real productivity out of AI
Measurement
What gets measured, and why I promise nothing
We pick four to six indicators on the call, based on what you can extract from your own systems without building anything new. These are candidates and the list is not closed. Six weeks don't give a statistical conclusion, and the report says so.
Tokens per finished task
What each accepted change costs, taken from /usage or your tool's dashboard. It is the cheapest indicator to measure and the one that moves most when context is put in order.
Time from opening to merging a pull request
It comes from the repository history. It can't tell who wrote what, but it does show whether the flow stalls in review.
Changes reverted or fixed afterwards
How many merged changes are reverted or need a fix in the following days. It tells you whether what reaches production holds up.
Review effort
Rounds of comments and diff size on agent-made pull requests. A huge diff that someone approves without reading is a signal.
Team perception
The same short survey at the start and at the end. The key question is how much time they think they save, and you can set that against what was measured.
Workshop or programme
| If you need | Workshop | Programme |
|---|---|---|
| The team sharing one way of working with agents | The workshop does it: one day, set up in your repositories. | It works too, and adds five weeks of follow-up. |
| Knowing whether anything measurable has changed | The workshop teaches how to measure a session, but there is no second measurement. | This is what the programme is for: two comparable measurements. |
| Reporting to management | Each participant leaves with their before and after numbers. | Adds the three-to-five-page report with five prioritised actions. |
| Correcting course on your real code | Only in the last block of the day. | I review two or three of your pull requests in the following weeks. |
What gets worked on
The topics, now that you've seen the benefits
The full content is that of the workshop in week 1. Each topic is explained in Claude Code and in GitHub Copilot, and the following weeks apply it to your pull requests.
Saving: model, cache and context
Fewer tokens without losing quality.
- Model and effort per round: planning, exploring, executing and reviewing don't call for the same thing.
- What breaks the cache, rewinding versus compacting and output filtered with hooks.
- Context on demand, without RAG: an index file, path-scoped rules and documentation the agent walks on its own.
Finite execution and orchestration
An agent with no limit isn't autonomous. It's expensive.
- Turn and spending limits, stop conditions and the Ralph loop with an iteration cap.
- A worktree per agent, an expert panel with disjoint roles, a judge and an adversarial agent.
- When not to build a multi-agent system: Anthropic measured 90% better performance in exchange for about fifteen times more tokens.
Verification
A change is finished when a check says so, and not when the agent says so.
- A test that fails first, tests protected against agent edits and a stop gate with the suite.
- A reviewer in a clean context and cross-validation between different models.
- A hook stops what an instruction can't guarantee.
Configuration and tools
Each mechanism solves a different problem.
- Plan mode, skills and commands, hooks, MCP and permissions: when to use each.
- Managed configuration for the organisation and your own catalogue of skills and agents.
- A single configuration folder read by both Claude Code and Copilot.
Material that stays with the company
When the programme ends, you keep this
Everything is made to live in your repository and your documents, and not in a training folder.
- Baseline and second measurementBoth sets of indicators and the method to repeat them.
- Management reportThree to five pages, with five prioritised actions and an owner for each.
- Configurations on a branchInstructions, permissions, hooks and subagents for Claude Code and Copilot, ready to review and merge.
- Finite-execution recipesThe Ralph loop with its progress file, turn and spending limits and stop conditions.
- Labs repository with solutionsLicence for internal use for one year.
- Comments on your pull requestsIn writing, with what gets accepted and why.
What else is included
Three pieces that come with the workshop
They are the same ones the standalone workshop includes. In the programme they are delivered within the six-week calendar.
- +1
Pre-workshop team survey
Ten minutes per person to adapt the labs to your stack and your tools.
- +2
Configurations on a branch of your repository
Instruction files, permissions, hooks and subagents with their model and turn limit, ready to review and merge.
- +3
Labs repository with solutions
Exercises, starter files and solutions, with a licence for internal use for one year.
Who it's for
For teams that want to know whether AI pays off
A strong fit for
- Teams that already use Claude Code or GitHub Copilot every day and have no data on what effect it has.
- Tech leads and engineering managers who have to explain to management what the licences and tokens have bought.
- Platform teams that want shared configuration and agents across several teams.
- Teams that prefer to change one thing at a time and check the effect before moving on.
Not the right programme if
- You want a single day of training with no follow-up. That is what the workshop is for.
- You expect a guaranteed saving figure. I don't give one and I would be wary of anyone who does.
- You want an audit of your code or your configurations.
- The team doesn't yet use a coding assistant on a real repository.
Who runs it
From cybersecurity at BBVA to AI at Santander
I’m Daniel Alfocea, and I’ve spent twenty years in development and security. At Banco Santander I was Principal Engineer in the AI department when the area was being set up. At BBVA I was Cybersecurity Tech Lead. At 42Crunch, in the UK, I was responsible for one of its API security products.
I’ve presented research at RSA Conference and OWASP AppSec EU, and I’m a regular speaker at RootedCON. Spain’s National Cybersecurity Institute (INCIBE) has asked me to judge its competitions several times. I founded Navaja Negra and the OWASP Madrid chapter. I’m the author of widely used security tools such as GoLismero, Plecost and Dockerscan, and of LAPIS, research published on arXiv on how to describe an API to a model with fewer tokens. With Alfonso Muñoz I wrote Secure MCP: A practical guide for developers, software architects and tech leads.
This programme comes from how I work myself: I measure my own sessions, I split work across agents with their own model, turn limit and report, and I don’t accept a change without a test I have seen fail.
Guarantees
What I fix without charging you more
The configurations work
If the configurations I leave in your repository don't work, I run a free remote session to fix them.
One hour if you get stuck
If after 30 days the team has got stuck applying something from the course, I give you one hour remotely, for free.
This is not an audit and I don't promise saving percentages. I promise it is measured the same way both times and that I tell you whatever comes out as it is.
Format
Six weeks, one team and two measurements
The programme includes the diagnosis, the full workshop, the report, the follow-up and the final review. We settle the length of the workshop and the group size on the first call. If you only want the day, the workshop will do.
- Participants from the same team or from teams that work together.
- On-site workshop in English or Spanish, and follow-up remotely.
- Room, screen, wifi and laptops provided by the company.
- If we have to travel outside Madrid, we agree it before the date is confirmed.
Before you ask for the call