Six-week programme for technical teams
Help the team develop with AI, with controls that can be measured before and after
Six weeks that cover a diagnosis of the team's configurations, the full workshop, a management report with five prioritised actions and a second measurement using the team's own numbers. I don't promise a percentage improvement. Whatever changes, I leave measured.
Remote or in person, in English or Spanish. For teams already using Claude Code or GitHub Copilot on real repositories. I close the proposal after a call.
Can be subsidised through FUNDAE (Spanish training credit).
Where teams start
One day of training changes what the team knows, but not always what it does.
After a workshop everyone goes back to their branch, their deadline and their habits. If nobody looks at what got applied, three weeks later what remains is a nice memory and very few changed configurations. With AI it’s worse: assistants, MCP servers and autonomy modes change every few months, and what was decided yesterday goes stale.
There is a second problem: feeling faster is not measuring. In 2025 a randomised trial by METR with experienced developers found they took longer with AI while believing they had gone faster. So I measure at the start and at the end instead of promising how it will go.
The programme puts together three things that are often bought separately: the training day, the follow-up afterwards, and the evidence an auditor asks for. At the end the company has changes in its repository, a report to show management and two measurements to compare.
What changes at the end
Five outcomes to show whoever decides
Each outcome has a concrete deliverable and a week in which it appears. What I can't promise is how much the indicators will move. That depends on the team's data.
- 01
Know where the team is starting from
With a ten-minute team survey and a review of the AI configurations already in the company's repositories, we get in writing what the assistant reads, what it is connected to and what it can run.
Evidence: a diagnosis sheet and a baseline measurement with 4 to 6 agreed indicators. - 02
Leave the workshop with controls in the repository
In the last block each participant applies the controls to the company's code. The configurations stay on a branch of its repository and the team merges it.
Evidence: a branch with configurations, a technical AI and MCP usage policy, and a Definition of Done. - 03
Have evidence for the control, and more than the memory of a course
Signed attendance, an individual certificate and a syllabus mapped to the standards that apply to the company, with a one-page letter for whoever audits.
Evidence: an evidence pack delivered in the week of the workshop. - 04
Give management a document it can read
What was seen, what was worked on, which risks showed up in the team's configurations and five actions with an owner. It is not an audit and the report says so on its first page.
Evidence: a 3 to 5 page report in week 2. - 05
Check what was really applied
At six weeks we repeat the indicators and go through with the team what stuck, what was dropped and what needs adjusting.
Evidence: a before-and-after comparison with the team's own numbers.
The phases
What happens each week and who does it
I do most of the work without the team having to stop. I ask for time in two places: the survey, ten minutes per person, and the day of the workshop.
Diagnosis and baseline measurement
The team answers a ten-minute survey. I look at the AI configurations already in the company's repositories and we agree four to six indicators. With that I adapt the labs to the team's stack.
Deliverable: Diagnosis sheet and baseline measurement.Workshop and evidence pack
I give the full workshop, 5 to 8 hours depending on the team, with the last block on the company's repository. Each participant signs the attendance sheet and when the day is over I prepare the course evidence.
Deliverable: A branch with configurations, a technical AI and MCP usage policy, and the evidence pack.Management report
I write a three-to-five-page document for whoever decides, with what the diagnosis showed, what we worked on in the workshop and five prioritised actions with a proposed owner for each. It is not an audit.
Deliverable: A 3 to 5 page report.Q&A channel and pull request review
We open a channel in the company's Slack or Teams and I reply within two working days. The team sends me two or three real pull requests and I comment on them in writing, on the company's platform with its permissions, or with snippets if the company prefers. The channel closes at the end of week 5.
Deliverable: Written review of two or three pull requests.Remote review and second measurement
Ninety minutes remotely with the team to see what was applied, what was not and why. We repeat the indicators and adjust any configuration that needs it.
Deliverable: Before-and-after comparison.
Week 1 is the full workshop, with its syllabus and labs: Secure development with AI
Measure, don't promise
How to tell if it helped
In 2025 a randomised trial by METR with experienced open-source developers found they took 19% longer with AI, while believing they had gone 20% faster. Those were early-2025 tools and it says nothing about the team, but it shows that impressions are no measurement. So I don't promise a percentage. We pick together the indicators that are useful for the team, and these are candidates.
Pull requests with generated code reviewed against the checklist
What share of assistant-made changes goes through the agreed review checklist.
SAST and secret findings per pull request
What the team's tools already detect, counted before and after on the same kind of change.
Review time for a generated pull request
How long a person takes to accept or reject, measured in the company's version control system.
Assistant configuration changes that get reviewed
How many edits to files such as mcp.json or IDE settings receive human review.
MCP and Skills inventory with an owner and a reason
How many of the connected ones have someone who answers for them.
Team confidence in generated code
A short survey, repeated in week 6. It is a perception and I treat it as one.
Course or programme
| Need | Workshop | Programme |
|---|---|---|
| The team learns to use assistants under controls | The course does it: between 5 and 8 hours depending on the team, with the last block on the company's own code. | Adds a diagnosis up front and a review afterwards. |
| Documented justification for the training for a standard or an audit | The course includes the evidence pack. | Adds the management report and the final comparison. |
| Knowing what was applied and what changed after a few weeks | The course does not cover it. That is up to the company. | Two measurements and a review at six weeks. |
| A team that will apply the controls alone and has the time to do it | That is all it takes. If the team gets stuck, the 30-day guarantee covers an hour. | Not needed. |
What stays in the company
What the company keeps six weeks later
On top of all the workshop material, the programme leaves documents made to be passed around inside the company.
- Diagnosis sheetHow the team's AI configurations look at the start, and what it says in the survey.
- Baseline and final measurementA template with the indicators we choose together, filled in week 0 and again in week 6.
- Management reportThree to five pages with five prioritised actions and who answers for each.
- Evidence packSigned attendance, individual certificates, a mapped syllabus and a one-page letter for the auditor.
- Written review of two or three pull requestsComments on the team's own real changes, using the workshop's checklist.
- Before-and-after comparisonWhat was measured, what changed and what did not, as it is.
What is included
Everything in the course, and the rest of the programme on top
The programme includes the workshop and the four bonuses that come with it. To explain internally what is included, this list is the best place to start.
- +1
Compliance evidence pack
Signed attendance, an individual certificate with date, hours and contents, a syllabus mapped to the standards that apply to the company, and a one-page letter for the auditor.
- +2
Ten-minute survey for the team beforehand
It helps me adapt the labs to the team's stack and is the basis of the baseline measurement.
- +3
Configurations on a branch of the company's repository
I leave them in the final block, together with a technical template for an AI and MCP usage policy. It is technical and not legal, so the company's legal team adapts it.
- +4
Labs repository with solutions
To repeat them with whoever joins, under an internal-use licence for 12 months.
Compliance
What evidence the programme leaves and which controls it supports
The pack serves as evidence for these controls, but it does not satisfy them on its own. The company runs and maintains the control, and this documents the training. On the call I point out which ones apply to the company.
| Standard | What it asks for | What I leave as evidence |
|---|---|---|
| PCI DSS 4.0 · 6.2.2 | Documented training, at least every 12 months, for people who develop bespoke software, on security relevant to their role and languages. | A syllabus mapped to the requirement's points, signed attendance and date. |
| ISO 27001:2022 · A.6.3 | Security awareness, education and training appropriate to each person's role. | A record per person and role, with contents and date. |
| ISO 27001:2022 · A.8.25 and A.8.28 | A secure development life cycle and secure coding, including training for developers. | A mapped syllabus, plus the resulting Definition of Done and review checklist. |
| SOC 2 · CC1.4 and CC2.2 | A documented training programme, with completion records per person and depth according to role. | A list with name, date, content and role, and an individual certificate. |
| DORA · art. 13(6) | Digital operational resilience training proportionate to the role, for financial entities subject to the regulation. | A training record and syllabus, for the company's file. |
| AI Act · art. 4 | Measures to support AI literacy among staff, adapted to their role and context. It is an obligation of means and no certificate is required. | An internal record of the training, with content on AI risks and use according to role. |
Who it is for
For teams that want to see what changed and not just say they attended
A strong fit for
- Security architecture, AppSec and Platform Engineering owners who need to show results to management.
- Companies under PCI DSS, ISO 27001, SOC 2 or DORA where training already has to be documented.
- Engineering managers who see generated code in production and want to know where their team stands.
- Teams who use Claude Code or GitHub Copilot and decide permissions case by case.
Not the right programme if
- The company wants an inspirational talk for the whole department.
- The goal is to train two hundred people. A training platform costs less for that.
- The team has never used an assistant on a real repository.
- What is needed is an audit of the company's code with a vulnerability report, or something that certifies compliance with a standard.
Who teaches it
Security and development from someone who has worked on both sides
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.
I run this programme myself from start to finish, from the diagnosis to the week 6 review. I review the pull requests too, and I don’t hand them to anyone else.
Guarantees
What I guarantee, in writing
If the configurations do not work, I fix them
If the configurations I leave in the company's repository do not work, I run a free remote session to correct them.
One more hour if the team is still stuck at 30 days
If after 30 days the team has got stuck applying something from the programme, I spend an hour with the team remotely, free.
This is not an audit and I don't promise percentages, neither fewer vulnerabilities nor more productivity. What I leave measured is the team's before and after.
Format
One team, six weeks and a fixed proposal
The price depends on the duration and the size of the team, and we fix it after a call, based on the team's stack, the number of repositories and the indicators the company chooses. It includes the diagnosis, the workshop, the evidence pack, the report, the follow-up and the second measurement.
- Participants from one team or collaborating functions.
- Diagnosis, workshop, evidence pack, report, follow-up and final review.
- In English or Spanish.
- The company provides room, screen and wifi on the workshop day. Everything else is remote.
- Travel outside Madrid is agreed before the date is fixed.
Before we talk