Why RAG failed on an automotive codebase and agents did not
Read the full post on AWS BlogA generic coding assistant writes plausible C++ that ignores the twenty years of libraries already sitting in your repository. For AUMOVIO, who write software-defined vehicle code against AUTOSAR, MISRA and a set of in-house rules, that isn't a small annoyance, because someone still has to review the duplicate, test it, and eventually take it back out. The first attempt was RAG: put the codebase in a vector store, retrieve, generate. It didn't work, because a single semantic query couldn't find the relevant code, and knowing what to look for depends on what you have already found.
Switching to an agentic setup fixed that. The assistant searches, reads what it got back, works out what it still needs, and searches again. Wired into Cline over Amazon Bedrock, it fixed a bug that had cost a senior developer five days, refactored a large file down by 50%, and turned out to be good at explaining unfamiliar code.
What it still wouldn't do is use AUMOVIO's own abstractions, and that isn't a retrieval problem, so the architecture splits the two jobs. An orchestrator, either Claude Sonnet 3.7 or 4 inside Q Developer or Cline, handles the conversation, plans, and answers anything open-ended. Models fine-tuned on AUMOVIO's code handle the narrow steps where house style matters, generating method bodies from system designs and then unit tests. They sit behind MCP endpoints the orchestrator calls, so adding one means registering it rather than rebuilding anything.
