Skip to main content

AI coding training for developers on your team's own repository

We teach engineering teams to write code with Claude Code, Cursor and GitHub Copilot without trading quality for speed. No tutorial to-do app: we work on your code, set up context for agents, write tests before the implementation, read diffs nobody on the team wrote, and agree what must never be sent to a model.

  • Claude Code, Cursor and GitHub Copilot
  • Practice happens on your team's repository
  • The trainer builds live products this way
  • Workshops of 4 or 8 hours
Book a consultationSee the modules

AI coding training for developers at a glance

AI coding training for developers from Webforte is a hands-on programme for engineering teams that want to write code with AI assistants and agents without losing control of quality. Teams work with Claude Code, Cursor and GitHub Copilot directly on their own repository, not on a sample app. The programme has six modules: preparing the repository and rules for AI, context and instructions for agents (CLAUDE.md, AGENTS.md), generation and refactoring with review, tests written with AI, code review and security, and agentic workflows and their limits. It covers secrets in the repository, licensing of generated code and data that should never be sent to a model. The trainer, Miroslav Douda, managing director of Webforte Technologies s.r.o. (company ID 23364343, Prague), builds his own products Kurikula.ai, Dotazio and Chytrejbyt.cz this way every day. For companies outside the Czech Republic we offer 4 or 8-hour workshops and a half day for leadership. The subsidised 50-hour programme is available to Czech companies only. Pricing follows a consultation.

You will recognise this in your team

AI tools are now part of most development workflows. The problems do not show up on day one. They show up a few weeks later in the git history.

  • More pull requests than review can handle

    An agent produces a change across twenty files in ten minutes. The reviewer skims it because the tests are green, and a month later nobody knows why the function looks the way it does.

  • The agent starts from scratch every time

    The repository has no file with project rules, so the agent picks a different form library, a different import style and different naming again. Developers fix it by hand and conclude that AI slows them down.

  • Tests are written after the code

    When an agent writes the implementation and the test in one go, the test often just confirms what the code does, bug included. A green pipeline then tells you nothing.

  • Nobody knows what was sent to the model

    The contents of .env in the context, a customer data export pasted into a chat, code under NDA in a tool without a company licence. Without rules nobody checks, and banning the tools only means people use them quietly.

The programme, module by module, on your repository

Before the training we agree access to the repository. If an NDA prevents sharing code, we prepare a practice project of comparable size. Every module ends with a concrete result in the repository, not just notes.

  1. 2 to 4 h

    Preparing the repository and AI rules

    We go through the project structure, build and test commands, and the places where an agent gets stuck: missing types, unclear folders, generated files. We set up .gitignore and tool ignore paths so secrets and build output stay out of the context. Then we draft the first version of team rules: which tool for which job, what can be committed without review and what never can.

    Output: A tidied repository and the first version of team AI rules

  2. 2 to 4 h

    Context and instructions for agents

    We write CLAUDE.md or AGENTS.md for your project: architecture, conventions, commands, forbidden patterns. We show why a short, precise file works better than a long essay, how to split instructions by folder and how the agent should load the relevant files itself before starting. We run the same task with and without context and compare the diffs.

    Output: CLAUDE.md or AGENTS.md tested on a real task

  3. 2 to 4 h

    Generation and refactoring with review

    We take a real ticket from your backlog. Plan first, then small steps, with the compiler and linter after each one. For refactoring we practise keeping the change small enough to read and pulling the agent back when it starts changing things outside the brief. Each participant reads a diff they did not write and explains it to the others.

    Output: A ticket delivered as a pull request that passed review

  4. 2 to 4 h

    Tests written with AI

    Test first: a person describes the behaviour, the agent writes the test, the test has to fail before any implementation exists. We show how to spot a test that merely mirrors the code, how to use an agent to add tests to legacy code with no coverage, and when writing the test by hand is quicker.

    Output: New tests for a chosen area of code and a test-first routine for the team

  5. 2 to 4 h

    Code review and security

    We build a checklist for reviewing AI code: new dependencies, invented APIs, silent behaviour changes, missing input validation. We cover secrets in the repository and in git history, licensing of generated code and filters for matches with public code. And we set out what never goes to a model: keys, customers' personal data, code that a contract does not allow you to share with a third party.

    Output: A review checklist and security rules in the PR template

  6. 2 to 4 h

    Agentic workflows and their limits

    An agent that runs commands on its own needs clear permissions. We set up an allowlist of commands, show parallel agents on independent tasks and checking the result with git diff every time one returns. Above all we agree where an agent does not belong: production database migrations, payment logic, permission changes without a second pair of eyes.

    Output: Configured agent permissions and agreed limits for the team

Copilot, Cursor or Claude Code

We do not pick a winner. Each tool suits different work and many teams use two of them. The comparison comes from our daily work, not from benchmarks.

Swipe the table sideways to see all columns.

Copilot, Cursor or Claude CodeGitHub CopilotCursorClaude Code
Where it runsExtension for VS Code, JetBrains and other editors, connected to GitHubA standalone editor built on VS CodeThe terminal, with extensions for VS Code and JetBrains
Where it is strongestCompletion while typing and smaller edits in the editor the team already usesMulti-file edits with a preview of changes right in the editorLonger tasks where the agent reads the repository, runs tests and corrects itself
Working with contextOpen files, a repository index and instructions in .github/copilot-instructions.mdWhole-project index, rules in .cursor/rules, AGENTS.md supportCLAUDE.md at several levels, the agent finds files itself using tools
When we recommend itThe company uses GitHub Enterprise and wants the tool under existing licence managementThe team wants an agent but still wants to see every change in the editorSenior teams who can scope a task, restrict permissions and read a larger diff
What to watchFast suggestions tempt people to accept code without reading itSwitching editor, settings and habits for the whole teamThe agent runs commands, so permissions must be set up in advance

These tools change month by month. That is why we mainly teach principles (context, planning, test first, review, permissions) that apply to all three. If your company has standardised on one tool, we build the training around it.

What we teach, because we do it every day

We build our own website, Kurikula.ai, Dotazio and Chytrejbyt.cz with AI agents. In the training we pass on the practices that worked for us, and the mistakes we made first.

Context belongs in the repository, not in the prompt

Our own repository has both CLAUDE.md and AGENTS.md: stack, commands, conventions, dark mode rules, SEO requirements and what the agent must not change. Every new session starts with the same knowledge. When the agent repeats a mistake, we do not rewrite the prompt, we add a rule to the file. Teams learn this on their own code: what belongs in the context, what only bloats it and when to split the file by folder.

  • One rules file for the whole team, versioned in git
  • Build, test and lint commands right in the instructions
  • A repeated agent mistake becomes a new rule
  • A shorter, precise file beats a long one

The compiler is the first reviewer

We build on strict TypeScript, Drizzle ORM and validation with Zod. The reason is practical: an agent gets types or the database schema wrong more often than the logic, and the compiler catches it before a person does. After every agent step we run type checks and the linter, and only a clean result goes to human review. In the training we set up this loop for your stack, even if you do not use TypeScript.

  • Type check and lint after every agent step
  • Strong types and schema as a boundary for generated code
  • Input validation on both client and server
  • The approach carries over to other languages and frameworks

A git diff after every agent

When we run several agents in parallel, each gets one independent task, and when it returns we always read the git diff, even if the agent reports that nothing went out of scope. Agents sometimes edit files outside the brief or delete code they think is unused. We teach this as a fixed rule: no commit without a diff someone has read. It sounds like a delay and saves hours of debugging later.

  • One agent, one task, clearly scoped files
  • A person reads the diff, even when the agent reports success
  • Out-of-scope changes are reverted, not patched afterwards

AI output has to be verifiable

Our products follow the same principle as our coding. Dotazio answers only from the documents it is given and cites the source, Kurikula.ai backs every suggestion with a code from the Czech national curriculum, and our editorial pipeline for the blog verifies sources before publishing. In development this means the agent must not invent an API that does not exist in the project, and every claim in a pull request must be traceable to code or a test.

  • Checking that called functions and packages actually exist
  • New dependencies only after deliberate approval
  • The PR description must match the actual diff

A trainer who teaches and builds

Miroslav Douda is the managing director and lead developer of Webforte and a former teacher. As a trainer with the PECKA team he has trained more than 9,000 teachers. The training is not a slideshow with demos but work at the keyboard: a short explanation, a task on your code, reading the result together. You deal directly with the person who uses these tools in production and knows where they fail.

  • Most of the time is spent on participants' own code
  • Questions are handled on concrete files, not in the abstract
  • The same trainer from the first call to the last module

Formats for teams outside the Czech Republic

We put modules together based on where your team is. Companies outside the Czech Republic can book formats paid for directly by the company.

WorkshopUp to 12 people, so the trainer can review everyone's work on the repository. Modules chosen for your team, priced after a consultation.
4 or 8 hours
Half day for leadershipFor CTOs, team leads and owners: choosing tools, licences, rules for data and security, and measuring benefit instead of guessing.
up to 8 people
Several modulesWe recommend spreading the full programme over several dates so the team can try the practices on everyday work in between.
2 to 4 hours each
Subsidised 50-hour programmeThe contribution from the Vzdělávání pro firmy scheme comes from the Czech Labour Office and is only available to companies employing staff in the Czech Republic.
Czech companies only

What your team has after the training

The results stay in your repository and belong to you.

  • CLAUDE.md or AGENTS.md for your project, tested on a real task
  • Team AI rules: which tool for what, what can skip review and what never can
  • A checklist for reviewing AI code, built into the pull request template
  • Security rules: secrets, personal data, licences, what never goes to a model
  • Configured agent permissions and a command allowlist
  • At least one real change taken through test and review
  • Materials for the modules covered and a certificate of attendance with hours

Where we use these practices

We do not teach from tool documentation. We teach what our own live products are built on.

Who the training is for

A good fit if

  • Your engineering team already uses AI tools but has no shared rules
  • You want to roll the tools out with review and security set up from the start
  • You can use your own repository, or part of it, for the training
  • You are looking for a small nearshore partner in Prague that builds this way itself

Not a fit if

  • You want an AI introduction for non-technical colleagues
  • You expect AI to replace developers and make review unnecessary
  • You are counting on the subsidised 50-hour programme, which is for Czech companies only
  • You want a certificate without hands-on work

Frequently asked questions

The price depends on the format, number of modules, group size and how much preparation your repository needs. Companies outside the Czech Republic pay for the workshop directly. You receive a quote after an initial consultation where we clarify your stack, the team's experience and the tools you already use.

Only as a Czech company. The contribution from the Vzdělávání pro firmy scheme comes from the Czech Labour Office and is tied to employees in the Czech Republic. For companies elsewhere we offer 4 or 8-hour workshops, a half day for leadership, or several modules spread over a number of dates. The content is the same, only the funding differs.

Yes. If your team already works with Claude Code or plans to adopt it, we build the modules around it: CLAUDE.md, permissions, hooks for type checks and tests, parallel agents and review. The same applies to Cursor or GitHub Copilot. The principles stay the same, only the setup differs.

We recommend it, because your own code shows what the team really struggles with: missing tests, a large repository, historical decisions. If an NDA or internal policy prevents sharing code, we prepare a practice project of comparable size. We can also work on a selected part of the repository without sensitive modules.

Developer training works well online, because everyone works in their own environment and shares their screen. On-site sessions at your office or at ours in Prague are arranged depending on group size. We agree the format and the language of delivery during the consultation.

That is why security is a module of its own. We decide which files the tools ignore, how to keep secrets out of the repository and git history, and which permissions the agent gets. We write down what never goes to a model: keys, customers' personal data and code a contract does not let you share. We also cover company licences and providers' data processing terms.

Code written during the training stays in your repository and belongs to you, as do all other outputs. On licensing we show why generated code can resemble existing open source, how to enable filters for matches with public code and how to check new dependencies during review. This does not replace legal advice on a specific contract.

Yes, we just start in a different place. Juniors mainly need to read and verify what the agent wrote and not accept code they do not understand. Senior teams move faster to agentic workflows, permissions and parallel work. We clarify the group's level in the first call and choose the modules accordingly.

Let us put together a programme for your team

Tell us how many developers you have, what stack you use and which AI tools are already in place. In the consultation we propose modules and a format and send a quote.

Free consultation