I built a skill for this: https://github.com/doubleuuser/rlm-workflow
The readme is a bit more to the point.
Readit Newsdworks commented on Ex-GitHub CEO launches a new developer platform for AI agents entire.io/blog/hello-enti... · Posted by u/meetpateltech
reddit for reddit: https://lurkkit.com/
DJ controller in your browser: https://dj.t-tunes.com/
@dworks: Good insights. Thanks!
If you add a dialectic between Opus 4.5 and GPT 5.2 (not the Codex variant), your workflow - which I use as well, albeit slightly differently [1] - may work even better.
This dialectic also has the happy side-effect of being fairly token efficient.
IME, Claude Code employs much better CLI tooling+sandboxing when implementing while GPT 5.2 does excellent multifaceted critique even in complex situations.
[1]
- spec requirement / iterate spec until dialectic is exhausted, then markdown
- plan / iterate plan until dialectic is exhausted, then markdown
- implement / curl-test + manual test / code review until dialectic is exhausted
- update previous repo context checkpoint (plus README.md and AGENTS.md) in markdown
adding another external model/agent is exactly what I have been planning as the next step. in fact i already paste the implementation and test summaries into chatgpt, and it is extremely helpful in hardening requirements, making them more extensible, or picking up gaps between the implementations and the initial specs. it would be very useful to have this in the workflow itself, rather than the coding agent reviewing its own work - there is a sense that it is getting tunnel visioned.
i agree that CC seems like a better harness, but I think GPT is a better model. So I will keep it all inside the Codex VSCode plugin workflow.
This is what I've been doing. Iterating on specs is better than iterating on code. More token efficient and easier to review. Good code effortlessly follows from good specs. It's also a good way to stop the code turning into quicksand (aside from constraining the code with e2e tests, CLI shape, etc).
But what is your concept of "stages"? For me, the spec files are a MECE decomposition, each file is responsible for its unique silo (one file owns repo layout, etc), with cross references between them if needed to eliminate redundancy. There's no hierarchy between them. But I'm open to new approaches.
The stages are modelled after a kanban board. So you can have whichever stages you think are important for your LLM development workflow. These are mine:
00: Iterate on requirements with ChatGPT outside of the IDE. Save as a markdown requirements doc in the repo
01: Inside the IDE; Analysis of current codebase based on the scope of the requirements
02: Based on 00 and 01, write the implementation plan. Implement the plan
03: Verification of implementation coverage and testing
04: Implementation summary
05: Manual QA based on generated doc
06: Update global STATE.md and DECISIONS.md that documents the app, and the what and why of every requirement
Every stage has a single .md as output and after the stage is finished the doc is locked. Every stage takes the previous stages' docs as input.
I have a half-finished draft with more details and a benchmark (need to re-run it since a missing dependency interrupted the runs)
https://dilemmaworks.com/implementing-recursive-language-mod...
Somewhat underwhelmed. I consider agents to be a sidetrack. The key insight from the Recursive Language Models paper is that requirements, implementation plans, and other types of core information should not be part of context but exist as immutable objects that can be referenced as a source of truth. In practice this just means creating an .md file per stage (spec, analysis, implementation plan, implementation summary, verification and test plan, manual qa plan, global state reference doc).
I created this using PLANS.md and it basically replicates a kanban/scrum process with gated approvals per stage, locked artifacts when it moves to next stage, etc. It works very well and it doesnt need a UI. Sure, I could have several agents running at the same time, but I believe manual QA is key to keeping the codebase clean, so time spent on this today means that future requirements can be implemented 10x faster than with a messy codebase.
dworks commented on Targeted Bets: An alternative approach to the job hunt seanmuirhead.com/blog/tar... · Posted by u/seany62
A few times in my life I have found job opportunities that would have been my dreamjob and I was uniquely qualified due to a cross-disciplinary background, previous experience and education, language skills and such. I was an SME with technical skills and I had so much knowledge of the company's products, industry and competitors that I could have done their marketing strategy and product strategy in a couple of weeks. Maybe it wouldn't all have been correct from the start, but I had so much knowledge that I could have done this by heart.
I spent a lot of time on targeted applications for these places, re-doing my CV and spending weeks iterating on my cover letter. I never heard back from any of those places.
Instead I've been hired into industries I knew nothing about. Sure, I was a decent candidate, but I was just another candidate. This has worked out fine.
Why did these places hire me and not the others? Because they were growing so they had a need to hire. The former places did not.
So for me the only real advice is to apply to places that are growing. When places are growing and really need to hire to expand, all the bullshit in the process is eliminated. Decisions are made fast. It's easier and more pleasant.
dworks commented on Show HN: Beats, a web-based drum machine beats.lasagna.pizza... · Posted by u/kinduff
Love the UI. I think these browser-based products are great at removing the "mystery" around music making or DJing by making it accessible. All you need to do is type a URL and click a few elements to get started and you get instant feedback. I built a similar browser app but for DJing (I was also inspired by Pocket Operators): https://dj.t-tunes.com/
And I use git hooks on the tool event to print the current open gate (subtask) from task.md so the agent never deviates from the plan, this is important if you use yolo mode. It might be an original technique I never heard anyone using it. A stickie note in the tool response, printed by a hook, that highlights the current task and where is the current task.md located. I have seen stretches of 10 or 15 minutes of good work done this way with no user intervention. Like a "Markdown Turing Machine".