Comment by spicyusername
8 days ago
Originally my workflow was:
- Think about requirement
- Spend 0-360 minutes looking through the code
- Start writing code
- Realize I didn't think about it quite enough and fix the design
- Finish writing code
- Write unit tests
- Submit MR
- Fix MR feedback
Until recently no LLM was able to properly disrupt that, however the release of Opus 4.5 changed that.
Now my workflow is:
- Throw as much context into Opus as possible about what I want in plan mode
- Spend 0-60 minutes refining the plan
- Have Opus do the implementation
- Review all the code and nitpick small things
- Submit MR
- Implement MR feedback
My workflow is something very similar. I'd say one difference now is PRs actually take longer to get merged, but it's mainly because we ignore them and move onto something else while waiting for CI and reviews. It's not uncommon for a team member to have multiple PRs open for completely different features.
Context switching is less painful when you have a plan doc and chat history where you can ask why yesterday afternoon you (the human) decided to do this thing that way. Also for debugging it's very useful to be able to jump back in if any issues come up on QA/prod later. And I've actually had a few shower thoughts like that, which have allowed the implementations of some features to end up being much better than how I first envisioned it.
Odd how you add the time for the requirement analysis but none for the coding.
Then you tell us you leave 83% of the analysis —and the coding— to a code chatbot.
Are you actually more productive or are you going to find out down the line the chatbot missed some requirements and made APIs up to fill up a downstream document and now you better support them by yesterday?
In ye olden days, people doing this would scream at the junior developers. Are you going to scream at your screen?
To be honest, I didn't think too hard about it. I just fired and submitted with the time estimates in there kind of randomly.
You are clearly a naysayer. I get it. I was one too for a long time. Then I found a workflow and a model that was clearly delivering results and that's what I use now.
It's only a matter of time before it happens to everyone, even you. Once you have the aha moment where it works for you, you'll stop asking everyone whether they really know if it's better.
The LLM-based workflow above produces good code at a speed at least as fast as my previous workflow and typically many, many, many times faster with the code produced often using designs I would have never thought of before being able to bounce ideas off an LLM first. The biggest difference, besides the time obviously, is that the energy I need to spend is in very different places between the two.
Before it was thinking about what I needed to do and writing the code.
Now it's thinking about what I need to do and reviewing the code.
Well, I'm not considering using any code generation outside of helper scripts because in my case coding is a negligible part of my work. If I didn't have the LLM, I would find and modify the tool it is lifting code from using pre-LLM Google.
I know asking one of these LLMs to produce a document from my notes, resulted in me having to review this professional and plausible-looking yet subtly wrong document for more hours than it would have taken me to produce the document from scratch.