Coding without blind trust

How can you explore an idea with generated code without confusing a convincing demonstration with reliable software?

  • Lovable
  • Claude Code
  • Codex

1250 € per session, excl. VAT

In short

This half-day session of 3 hours offers a guided introduction to code generated through instructions. Through a simple exercise, participants learn to clarify a request, observe the result and identify its limits. They leave with a verification dossier they can use to discuss a trial with a technical contact.

Why this training?

An interface displaying a plausible result can conceal an incorrect calculation, poorly validated input or code that is difficult to maintain. Vibe coding makes exploration through instructions easier, but replaces neither an understanding of the need nor verification of the resulting behaviour. The risk is repeatedly asking AI for corrections without knowing what has changed. This introduction teaches participants to limit the scope, retain observations and recognise situations where a competent human review becomes essential. Running case study: The fictional association Avelune Partage wants to illustrate the calculation of the charge for a loan of equipment: quantity multiplied by duration and daily rate. Participants explore an educational calculator with no user account, payment, storage or connection to a real system. Transfer to work: Before proposing a trial within their organisation, participants reuse the verification checklist to describe the need, exclude sensitive data and identify the necessary technical validations. They explicitly distinguish between exploration, correction and a possible decision to proceed with development.

Objectives of this training

  • Describe the principle of vibe coding and the role of instructions.
  • Distinguish between visible results, generated code and verified behaviour.
  • Formulate a simple request with explicit limits.
  • Carry out guided checks and record discrepancies.
  • Identify risks requiring a technical review.

Who is it for and what are the prerequisites?

Roles and tasks concerned

  • Team leaders and non-developer staff wishing to understand this approach.
  • People with digital ideas who need to engage with a technical team.

Prior skills

  • No prior knowledge of AI or programming required.
  • Ability to use a browser and enter written instructions.

What you will work on

  1. Observe before trusting

    Objective: Recognise what an instruction produces and what it does not prove. The principle of vibe coding; code generation and modification; the difference between a correct appearance and verified operation.

  2. Define the scope of the request

    Objective: Express a need precisely enough for it to be verifiable. Inputs, formula, units, expected behaviour and exclusions; a cautious introduction to Lovable, Claude Code and Codex, with reference to their official documentation.

  3. Experiment and compare

    Objective: Try an iteration without delegating judgement. Guided generation in the selected tool; observation of changes; the value of retaining a reference version.

  4. Identify limits and decide

    Objective: Define what conclusions the trials actually support. Human review, incomplete testing, maintenance and secrets management: never insert a real key into instructions or shared code.

What you take away

  • Scoped request sheet for the calculator.
  • Log of instructions and observed changes.
  • Completed verification checklist with expected and actual results.
  • Note on limitations and questions for a technical review.

Method and assessment

  • Short explanations followed by immediate practice on the running case study.
  • Individual work followed by work in pairs, with peer review of outputs.
  • Guided group discussion: what works, what needs correcting and what remains a human decision.
  • Preparation: Arrange access to one of the tools authorised by the organisation: Lovable, Claude Code or Codex; check access conditions before the session. Prepare the calculator’s fictional values and an isolated practice environment; do not use any confidential data or real secrets.

Observable criteria: The request specifies the formula, inputs and excluded functions. ; Four checks explicitly compare expected and actual results. ; A change is followed by a new check of the normal case. ; The note distinguishes between an observed defect, a suspected risk and an unverified point. ; Participants explain why the exercise does not constitute validation for deployment to production..

Frequently asked questions

Do I need to be able to read code?

No. In-depth technical reading remains outside the scope; the exercise focuses on requests, observations and limitations.

Will we practise with all three tools?

No. One authorised tool is enough. The exact arrangements depend on the environment and the official documentation.

Can I bring a real file?

Only in an anonymised and authorised form. The running case study uses fictional data exclusively.

Can the calculator be deployed to production?

The session does not validate this. Technical and security reviews and additional tests would be necessary.

Last updated: