“Backend” was not a baking service.
A long software development description exposed both an input limit and a cross language false match.
I described software work in a full paragraph: React, Next.js, frontend, backend, and different ways of pricing a project. The interview should have used what I had already explained. It failed before it could do that properly.
The investigation found two separate problems. One was a field size limit. The other was a surprisingly literal mistake in service matching.
See the original requestInside the screen
A question that belongs to software.
The later screen is useful because its choices stay in the same profession as the service being described.
Select a detail
The question asks about software work. That is the first thing I would inspect after the earlier baking mismatch, before judging the layout or tone.
The options distinguish work such as SaaS and internal tools. A familiar sounding question is insufficient if its choices belong to the wrong service.
The custom answer keeps the choices from becoming the entire definition of the profession. I want the AI to learn from an unexpected answer, not force it into a convenient label.
Captured 30 July. It is a later example of the intended behaviour, not a screenshot of the June classification failure.
The original request20 Jun 2026 · excerpt
if i provide that much info, it should be versatile to ask relevant questions and fill up these automatically for users profile
Excerpted from the development conversation. Punctuation is lightly edited; the surrounding story is an edited retrospective.
01
April 6: the old example was still in the definition.
“we need to completely migrate to the new app and architecture for neeed.app”
Before the June classification failure, I had already found a vehicle requirement lingering in the description of a broader service platform. I asked the AI workflow to correct the product definition and make category specific context optional. The work revised the broad documentation while keeping legacy compatibility explicit.
That distinction matters when a coding tool repeatedly reads the project notes. An old example can become a rule simply by surviving in the context. Correcting the documentation gave later work a better starting point, but the June failure showed that the definition still had to survive input validation and rendering.
02
The first failure happened before the model had a chance.
The useful diagnosis had two layers. The first was an input boundary: a field intended as a short service label was limited to 120 characters. I was providing a description of real work. That longer paragraph could be rejected before the AI interview ever interpreted it. Asking for a more intelligent model would not fix a request that never reached the model.
I want the starting point to accept the level of detail a person naturally offers. A short title can be derived for display, but the original description carries context that should not disappear just to fit the title’s constraint. The recorded repair enlarged and normalised the input path. It turned my actual paragraph into a regression case rather than replacing it with an easier sample that happened to pass.
03
Substring overlap is not professional meaning
After the input limit was addressed, the English word backend matched the German baking keyword backen. The taxonomy could therefore route software work toward the wrong profession.
The fix corrected that false match and added tests for the exact paragraph, the backend/backen case, and software bracket mapping. The difficult input became a reusable regression case rather than a one time exception.
04
Similar letters were doing the job of understanding.
The second failure made the first one memorable. Backend development was being associated with baking through an overly broad language match. That is an absurd result from the provider’s point of view, but it is also a very useful diagnostic example. The wrong profession can send every subsequent question in the wrong direction while each individual control continues to function.
The repair addressed profession interpretation and the software service context. I would still inspect the next question, not just the chosen category label, because that is where the interpretation becomes an experience. The later software provider capture offers a visible comparison: the question relates to development work. This was a good reminder that my role with AI tools is often to preserve the stubborn real example until the whole path handles it.
A correct interpretation can still be lost before it reaches the screen. I return to that question in The model answered. The app threw it away.
Where this chapter landed
What changed.
The description length rejection and the backend/backen false match were fixed. The detailed input seeded a software profile and led to a relevant client question.
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.
Inspect acceptance before interpretation
The schema documentation distinguishes the object’s property definitions from required fields. For this failure, my first diagnostic question is whether the input reaches the intended interpretation path at all. Validating the request and understanding the profession are separate checks.