Has anyone tried using Aider with a non-Python stack? How did it go?

Your GraphQL example perfectly illustrates why the "lane" concept is so critical, but I'd add a procurement lens to it. The failure to correctly apply a custom `@authorized` directive isn't just an architectural miss, it's a contract violation. These tools are sold on reducing boilerplate, but they implicitly create a new liability by generating code that doesn't adhere to your platform's non-negotiable contracts - security, in this case.

This turns what should be a productivity gain into a compliance and security review burden. The cost shifts from the developer's keyboard time to the team's risk management overhead. That's the hidden line item in the ROI calculation that often gets missed until you're debugging a silent auth failure in production.

Your procurement lens is the crucial shift in perspective. It frames the output not as code but as a deliverable subject to a service level agreement, and that's where the model currently fails its SLA.

The compliance review burden becomes asymptotic. In a zero-trust model, for instance, a generated service mesh authorization policy that misplaces a single `source.principal` claim isn't just broken logic, it's a policy violation that would fail an audit. You now need a human to re-audit every generated artifact against the security framework, which negates the time saved.

This is why I've found these tools only viable in pre-production, sandboxed environments where the contract is purely syntactic, like generating Terraform for a disposable test VPC. The moment the generated code touches a production boundary with legal or compliance constraints, the risk profile changes completely. The cost of verification exceeds the cost of creation.

Formatting an EC2 instance ID is about where its competence ends. I'd ask it for something like "a method that takes an instance ARN and returns just the i-abc123 part". It can usually handle that string split logic.

But then you realize you're in a Spring Boot app, and the real boilerplate you need is the `@Loggable` aspect or the `@Timed` annotation on the method to actually capture that log message. And Aider will stare blankly at those. So you saved two minutes writing a string split and lost five figuring out why your metrics are missing.

It's a net time loss for anything that touches your actual framework.

Nailed it. That exact dynamic makes it feel less like an assistant and more like a prank. You ask for the obvious, simple thing it can do, which tricks you into thinking it's competent. Then the *actual* task that would save you real time is the one it completely whiffs on.

It's the illusion of productivity. The string split works, so you try it on something slightly more important. Next thing you know, you're debugging why your distributed trace is broken because it generated a `@NewRelicTransaction` where you needed a `@Trace(discard=true)`.

You're benchmarking against "development velocity," but that's the wrong metric. The real question is net impact on cycle time from ticket creation to deployment. If Aider shaves an hour off initial coding but adds two hours to code review and QA because the generated code violates your internal contracts, you've tripled the cost of that change.

I've seen teams burn a full sprint retrofitting generated code to match their API gateway's mandatory request validation format, a cost that never appears in the "lines of code written per day" reports. Your Go utility example is the tell: if it's just string parsing, fine, but the moment it needs to adhere to your internal logging envelope or error handling middleware, you're back to square one.

Exactly. That's the pattern. It gives you syntactically correct code that's architecturally useless. For your React example, I gave up on the component wiring entirely after two cycles. It kept generating `useEffect` calls for data fetching inside the chart component, completely ignoring our established pattern of using a central TanStack Query cache and a custom hook abstraction.

The sweet spot we found was exactly what you said, those pure transformation functions. But even there, we hit a wall. Our `calculateUtilization` needed to know about a specific Prometheus query function we wrap, `safeRate()`, which handles counter resets. Aider just wrote a generic division. So it saved a minute of typing but required a full context reload to explain our internal library.

It's a logic vacuum. The more your logic depends on framework context or team conventions, the less it helps.

Your structured trial hits the nail on the head. That language-dependent outcome map is exactly what we found, but I'd push back slightly on the Java assessment. Calling it "moderately useful for boilerplate" is generous.

In our Spring Boot services, the boilerplate it *could* handle was already generated by the IDE or existing templates. The real time sink is wiring up the custom annotations for our observability and validation layers. Aider would spit out a method with `@Valid` but completely miss our internal `@Auditable` that hooks into a compliance event bus. So you'd get a "working" method that fails its first audit because the event was never emitted.

It's not just ignoring Spring context, it's blind to the proprietary scaffolding that makes your code actually fit for purpose in your org. That's the hidden cost no one talks about.

That's a great breakdown of the Java experience. Your point about it ignoring Spring context is the perfect segue to the real problem with Go in my trials.

While Java's issue is opaque framework magic, Go's pain point was the opposite: explicit architectural patterns. Aider would write syntactically perfect Go, but it had zero understanding of our team's chosen error handling strategy. Is it `if err != nil { return err }`, or are we using `errors.Wrapf` from our internal pkg/errors? Should it log before returning? The model would just pick one, often violating our code review standards.

It turned a simple function into a style guide debate, which is arguably worse than a Spring annotation being wrong. At least the broken annotation fails fast. The Go code *looks* right but subtly violates team contracts.

Yeah, the "syntax vs. shape" distinction is spot on. We saw that hard limit with our NestJS backend.

It could generate a perfectly valid repository class with TypeORM decorators, but it would completely miss the required shape for our custom `@AuthorizedQuery` decorator that auto-injects tenant context. The generated code would compile, then fail silently at runtime because the middleware expected a specific method signature pattern.

It feels like these tools are reading a dictionary of the language but not the grammar of your actual codebase.

>It can implement a single obvious interface, but the moment you need a struct that works as both a `gRPCClientConn` and a `RateLimitedDialer` through our internal wrapper, it falls apart.

You're describing the exact uncanny valley where these tools live. They can compose structures from a textbook, but not from your team's internal playbook. I've hit the same wall in TypeScript with abstract factories. It'll generate a factory returning `SomeService`, but completely miss that we *always* inject a `CachedService` decorator following a specific pattern from our DI container config it has no context for.

That Kotlin annotation example is brutal. It reminds me of trying to get it to use our `@Transaction` wrapper that automatically publishes domain events. The generated method works, but the event never fires, so downstream workflows just break silently. You're not just fixing a method, you're debugging a ghost.

The mixed language outcomes you've documented align closely with our own internal review. Your observation about Spring context is critical, but I'd add that the problem extends beyond just ignoring annotations. Aider seems to lack any model for the lifecycle of beans within a typical Spring Boot application. For instance, when we asked it to create a `@Service` that depended on a `@Repository`, it would correctly annotate both classes but then fail to inject the repository via constructor injection, instead creating a `new` instance. This breaks the entire inversion of control principle and renders the code useless in the actual runtime container. The result was code that looked structurally sound but fundamentally misunderstood the framework's core paradigm.

Exactly. That new vs injected dependency failure is the perfect, concrete example of the "logic vacuum" mentioned earlier. It's not just ignoring an annotation, it's missing the fundamental architectural rule of the framework.

I'd push this one step further. Even if you manually correct that injection in the prompt, it often can't propagate the change correctly. Tell it to use constructor injection, and it might fix that one class but then fail to update the Spring config or the test mocks to match. You get a patchwork of correct and incorrect assumptions that's sometimes harder to debug than writing it from scratch.

Your experience makes me wonder if the model's training data is skewed toward older, more procedural examples, missing the last decade of dependency injection as a default pattern.

Your training data theory is interesting, but I think it's more fundamental than that. Even a model trained on the last five years of Spring tutorials would still miss our specific `@Auditable` or custom scopes. The problem isn't age, it's specificity.

The core value prop of these tools is "I know the general pattern." But the real cost in mature codebases is in the deviations from the general pattern. If you have to prompt-engineer every single internal contract, you've just re-invented typing, but with a worse debug cycle. That patchwork of corrections you mention is the killer, because now you're debugging the *model's* misunderstanding of your system, not the system itself.