The model answered. The app threw it away.
A response shape mismatch quietly turned a live AI interview into hardcoded questions.
The interview was supposed to ask a service provider questions that fit their work. Then it asked hardcoded questions. I had already clarified that the example category was only an example. It was not supposed to become the shape of the whole product.
The useful discovery was more specific than “the AI was not good enough”. The model was answering. The interface never used the answer.
See the original requestInside the screen
Before: a broad question and a generic preview.
This later development capture gives me a visible baseline for the interview. The question and the profile should become more specific as the person answers.
Select a detail
The opening question is broad. Reading a useful model response in a log is not enough if the interface keeps presenting a generic prompt.
The profile remains generic here. I need to follow the information into both the next question and the profile, rather than stop when the request succeeds.
Captured in July, after the June response handling work. This is a visible comparison, not a capture of the discarded model payload.
The original request18 Jun 2026 · excerpt
the whole flow should be AI interview, its asked hardcoded questions
Excerpted from the development conversation. Punctuation is lightly edited; the surrounding story is an edited retrospective.
01
The failure was between the model and the screen
The route rejected the AI’s compact response shape and fell through to an old static question. The product could continue displaying a working form while the reason for that form had stopped working.
A provider would not see a schema mismatch. They would see a question that did not belong to their service, then have to decide whether to force an answer into it. A functional control can still represent a broken interaction.
02
Normalize, validate, then render
The fix normalized the real AI output into the validated control schema. The route stopped silently substituting generic questions. If the AI was unavailable, the client showed a localized retry message.
That is a meaningful product decision as well as an integration fix. A retry tells someone that the interview needs another attempt. A generic fallback can hide the failure by continuing as if it understood their work.
Inside the screen
After: the answer has a visible consequence.
I can trace the SaaS answer into a more specific question and the profile preview. Each is a separate place where useful information could be lost.
Select a detail
The SaaS products response remains visible. It gives the next question a reason to exist and gives me something concrete to compare against the preview.
The interview now asks who the typical SaaS clients are. I would compare the rendered wording with the accepted response, not just check whether the API returned successfully.
The profile tags and description now mention SaaS. That visible change is useful evidence of propagation in this fixture, without proving that every possible answer survives the same route.
This July fixture illustrates the visible relationship. The June account of the parsing fix comes from the development record.
Follow the response.
The same model can lead to a different experience depending on what happens at the interface boundary.
- 01The model returns a relevant answer
- 02The response is normalized and validated
- 03The tailored question reaches the screen
03
An answer should change what comes next
The recorded local check used a sound engineer who described mastering tracks for electronic artists. The next question asked which electronic genres they specialised in, with relevant options. The later application captures show a software provider example; the June sound engineer check is preserved in the written record.
The response recorded passing implementation checks, including tests and a build. That did not prove that every possible service now received a perfect interview. It established that the identified response mismatch was repaired and that a concrete category specific flow worked locally.
04
The next question became the next piece of work
Later captures show this idea continuing: a software provider answer leads to a question about the provider’s clients, while a profile builds alongside the conversation. Those screenshots retain their July dates.
This is the engineering work I want to make visible. The model is one participant in a system. Parsing, validation, failure handling, and interface state determine whether its output reaches a person as something useful.
05
The fallback was hiding the failure from both of us.
A silent fallback is particularly dangerous when the product promises to adapt. The screen can remain responsive, its buttons can work, and a basic browser check can pass. Meanwhile the person has lost the only reason this form was different. The error had moved from an obvious technical failure into a subtle experience failure: the next question no longer belonged to the answer.
The useful AI development loop here crossed the full boundary. I needed the model response, the route’s interpretation of that response, and the control that appeared in the browser. Normalising a supported compact response addressed the mismatch without giving the model permission to invent arbitrary interface code. The later provider captures make that distinction visible: a broad answer leads to a more specific question. They are later examples of the behaviour, not replacements for the original June evidence.
Preserving the answer led to a broader question about the input itself. I return to that question in Let the answer shape the form.
Where this chapter landed
What changed.
The response normalization and retry behaviour were implemented and locally verified. The exact sound engineer path produced a relevant follow up instead of a generic fallback.
Added while revisiting this story · September 2026
The thinking behind the detail.
Research notes to take these decisions further. These sources were reviewed for this retrospective.
A property description is not a requirement
JSON Schema distinguishes declared properties from required properties and controls for additional fields. That reinforces the need for an intentional contract between model output and UI, rather than assuming a plausible object is a renderable interview step.