{"slug": "thoughts-on-starting-new-projects-with-llm-agents", "title": "Thoughts on starting new projects with LLM agents", "summary": "Developer Eli Bendersky details his experience building the watgo WebAssembly toolkit from scratch using LLM agents, emphasizing the need for human oversight and code review in maintainable projects. He argues that while agents boost productivity, they are not yet capable of fully autonomous development for high-importance software.", "body_md": "A few months ago I wrote about [using LLM agents to help restructuring one of my\nPython projects](https://eli.thegreenplace.net/2026/rewriting-pycparser-with-the-help-of-an-llm/).\nIt's worth beginning by saying that the\nrewrite has been successful by all reasonable measures; I've been able to\ncontinue maintaining that project since then without an issue.\n\nIn this post, I want to discuss another project I've recently completed with\nsignificant help from agents: [watgo](https://eli.thegreenplace.net/2026/watgo-a-webassembly-toolkit-for-go/). In\nthis project many things are different; most notably, it's a from-scratch\nproject rather than a rewrite, and it uses a different programming language\n(Go). This post describes my experience working on the project, and some lessons\nlearned along the way.\n\n## The process\n\nThis is a new project, so it required extensive design. I began by iterating on\nthe design with the agent, with a sketch of the API. For this purpose, I\nrecommend using a Markdown file [committed into the repository](https://github.com/eliben/watgo/blob/main/doc/notes.md)\nfor future reference.\n\nAfter that, I started asking the agent to write CLs [[1]](#footnote-1) in a logical order that\nmade sense to me, keeping them small\nand reviewable (more on this in the next section). Sometimes it's not easy to\nhave a small CL, and multiple rounds of revision may confuse the agent;\nin this case, I commit the CL and then go back and ask the agent to modify\nor refactor the code, as much as needed, with separate CLs. In the worst case,\nthe whole sequence can be reverted if I feel we've taken the wrong direction\n(branches could also be helpful here for more complicated scenarios).\n\nThis point is worth reiterating: sometimes a single CL is a huge step forward, but requires lots of review, cleanup and refactoring to be viable. I've had multiple instances where an agent produced several days of work in a single CL, but I then spent hours instructing it to clean up and refactor. Overall, it's still a productivity gain, just not as much as some pundits would like us to believe.\n\n## Keeping the human in the loop\n\nGiven the current state of agent capabilities, I think it's worth splitting projects into two categories:\n\n- Low importance / prototype / throw away projects where deep code understanding is unnecessary. These can be \"vibe-coded\" (submitting agent code without even reviewing it).\n- High importance projects that I actually want to maintain; here, vibe-coding is ill advised and I insist on reviewing and guiding all code the agent writes before it's submitted (or shortly after, as discussed above).\n\nThe `watgo` projects is a clear example of (2): I certainly intend to maintain\nthis project in the long term, so I insist on code that I understand. With very\nfew exceptions, no code gets in without full review and often multiple rounds\nof revisions.\n\nEven if the cost for writing code went down, maintaining a project is so much\nmore than that. It's triaging and fixing bugs, it's thinking through what needs\nto be done rather than how to do it, it's keeping the code healthy over time,\nand so on. As [Brian Kernighan said](https://www.goodreads.com/quotes/273375-everyone-knows-that-debugging-is-twice-as-hard-as-writing):\n\nEveryone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?\n\nMaybe at some point agents will become good enough that projects in category\n(2) can be implemented and maintained completely autonomously. Maybe. But\nwe're certainly not there yet. My hunch is that getting there will require\ncrossing the AGI line [[2]](#footnote-2), after which little in our world remains certain.\n\n### Practical workflow\n\nIf you're using an agent to send an actual PR and only review *that*, it's\ndifficult to be disciplined enough to actually perform a thorough review. I find\nthe following method to be more reliable:\n\nI use a CLI agent running locally in my repository, and ask it to update the code there. In parallel, I have a VSCode window open in the same project, where I can:\n\n- Review the agent's changes using VSCode's diff view\n- Make my own tweaks and code changes if needed\n\nOnce I'm pleased with the change, I manually create a commit.\n\n## Keeping the CLs small\n\nAs mentioned above, it's imperative to keep making progress in small chunks, with small enough CLs that a human can fully understand in a single review. It's very tempting to sprint ahead submitting thousands of lines of code every day, but this temptation has to be avoided. Coding with an agent is like speed-reading; yes, you're making more progress, but comprehension suffers the faster you go.\n\nParticularly for refactoring, agents still take the shortest route to destination. It's important to guide them to think about the \"big picture\" at all times, find all instances where X is better done as Y, not just a single place noticed during a review. This is why it's sometimes OK to have a CL submitted before you fully agree with everything, and go back to it later for several refactoring rounds. Source control works amazingly well when pair-coding with agents.\n\n## Testing strategy\n\nIt's a key point discussed in every \"how to succeed with AI\" article, but still critical enough to reiterate here: a solid testing strategy is absolutely crucial for success. Agents produce - by far - the best results when they have a solid test suite to test their code against.\n\nWith the [pycparser](https://github.com/eliben/pycparser) rewrite, I had\na large existing test suite. For [watgo](https://github.com/eliben/watgo),\nthe very first thing I did was think through how to adapt the test suites of\nthe [WASM spec](https://github.com/WebAssembly/spec/) and of the\n[wabt project](https://github.com/WebAssembly/wabt) for my needs.\n\nIf your project doesn't have such tests to rely on, this should be your first order of business - finding one, or building one from scratch. Beware of self-reinforcing loops though; it's dangerous to trust agents for both the tests and the implementations tested against them.\n\n## Language choice - Go for agent-written projects\n\nGo is a fantastic language for agents to write, because it's designed to be very readable by humans. The biggest strengths of Go are exactly what makes the experience of reviewing agent code so positive:\n\n- Go changes very infrequently, so you don't have to wonder \"are we using the most modern / idiomatic approach\" or \"what the hell is this construct\" as often as with other languages (looking at you, Python and TypeScript).\n- There are relatively few ways to accomplish the same thing in Go, further lowering the mental burden.\n- The standard library is rich and there's much less need to keep abreast of the package-everyone-uses du jour.\n- In general, Go is designed for readability, with a mild-but-still-strong type system, uniform formatting, explicit error propagation and opinionated choices already made for you.\n\nSince most of the time spent by humans when using agents is *reading* rather\nthan *writing* code, these effects compound and produce a great experience.\nRecall the discussion of how some languages are optimized for writability (Perl)\nwhile others are optimized for readability (Go)? Well, when working on a project\nwith an agent we live in a world of 99% reading vs. 1% writing, so this really\nmatters.\n\nI find this aspect really crucial in light of the earlier points made in this post - namely, keeping the human in the loop by understanding and reviewing all of the agent's design choices and code.\n\n## Final thoughts\n\nIf you're working on a subject that's completely new to you, I would strongly\nrecommend *against* the approach described in this post. To really learn\nsomething, you have to work through it from scratch, yourself, reading,\ndesigning, writing the code. Agents don't change this basic fact; even before\nagents, if you wanted to learn X, copying it from Stack Overflow or some other\nproject clearly wasn't the right way to go. Similarly, while agents can be used\nas a prop for learning, they cannot learn *for you*.\n\nAs a corollary, junior engineers should exercise *extreme caution* when relying\non LLMs. There's no replacement to hard-won experience and the sweat and tears\nof learning new, challenging topics. Learning is supposed to be hard; if it's\ntoo easy, you're probably not learning.\n\nFor senior engineers, agents are a boon; it's a great tool to increase productivity, avoid the boring stuff, and get unstuck from procrastination; but only when used judiciously.\n\n|\n\n|", "url": "https://wpnews.pro/news/thoughts-on-starting-new-projects-with-llm-agents", "canonical_source": "https://eli.thegreenplace.net/2026/thoughts-on-starting-new-projects-with-llm-agents/", "published_at": "2026-07-14 10:36:11+00:00", "updated_at": "2026-07-14 10:48:09.118964+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-agents", "developer-tools"], "entities": ["Eli Bendersky", "watgo", "Go", "WebAssembly", "Brian Kernighan"], "alternates": {"html": "https://wpnews.pro/news/thoughts-on-starting-new-projects-with-llm-agents", "markdown": "https://wpnews.pro/news/thoughts-on-starting-new-projects-with-llm-agents.md", "text": "https://wpnews.pro/news/thoughts-on-starting-new-projects-with-llm-agents.txt", "jsonld": "https://wpnews.pro/news/thoughts-on-starting-new-projects-with-llm-agents.jsonld"}}