❄️ Winter Bootcamp · July 2026 · Day 4 · Thursday

Day 4 — Sprint, Refinement & Tests

The longest day of the camp: build the MVP, test and refine end to end

🗓️ Today's blocks

09:30 – 11:00 — Instruction, alignment and architecture presentation
11:00 – 12:00 — 1st development block
13:30 – 15:00 — 2nd block + tests and refinement
15:10 – 16:00 — Publishing and final checklist

🎯 Goal of the day

Working MVP end to end by 4pm
Tested against the acceptance criteria and refined
Published by link in Lovable, externally accessible

How to run the development

Kanban, focus on one task at a time, and continuous checking

Guidelines

🔄 Kanban of the day

To do

Interview data form

Integrate the prompt in Lovable

Render classification and summary

Publish link in Lovable

Doing

One task per person at a time

Done

Spec validated ✅

Classification prompt tested ✅

✅ Does it work? — before calling the instructor

Can the user enter the interview data?

Does the prompt receive that data as parameters?

Do the candidate's classification and summary appear legibly?

Is the public Lovable link working?

Checkpoints of the day

Goals per time block — use them to know if the group is on pace

Pace

By 12:00

Interview data form working

Spec fields mapped as parameters

By 15:00

Classification prompt integrated and generating output

Candidate classification and summary in the interface

By 16:00

Published in Lovable via link

Tested against the acceptance criteria

🆘 When to call the instructor

More than 30 minutes stuck on the same problem
Long discussion with no one writing code
Inconsistent output and the group cannot explain why

Publish in Lovable

From the form to the public link, step by step

Tool

🚀 Step by step — Lovable

Describe the interface in Lovable: a form with the interview data fields defined in the spec.
Integrate prompt: connect in Lovable the prompt that classifies the candidate by the evaluation criteria.
Parametrize: map each form field as a parameter of the prompt.
Render output: display in Lovable the candidate's classification and summary in the funnel.
Test: run a real interview case and compare it against the spec's acceptance criteria.
Publish link: use Lovable's publish button and confirm external access.

When the output diverges

Minimal debugging guidance before asking for help

Debugging

🔍 How to investigate

Confirm that all interview fields reach the prompt: empty parameters produce generic answers.
Narrow the test to a single candidate and follow the result step by step.
Reread the prompt: are instruction, evaluation criteria, and output format explicit?
Run the same case twice: large variation signals an under-constrained prompt.
Check that the classification reflects the spec's criteria, not irrelevant attributes.

Before considering it done

Acceptance criteria, fairness, and data protection

Responsible AI

✅ Definition-of-done checklist

Does the output meet the acceptance criteria defined in the spec?

Does the classification reflect the spec's evaluation criteria, not protected attributes?

Does the output avoid reproducing discriminatory bias between candidates?

Is the interview data handled per LGPD (minimum necessary, no undue exposure)?

Is the public Lovable link working and accessible externally?

🎤 Present the architecture and draw the flow

Each group shows where it got and draws the application flow live · ~5 min per group

⏱️ Dynamic

🧭 How it works

Each group has ~5 minutes — the on-screen timer keeps the time.
Draw the application flow live: whiteboard, paper or screen, whatever you have.
While drawing, explain the architecture and the current state.

✏️ What the drawing must show

The steps in order: upload → screening → invite → video → decision.
Where the AI comes in — the screening engine.
The data that enters and leaves each step.
The integrations: database, email and storage.

🗣️ What to explain

Which slice of the problem the platform solves.
How the application is working today — what already runs in Lovable.
What is still missing and where the group is stuck.

👀 The class takes part

Each presentation gets one question from the class.
Note the feedback — it feeds the afternoon refinement.

A good flow

Anyone understands the data's path with no extra explanation.

Why test the prompt

The perfect input is rarely the real one — robustness is verified at the edges

Afternoon · Concept

⚠️ Where screening prompts break

Incomplete interview: a stage or a candidate data point is missing
Out-of-scope request: something that is not candidate selection
Malicious input: attempts to bypass the constraints (prompt injection)
Protected attribute: age, gender or origin trying to weigh on the score
Volume: a transcript that is too long or an answer too short

🛠️ How to handle failures

Validate before sending: check required fields in the interface
Instruct the fallback: state in the prompt what to do when data is missing
Reinforce constraints: repeat the limits at the end of the prompt
Clear messages: when the AI cannot classify, explain why

Principle

A robust prompt fails predictably — never with a wrong classification presented as correct.

Each test verifies a quality from the spec

Linking test types to the NFRs and the ISO/IEC 25010 characteristics

NFR · ISO 25010

Test type	ISO/IEC 25010 characteristic	What it guarantees
Happy path vs criteria	Functional suitability (correctness)	With a complete interview, the classification matches the acceptance criteria
Incomplete input	Reliability (fault tolerance)	Without a stage, the AI flags the gap instead of inventing a score
Malicious input / protected attribute	Security	The AI resists bypasses and does not use sensitive data to classify
Out of scope	Functional suitability (appropriateness)	The AI performs only the screening defined in the spec and declines the rest

Continuity with the spec (Day 1)

Each NFR written in the spec becomes a concrete test. Testing is not optional: it is how you prove the promised quality exists.

Testing against bias and LGPD breaches

In an agent that screens candidates, this test is not optional

Responsible AI

⚠️ What to verify

Protected attribute: build two equivalent interviews that differ only in age, gender or origin — the funnel classification must be identical.
Privacy (LGPD): confirm the output does not expose the candidate's sensitive personal data nor use it to score.
Human decision: the AI recommends and flags uncertainty; the recruiter decides. Never an automatic rejection.

🔗 Why test this

These are prompt constraints — they come straight from the spec's NFRs (Day 1)
They connect to ISO/IEC 25010: security and reliability
Fairness and privacy are proven with a test, not assumed

Constraint to test: classify the candidate only by job-related competencies; ignore age, gender and origin; do not expose sensitive personal data.

Worked example — iterative refinement

Prompt fails → diagnosis → fix one part → re-test

Iteration

❌ v1 — the test fails

Classify this candidate from the interview: [interview]

Failure observed in the test

Classified without justifying the funnel position
Mentioned the candidate's age as a factor
Each run returns a different format

✅ v2 — fix one part and re-test

Diagnosis: constraint and format are missing

Classify the candidate by job criteria.
+ Do not use age, gender or origin.
+ Return a table: funnel stage + score + justification.

Changed one part at a time (constraint and format)
Re-test: consistent and justified classification
The protected-attribute test pair now passes

Group activity — build the test table

Screening for Azul Linhas Aéreas · 30-min timer · one case per row, run them all

⏱️ Active Learning

Case type	Test input (interview data)	Expected output
Happy path	Complete interview, all stages recorded	Candidate classified in the funnel, within the acceptance criteria
Incomplete input	Candidate missing one interview stage	Flags the pending stage or uses a fallback — does not invent a score
Out of scope	Request unrelated to selection (e.g. book a flight)	Politely declines and redirects to screening
Constraint test (protected attribute)	Two equivalent interviews differing only in age, gender or origin	Identical classification — the protected attribute has no influence

⏱️ 30 minutes — start the timer 👥 Full group 🔁 Adjust the prompt and re-test

Checklist — is the screening robust?

Answer "yes" to everything before considering the prompt ready

Self-assessment

Does the happy path produce the expected classification?
Does incomplete input flag the gap without inventing?
Is the out-of-scope request declined and redirected?
Does the protected-attribute pair give an identical classification?
Does the output always come in the defined format?
Does no sensitive personal data appear in the output?
Was each failure tied to the prompt part that caused it?
Was the prompt adjusted one part at a time?
Is it clear that the decision is human?
Does the table record the obtained output and ✓/✗?

🎓 Day 4 wrap-up

Where we got and what comes next

Wrap-up

✅ Today you

Built the platform MVP end to end
Presented the architecture and tested against the acceptance criteria
Refined the prompt and handled bias and LGPD
Published the link in Lovable

➡️ Tomorrow (Day 5)

Presentations: a 4-minute pitch to the panel
Arrive with the demo ready and the published link working

📌 Before tomorrow

Leave the Lovable link published and tested, and organize who says what in the pitch. Tomorrow the format is free — what matters is the panel understanding the problem, seeing the solution work and feeling the value.