During a recent internal Bitmovin hackathon focused on experimentation with AI tools, I decided to work on a project I wanted to explore, even though it was outside of our usual video focus. I gave myself a simple solo project that I thought would be a great way to test modern AI coding assistants: integrating an API that returns solar energy production data. It turns out that what should have been a straightforward integration turned into a two-day reminder of how easily AI can fail.
Two major tools, Cursor and Cloud, both encountered the same small string formatting bug and neither could overcome it. The result was that they lost at exactly the same task, but in a completely different way. One ran into a dumb logical wall, while the other dramatically imagined a completely wrong solution.
Shared battlefield: a highly distinctive signature
My objective was to interface with the FoxyCloud platform. The main hurdle was to generate a unique signature for each request, a standard practice in proprietary APIs to ensure the authenticity of the request and prevent tampering.
This signature is created by taking a short string of five important request parameters:
- HTTP method (POST)
- api path
- unique authentication token,
- timestamp
- JSON request body
You then run that final string through an HMAC-SHA256 hash function. The difficulty lies entirely in preparing the input string, not in hashing it.
Biggest Hurdle: Combination Trap
The API documentation requires that strings be concatenated using newline characters (\n). However, the API was expecting that newlines would be handled as literal characters within parts of the string, not just as concatenation operators. This created a huge blind spot for both AI tools, as shown in the examples below.
| Situation | Pseudo code generated by AI (false) | Required Format (right) |
| crisis | AI-generated code often uses concatenation operators (+ “\n” +) to create strings, resulting in an “invalid signature” error. | API required new lines incorporated as literal For the first section of the string within the string structure itself. |
| Example | String signature = “POST” + “\n” + “/api/v1/query” + “\n” + token + “\n” + timestamp + “\n” + “{“body”:”content”}” | String signature = “POST\n/api/v1/query\n” + token + “\n” + timestamp + “\n” + “{\”body\”:\”content\”}” |
No matter how I prompted them, both AI tools remained locked on the version on the left, and the API rejected every request until I switched to the format on the right.
Day 1: Silent cursor failure (logical deadlock)
i started cursorAI-powered editor, feeding it API documentation and error logs.
Cursor’s approach was systematic but ultimately circular. It correctly identified the part of the code responsible for hash generation, but it lacked the critical insight needed to challenge the construction of the input string. I spent hours debugging with it, and its suggestions revolved around changing the encoding or hashing library, which were all standard boilerplate fixes that were wrong.
Cursor failure was one of logical stubbornnessIt will not deviate from its initial, flawed combination pattern, making it a technical impasse, The error was always the same: “Invalid signature.”
Day 2: Claude’s dramatic failure (confident hallucination)
Frustrated with cursors, I switched to cursors cloud Another day to get a new perspective on the logs. The cloud was immediately more conversational and personable, which made it seem more helpful at first, but its output was even more confusing.
When presented with the failing code and an “invalid signature” error, the cloud was unable to identify the simple string concatenation bug that even the cursor had missed. Instead, it dramatically turned the entire debugging process around by declaring it a success.
story of wrong time
While I was giving it logs and error messages, Cloud captured the timestamp parameter, confidently declaring:
found it! Timestamp is visible 2025-11-18 but the actual current date is 2024-11-18Your system clock is set exactly one year in the future! Foxes API is rejecting requests because the timestamp is in the future,,, Please adjust your system clock.
it was a red Herring Of the highest order. This sent me off on a completely baseless tangent; I immediately checked my system clock, and This was absolutely correct. Instead of addressing the actual bug in the code, the cloud completely confused a complex, plausible system-level problem (time drift) to explain the error. It turned the cursor’s quiet inability to solve the problem into a credible, official explanation that was completely wrong.
unsolved problem
After correcting the initial timestamp tangent, I was back at square one. I explicitly asked Cloud to fix the string format, and, like cursors, it produced the erroneous collation highlighted in the previous section.
Important Findings: Two separate, high-powered AI coding tools are simultaneously defeated by a single, subtle formatting requirement in API integration. They could perform complex HMAC hashing, but they could not master the required string structure.
Conclusion: The New Rules of AI-Assisted Coding
My hackathon project ended not with data visualization, but with an important lesson on the status of LLM in development:
- AI shares blind spots: LLMs are powerful pattern matching systems. If there is a common pattern (like string + “\n” + string}) Wrong Solution For highly specialized APIs, the mistake is likely to be repeated by both models. They lack the ability to read the documentation seriously and enforce byte-level precision.
- Paradox in failure: The cursor failed silently, getting stuck in its initial argument. The cloud failed dramatically, combining a real bug with a credible, fabricated system error. Maya Proved to be a more disruptive, time-wasting error mode.
AI is a powerful coding assistant, but for subtle, context-heavy, and non-standard parts of coding, where literal truth is paramount, the human developer armed with the print(signature_string) command is still a better debugger.
<a href