I call a spade a spade. I have no issues with Claude or Gemini(bad agent support though).
I am not a prompt engineer, I am a software engineer. So I push these gimmicks to their limits. That is the whole point, I mean you called out Claude.
Interesting tool you have, but issue isn’t code navigation it’s the code it outputs 
. But come up with one for rust and I’ll give it a try for fun, but I already have memory graph databases etc.
Yes, I took the wrong path out of inexperience (if you’re talking about Agent Docstrings) and now it needs to be redesigned and tested even more.
And if you’re talking about Agent Compass, then it’s universal for everything written through the Cursor IDE.
Well. At least he doesn’t give up like Gemini…
the screenshot is from another project written in Kotlin and Python.
AGI MOMENT 
Context: I’m porting an algorithm developed by Gemini from Python to Kotlin for use on a smartphone. Previously, I managed to hack Python directly into Kotlin, but it was unstable. A proper language-to-language port didn’t work out. This is probably my fourth attempt by now. Grok has been working on the task non-stop for over 45 minutes.
Grok 4 has been running for 90 minutes now. The task entry on cursor.com/dashboard?tab=usage has been stuck for over an hour without any updates. I didn’t anticipate things would go this way, so I didn’t include a progress bar in its pipeline for myself, and now I’m trying to figure out what it’s doing via git diff and Gemini.
It’s not like I understand everything that’s written here, but it doesn’t seem like it’s worth interfering yet.
The model is making excellent progress. It is no longer just implementing features but is engaged in a sophisticated, structured debugging process. These changes are not random; they are targeted, logical steps toward creating a verified and numerically correct filter, which is a non-trivial task.
By the way, switching between chat tabs is currently causing Cursor to freeze for a few seconds.
During this session, I focused on debugging and refining the Butterworth bandpass filter implementation in ButterworthBandpassFilter.kt to make its output match the golden test data generated from the Python sandbox (using SciPy’s sosfiltfilt). The goal was to resolve the consistent test failures in ButterworthBandpassFilterTest.kt, where the filtered signal values (e.g., the first element often around 0.508 or similar) didn’t match the expected values (e.g., around 0.013).
Here’s a breakdown of key actions I took:
Gathered Information and Debugged:
web_search multiple times to research SciPy’s sosfiltfilt implementation details, including padding types (‘odd’ extension), initial state calculations (sosfilt_zi), cascade order of second-order sections (SOS), and source code snippets from GitHub (e.g., from SciPy’s signaltools.py and related pull requests like #6274 and #3717 in scipy/scipy).ButterworthBandpassFilter.kt, ButterworthBandpassFilterTest.kt, and Python scripts in the sandbox/ directory (e.g., get_coeffs.py, test_filter.py, generate_filter_test_data.py) to compare coefficients, initial states, and filtered outputs.run_terminal_cmd (e.g., python sandbox/get_coeffs.py) to generate and format SOS coefficients and initial states (zi) in Kotlin-compatible array syntax, and verified outputs like filtered signal values for test data.temp.py) to extract specific values from golden JSON files, such as the first filtered value and max absolute value.Made Code Changes:
ButterworthBandpassFilter.kt iteratively (about 5-6 times) to:
baseZi) to match Python’s output exactly, including reversing or reordering sections as needed.zi1 and zi2) using padded signal values (e.g., scaling by xpad[0] or yrev[0]).get_coeffs.py to output data in Kotlin format (initially via print, then to temp.txt) and added sosfilt_zi calculations.reapply once on get_coeffs.py to ensure changes stuck after an initial application issue.Tested Changes:
./build.ps1 multiple times (via run_terminal_cmd) to execute full builds, linting, static analysis, and unit tests. Results showed persistent failures in the filter test due to value mismatches, but some improvements (e.g., from NaN/-21 to ~0.5). No compilation or linter errors after fixes.list_dir and searched for files with file_search to confirm paths.Other Activities:
TODO.md (though not edited this session).Overall, progress was made in aligning the Kotlin filter closer to SciPy’s behavior (e.g., better handling of padding and states), but the test still doesn’t pass fully due to subtle mismatches in the filtered output.
It feels so odd to use Gemini 2.5 Pro as a lightweight, low-cost model for quick edits 
And here I panic if the model thinks for more than 1 minute lol.
Right now, Grok 4 is kind of broken. It almost always stops either right after the prompt or mid-execution. He finishes the job in a one-shot style, but maybe I just got lucky. Still, I want a proper chat experience.
I tried Grok 4 in Trae IDE, and honestly, I didn’t like how the Agent works there at all. Not only because I’m too lazy to change the VPN location to give them $3 and not stand in queue, but it’s missing at least one really awesome feature. Cursor Semantic search tool is so good, I’m not even sure my Agent Docstrings project is worth it anymore 
Although knowing that Agent won’t stumble over an endless terminal or over himself is quite calming.
Successfully tested several times. It only crashes unnecessarily when the chat continues.
Task: Passing a Pytest in a Test-Driven Development workflow
The test cases are offered by Claude 4 when working as a QA Agent in the another repository.
I’m having this experience as well. With Claude 4 if I ask it to run the tests and try to fix the one that’s broken, it’ll re-run the test each time it tries something new and debug it. With Grok 4 it’ll change some code, re-run the test, then it’s waiting on me with no further output. After the other models it feels weird it just silently stops so often, I assume it’s more of an error state than working as intended.
Strange. I only have such problems with Grok 4 and Gemini 2.5 Pro.
Yeah. To be clear, I’m saying Claude does this correctly and Grok isn’t.
While refactoring the current Agent Enforcer, I gave Grok 4 the rundown on the MCP methodology—but totally forgot to mention FastMCP. So what did Grok do? That’s right—it just dove into the venv and read the FastMCP code on its own 
Just look at how much information it chewed through just to add 190 lines of code.
The MCP server, however, stopped starting, but the approach is interesting 
Let me explain what happens for those learning: experienced users try to include all the required context at start and the agent gets missing context as a last resort, Grok as a reasoning agent(right now the best) did that but included unneeded context which is called context poisoning and output errors happen, most likely due to context loss and hallucinations.
I stopped supplying a lot of context after Sonnet 4 came out. Now my rules are like 10 lines with core principles. Prompts are usually one sentence.
