How I Program with Agents

Here are the cases where it helps me (I promise this isn't ai generated even though im using a list...)

- Formulaic code. It basically obviates the need for macros / code gen. The downside is that they are slower and you can't just update the macro and re-generate. The upside is it works for code that is slightly formulaic but has some slight differences across implementations that make macros impossible to use.

- Using apis I am familiar with but don't have memorized. It saves me the effort of doing the google search and scouring the docs. I use typed languages so if it hallucinates the type checker will catch it and I'll need to manually test and set up automated tests anyway so there are plenty of steps where I can catch it if it's doing something really wrong.

- Planning: I think this is actually a very under rated part of llms. If I need to make changes across 10+ files, it really helps to have the llm go through all the files and plan out the changes I'll need to make in a markdown doc. Sometimes the plan is good enough that with a few small tweaks I can tell the llm to just do it but even when it gets some things wrong it's useful for me to follow it partially while tweaking what it got wrong.

Edit: Also, one thing I really like about llm generated code is that it maintains the style / naming conventions of the code in the project. When I'm tired I often stop caring about that kind of thing.

I am beginning to love working like this. Plan a design for code. Explain to the LLM the steps to arrive to a solution. Work on reading, understanding, fixing, planing, ect. while the LLM is working on the next section of code. We are working in parallel.

Think of it like being a cook in a restaurant. The order comes in. The cook plans the steps to complete the task of preparing all the elements for a dish. The cook sears the steak and puts it in the broiler. The cook doesn't stop and wait for the steak to finish before continuing. Rather the cook works on other problems and tasks before returning to observe the steak. If the steak isn't finished the cook will return it to the broiler for more cooking. Otherwise the cook will finish the process of plating the steak with sides and garnishes.

The LLM is like the oven, a tool. Maybe grating cheese with a food processor is a better analogy. You could grate the cheese by hand or put the cheese into the food processor port in order to clean up, grab other items from the refrigerator, plan the steps for the next food item to prepare. This is the better analogy because grating cheese could be done by hand and maybe does have a better quality but if it is going into a sauce the grain quality doesn't matter so several minutes are saved by using a food processor which frees up the cook's time while working.

Professional cooks multitask using tools in parallel. Maybe coding will move away from being a linear task writing one line of code at a time.

> I still don't understand the benefit of relying on someone/something else to write your code and then reading it, understand it, fixing it, etc.

Friction.

A lot of people are bad at getting started (like writer's block, just with code), whereas if you're given a solution for a problem, then you can tweak it, refactor it and alter it in other ways for your needs, without getting too caught up in your head about how to write the thing in the first place. Same with how many of my colleagues have expressed that getting started on a new project from 0 is difficult, because you also need to setup the toolchain and bootstrap a whole app/service/project, very similar to also introducing a new abstraction/mechanism in an existing codebase.

Plus, with LLMs being able to process a lot of data quickly, assuming you have enough context size and money/resources to use that, it can run through your codebase in more detail and notice things that you might now, like: "Oh hey, there are already two audit mechanisms in the codebase in classes Foo and Bar, we might extract the common logic and..." that you'd miss on your own.

On one codebase I work with, there are often tasks that involve changing multiple files in a relatively predictable way. Like there is little creativity/challenge, but a lot of typing in multiple parts/files. Tasks like these used to take 3-4 hours complete before just because I had to physically open all these files, find right places to modify, type the code etc. With AI agent I just describe the task, and it does the job 99% correct, reducing the time from 3-4 hours to 3-4 minutes.

Some people cannot do anything without a tool. These people are early adopters and power users, who then evangelize their latest discovery.

GitHub's value proposition was that mediocre coders can appear productive in the maze of PRs, reviews, green squares, todo lists etc.

LLMs again give mediocre coders the appearance of being productive by juggling non-essential tools and agents (which their managers also love).

I felt the same way until recently (like last Friday recently). While tools like Windsurf / Cursor have some utility, most of the time I am just waiting around for them while I get to read and correct the output. Essentially, I'm helping out with the training while paying to use the tool. However, now that Codex is available in ChatGPT plus, I appreciate that asynchronous flow very much. Especially for making small improvements , fixing minor bugs, etc. This has obvious value imo. What I like to do is queue up 5 - 10 tasks and the. focus on hard problems while it is working away. Then when I need a break I review / merge those PRs.

I kinda consider it a P!=nP type thing. If I need to write a simple function, it will almost always take me more time to implement it than it will to verify if an implementation of it suits my needs. There are exceptions, but overall when coding with LLMs this seems to hold true. Asking the LLM to write the function then checking it's work is a time saver.

As a senior developer you already spend a significant amount of time planning new feature implementations and reviewing other people's code (PRs). I find that this skill transitions quite nicely to working with coding agents.

What’s not clear to me is how agents/AI written code solves the “half hearted review” problem.

People don’t like to do code reviews because it sucks. It’s tedious and boring.

I genuinely hope that we’re not giving up the fun parts of software, writing code, and in exchange getting a mountain of code to read and review instead.

Yeah, honestly what's currently missing from the marketplace is a better way to read all of the code, the diffs etc. that the LLMs output, like how do you review it properly and gain an understanding of the codebase, since you're the person writing a very very small part of it.

Or even to make sure that the humans left in the project actually read the code instead of just swiping next.

Isn't that the point of agents?

Assume we have excellent test coverage -- the AI can write the code and ensure get the feedback for it being secure / fast / etc.

And the AI can help us write the damn tests!

I agree with not liking the author’s definition of an Agent being … “a for loop which contains an LLM call”.

Instead it is an LLM calling tools/resources in a loop. The difference is subtle and a question of what is in charge.

I liked the phrase “tools in a loop” for agents. I think Simon said that

I actually take some minor issue with OP's definition of an agent. IMO an agent isn't just a LLM on a loop.

IMO the defining feature of an agent is that the LLM's behavior is being constrained or steered by some other logical component. Some of these things are deterministic while others are also ML-powered (including LLMs).

Which is to say, the LLM is being programmed in some way.

For example, prompting the LLM to build and run tests after code edits is a great way to get better performance out of it. But the idea is that you're designing a system where a deterministic layer (your tests) is nudging the LLM to do more useful things.

Likewise many "agentic reasoning" systems deliberately force the LLM to write out a plan before execution. Sometimes these plans can even be validated deterministically, and the LLM forced to re-gen if plan is no good.

The idea that the LLM is feeding itself isn't inaccurate, but misses IMO the defining way these systems are useful: they're being intentionally guided along the way by various other components that oversee the LLM's behavior.

It seems like an excellent name, given that people understand it so readily, but what else would you suggest? LoopGPT?

> a consistent path to interacting with the world e.g sms, mail, weather, social, etc.

Here's an interesting toy-project where someone hooked up agents to calendars, weather, etc and made a little game interface for it. https://www.geoffreylitt.com/2025/04/12/how-i-made-a-useful-...

> When you can give it all the generic abstractions for everything we use, it can become a better assistant than what we have now or possibly even more than that.

The range of possibilities also comes with a terrifying range of things that could go wrong...

Reliability engineering, quality assurance, permissions management, security, and privacy concerns are going to be very important in the near future.

People criticize Apple for being slow to release a better voice assistant than Siri that can do more, but I wonder how much of their trepidation comes from these concerns. Maybe they're waiting for someone else to jump on the grenade first.

Don't worry you will still get to do plenty / more of the most fun thing: fixing code.

I like writing code, and it definitely isn't satisfying when an LLM can one-shot a parser that I would have had fun building for hours.

But at the same time, building a parser for hours is also a distraction from my higher level ambitions with the project, and I get to focus on those.

I still get to stub out the types and function signatures I want, but the LLM can fill them in and I move on. More likely I'll even have my go at the implementation but then tag in the LLM when it's not fun anymore.

On the other hand, LLMs have helped me focus on the fun of polishing something. Making sweeping changes are no longer in the realm of "it'd be nice but I can't be bothered". Generating a bunch of tests from examples isn't grueling anymore. Syncing code to the readme isn't annoying anymore. Coming up with refactoring/improvement ideas is easy; just ask and tell it to make the case for you. It has let me be far more ambitious or take a weekend project to a whole new level, and that's fun.

It's actually a software-loving builder's paradise if you can tweak your mindset. You can polish more code, release more projects, tackle more nerdsnipes, and aim much higher. But it took me a while to get over what turned out to be some sort of resentment.

I have to flip the question, what is it that people like about it? I certainly don't enjoy writing code for problems that have already been solved a thousand times. We reach for a dictionary, we don't write a hash table from scratch every time, that's only fun the first time you do it.

If I could go "give me a working compiler for this language" or "solve this problem using a depth-first search" I wouldn't enjoy programming any less.

About the natural language and also in response to the sibling comment, I agree, natural language is a very poor tool to describe computational processes. It's like doing math in plain English, fine for toy examples, but at a certain level of sophistication it's way too easy to say imprecise or even completely contradictory things. But nobody here advocates using LLMs "blind"! You're still responsible for your own output, whether it was generated or not.

Exactly. Also related on why Natural Language is not really good for programming[0]

[0]: https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...

Anyway I indeed find LLMs useful for stackoverflow-like programming questions. But this seems to not be true for long as SO is dying and updated data on this type of questions will shrink I think.

Don’t agree with the assessment. At this point most of what I find LLM taking over is all the repetitive crud like implementations. I am still doing what I consider the fun parts, architecting the project and solving what are still the hard parts for the LLM, the non crud parts. This could be gone in a year and maybe I become a glorified product manager but enjoying it for the time being l, I can focus on the real thought problems and get help lifting the crud or repetitive patterns.

Author here. I like programming and I like agents.

Interesting, I found AIs annoyingly incapable of writing good CSS. But I understand the appeal of using it for a task that you do not like to do yourself. For me it's writing ticket descriptions which it does way better than me.

I'm not trying to be presumptuous about the state of your CSS knowledge so tell me to get lost if I'm off base. But if you haven't updated yourself on where CSS is at these days I'd recommend spending an afternoon doing a deep dive. Modern-day CSS is way less kludgy and hacky than it used to be. It's not so hard now to manage large CSS codebases and centering elements is relatively simple now.

Having said that I still lean heavily on AI to do my styling too these days.

The issue is, whats the alternative? People are generally bad at predicting what work will get broad adoption. Carefully elegantly constructing a project that goes nowhere also seems to be a common failure mode; there is a sort of evolutionary pressure towards sloppy projects succeeding because they are cheaper to produce.

This reminds me of classics like "worse is better," for today's age (https://www.dreamsongs.com/RiseOfWorseIsBetter.html)

ChatGPT is great for debugging common issues that have been written about extensively on the web (before the training cutoff). It's a synthesizer of Stack Overflow and greatly cuts down on the time it takes to figure out what's going on compared with searching for discussions and reading them individually.

(This IP rightly belongs to the Stack Overflow contributors and is licensed to Stack Overflow. It ought to be those parties who are exploiting it. I have mixed feelings about participating as a user.)

However, the LLM output is also noisy because of hallucinations — just less noisy than web searching.

I imagine that an LLM could assess a codebase and find common mistakes, problematic function/API invocations, etc. However, there would also be a lot of false positives. Are people using LLMs that way?

If you do "please review this code" in a loop, you'll eventually find a case where the chatbot starts by changing X to Y, and a bit later changes Y back to X.

It works for code review, but you have to be judicious about which changes you accept and which you reject. If you know enough to know an improvement when you see one, it's pretty great at spitting out candidate changes which you can then accept or reject.

Why isn't this spoken more about? Not a developer but work very closely with many - they are all on a spectrum from zero interest in this technology to actively using it to write code (correlates inversely seniority from my sample set) - very little talk on using it for reviews/checks - perhaps that needs to be done passively on commit.

> LLMs for code review, rather than code writing/design could be the killer feature

This is already available on GitHub using Copilot as a reviewer. It's not the best suggestions, but usable enough to continue having in the loop.

Totally agree - we’re working on this at https://sourcery.ai

You can write the tests first and tell the AI to do the implementation and give it some guidance. I usually go the other direction though, I tell the LLM to stub the tests out and let me fill in the details.