My results after a 30-day trial: It's good for Java, mediocre for Python.

Your observation about Q's uneven performance matches what I've seen in our data engineering workflows. The disparity likely stems from the underlying training corpus and the dynamic nature of the Python data ecosystem.

Java frameworks like Spring Boot have a more structured, convention-over-configuration paradigm, and the language's static typing provides clearer context. This makes generating accurate boilerplate more tractable for a model. For Python data pipelines, the rapid iteration of libraries like pandas and the flexibility of web frameworks like FastAPI create a moving target. A model trained even six months ago might suggest deprecated DataFrame methods or Pydantic v1 patterns.

Given a tight budget, the value depends on your team's composition. If the majority of your velocity-critical work is in Java, it might still be justifiable. For teams where Python data pipelines are the primary bottleneck, the manual correction overhead could negate the time saved on the Java side. Have you quantified the average time lost correcting its Python suggestions versus the time gained on Java tasks?

Thanks for sharing your results from the trial. It's a really useful data point for others considering the tool for similar stacks. I've heard similar feedback about uneven performance across languages from a few other teams.

The budget question is tricky. If it's mostly saving time on your Java work, that might still be worthwhile even if you have to double-check the Python output. But if your pipeline work is the real bottleneck, the mediocre help there could be a dealbreaker. Have you looked at whether it improved over the 30 days as it learned your codebase, or was the Python performance static?