Gave a lightning talk yesterday at Tokyo AI x OpenAI event on my Codex CLI workflow. Here are the notes in case you missed it:

Use speech-to-text to give detailed context to coding agents: As a developer, I love keyboard and I can understand if you’re skeptical, I was too, but using speech-to-text is one of the high-leverage things you can do as a developer.

We all know that LLMs work better when given more context and clear instructions. When you are working with coding agents, you are giving instructions to them multiple times a day, every day. Over time, you end up giving much better instructions and detailed context if you use speech-to-text compared to manually typing all those instructions all the time.

There are tons of open source and proprietary products for speech-to-text which offer inference on local machine or on cloud. Pick whatever you find suitable, but I definitely recommend using speech-to-text to give your instructions to the LLMs. And if you’re skeptical, I’d say give this a try for a week and then you can re-evaluate.

Planning and implementation: After I speak out loud things I want to do, I feed it into Codex for planning and iterate on the implementation plan until I’m satisfied. Then I use the wedow/ticket application which is a minimal lightweight version of Beads to create tickets for all the tasks.

After I’m done with planning and all the tickets have been created for the task, I go to new Codex session and then pick the ticket that’s not blocked by any other ones and then start the implementation. After the agent has completed the implementation, I check the code manually and iterate on it until I’m satisfied.

Getting the changes ready for creating a pull request: After I’m satisfied with the implementation, I use an Agent Skill I have created for myself in a fresh Codex session for polishing the implementation. It checks the git diff and removes all the unnecessary comments made by LLMs. Then it runs tests and if there are any failing tests, it recursively fixes them until all of them pass. Then it runs formatting and linting recursively until issues are fixed.

After that the implementation is ready for pull request. So then I go to the editor myself and then review all the code again and make small meaningful commits. And then I manually create the pull request.