Discussion on hn: https://news.ycombinator.com/item?id=48231575

Repo: https://github.com/sermakarevich/sddw

Slides: https://docs.google.com/presentation/d/1SjKXF7hkoqyiN9-3tBGY...

Besides that I have a collection of custom skills (plan for JIRA tickets, github PR creation, code review, etc), a set of MCPs (most are for internal tooling) and most of the time I use Claude Code.

For devs:

Claude, Codex and Cursor. All on the $20 subscription.

Then use Conductor for worktrees w/ Claude/Codex for mid-size tasks and code review.

Cursor for manual or small changes w/ Composer 2.5.

I mostly do TDD with TypeScript. I write the test, write the code myself (sometimes with the help of LLM), and then hand it to the LLM. Instead of asking it to write things for me, I use it to find edge cases, check if it's leak-proof, and verify efficiency.

For architecture questions, I debate with it for a while. I almost never ask for code without conversing 4-5 times first to push back on its assumptions. It's the best rubber-ducking partner I've had.

Personal plug: I wrote more about why/how I use AI to write slow, better code on my blog: https://nabraj.com/blog/ai-write-slow-better-code

- Claude Code

- flow: https://github.com/RivoLink/flow

- leaf: https://github.com/RivoLink/leaf

- GNOME Terminal

It's a pretty terminal-first workflow.

Most of the participants has Windows laptop. (Except one with Mac)

We had suggested Linux on WSL2 and VSCode. (`uv` for python package management)

But realized that we were spending a LOT of time fighting the tools/combination. WSL2 + Windows filesystem + uv did not work well together.

For person with macOS - it was smooth sailing

If I do another batch, we'll use native `pip` and python (not uv) and I think then we won't need WSL2

1 - https://github.com/raine/workmux

Sublime Text and a DeepSeek plugin for file by file cosmetic fixes

Nothing else. With these tools I am building apps like never before in minutes instead of months

[1] https://www.npmjs.com/package/mecha-ai

My way is to just run a giant AI agent factory engine and make the agents full flow do everything. (plan long term, write prd, task, review).

Here's ~4000 commits in last month as an example, i have about ~10k ish including private/work stuff? https://github.com/portpowered/you-agent-factory/commits/mai...

The premise when you get to full automation generally is you go full industral engineering:

1. watch overall flow, improve process via continuous improvement

2. work via checklists and gates.

3. replace process with mechanisms as much as possible (code > agents)

4. optimal throughput is continual testing and iteration (CI, CD), coverage, full e2e tests, mock everything, general best practices really.

decent blog: https://openai.com/index/harness-engineering/

general points:

- build lots of linters

- document literally everything (arch, prd, best practices in repo)

- too many agents at the same time makes lots of code conflicts, so need to consider architecture of code how to maximize concurrency.

and then an MCP+Channels system that let’s the claudes DM each other

plus the Telegram channel so one of the claudes can talk to me over text message

I can tick files in Vim, those get concatenated into a prompt. Along with a feature request. Plus an instructions file that tells the LLM how to reply. Plus my general "rules for good code" file, plus one "rules for good code" file per language involved, plus a project specific overview file. The LLM then answers with a list of changes it wants to make to the code. My tooling then applies those changes and I look at them via "git diff". If I like it, I commit. If not, I change one of the prompts and start the process again.

Instead of replying with code changes, the LLM can also decide to request more files. I wrote a little DSL for that.

I described the beginnings of this workflow last July:

https://www.gibney.org/prompt_coding

Feels like an eternity ago. I think I will write a new blog post this July and describe how the workflow has evolved over the past year.

I have a base container.

"A" to make a new instance.

Pi.dev when I hit enter on any container. Hot swap anthropic enterprise and openai and openrouter as needed.

Every container has the dev env already running for my current projects. Iterate, rarely use vim when needed, spec driven and have llm draft prs for me then I review.

I know the codebase in and out so what I want done is on bypass mode and then I review closer at the draft PR step before marking ready for the team.

1/ spec driven dev (https://github.com/github/spec-kit)

2/ then degrade to multiple sessions (no worktrees) debugging various problems until its done

On UI Design (MacOS, Web):

1/ AI does a first pass. Try to give it style guidance on my own (colors, style, etc).

2/ Prompt ChatGPT.com with screenshots and ask for recommendations on how to make it better.

3/ Codex the changes (with minor edits)

4/ loop 2-3, ask Gemini for feedback too

The zellij layout includes panes for OpenCode, a shell, a neovim, inotify tests, etc.

I cycle through the zellij sessions during agent prefills.

I've found that converting stuff that's previously been very ops-cli heavy into very detailed skills has worked really really well.

I use Claude Opus 4.8 + Conductor as my daily driver

Mostly Hand coded, using an agent in the browser (Claude / Corporate ChatGPT account) when necessary. I am aware we will fall behind using this methodology and have advocated for change, but I suppose it comes with the territory.

More details here:

https://www.stavros.io/posts/how-i-write-software-with-llms/

I won’t go into any details on why here, because that would make it too much about me. There have been plenty of discussions of reasons, trade-offs, &c. Plenty of people are rejecting this stuff, for a wide variety of reasons.

But one thing I will say: if I were teaching someone to program, I would actively discourage them entirely from using AI stuff, even though it will seem to help. (I mean someone that wants to learn programming, not someone that just wants results and is not interested in programming as such.)

Especially along the range of newbie to expert it’s extremely variable and you’re not gonna be able to pick one that rules them all

I would suggest you revamp your approach and have different courses for different types of people I had to split my course into a basic and an advanced and they are extremely different

Even within the advanced course fairly simple stuff like hosting your own LLMs seems to really be a stretch for a lot of people

Start with a nice batteries included setup, read anthropic's knowledge share, play and iterate, stay human in the loop.

Check out Dax Raad (behind OC) on the Pragmatic Engineer podcast, I think you will like his philosophies, I sure do.

1) Claude Desktop which includes Claude Code for Anthropic: https://claude.com/product/claude-code (alternatively the terminal based version; either way get the subscription)

2) Codex for OpenAI: https://developers.openai.com/codex/app (same as above, subscription preferred instead of paying per token)

3) OpenCode for a variety of models: https://opencode.ai/ (they also have a subscription, but this in particular also makes it really easy to connect to OpenRouter)

4) KiloCode is essentially the above, but for VSC derived editors: https://kilo.ai/ (I personally liked RooCode more, but that got retired)

More niche tooling options:

1) Zed is pretty good, though I saw some issues with their LSP Edits and found that connecting them to OpenCode through ACP worked better, still a cool editor: https://zed.dev/

2) If you have to pay for tokens and can't get subscriptions, look at DeepSeek as a provider (V4 Pro with Max reasoning): https://api-docs.deepseek.com/quick_start/pricing

3) I'm also writing a launcher to make running Claude Code with 3rd party providers earlier, early days still: https://ccode.kronis.dev/

Note: for anyone on Windows, if you install the terminal versions of the tools (Claude Code, Codex, OpenCode, ...), you probably want them inside of WSL so there's less confusion with file paths etc. that some models have.

In regards to actually using the tech:

  - version control and maybe worktrees
  - sub-agents are pretty nice to have, Claude Code also introduced support for longer running workflows
  - throw as much tooling as possible at the project, like Oxlint, Oxfmt etc., for Python it might be Ruff and ty or Pyright or whatever
  - throw as much testing as possible at the project, maybe require certain coverage or just have CLAUDE.md that nudges the models to write and run tests
  - throw as many additional scripts at the project as you want, e.g. how you want the architecture to be laid out, max file length limits etc., whatever common tools don't cover
  - some tools also support LSP, use those when possible
  - pretty much all models will still output slop, though making fresh instances (even of the same model) review its output, e.g. 3 parallel sub-agents looking for critical/serious issues works pretty well, I just have a review loop that I make the models run before commits
  - ideally you'd also test local instances of whatever you build (e.g. real PostgreSQL instance etc.), just so the dev loops are tighter and faster