Perhaps in a small codebase without issue tracking this might be something leverage. It's just not reasonable with 100k+ lines of enterprise grade code.
You might be approaching PR comments differently than I've seen. When a comment is something to be addressed, it's either put into a new development task (i.e. on something like Jira), or it is completed before the PR merges. I'm not sure that having comments in the code surfaces that information in a useful manner. The code is for the code, not for what the code could be. The comments on what it could be should be handled outside the code at a different abstraction layer.
Some subscriptions offer "unlimited tokens" for certain models. i.e. GitHub co-pilot can be unlimited for GPT-4o and GPT-4.1 (and, actually, GPT-5 mini!). So: I spent some time with those models to see what level of scaffolding and breaking things down (hand holding) was required to get them to complete a task.
Why would I do that? Well, I wanted to understand more deeply how differences in my prompting might impact the outcomes of the model. I also wanted to get generally better at writing prompts. And of course, improving at controlling context and seeing how models can go off the rails. Just by being better at understanding these patterns, I feel more confident in general at when and how to use LLMs in my daily work.
I think, in general, understanding not only that earlier models are weaker, but also _how_ they are weaker, is useful in its own right. It gives you an extra tool to use.
I will say, the biggest findings for "weaknesses" I've found are in training data. If you're keeping your libraries up-to-date, and you're using newer methods or functionality from those libraries, AI will constantly fail to identify with those new things. For example, Zod v4 came out recently and the older models absolutely fail to understand that it uses some different syntax and methods under the hood. Jest now supports `using` syntax for its spyOn method, and models just can't figure it out. Even with system prompts and telling them directly, the existing training data is just too overpowering.
Find another developer and pair/work together on a project. It doesn't need to be serious, but you should organize it like it is. So, a breakdown of tasks needed to accomplish the goal first. And then many pull requests into the source that can be peer reviewed.
I like reading these types of breakdowns. Really gives you ideas and insight into how others are approaching development with agents. I'm surprised the author hasn't broken down the developer agent persona into smaller subagents. There is a lot of context used when your agent needs to write in a larger breadth of code areas (i.e. database queries, tests, business logic, infrastructure, the general code skeleton). I've also read[1] that having a researcher and then a planner helps with context management in the pre-dev stage as well. I like his use of multiple reviewers, and am similarly surprised that they aren't refined into specialized roles.
I'll admit to being a "one prompt to rule them all" developer, and will not let a chat go longer than the first input I give. If mistakes are made, I fix the system prompt or the input prompt and try again. And I make sure the work is broken down as much as possible. That means taking the time to do some discovery before I hit send.
Is anyone else using many smaller specific agents? What types of patterns are you employing? TIA
Aren't down votes on this forum restricted to 500+ karma? And how would those compare to flagging? I'd hate for people under 500 karma to think they need to flag a post in order to have it get any attention by moderation. And, with your idea that LLMs help folks write, wouldn't that make the community worse for them?
In our org that would not fly. They would be required to break it down. Did you or anyone tell them they need to make it readable for the rest of the team?
I understand where you're coming from, and think there is something missing in your final paragraph that I'm curious to understand. If LLMs do end up improving productivity, what would make them go away? I think automated code generators are here until something more performant supersedes them. So, what in your mind might be possibilities of that thing?
It's definitely sort of that. You can run your own server, as well, though this comes with its own limitations (and inherently takes away from the want for more players). Most of the developers have varying goals with the project. When I was working on the project, my care was primarily for making the game as close to the original as possible using "replays" by dedicated players before the original shut down. It was fun to write code for something that felt like it would give some folks a nostalgia hit.
I think optimally, you'd do something more akin to a "group ironman" with some friends. This guarantees you've got others around.
Companies need to set the bar and uphold it. Saying people are "quiet quitting" is synonymous with saying, "we don't know how to set and uphold standards". Putting the blame on the employee instead of having clear guidelines (i.e. making it a performance problem) is an unfortunate scapegoat used to shift the blame and accountability. A job is a contract. Ain't just one sided.
Edit: Amending to mention that there are companies that do quite well at upholding standards. To those, thank you for trying.
I think there may be a set of people that have figured out, 1) how to interact with LLMs; and 2) what in their lives is improved when interacting with LLMs. I am in the group that has not found the best use case for my own life, and have never needed it for improving anything I need to get done. Always looking for suggestions, though!
I enjoy brewing some loose leaf* green tea with varying ratios (leaf, water, temperature, time). Others might enjoy it! I think it's a fantastic replacement beverage that helped me cut soda.
I like doing 4g of Japanese sencha leaves, 80-100mL of water, at 60-70C for 30s to a minute. Second steep 10 seconds, and third 30-40 seconds. But honestly the fun is in experimenting! (plus at lower temperatures you can drink it right away!)
Congrats on your feat of strength! To others looking to quit, I've read[1] that it's dangerous to quit cold turkey. Ease yourself out, and save yourself from possible complications.
The ideas shared in the post replies are great. My approach has been more hands-on and puzzled together recently. I've been digging into harder problems on sites like leetcode to learn more math, and solidify some algorithm and data structure concepts. It has really helped me feel more confident and erase some of the lingering imposter syndrome around the algorithm-side of programming. A great guide that got me started on this was the tech interview handbook[1], which helped me dig into specific concepts instead of just randomly targeting. I've found my ability to review code has also improved through this, as I am picking up different libraries and concepts that I wouldn't have otherwise.