🎯 Goal of the day
The longest day of the camp: build the platform MVP end to end in Lovable, present the architecture, test against the acceptance criteria, refine the prompt and publish the link. By the end of the day, the screening solution truly runs — from input (interview data) to output (candidate funnel).
🗓️ Blocks of the day
Time organization
- 09:30 – 11:00 — Instruction and scope alignment.
- 11:00 – 12:00 — 1st development block.
- 13:30 – 15:00 — 2nd development block.
- 15:10 – 16:00 — 3rd development block.
🔄 How to run the development
Use a simple kanban with three columns — To do, Doing, and Done — keeping at most one task in "Doing" per person. This preserves focus and makes progress visible to the whole group. Anchor the tasks in the Azul Linhas Aéreas case: interview data form, a prompt that classifies the candidate by the spec's criteria, and display of the classification and summary in the funnel.
Checkpoints — goals per time block
- 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 appearing in the interface.
- By 16:00: published in Lovable via link and tested against the acceptance criteria.
When to call the professor
- More than 30 minutes stuck on the same problem.
- A long discussion with no one writing code.
- Inconsistent output and the group cannot explain why.
🎤 Afternoon start — Architecture dynamic
Before diving into testing, each group presents in about five minutes the architecture of its solution and the current state of the application, drawing the flow live — on a whiteboard, on paper or on screen, as they prefer. The goal is to make the data's path explicit and to show, to the class and the professor, where the solution stands and where it gets stuck.
What the drawing must show
- The steps in order: spreadsheet upload, AI screening, email invite, video collection and human decision.
- Where the AI acts — the screening engine — and the data that enters and leaves each step.
- The platform's integrations: database, email service and video storage.
In the presentation, the group explains which slice of the problem the platform solves, how the application is working in Lovable and what is still missing. The class asks one question per presentation, and the recorded feedback feeds the afternoon refinement. A good flow is one anyone understands with no extra explanation.
⚠️ In the afternoon — Why test the prompt
Almost every prompt works when the input is perfect, but the perfect input is rarely the real one. A solution's robustness is verified at the extremes — when the interview is incomplete, the request is ambiguous, out of scope, or tries to introduce a protected attribute into the decision.
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 classification.
- 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: tell 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 if it were correct.
📐 Each test verifies a quality from the spec
The test types are not arbitrary: each one proves a non-functional requirement (NFR) and an ISO/IEC 25010 characteristic defined on Day 1. Testing is how you demonstrate that the promised quality exists.
| 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. |
🧪 The test table
Record each case in a row, run them all, note the obtained output, and mark ✓ (passed) or ✗ (failed). Adjust the prompt and repeat until every case passes. All cases are written for the screening agent of Azul Linhas Aéreas.
| Case type | Test input (interview data) | Expected output | Obtained 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 | — | — |
⚖️ Testing against bias and LGPD breaches
In an agent that screens people, fairness and privacy are not assumed: they are proven with a test. These safeguards revisit the Day 2 responsible-AI vocabulary — bias, protected attribute, and LGPD — and now appear as concrete test cases.
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.
These are prompt constraints, coming straight from the spec's NFRs, and they connect to ISO/IEC 25010 (security and reliability). Write them explicitly in the prompt:
🔁 Worked example — iterative refinement
A prompt is not born robust. The cycle is prompt fails → diagnosis → fix one part → re-test. Fixing one part at a time lets you know exactly what solved the problem.
v1 (the test fails):
Failure observed in the test: the AI classified without justifying the funnel position, mentioned the candidate's age as a factor, and returned a different format on each run.
Diagnosis: the protected-attribute constraint and the format definition are missing.
v2 (fix one part and re-test):
+ Do not use age, gender, or origin.
+ Return a table: funnel stage + score + justification.
On the re-test, the classification comes out consistent and justified, and the protected-attribute test pair now produces the same funnel position.
🚀 Publish in Lovable — step by step
The MVP building tool is Lovable. The path to the public link follows six steps:
From the interface to the public link
- 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
If the candidate's classification or summary does not match what was expected, investigate before asking for help:
Investigation routine
- 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.
✅ Checklist before considering it done
| Verification |
|---|
| Can the user enter the interview data? |
| Does the prompt receive that data as parameters? |
| Do the candidate's classification and summary appear legibly in the interface? |
| Does the output meet the spec's acceptance criteria? |
| 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? |
🏁 Deliverable
➡️ Next day
Day 5 — Presentations: align, rehearse and present the solution to the panel with a live demo, in a free-format 4-minute pitch.