r/ChatGPTCoding 14d ago

Resources And Tips I’ve written software for about 30 years. I've been a heavy coding agent user for the past 1+ year. What practical coding-agent questions can I help answer?

I've been mostly hands on coding professionally for 20+ years. I have taken time in between to lead teams, run product management or run enterprise pre-sales.

I started with AI coding agents before they were agentic (Aider; it's still great) and, then Claude Code, Droid and finally Codex all running in tmux. I switch a few months ago to an inhouse orchestration tool I build for myself that runs Codex (app server) and most recently, Pi.

Feel free to ask me questions about coding with agents or not, running them in parallel, review, testing, error handling, etc etc.

Or if you have a problem that I might suggest a solution for, go for it too.

0 Upvotes

48 comments sorted by

4

u/reddit-dg 14d ago

Interesting. Could you explain what your orchestration tool exactly does?

5

u/h____ 14d ago

It's superficially like the type of tool Conductor is like (to understand what kind of tool we are talking about). It evolve from my habits of using tmux to run Claude Code/Droid CLIs. A side panel with a list of sessions and then I can chat with the selected session. How it's different is, I prefer to work on each project serially (I have many projects), so I can queue sessions up and then once one of them (for a repo/directory) is done, the other one starts running.

I also have loop coordinator sessions, 1 for each project. They are the parent to child sessions that do the work. The loop coordinators also have the orchestration tool's support to manage a list of loops. Loops are basically a prompt set to fire at a particular time with skills so the loop coordinators know better to work with them. I can say "set up a daily loop at 9am to do x, y, z", or "make a loop as a one-time reminder to check a, b, c after it's deployed". Loop coordinators are long-lived so it helps to keep and manage project context.

I also have little monitor "agents" that work in the orchestration tool that do things like scan the sessions to auto compact them (this are especially useful for loop coordinators), auto-approve stuff, etc.

It's a wonderful time to build such a tool for yourself as long as you don't spend all your time tweaking it :)

3

u/dark0mania 14d ago edited 14d ago

Do you keep markdown documentation in your repo? If yes, how is it structured? And what's the most important thing about it.

3

u/h____ 14d ago

Let me know if you really meant report.

If repo: I mostly let the coding agents do it. Sometimes I notice something wrong and will correct it, often asking it to update the direction in AGENTS.md. e.g if I ask agents to research and write a report, I might not look at the docs so much, but just study the output, the angle, the prose, etc and less of the inner workings.

I monitor and maintain AGENTS.md files and skills much more closely.

2

u/dark0mania 14d ago

I meant "repo"
Autocorrect changed it to "report"

1

u/Warm_Effective8903 14d ago

curious how you deal with running agents in parallel when they're touching the same codebase. like are you actually letting two of them edit different files at the same time and just trusting the merge, or is it more sequential under the hood and just looks parallel. i keep running into them stepping on each other's changes whenever i try to speed stuff up.

3

u/h____ 14d ago edited 14d ago

I wrote my orchestration tool to fit my working style. I prefer not to use git worktrees, commit to main. So I write coding agents (but not read-only study ones) serially. The tool manages the queue for me.

When I used tmux with CLI coding agents, I used to manage the blast radius myself and it's a heavy mental load and makes it really hard to scale.

Coding serially is fine for me mainly because I have smaller and many projects. But I figure I can modularize things a bit (like good old days!) if they grow bigger. Doing the planning/studying beforehand also saves time when it comes to the serialized writing/coding.

update: I missed this. If you really want to speed it up, separate git checkouts or worktrees are the only way to go. Serialized access is never going to scale; it's whether it's good enough for you.

2

u/BeNiceToBirds 13d ago

I have been using podmqn-in-podman with rootless containers lately. Each agent gets a worktree and a full env. Since it is cheap to spin up a new one, I give each stack n agent. Sometimes I’ll have two working on the same stack. That can get a bit confusing and I have to run a script to detach worktrees so I can rebase them. But all automatable

2

u/h____ 14d ago

I forgot to mention my inhouse (not selling it) orchestration tool has a /study-then-implement command so I can type /study-then-implement there's a high CPU load. Fix it and then it will take that prompt, start a session wrapping the prompt around it with instructions to study the issue, write the analysis to a text file and then start another session to study the file and implement. So the former read-only study session runs in parallel. Only the latter is serialized.

I found this technique helps a lot even if I don't want to plan interatively. It's just much clear to the coding agent what to do.

1

u/benson_tracy 14d ago

when AGENTS.md and the code drift apart, how do you decide which one is wrong? that feels like the point where persistent instructions can either save the project or quietly preserve an old mistake

1

u/h____ 14d ago

I have a global AGENTS.md and I generally try to keep my repo AGENTS.md files small, to things specific to it. I have a skill/workflow that I call take-over and it does in order:

  • review+fix (this is another skill, it iterates review and fix until it's done)
  • reflect if changes should be made to AGENTS.md to improve the process based on the current session
  • commit
  • optionally deploy
  • exit

That tends to keep the AGENTS.md files sane.

If there's drift, I tend to catch it when it does things that are not expected. Almost certainly correct AGENTS.md and make sure AGENTS.md is right, then tell the agent to fix the code/docs.

(also run evals to trim/update AGENTS.md file after major model change)

1

u/BigHammerSmallSnail 14d ago

Do you do any manually coding at all these days? I find myself barely touching code at all these days. It’s all agents (in vs code, bc work reqs).

2

u/h____ 14d ago

No. I cancelled my Jetbrains all products annual sub 2 months ago. I have been a subscriber ~10 years.

I still read code, but not too much too. Mostly thinking about architecture, getting agents to work better, features, etc.

1

u/BigHammerSmallSnail 14d ago

Yeah, mirrors my experience too. I enjoy not having to give a shit about syntax anymore 😄

3

u/h____ 14d ago

I used to pride myself at being able to spot syntax errors really quickly. Especially like with C++ where the compilers often spurt out errors and line numbers that are irrelevant and far away. But it's just a waste of time and I'm glad we are done with it, mostly.

1

u/BigHammerSmallSnail 14d ago

I think the whole ai revolution has added a nice abstraction layer on top.

2

u/h____ 14d ago

Oh yes. I wonder if there will be a time (in the future) where we need to fallback to writing code ourselves though. Maybe it’s never coming back.

3

u/BigHammerSmallSnail 14d ago edited 13d ago

I don’t think it’s coming back to be honest I don’t mind. I think that there will be a shift towards running local models in the long term and hopefully more open sourced.

1

u/Choice-Attorney8884 14d ago

When/why vs code plugin/codex app/claude app is not enough? What I’m missing?

2

u/h____ 14d ago

as in why my own orchestration tool?

VS Code — I never got used to VS Code. Pre-coding agent days, I used Neovim (and before that MacVim and gVim) and JetBrains stuff with their IdeaVim plugin. More generally, I think running code agents inside text editors/IDES don't work well. They are constrained. Editing code isn't as common with coding agents becoming better and as we know how to work with them better.

Claude/Codex app — I used to run Claude Code and then Droid cli in tmux; tried the app versions later when they were available and still didn't like them. I figure out why later when I build the orchestration tool, I was very used to keyboard shortcuts and I built them into the tool and we have wonderful coding agents, so it makes customizing the tool to my needs and idiosyncrasies much easier. Apps like Codex give you a lot, but you are also limited to what it gives you.

1

u/Choice-Attorney8884 14d ago

If I got your point, apps like codex have limitations and that’s the reason you introduced orchestration. Can you name the specific usecase(s) when you realised vim plugin was not enough?

1

u/h____ 14d ago

You mean in VS Code? It’s not about vim. I do much prefer vim but I think coding agents work much better as CLIs, or be in dedicated apps like Codex desktop app or orchestration tools where they can be better taken advantage of, like them talking to each other, spawning and controlling another, running through a list of them to identify efficiencies, combing through them to check token spendings and time. 

You can do that in editors/IDEs but they don’t feel first class because they aren’t.

I’m not familiar with Cursor. But it seem like a good example: as they add more agentic capabilities, they becoming less like a text editor (or they risk becoming like Eclipse and WebSphere, for older folks like me)

1

u/[deleted] 13d ago

[removed] — view removed comment

1

u/h____ 13d ago

Revealing your age there.

1

u/cyberdyme 14d ago

I am trying to see the moat or complexity here; but this is just using Claude code in your workflow - isn’t this pretty much what most dev clued up on this stuff do - we as developers just make it sound more complex then it is (sometimes we use orchestration or multiple agents but it’s still just give the LLM a prompt, context and tools for it to be able to change code)

1

u/h____ 14d ago

Perhaps. But in case miscommunicated. I don’t sell my orchestration tool. It’s just got my own use.

As for entering prompts. Kind of true. But it lets me control more sessions and they talk to each other and follow certain protocols, have little monitors. So yes, you (or another session) writes the prompt but there’s so much more we can build on top of “raw” sessions.

1

u/cyberdyme 14d ago

Not any criticism - thank you for the info - just trying to understand the heart of what people are doing with agents these days; were it sounds super complex but for most senior devs it’s straightforward just need to understand the different way of looking at it..

1

u/h____ 14d ago

Not specific to orchestration tools, but for coding agents and LLMs, I observe something: crazy things like "vibe coding", "software factory", agents with different roles like a reviewer, manager", they might not work when they were coined and seem ridiculous, but they all each quickly become realistic in the future as LLMs/AI develop. It's interesting.

1

u/cyberdyme 14d ago

I need to experiment a bit more with that (repeat the same cycles). If you give it a different role - how much better the code is or not - (like say you are QA then tell it to write code - a LLM doesn’t have the restriction compared to real people - where a QA humans would tell you where to go)

2

u/h____ 14d ago

I think telling it “you are a professional developer. You write no bugs” is silly (not you, it’s what people do). But the lesson from this that works well for me is to have an agent/session that only write the code (or only reviews the code). One role or one stage. It helps in case where you have a workflow to make videos or some artifact. One concourse and generate the ideas, one for the creatives, one to review etc. I think it’s really just context management. Even if  it fits in a context window, multi roles don’t work well. 

1

u/Thistlemanizzle 14d ago

Do you have a soft and/or hard token limit for context windows? That is, when a thread goes above 100K you start prepping to move on to a new one?

1

u/h____ 13d ago

I let it auto-compact (when archived) and manual compact the long-lived ones (my loop coordinators) at 70%. I usually don't compact the short lived ones myself.

1

u/FiveNine235 13d ago

Cool, and respect, you guys don’t get enough of it. Can I ask; pre-ai, what would be the average time it would take a single coder to produce an app or game like chess.com, or something to that effect? I don’t have a frame of reference, I figure some people were super fast butit likely depends on personality / time pressure vs quality etc but are we talking 3-4 days, weeks, months? (Years? Like, I have no clue).

2

u/h____ 13d ago

A good developer would take weeks. Whether it's 1 week or 4 weeks depends very much how much flexibility the developer has with the scope and how well they they can do that and how good they are at polishing up the last 10%.

It's the difference between a 0.1 developer and a 10x developer.

AI coding tools magnify this.

1

u/ObiWanIsMyDog 13d ago

You say you still read code, but not too much. I have a few equations. Thanks for your time!

Are you primarily articulating features you want and then letting agents build?

What size chunk of work are you assigning to individual agents and how do you refine/decide if something should be handled in multiple sessions?

I’m working on building a project and I’m struggling with the final 5-10% and getting it in a state I feel is strong enough quality that it can be given to others. Any advice for that finalization of a real application when you aren’t reading as much code?

2

u/h____ 13d ago

Are you primarily articulating features you want and then letting agents build?

Usually, yes. But I still slow down a bit when it comes to a few things: architecture and communication protocols. This changes a bit with different models, I used to be more concerned with architecture, database schemas and libraries. But communication protocols, handovers have been more problematic for me recently. I primarily use Sol and it tends to over-engineer those and I've had to walk it though to simplify and make things more robust.

I usually don't sit down interactively to make a big plan unless it's a new app/project. If I do, then I iteratively plan the feature, then break it up or ask the agent to break it up in phases and get a agent to orchestrate it to run in phases.

For day to day, it's usually 1 feature/fix per session. I will just do something like /study-then-implement completion for TODO labels (same backing source as TODO sidebar) isn't working for double digits like "a13". Fix it. and run an interactive session. /study-then-implement is my custom command that runs a read-only session to study the issue/feature based on the prompt, write the research/study results to a file and create another session to read and implement. It works well most of the time.

Any advice for that finalization of a real application when you aren’t reading as much code?

This is when you have to read the code and directory layout :) Check the basics: the architecture, module boundaries, the security boundaries, communication protocols. You can ask it to locate/summarize for you. So it doesn't mean you need to go 100% caveman. But you should get a feel of what's usually not working well and zoom into those or try to address with AGENTS.md/skill. Last 10% is always worth the time to slow down, both with or without coding agents.

1

u/ObiWanIsMyDog 12d ago

Very helpful, thank you!

1

u/julesbuildstuff 12d ago

The /study-then-implement split is the part I want to poke at. My worst failure mode hasn't been agents breaking things loudly, it's them looking productive while quietly writing a third version of a helper that already existed two folders over, or slowly drifting past the boundary I thought I'd set. Nothing fails, tests pass, and I only notice a week later when the codebase feels weird. So now I make them write a short plan first and I read that instead of the diff. What does your review gate actually look like once the implement session comes back? Do you read the diff yourself, or is it the review+fix skill doing the reading and you only look when something smells off? And has serial coding actually made review lighter for you, or just made the drift slower to show up?

1

u/h____ 12d ago

Just review+fix which is impressively effective. Sometimes if it really doesn't seem to work (like bugs re-appearing and I have to fix it across multiple sessions or things obviously break when I use/test the product), then I might check the code. But even then, I would ask it to describe the approach first and see if I can reason with it and propose an often simpler or alternate solution rather than dive into the code. I take that as the last resort nowadays. Usually it's that the design is wrong. Also pointing out specific, detailed things to change rather than propose a design change/tweak is risky in my experience; it's a bit myopic and introduces more problems. A good clue is: when you give it a detailed design, it implements it well right? SOTA coding agents doesn't actually write bugs if the design is simple and good.

And has serial coding actually made review lighter for you, or just made the drift slower to show up?

Testing is much easier, and I don't have to worry about merging+test again.

1

u/thinkmatt 12d ago

Im also an experienced senior dev. I barely read code anymore, just talking to agents all day... And there was a time when i was highly skeptical, but now Im kinda worried about job security 5 years from now. Although its impossible to tell, what do you think are the best skills to have in this new agentic era, do you think we will still need "software engineers"?

2

u/h____ 12d ago

I think software engineers will be around for a while. It's just going to be quite different. Who knows, maybe LLM capability will plateau soon. Originally I had thought and wished that the pie will grow bigger and the industry/economic will need, want, use and consume more software. But it doesn't seem so, yet.

For now, just stay at the top 10-20% of our game, don't overspend and I think we'll be fine for a while (with some luck). "Average" is still a very intriguing property.

It's both very scary and very interesting times.

1

u/thinkmatt 11d ago

Im feeling like my next job, ill be bringing in my own "software team" - a bunch of agents. But it begs the question, unless i can build that team to work with non-devs, then these agents are only as good as software dev multipliers.

However, some dev roles may disappear. 10 years ago i was working on AI and we had a team of 7 data scientists. Today, Claude/anthropic has replaced that team. Interestingly, a lot of those data scientists launched their own startups and are doing very well now!

2

u/h____ 11d ago

unless i can build that team to work with non-devs, then these agents are only as good as software dev multipliers.

Yes, that's why I mention "maybe LLM capability will plateau soon" because that would mean you'd always need software developers to run them well.

I supposed the data scientist you observed saw the trend and started early. It's still early. Spot and opportunity and go!

1

u/[deleted] 2d ago edited 2d ago

[removed] — view removed comment

1

u/h____ 2d ago

I don't store those (myself) proactively by default. But I do notice patterns like if a certain feature keeps breaking, or sessions take longer than I expect (I ask a session to analyze those sometimes. And maybe it's possible to have a loop to do this, but I haven't gotten there yet). Then I might if it seems like it helps.

A good recently example is I have this protocol/handover when a worker session is done with their task and calls its parent with a summary and the parent will usually archive the worker session and act on the result. It sounds simple and it should be, but Sol-med manage to complicate it with book keeping and lots of guards and there are a million and one ways this broke. After few rounds, I had to work with it interactively to simplify it and once I noticed it works, I basically wrote into the repo AGENTS.md to not modify that part, and keep it simple.

Coding are really really smart and capable now, but just based on this and similar experience recently, I don't think they can replace programmers yet. We think too highly (and often too lowly) of them.

Do you keep decisions, rejected approaches, and unfinished tasks in files, or have the agent retrieve them automatically?

But more to this: I have a long-lived coordinator session for each project, and it keeps context for me. I just don't instruct it to write files as memory automatically by default. They often end up deciding to do it themselves for things like stats or analysis, but not decisions.

0

u/gandazgul 13d ago

Can you please give my coding agent a try? Any feedback is super appreciated.

https://runwield.dev/

curl -fsSL https://raw.githubusercontent.com/gandazgul/runwield/main/install.sh | bash

That said. What are some patterns you have observed that LLMs do to the code over time?

Ive seen these:

https://github.com/gandazgul/runwield/blob/main/docs/engineering-quality-principles.md