I've been using this method for several weeks. The issue I'm currently facing is that Claude Code incorrectly believes it has completed the task and then stops.

Let me illustrate with a specific, simple example: fixing linter or compiler errors. The problems I solve with this method are all verifiable via the command line (this can usually be documented in CLAUDE.md). Claude Code will continuously adjust the code based on the linter's output until all errors are resolved. This process often takes quite some time. I typically do this after completing a feature development. If Claude Code mistakenly thinks it has finished the task during one of these checks, it will halt the entire process. I then have to restart it using the same prompt to continue the task.

Therefore, I'm looking for an external tool to manage Claude Code. I haven't found one yet. I've seen some articles suggesting the use of a subagents approach, where tools like Gemini CLI or Codex could launch Claude Code. I haven't thoroughly explored this method yet.

This is a really interesting idea.

I actually have a toy project that does the complete opposite - I filter Hacker News to keep only the technical content, then use AI to generate summaries (which get translated into my native language since I'm not a native English speaker).

My friends and I have been using this system to consume a lot more content with significantly less reading overhead. Eventually, I turned the generated content into a maintained online website.

> I hope the feature mentioned in the article will cause a compiler error.

Read the article. It won't.

At best you can perhaps find a linter that'll report it?

> However, I wouldn't use this approach when writing my own code.

You might use it by accident.

I know, so this is a wish. Looking at other comment sections, there are actually linters that can warn about such behavior.

I tested the tool more thoroughly using a strict method to review the code, but it couldn't find the problems mentioned in the article.

golangci-lint run --enable-all --max-issues-per-linter=0 --max-same-issues=0

This comment unexpectedly received a few downvotes, which might be due to some misunderstanding. My point is as follows: 1. People choose Go for various reasons. 2. Beginners will encounter the issues mentioned in the article, so I hope there could be a feature that provides hints for newcomers. While the compilation errors might not be reasonable, at least the LSP/linter could provide some guidance.

This may be a language issue, but saying "I hope this causes a compilation failure" implies that you don't know if it does - this is probably why you got down voted, since the article very explicitly says that this doesn't cause compilation failure. You may have meant that you hoped it wouldn't do this - in that case you should have used a construction like "I'd hoped this would have caused a compilation failure".

Thank you so much for your reply! Your advice has been really helpful. I was confused about this.

I feel the same way, so this post inspired me to think about "how to improve intelligence."

If I encounter a problem that's difficult to solve (and more automated tools like Claude Code can't solve it), I might try to package the source code context and send it separately to the LLM chat window.

This approach can reduce the length of the context.

The scene you described helped me quickly grasp the whole situation! I'd like to add a new example. In your example, the most dangerous part is "the user being convinced to visit the BAD website." Here's my example:

- The scammer initiates a login attempt.

- The user receives a text message with a 6-digit code and might get confused.

- The user receives a phone call from the fraudster.

- The fraudster pretends to be a representative from the software platform, convincing the user there's an issue.

- At this point, another fake text message is sent, with a link to a convincing-looking platform.

- The user enters the 6-digit verification code they just saw on this fake platform.

- The scammer logs in successfully.