You may have misunderstood. I am asking about why your reply got -5 agreement vote despite it seeming correct to me, nothing related to the other comments.

Can someone explain why they disagree? I don't see a particularly obvious reason.

Reading through all the responses the one thing that sticks out is Gemini-2.5 really, really wants to write the first character in caps.

what it produces in these unmonitored runs takes more work for me to clean up than just iterating with Claude directly

It may be the type of work that we are doing differs then.

Also, you don't seem too bothered that running claude code implies a responsibility to review the code soon-ish (or have your local codebase go increasingly messy). The fact that I don't need to worry about state with PR agents mean it is more affordable to spin more attempts, and because more attempts can be ran simultaneously, each individual attempt can be of lower quality, as long as the best attempt is good. Deciding that the code is garbage and not worth any time cleaning up is much faster than cleaning up, so in general I don't find the initial read-through of the n attempts to take that much time. At the end I still only spin up codex on desktop if I think the task has reasonable chance to be done well, which really depends on the specific task size/difficulty/type (bug fix, refactor, adds). It's also likely that claude code work better for you because you're more experienced and can basically tell claude exactly what to do when it's stuck.

I like to use the PR agents in some cases. (But I still manually checkout on those branches and rebase, split the commits or rewrite some stuff)

1. spin off tasks when I'm on mobile
2. it is easier to do multiple parallel attempts on the same task when I know the output probably suck. And not gonna lie OpenAI's codex cloud has very lenient compute limit so I also feel like I'm saving money this way.
3. they live in (other people's) containers so I don't need to worry about multiple agents colliding with each other. I know git worktrees exist but juggling the which worktree is on which branch turns out to be somewhat annoying too.
4. They are good for queueing up tasks that I don't expect to have to bandwidth to start working on today. I can make the agents do the PR today and forget about them until a few days later.

LW uses graphql. You can follow the guide below for querying if you're unfamiliar with it.

https://www.lesswrong.com/posts/LJiGhpq8w4Badr5KJ/graphql-tutorial-for-lesswrong-and-effective-altruism-forum (For step 3 it seems like you now want to hover over output_type instead of input)

For step 3 it seems like you now want to hover over output_type instead of input

How I use AI for coding.

I wrote this in like 10 minutes for quick sharing.

• I am not a full time coder, I am a student who code like 15-20 hours a week.
  • Investing too much time on writing good prompts make little sense. I go with the defaults and add pieces of nudges as needed. (See one of my AGENTS .md at the end)
• Mainly codex (cloud) and Cursor. Claude Code works, but being able to easily revert is helpful, so Cursor is better.
  • I still try out claude code for small pieces of edits, but it doesnt feel worth it.
  • I have no idea why people like claude code so much? CLI is inferior to GUI
  • Using cursor means I don't need to have multiple git worktrees for each agent, as long as I get them to work on different parts of the codebase
• Mobile coding is real and very convenient with codex (cloud), but I still review and edit on desktop.
• Using multiple agents is possible, but usually one big feature and multiple smaller background edits.
  • Or multiple big features using codex cloud, and delay review to a later time.
• Codex cloud is good but only generate one commit for PR, often I need to manually split them up. I am eyeing on other cloud agents solution but havent tried them seriously yet.

## Code Style  
- 120-character lines  
- Type hints is a must  
- **Don't use Python 3.8 typings**: Never import `List`, `Tuple` or other deprecated classes from `typing`, use `list`, `tuple` etc. instead, or import from `collections.abc`  
- Do not use `from __future__ import annotations`, use forward references in type hints instead. `TYPE_CHECKING` should be used only for imports that would cause circular dependencies.  
  
## Documentation and Comments  
Add code comments sparingly. Focus on why something is done, especially for complex logic, rather than what is done. Only add high-value comments if necessary for clarity or if requested by the user. Do not edit comments that are separate from the code you are changing. NEVER talk to the user or describe your changes through comments.  
  
### Using a new environmental variable  
When using a new environmental variable, add it to `.env.example` with a placeholder value, and optionally a comment describing its purpose. Also add it to the `Environment Variables` section in `README.md`.  
  
### Using deal  
We only use the exception handling features of deal. Use `@deal.raises` to document expected exceptions for functions/methods. Do not use preconditions/postconditions/invariants.  
  
Additionally, we assume `AssertionError` is never raised, so `@deal.raises(AssertionError)` is not allowed.  
  
## Testing Guidelines  
To be expanded.  
  
Mocking is heavily discouraged. Use test databases, test files, and other real resources instead of mocks wherever possible.  
  
Allowed pytest markers:  
- `@pytest.mark.integration`  
- `@pytest.mark.slow`  
- `@pytest.mark.docker`  
- builtin ones like `skip`, `xfail`, `parametrize`, etc.  
  
We do not use  
- `@pytest.mark.unit`: all tests are unit tests by default  
- `@pytest.mark.asyncio`: we use `pytest-asyncio` which automatically handles async tests  
- `@pytest.mark.anyio`: we do not use `anyio`  
### Running Tests  
Use `uv run pytest ...` instead of simply `pytest ...` so that the virtual environment is activated for you.  
  
## Asking for Help  
- Refactoring:  
As a command-line only tool, you do not have access to helpful IDE features like "Refactor > Rename Symbol". Instead, you can ask the user to rename variables, functions, classes, or other symbols by providing the current name and the new name. It is important that you don't rename public variables yourself, as you might miss some occurrences of the symbol across the codebase.  
  
## Information  
Finding dependencies: we use `pyproject.toml`, not `requirements.txt`. Use `uv add <package>` to add new dependencies.

I don't doubt the conclusion, but I think we would be buying (life expectancy - age) life years instead of 1 life.

Are you guys talking about tin foil for small lights that some appliances emit? For windows I don't understand why not just use a curtain.