Ask HN: Is anyone experimenting with different ways of using LLMs for coding?

Thanks to being unemployed, the last few months I've been experimenting a lot with coding agents, harnesses and most importantly, the workflows around them.

Currently I'm refining what I think works best for me, which I'd call something like "issues/PR based LLM workflow", powered mainly by this action I'm building on top of the Pi coding agent SDK: https://github.com/shaftoe/pi-coding-agent-action

Essentially I issue prompts swapping between the terminal and the git forge web app (GitHub and my own Forgejo instance) and it currently looks something like this:

- create an issue with detail/quality of spec based on how the task or the project is important

- trigger a Pi session prepending a comment in the forge with "/pi " to work on it, either to produce a report or to e.g. implement the change in a new PR

- trigger more sessions in the same thread, be it an issue or a PR, to steer or to add more requests like fork out a new PR or similar. This works also for reviews so I just add comments and the submit a review with "/pi follow the comments instructions" or similar

- if I want more fine graded control and I am at the workstation I use the bridging Pi extension to pick up the work locally: https://github.com/shaftoe/pi-coding-agent-action/tree/devel...

- rinse and repeat until I'm either happy with the change or the PR is so bloated that I get rid of it and start anew

I know it's probably something Claude / Codex / Cursor offer with their web app but I want the freedom and the flexibility to use the LL provider/model I want, and Pi as a harness does that plus all the rests egregiously. Another advantage is that I can fit the LLM action in any pipeline I want and take care of chores like automated changelog generation and what not.

As I said it's still mostly work in progress but in general I think there's lot of potential with this kind of workflow, it forces me to keep the scope of the changes small (I still want to review the PR content after all) and gives me a memory for free just leveraging the ticketing system. I also like the fact the harness is running most of the time in the ci/cd sandbox which, in the case of Forgejo, I control fully.

PS I try to keep my work with/on AI tools on my website at https://a.l3x.in/ai

I feel that flow state[1] is possible as long as you don't feel distracted into doing other things and you're needed to guide the LLM along every few seconds/minutes (someone mentioned a pair-programming type tool in this thread). For me that works if you have a good spec + workflow tool (assuming you're doing interactive coding and not kicking off long running coding jobs). I feel that a good test of a workflow tool is that it should offload all bookkeeping from you, leaving you to just read the generated code and think about design/architecture.

I built one such tool for myself: https://www.shipsmooth.net. You can use it to spec/plan out a piece of work, and then easily keep updating the spec/plan as you churn through its implementation. The tool assumes that you will pretty much end up changing the spec/plan during implementation, based on how it's going. In general, I don't see how it's possible to one-shot high quality code for custom use cases.

[1] Going by the definition of flow state here: https://en.wikipedia.org/wiki/Flow_(psychology): "fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by the complete absorption in what one does, and a resulting transformation in one's sense of time."

1. Find a problem that LLMs suck and you're good at. Then you'll have no choice but to enter the flow state.

There's lots of those still. Portable shell programming is my favorite. Even the most capable models limp at it, but I thrive on my own, so it becomes an interaction where I really feel I need to think.

2. Work on dense programs, and use LLM for debugging only. LLMs suck at writing dense code. They thrive at redundancy and verbosity, so it will make you avoid it and use it for adjacent work, not the main thing.

3. Multitask. Ride several bikes at once, but not for the sake of doing more (for that you could automate), do it for the multitasking. Parallelize, split projects into multiple work fronts, work on reducing the time to mental switch between contexts. It's not coding per se, but a great skill, AI involved or not.

My flow state with AI is having 5 different conversations at the same time making good progress on all of them by giving key insight and feedback at the right times.

You can actually go super fast with the right setup and focusing only on the important details like ensuring the shape of the APIs make sense and that test quality is good.