I cut several paragraphs from this explaining how agents work, which I wrote anticipating this exact comment. I'm very happy to have brought you to this moment of understanding --- it's a big one. The answer is "yes, that's exactly what people are doing": "turning LLMs loose" (really, giving them some fixed number of tool calls, some of which might require human approval) to do stuff on real systems. This is exactly what Cursor is about.

I think it's really hard to undersell how important agents are.

We have an intuition for LLMs as a function blob -> blob (really, token -> token, but whatever), and the limitations of such a function, ping-ponging around in its own state space, like a billion monkeys writing plays.

But you can also get go blob -> json, and json -> tool-call -> blob. The json->tool interaction isn't stochastic; it's simple systems code (the LLM could indeed screw up the JSON, since that process is stochastic --- but it doesn't matter, because the agent isn't stochastic and won't accept it, and the LLM will just do it over). The json->tool-call->blob process is entirely fixed system code --- and simple code, at that.

Doing this grounds the code generation process. It has a directed stochastic structure, and a closed loop.

> Is this what people are really doing?

Some people are, and some people are not. This is where some of the disconnect is coming from.

> Who is just turning AI loose to modify things as it sees fit?

In the advent of source control, why not? If it does something egregiously wrong, you can throw it away easily and get back to a previous state with ease.

> If I'm not directing the work, how does it even know what to do?

You're directing the work, but at a higher level of abstraction.

This is how I work:

I use Cursor by asking it exactly what I want and how I want it. By default, Cursor has access to the files I open, and it can reference other files using grep or by running specific commands. It can edit files.

It performs well in a fairly large codebase, mainly because I don’t let it write everything. I carefully designed the architecture and chose the patterns I wanted to follow. I also wrote a significant portion of the initial codebase myself and created detailed style guides for my teammates.

As a result, Cursor (or you can say models you selecting because cursor is just a router for commercial models) handles small, focused tasks quite well. I also review every piece of code it generates. It's particularly good at writing tests, which saves me time.

Zed has a great four minute demo showing how it works: https://zed.dev/agentic

I personally have my Zed set up so the agent has to request every command be manually reviewed and approved before running.

I run Cursor in a mode that starts up shell processes, runs linters, tests etc on its own, updates multiple files, runs the linter and tests again, fixes failures, and so on. It auto stops at 20 iterations through the feedback loop.

Depending on the task it works really well.

I let an agent upgrade some old C code that wouldn’t compile and had 100’s of warnings. It was running builds on its own, looking at new errors, etc. It even wrote some tests! I could’ve done this myself but it was a hobby project and tedious work. I was impressed.

you are giving it instructions but it's running a while loop with a list of tools and it can poke around in your code base until it thinks it's done whatever you ask for.

See Claude Code, windsurf, amp, Kilcode, roo, etc.

I might describe a change I need to have made and then it does it and then I might say "Now the tests are failing. Can you fix them?" and so on.

Sometimes it works very great. sometimes you find yourself arguing with the computer.