Discussion summary
Participants discussed experimenting with LLMs for coding, including building agents, workflows, and tools. Some shared specific implementations like llama.cpp and Pi, while others emphasized automation and verification.
What the discussion says
- Building autonomous coding agents and workflows is a common theme.
- Using small LLMs like llama.cpp and Pi for experimentation.
- Concerns about maintaining context and verifying generated code.
- Some focus on customizing tools for personal workflows.
“I built a terminal that is also an agent comms system.”
“I've been experimenting with coding agents, workflows, and refining what works.”
Comments
Hacker News
I'm in the same boat and I'm not a fan on the current way of working of agents, but I think tooling is what needs to catch up.
So, I actually decided to try to tackle it myself and worked some months (full time) on it.
https://beolis.com is the result of that, it's a local cli in a kanban board style with a remote server to keep the team on track (I've been using it myself for some time and actually started to ask some friends to use it just yesterday -- feedback very welcome, I still wanted to do some additional things before asking more people to use it, but oh well, I'm a fan of building in public anyways and it's probably better to have feedback sooner rather than later).
The main point there is that you work mostly in the ticket description (your own spec) and the plan (the spec as the agent sees it, generated with a custom workflow) and then having another custom workflow to implement it (you can choose how you want it -- https://beolis.com/blog/post/custom-coding-workflows has some info on what I'm using myself).
As a result, at least for me, I do spend more time immersed in a flow state (although I'm in that state writing the specs and reviewing code -- although in some cases it's more work to write the spec in a way the agent can work when things get more complicated vs just diving into the code, so, going into "code" mode is something I still have to do, agents are definitely not perfect).
I guess I'm lacking in docs on how to effectively use it. I have plans to create a video next week and post it in the blog, so, if you're interested, keep track of it ;)
by fabioz
Yeah, flow state is not the same, and I miss it.
I've stumbled into a couple of different ways to work with AI, each with their advantages and disadvantages:
* Ask it to solve the issue and trust the results. You're outsourcing your thinking, and lose understanding of the code. The result might work, or it might not. Chances are it will work, but your code slowly grows messier.
* Ask it to solve the issue and review the results. This should help you understand the resulting code, and give you a better chance of setting the AI straight when it messes up. But you're still outsourcing your thinking, and not thinking of the solution yourself still means you lose touch with the code. But more importantly, reviewing is the boring part of software development.
* You write the code, and let the AI review it. In a way, I think this should be the sweet spot. It doesn't make you faster, but your quality should go up. AI is very good at reviewing, and often finds issues that humans skip over. This is the quality over quantity solution. More than code, I think this is particularly important for writing high-stakes non-code documents, like financial reports for customers. Quality is really important there.
* You tell the AI how to solve the issue. The AI still writes the code, but it receives tighter guidance from you. This is what I usually end up doing. I like to think this results is better code. It certainly gives me the impression I understand better what the code does. And I do tackle much larger amounts of code, but I check what the AI does, and often push back on its suggestions and assumptions. I think this is a nice middle ground between speed and quality.
* Full agent mode. Let the AI do everything. Let multiple agents work simultaneously doing everything. You lose control and your mental model. You're going to have to trust whatever the AI is doing. Something it will be correct, sometimes not. Let's hope you never have to personally touch that code anymore. But it sure is fast.
by mcv
I had this exact problem, tried opening multiple agents in different terminals but that just frays your flow state even more. There is one great workaround I’ve found.
Walk coding. Walkoding, if you like.
Use a harness, create a harness if you like, then load it up in telegram and off you go. I’ve been on solo hiking trips and shipped numerous features. It means you can stay concentrated on your task, while not sitting there being bored.
It’s truly liberating, highly recommend.
Not being able to enter flow state is a very interesting observation. I've felt it too to the extent that I went down a whole new rabbit hole of what it means to be in flow state. Let me know if anybody here wants to know more, happy to post some links.
To answer your question - I discuss the approach with Claude Code (e.g., should I implement my own ACT model in JAX or PyTorch, Python or Rust or Julia, etc.). Then write the initial part of the code myself. Opening up a blank vscode is a simple joy of life I refuse to give up :-) I'll ask Claude for advice if I get stuck, it will helpfully offer to write that code for me, I obstinately decline. Eventually, I'll get bored of some minutiae or other, at which point I'll ask Claude to complete just that part of it.
by avilay
I've been experimenting with making AI generate literate code. The goal is to have the AI produce a bunch of prose alongside the code. A lot of context for the purpose and design of what you are doing usually gets thrown away, but with literate programming you can save it. And this way I can have some hope of understanding the code being created. I've liked it so far.
I am using a literate programming project I built (https://github.com/adam-ard/organic-markdown) and I have an AGENTS.md file that looks like this:
"All the work we do on this project should utilize the organic-markdown literate style that you see explained/demonstrated in the `organic-markdown` project: https://github.com/adam-ard/organic-markdown
Some guidelines for how you should utilize organic-markdown literate programming..."
Then I list a bunch of conventions for making literate code the way I like it.
by aard
"I haven't been able to enter flow state like I can when I hand write code." new flow state is having 10 terminal tabs in diff worktrees and trying to remember what each bit is
by tombot
I, like many nerds of the same stripe, have a dragon's hoard of every PC component I've owned in the last 20 years. I've attached as much of it to my homelab as is practical, but there's still a pile of GPUs from the last decade plus.
So I decided to load up everything with more then 3GB of VRAM into various machines on the network. Anything that could conceivably run an LLM of any utility. I've been experimenting with driving a swarm of heterogenous LLMs into coding tasks. I have models as small as llama3.2:3b up to Qwen3.6:27b dense. Over 10 unique models in the swarm.
So far, the results are... interesting. Coding isn't great, but what has worked shockingly well is polling the swarm for opinions. Getting ten unique perspectives synthesized into a single summary has been astonishingly useful. When I gave the swarm the ability to debate with itself, the results got even more interesting.
The end goal here is an autonomous routing network that learns which models excel at which tasks, which machines can fit which models, and intelligently routes requests and models to where they're most effective.
I can't afford an RTX 6000, but I can run smaller models on the pile of GPUs I do have. So far it hasn't worked out the way I'd hoped, but it did turn out to be very useful in other ways. Hopefully soon I can get coding worked out and the swarm can drive itself into self-improvement
by vitally3643
I'm using what I call "hermetic agents", where completely sandboxed agents write code and tests from the same specification, where the code writer can't see the test and the test writer can't see the code. The idea is that we can get better quality this way (by avoiding confirmation bias between code and tests). It is more painful to set up however, since you have to distill a spec and guides that the agent would normally hook into using RAG.
It is more like people (agent?) management than coding though. I'm setting up and debugging processes, rather than writing code. I spend a lot of time cursing at and arguing with the agents I'm using to set up hermetic agents (who I can't argue with obviously, but I can have conventional agents go over their logs to figure out how to improve their sandboxed-context).
by seanmcdirmid
Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I'm in the same boat and I'm not a fan on the current way of working of agents, but I think tooling is what needs to catch up.
So, I actually decided to try to tackle it myself and worked some months (full time) on it.
https://beolis.com is the result of that, it's a local cli in a kanban board style with a remote server to keep the team on track (I've been using it myself for some time and actually started to ask some friends to use it just yesterday -- feedback very welcome, I still wanted to do some additional things before asking more people to use it, but oh well, I'm a fan of building in public anyways and it's probably better to have feedback sooner rather than later).
The main point there is that you work mostly in the ticket description (your own spec) and the plan (the spec as the agent sees it, generated with a custom workflow) and then having another custom workflow to implement it (you can choose how you want it -- https://beolis.com/blog/post/custom-coding-workflows has some info on what I'm using myself).
As a result, at least for me, I do spend more time immersed in a flow state (although I'm in that state writing the specs and reviewing code -- although in some cases it's more work to write the spec in a way the agent can work when things get more complicated vs just diving into the code, so, going into "code" mode is something I still have to do, agents are definitely not perfect).
I guess I'm lacking in docs on how to effectively use it. I have plans to create a video next week and post it in the blog, so, if you're interested, keep track of it ;)
by fabioz - Yeah, flow state is not the same, and I miss it.
I've stumbled into a couple of different ways to work with AI, each with their advantages and disadvantages:
* Ask it to solve the issue and trust the results. You're outsourcing your thinking, and lose understanding of the code. The result might work, or it might not. Chances are it will work, but your code slowly grows messier.
* Ask it to solve the issue and review the results. This should help you understand the resulting code, and give you a better chance of setting the AI straight when it messes up. But you're still outsourcing your thinking, and not thinking of the solution yourself still means you lose touch with the code. But more importantly, reviewing is the boring part of software development.
* You write the code, and let the AI review it. In a way, I think this should be the sweet spot. It doesn't make you faster, but your quality should go up. AI is very good at reviewing, and often finds issues that humans skip over. This is the quality over quantity solution. More than code, I think this is particularly important for writing high-stakes non-code documents, like financial reports for customers. Quality is really important there.
* You tell the AI how to solve the issue. The AI still writes the code, but it receives tighter guidance from you. This is what I usually end up doing. I like to think this results is better code. It certainly gives me the impression I understand better what the code does. And I do tackle much larger amounts of code, but I check what the AI does, and often push back on its suggestions and assumptions. I think this is a nice middle ground between speed and quality.
* Full agent mode. Let the AI do everything. Let multiple agents work simultaneously doing everything. You lose control and your mental model. You're going to have to trust whatever the AI is doing. Something it will be correct, sometimes not. Let's hope you never have to personally touch that code anymore. But it sure is fast.
by mcv - I had this exact problem, tried opening multiple agents in different terminals but that just frays your flow state even more. There is one great workaround I’ve found.
Walk coding. Walkoding, if you like.
Use a harness, create a harness if you like, then load it up in telegram and off you go. I’ve been on solo hiking trips and shipped numerous features. It means you can stay concentrated on your task, while not sitting there being bored.
It’s truly liberating, highly recommend.
- Not being able to enter flow state is a very interesting observation. I've felt it too to the extent that I went down a whole new rabbit hole of what it means to be in flow state. Let me know if anybody here wants to know more, happy to post some links.
To answer your question - I discuss the approach with Claude Code (e.g., should I implement my own ACT model in JAX or PyTorch, Python or Rust or Julia, etc.). Then write the initial part of the code myself. Opening up a blank vscode is a simple joy of life I refuse to give up :-) I'll ask Claude for advice if I get stuck, it will helpfully offer to write that code for me, I obstinately decline. Eventually, I'll get bored of some minutiae or other, at which point I'll ask Claude to complete just that part of it.
by avilay - I've been experimenting with making AI generate literate code. The goal is to have the AI produce a bunch of prose alongside the code. A lot of context for the purpose and design of what you are doing usually gets thrown away, but with literate programming you can save it. And this way I can have some hope of understanding the code being created. I've liked it so far.
I am using a literate programming project I built (https://github.com/adam-ard/organic-markdown) and I have an AGENTS.md file that looks like this:
"All the work we do on this project should utilize the organic-markdown literate style that you see explained/demonstrated in the `organic-markdown` project: https://github.com/adam-ard/organic-markdown
Some guidelines for how you should utilize organic-markdown literate programming..."
Then I list a bunch of conventions for making literate code the way I like it.
by aard - "I haven't been able to enter flow state like I can when I hand write code." new flow state is having 10 terminal tabs in diff worktrees and trying to remember what each bit isby tombot
- I, like many nerds of the same stripe, have a dragon's hoard of every PC component I've owned in the last 20 years. I've attached as much of it to my homelab as is practical, but there's still a pile of GPUs from the last decade plus.
So I decided to load up everything with more then 3GB of VRAM into various machines on the network. Anything that could conceivably run an LLM of any utility. I've been experimenting with driving a swarm of heterogenous LLMs into coding tasks. I have models as small as llama3.2:3b up to Qwen3.6:27b dense. Over 10 unique models in the swarm.
So far, the results are... interesting. Coding isn't great, but what has worked shockingly well is polling the swarm for opinions. Getting ten unique perspectives synthesized into a single summary has been astonishingly useful. When I gave the swarm the ability to debate with itself, the results got even more interesting.
The end goal here is an autonomous routing network that learns which models excel at which tasks, which machines can fit which models, and intelligently routes requests and models to where they're most effective.
I can't afford an RTX 6000, but I can run smaller models on the pile of GPUs I do have. So far it hasn't worked out the way I'd hoped, but it did turn out to be very useful in other ways. Hopefully soon I can get coding worked out and the swarm can drive itself into self-improvement
by vitally3643 - I'm using what I call "hermetic agents", where completely sandboxed agents write code and tests from the same specification, where the code writer can't see the test and the test writer can't see the code. The idea is that we can get better quality this way (by avoiding confirmation bias between code and tests). It is more painful to set up however, since you have to distill a spec and guides that the agent would normally hook into using RAG.
It is more like people (agent?) management than coding though. I'm setting up and debugging processes, rather than writing code. I spend a lot of time cursing at and arguing with the agents I'm using to set up hermetic agents (who I can't argue with obviously, but I can have conventional agents go over their logs to figure out how to improve their sandboxed-context).
by seanmcdirmid