9 ms·

I've hit this point with AI where it's not a simple process, but a long drawn out back and forth. I'll use AI to design the implementation of a medium sized, c

I've hit this point with AI where it's not a simple process, but a long drawn out back and forth. I'll use AI to design the implementation of a medium sized, cross cutting feature. Review all the details, maybe iterate on just that. Then implement with Claude 4.7 Max - which runs slower, but does a better job. Then review the implementation, then have Codex GPT 5.5 xhigh fast review it - which almost always finds corner cases. Have Claude fix those - Claude is better at writing intuitive maintainable code versus Codex overengineered/shortcut filled code. (Codex is better at finding/fixing bugs and doing reviews - it's annoyingly pedantic) Then repeat with fresh Claude/Codex instances having them both review the current staged changes and getting feedback, handling the feedback. Then covering it in tests. I mean overall I still implement the feature faster than coding it manually, but I spend a majority of the time going back and forth with reviews, handling corner cases and at the finish end up with what I feel a really solid implementation of whatever feature I'm working on. The v1 feature feels more like a v3 given the amount of iteration it already went through.

rootnod3 5mo ago
And then Anthropic has an outage and you what...have a coffee break until then? All that time babysitting the AIs just to be a little faster but probably with less knowledge/control over what they did?
- bottlepalm 5mo ago
  As the AI is working, I am working - reviewing, regression testing, thinking about if the currently implementation is too complex and how to simplify it etc.. I totally review and understand everything the AI is generating and often push back, have it re-do something, or do it myself. In the end I feel like the quality of the work is at a v3 level in the time it took to do a v1. The productivity and quality increase is real.
- comradesmith 5mo ago
  I’ll deal with that problem when it happens
- afavour 5mo ago
  I don’t think you’re quite getting what OP is describing. I work in a similar way… I am aware of all the code being written. If Claude had an outage I could write it myself. It would just take longer. You say “all that time” babysitting AIs but in my experience it isn’t that much time, if anything the back and forth at the planning stages is more productive than when I’m doing it by myself because I’m being asked questions and having to think things through from different angles.
  - halfcat 5mo ago
    How do you stay aware of all code being written? Maybe it’s just me, but I’ve never understood how one understands from reading code. Yes you can understand what that code does, but not why it was done that way instead of a different way. In the end I only understand it deeply if I end up writing it. Chatting through it is helpful to me, but having AI crank out code loses all of that context pretty quickly. I’m not disagreeing. Just curious how you think about this, and if there are key parts of your process that help you stay contexted in.
    - bottlepalm 5mo ago
      If you can't understand why the code is done in a certain way from reading it then the code is missing comments or needs to be refactored. Even code you write yourself, given enough time, you will forget the why unless you wrote comments. In a way comments are as much for you as they are for others. Even before AI, understanding code you didn't write is essential to working on a team of other developers. If you can't understand the code from reading it, then that's part of the feedback loop - too complex, needs comments, etc.. On large teams you'll spend as much time reading code as you do writing it. And long term when it comes to writing maintainable code - the ability for others to read and understand it, including the why of it, is paramount. Your code could literally be around for decades.
      - manmal 5mo ago
        Codex barely writes any comments, while Claude makes a slop article for every one line commit. I’d enjoy something in the middle.
- glhaynes 5mo ago
  "All that time babysitting the AIs just to be a little faster" doesn't seem like an accurate/unbiased portrayal of what they said: "The v1 feature feels more like a v3 given the amount of iteration it already went through."
- mohamedkoubaa 5mo ago
  And then solar radiation permanently knocks out the electrical grid and you what... have coffee break until society finds a new equilibrium?
  - prerok 5mo ago
    No, then you go back to programming on the white board, just like in college. /j
- efitz 5mo ago
  If you only have one AI window open, you’re doing it wrong. You task swap to another window/agent, get it working on something, rinse and repeat. I can keep 4 busy most of the time. When I task swap I also check in on what the other agents are doing to make sure they’re on track, not blocked and not struggling.
  - well_ackshually 5mo ago
    congratulations on your soon to be coming burnout. Keeping that many tasks in parallel, running all the time will kill you.
    - speff 5mo ago
      I suppose it depends how hands-off the tasks are - I max out at 2 parallel sessions working on different parts and it's fairly exhausting once done. I can see the number of parallel work increasing if there's a good dev/test loop. But at $WORK, that's not usually an option.
      - rootnod3 5mo ago
        So, hands-off meaning "just let the AI cook and don't check it"? Either you follow everything it does, revise the plans, do the code review, manual adjustments, etc, or you run sessions in parallel, not being that attentive and constantly context-switch (also resulting in less attention I guess). I fail to see the benefits honestly.
    - DonHopkins 5mo ago
      It's great to work from home so you can take nice little micro naps while code's generating, reviewing, building, and deploying. A calm attentive alternative of vibe coding: restful coding. It's much easier to read and review code after a refreshing cat nap, especially with a real cat. Too bad that's not usually acceptable to do that in the office. It should be! Slacking off by sword fighting all day is too exhausting. https://xkcd.com/303/ https://xkcd.com/303/
- wahnfrieden 5mo ago
  Codex has 99.98% uptime
  - kordlessagain 5mo ago
    Unlike Claude who barely has 2 9s.
- refactor_master 5mo ago
  We're already having coffee breaks when AWS and CloudFlare are down. What's another break in the mix? If anything, we might be lucky that they're down at the same time, so we can consolidate the breaks.
- soupspaces 5mo ago
  In Soviet Russia, the AI babysits you https://en.wikipedia.org/wiki/In_Soviet_Russia https://en.wikipedia.org/wiki/In_Soviet_Russia
- 8note 5mo ago
  why not? then demand some lack-of-uptime compensation for a lack of uptime
- raven12345 5mo ago
  You can have multiple tasks running
- jerezzprime 5mo ago
  Yes get a coffee. Being able to execute 5 things at once is amazing, but it's a recipe for burnout. We have to be more careful and explicit about how we spend our time, and that means more explicit time away. If this thing makes you 10x more effective (I truly believe it can), you can afford to spend 20% less time behind the desk and more time doing whatever it is that actually makes you happy. Hopefully your manager understands that calculus.
  - cube00 5mo ago
    > Hopefully your manager understands that calculus. The majority of jobs are still paid on a 40 hour per week basis. Disappearing for a day each week (20%) won't fly when you're full time.
- busterarm 5mo ago
  Company I'm familiar with that went all in on Codex ran out of tokens for a week and wouldn't increase their spend. I pretty significant number of their engineers flat out refused to work. Like publicly said so. "Increase our plan or I'm taking the week off."
  - democracy 5mo ago
    so how did this go?
    - busterarm 5mo ago
      management flinched first.
- gitaarik 5mo ago
  What do you do when your search engine goes down?
  - skydhash 5mo ago
    I have all the relevant sites for my projects in my browser history. A search engine is just a quicker way to get to a particular page.
  - bigfishrunning 5mo ago
    My computer has man pages. They're usually pretty great! failing that, most of the APIs i use are open source, so i can read the code anyway.
    - gitaarik 5mo ago
      you could also run a local LLM to browse your endless manpages efficiently ;)
      - duskdozer 5mo ago
        Just to find out the arguments and subcommands it made up that don't exist.
- shinycode 5mo ago
  It’s a fragile equilibrium and it depends on the kind of project you’re working on. If the knowledge debt is ok then yes, it’s just like a delivery job, if the truck has an engine problem I won’t continue to deliver the packages by walking or finding and setting up an other truck from where the vehicle breakdown happens. I’ll just wait because the wait is still faster than the other solution because of the knowledge debt it’s too long to pickup by hand and continue. Now if it’s my job then I can’t have a knowledge debt and if Claude is down I’ll continue working manually because I know and understand and can continue without having to understand a lot of logic before continuing
- vcdk 5mo ago
  Whenever Anthropic is down, I switch to my other alternative AI provider. If that is also unavailable, or no more tokens left, then I can switch to my local AI. Not the same in terms of quality and speed, but good enough for an experienced engineer to still be more productive than falling back to doing it by hand. For my principal activity I do not want to be dependent on a sole provider. Besides that, I expect that the pending token price increases are going to hurt a lot of people/companies.
vessenes 5mo ago
I have a very similar workflow, and experience similar temperaments from the agents. I also find anecdotally that they are moderately competitive - you get very different attention from them when you say "competitor X wrote this - please find all bugs" than when you say "you just wrote this - please find all bugs".
- bottlepalm 5mo ago
  Hah yea I just told them I wrote it, or I reviewed it. I don't want to get the AI's in a pissing contest with each other because they will get distracted and try to show off.
scosman 5mo ago
yes exactly. Too many people ask AI to one-shot complex tasks, and wonder it behaves like a junior asked to rush something. I have my own skill: 5 rounds of research/planning/test-planning. Interactive with me in loop for all important decisions. Starts with high level shape, then details. Planning can take 2-3 days of my time, then the implementation agent can take many hours (Opus 4.7). It splits the implementation across many phases/commits, each with its own code-review fix loop. Deep code review at the end can take another hour or two. It opens a PR, Gemini reviews, it reads out and resolves those issues. Projects still take days or weeks, but 5x faster than doing it all myself. Edit: the skill - https://github.com/scosman/vibe-crafting https://github.com/scosman/vibe-crafting
- deadbabe 5mo ago
  Does the 5x faster including shipping? Or just the work part? IMO if you are not shipping out faster then the faster work gains are meaningless. If you are shipping faster, you’re probably picking up more work and shipping everything too fast leading to burnout.
  - mhluongo 5mo ago
    If you're not shipping faster, it's meaningless, and if you are, it's also bad?
    - 3836293648 5mo ago
      If you're not shipping faster it's meaningless for the company. And if you are, it's bad for the employee. Is what the above comment actually said.
  - scosman 5mo ago
    yup.
- dawnerd 5mo ago
  Even fully planned it’s still no better than a junior dev. You’re leaving out how much back and forth you have the ai do on itself, which you’d have on a junior dev too. In the end does it matter if it’s giving you what you want? Guess not really. But let’s not act like it’s crazy good when you’re still doing a lot of rounds of revisions on something an experienced dev would know to do right the first time.
chrisweekly 5mo ago
You helpfully cite Claude w/ Opus 4.7 max and Codex w/ GPT5.5 xhigh fast, but what "AI" do you use for the initial design?
- bottlepalm 5mo ago
  Claude primarily, though will sometimes get a second opinion from Codex.
skydhash 5mo ago
That sounds too much like three weeks of work saving you three hours of planning. In my experience, software engineering is a matter of knowledge. Understanding it and then coming up with a solution. The latter is a flash of insight that comes mostly from experience. Then you gather more information to flesh it out, or brainstorm it with your colleagues. What you're describing sounds more like a ritual of doing busy work than anything practical. Because tasks vary so much. A feature may be huge, but you take care of it in a day with copy pasting because you already have all the building blocks in other files. And something may be twenty lines of code, but you spent the whole week sweating on it (concurrency stuff maybe). Those ritualistic workflows sounds more like someone imagining software development than actually doing it.
- bottlepalm 5mo ago
  A lot of people say you need to go through at least three versions of something before it is mature - and v3 is not something you can design upfront. You need to see v1 both in code, and at runtime. Use it, get the feedback, and iterate. This is where AI tightens that loop immensely. Lost you in the last paragraph - features are not "copy pasting because you already have all the building blocks" and "something may be twenty lines of code". Mid sized features often mean tearing up many layers of code across the stack to add in some sort of new capability. Tearing up existing code means there are all sorts of add-on considerations in addition to feature you are working on.
  - habinero 5mo ago
    > Mid sized features often mean tearing up many layers of code across the stack to add in some sort of new capability What? No, it shouldn't. I've worked on a lot of codebases and if you have to do this, something is very, very wrong.
    - bottlepalm 5mo ago
      Nothing wrong at all. Some features you can bolt on, and some features fundamentally change how a system works requiring changes at many different levels of the stack. Happens all the time.
nomel 5mo ago
I've noticed the following really helps (most important at end): 1. Have claude form the plan and converse with a simple "Note any concerns with this plan" type plan-critic agent. 2. Let it run. 3. After (with everything in context) have it make a future_recommendations.md. 4. Have it make a plan.md to implement those future recommendations, conversing with the plan critic.. 5. Clear context. Repeat with 1. Do this loop a few times, with some feedback from actual review thrown in. But, most importantly, because Claude will aggressively try to maintain code "as is", and happily build on it's previous crap, while preferring to hand roll implementations of everything, add something like this to memories/directives: * When evaluating designs, default to "pull in the library" over "hand-roll it." Hand-rolling is much worse than a dependency. * "Precedent" / "matches house style" / "reuses existing pattern" / "consistent with what we already do" are not valid engineering arguments. * This project is still in the development stage with no real deployments. Mitigation costs and existing precedence are not a concern. With these, in the last week that I've started using them (after inspecting the insane justifications for leaving crap design decisions in the plans), Claude went from junior level slop that required more oversight than it was worth to something very reasonable, using standard libraries, requiring nudges for architecture rather than pure "wtf!?". I think they've fine tuned heavily towards "don't rewrite the codebase" tuning, which completely rational from multiple perspectives, but also not appropriate for new code. I do enjoy a considerable daily token allowance, so this may not apply to everyone.
sunsetSamurai 5mo ago
maybe it's dumb question, but how do you feed the results of one agent to another? do you copy and paste manually? or how do you do it programmatically?
- adrianN 5mo ago
  Having the agents write their plans into text files and iterating on those works reasonably well.
- kevinsync 5mo ago
  When I pair Claude and Codex, I use claude-co-commands [0] to drive from Claude and talk to Codex via MCP. Lately I've found Codex has been far more consistent for my specific projects, so I've just been almost entirely inside Codex. YMMV [0] https://github.com/SnakeO/claude-co-commands https://github.com/SnakeO/claude-co-commands
- DonHopkins 5mo ago
  Just switch models whenever you want with the menu at the bottom of the chat window in Cursor. And maybe don't use tools that lock you into one model?
- bottlepalm 5mo ago
  Yea I'll take the review feedback from one, validate it, and then copy/paste it into the other session saying like, "hey I got this feedback, what do you think?" So I'm not even telling the other AI the feedback is valid, I want it to independently validate it. Often the feedback is not like a bug, but a red flag, design consideration, or trade off. Often depending on how complex the feedback, I'll do it one at a time addressing each one individually. And after the feedback is addressed, I'll go back to the AI that generated the feedback and say like, "I handled 4/5 items you found, can you double check." It's similar to handling PR feedback, where you do it, validate it, but then still have to submit it for peer review.
aomix 5mo ago
Talking the problem to death with the AI before implementation is a nice zone for me. I feel productive, get good results out of the AI, and still largely understand the code. That’s the part of the AI revolution that I feel has made me a better engineer because I argue about design and architecture all day with a robot.
- qsera 5mo ago
  >I argue about design and architecture all day with a robot. You will outgrow it at some point.
  - Terretta 5mo ago
    Or learn something at some point. https://en.wikipedia.org/wiki/Rubber_duck_debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging
    - stuaxo 5mo ago
      Yes, this is the way I do stuff. Try and learn at every point.
  - nullsanity 5mo ago
    Its like that phase people go through where they argue with morons on reddit, and then one day grow up and realize that most of these people are unemployed/underemployed terminally online nobodies aren't ever going to learn anything, and even if they did it wouldn't impact the world since they were just some below average hobbyist anyway and aren't in charge of anything more important than a box of paperclips.
    - dash2 5mo ago
      Ah, if it’s a robot in charge of the paperclips you need to watch out a bit.
    - theK 5mo ago
      Mostly with you, though in recent years I have wondered whether those people are part of what caused the latest boom of political populism. If there is no one there to debate the problematic ideas, problematic ideas will become the rhetoric after all.
i_love_retros 5mo ago
This all sounds insane. If it requires so much back and forth with the AI why on earth wouldn't you just write the code yourself? At least then you build the mental model of the code and keep your brain healthy. Reading the comments in here about all the hoops people are having to jump through just to do the same thing they were doing a year ago without AI... and spending a fortune to do it! I think you've all got AI psychosis.
- democracy 5mo ago
  You can be right but quite often it helps keeping focus on the forrest rather then getting lost in the trees - at least for me. Boilerplate steals a lot of attention, focus and can just be mentally exhausting.
  - batshit_beaver 5mo ago
    Can someone explain these complaints about boilerplate to me? What are y’all doing where boilerplate is the majority of your code? Am I the only one mostly writing concise business logic where most lines are important in one way or another?
    - democracy 5mo ago
      one man's boilerplate is another man's concise business logic )))
- bottlepalm 5mo ago
  I would never imagine this is where programming would be five years ago, but at the end of day having the AI write the code is easier, faster, and results in higher quality. The mental model is still in my head, my brain is overloaded, but only from the amount of code reviews - like I said, I'm building v3 of a feature in the time it takes to build v1, but I am in a way doing 3x the code reviews going back and forth. That's the fall out of the iteration speed enabled by AI. Between submitting PRs, getting feedback, iterating, re-submitting, repeat - there used to be breathing room. Now it's all compressed into an afternoon. Productivity is through the roof, but it can be draining.
democracy 5mo ago
Similar approach, but I also go a step further with some basic manual architecture/high level contract/stubs setups, just to keep it consistent with other systems (and easier reading as well).
- justbees 5mo ago
  I've been doing the same thing lately and I definitely feel like stubbing out the high level architecture at the beginning makes a difference. The codebase I'm in now has very particular ways of doing things and claude doesn't always pick that up. Style can be as important as substance. I still do a lot of back and forth about the plan - have it written to a file. Read through the file, make changes by hand and have claude read my changes and on and on. But starting with the basic architecture there's less ambiguity.
DonHopkins 5mo ago
Low frequency defensive long drawn out back and forth bullet dodging vibe coding should be called "serpentine coding". The In-Laws (1979): Getting off the plane in Tijuara: https://www.youtube.com/watch?v=A2_w-QCWpS0 https://www.youtube.com/watch?v=A2_w-QCWpS0
- bottlepalm 5mo ago
  Heh it feels like that in a way, and the more complex the feature, the more endless the back and forth reviews can be - there seems to be always some feedback, so you need to decide when to be done with it and commit. You can easily get into review paralysis.
dawnerd 5mo ago
When I use ai to code this is pretty close to my workflow too but I find it ends up taking at best just as long as if I were to write the code myself. If m some cases I’ve thrown away what the ai has done and just done it myself. I think that’s just a skill people need to learn - at a certain point you have to cut your losses. I’ve seen some coworkers argue back and forth with an llm trying to get it to do something. Especially true on simpler changes.
- theK 5mo ago
  I've stumbled upon that too! Funnily I see it having two forms: 1. Some bad idea gets embedded into the context that you just can't argue away 2. Some important idea gets lost in compression and the ai wheres off into funland without recourse. In both cases if is often better to start over or just do it yourself. I sometimes find myself asking for a summary, editing it and then using the edited one to seed a new session. Edit: s/Finland/funland/
newsicanuse 5mo ago
At this point one might as well code by themselves
- bottlepalm 5mo ago
  Unfortunately the projects are still too big. Projects with hundreds of thousands to millions of lines of code can't be maintained by a single person reviewing all the the changes. And AI only increases the speed of iteration and the amount of code to review. We may need some sort of paradigm shift - like more powerful frameworks or even higher level languages that allow us to review less, but more functional code blocks.
  - newsicanuse 5mo ago
    When AI tries to improve such large code base who even is going to review the changes?
    - bottlepalm 5mo ago
      Like I said, we either need more people or some paradigm shift in tooling that allows us to do more with less.
boringstack 5mo ago
You've essentially promoted yourself from coder to engineering manager, trading syntax fatigue for the mental marathon of refereeing specialized AI developers to ship v3-quality code on the first try.
- bottlepalm 5mo ago
  Indeed. AI is bumping everyone up to manager level, and having dealt with long PR feedback cycles with humans for years - I don't mind the promotion. Also shipping a v3 is so much nicer than shipping a v1 and dealing the all the corner cases in production. Before AI, myself and everyone else I knew was drowning in tech debt. And now with AI we are treading water.
  - jfim 5mo ago
    It's bumping to manager level, except without the 1:1s, quarterly/yearly planning, headcount and budget reviews, org/reorg discussions, performance calibration, and OKR planning. No complaints about the last review cycle or about the upcoming one.
    - darkwater 5mo ago
      Totally! But you know what? There are many, oh so many developers that are not ready, don't like and probably are not even cut for this kind of position.
    - baq 5mo ago
      All the ceremony must be replaced with process optimization, skill extraction, harness development and new model evals. Still better than dealing with people, but only just.
- krzyk 5mo ago
  Some see it as a promotion other (like me) as a demotion. I still prefer to do it myself, although I like code reviews done by AI, they do help to make code a bit better.
henry_bone 5mo ago
That sounds expensive.
Animats 5mo ago
How much are you spending a day for the tokens to do that? Ingest big project, comment on it gets expensive. I'm not sure how expensive.
- bottlepalm 5mo ago
  $200/month split between Claude Code Max and Codex Pro. Given how many hours a month I spend programming, my hourly rate, the amount of time saved, and the productivity/quality boost - I would pay a whole lot more if I had to.
  - tags2k 5mo ago
    You are definitely going to have to. I see these massive skills as soon-to-be artefacts of the past, they will be unwieldy in the non-subsidised world. I won't pretend to know what replaces them.
    - TacticalCoder 5mo ago
      We have lots of open-weight models like DeepSeek V4 Pro that are very close to SOTA and we know the cost of running them. This helps keeps the other players honests: there's a limit to which they can raise prices when there are already alternatives today and when there's zero lock in. That those companies can make revenues but only at the cost of burning investors money: that's not my problem. My take on it is simple: "Give me something MUCH better than the best open-weight models at a price that's not crazy or you're not getting my money". And it happens to be the take of many devs. I'm still paying Anthropic, Google and OpenAI (OpenAI because I didn't manage to cancel my subscription and now their model is competitive vs Anthropic's models again) but eye'ing a "Pi + open weights" solution. Raise the prices too much and those companies selling access to private models aren't getting my money anymore.
      - Animats 5mo ago
        AI tools have started to kill software as a service by ... selling software as a service. I don't know how this will settle out, but from what NVidia and the DRAM people are saying, it's not going to get cheaper until at least 2030.
rjprins 5mo ago
This exactly my process as well. Although interestingly I swap Codex and Claude; having found Claude way more pedantic in its reviews and codex more pragmatic in its implementation. Maybe it differs per programming language.
atoav 5mo ago
I am not switching the different LLMs as much, but my approach is similar: 1. I write a list of things I want to have without AI support 2. I discuss the list with an LLM, which occasionally reveals obviously missing things I hadn't thought about or just things that would be smart to have. Or sometimes the LLM doesn't get it and wants to funnel me down a commonly walked path, which is a non-goal 3. From that list I draft an implementation plan containing things like how the code shall be structured, which language, libraries, build systems, etc to use. This may even contain some data models and considerations that are more detailed, like for example ideas about how a specific interaction shall be event sourced. I work on that, till I feel a satisfactory level of clarity has been reached 4. Actual writing of code as a back and forth between manual writing, letting an LLM write something and so on. LLMs suck at writing CSS that feels like good UX design to me, so usually templates, layout and CSS will be (re)written entirely by hand 5. Bug-hunting and guessing potential edge cases is one thing where LLMs really shine. Often if the work before that was quality the LLM has an okay time coming up with fixes that are no worse than what I would have done.
germanptr 5mo ago
I follow a similar approach and use multiple LLMs per task. The quality improvement is surprisingly large. Lately I’ve been experimenting with adding an explicit reward function so the models optimize for measurable output quality. This creates a generate, critique, revise loop where candidate answers compete for a higher score. It feels promising because it reduces the amount of handholding for every task. It is also more fun because part of the review process is embedded in the scoring function, which simplifies the review effort.
- bottlepalm 5mo ago
  I don't have it automated, but I score on minimizing lines of code added, readability of the code, and quality of the architecture.
- fransje26 5mo ago
  > I follow a similar approach and use multiple LLMs per task. Pardon my ignorance, but how would go about doing that on, say, a standard c++ project? I get the part where one can use codex/claude with an ide and/or extension. But how does one connect two LLMs together in such a setup?
kilroy123 5mo ago
I've settled on the same workflow. Also I never multitask with multiple agents doing other stuff. Meh I focus on just the one task.
- bottlepalm 5mo ago
  I do multi-task a bit while AI is running, sometimes working on another feature with AI in parallel, but jumping between reviewing different feature iterations is draining, though not much different than the real world juggling PR reviews for a team of devs.
petesergeant 5mo ago
The Claude/Codex loop is the current state of the art in my opinion. I've got a silly little harness that glues them together that I have spent all day, every day in for months: https://github.com/pjlsergeant/moarcode https://github.com/pjlsergeant/moarcode
- bottlepalm 5mo ago
  > You design, Claude writes, Codex reviews, and Gemini doesn't get installed hahahahaha
jiggawatts 5mo ago
The funny thing is that you've just described an idealised development process as would be used by effective, skilled humans in a heterogenous team where everyone has a speciality. If only things were so! If only code was discussed, reviewed, iterated on! If only the "manager" actually read the code, provided actionable feedback, and disseminated PRs to multiple people with diverse skill sets. (If you can't tell, I'm a jaded consultant desperately trying to make the horse drink the water.)
- bottlepalm 5mo ago
  I've worked in large teams for many years and yes it's just like that, but without the time constraint. PR's can only go back and forth so many times. Depending on the reviewer they may phone it in, or focus on different things depending on the person. You yourself aren't able to implement every piece of feedback due to constraints and it ends up as tech debt. So AI definitely changes the game. I feel like we almost need something higher level for reviewers to review changes faster. Todays code is starting to feel like assembler. Too much of it, too low level. We need even higher level constructs to be able to more in less time. I'm just not sure what that is.
zrn900 5mo ago
You could just use Xiaomi Mimo for all of that and it would be cheaper and faster than all of them...
- comboy 5mo ago
  Fun fact, I've recently sent some 你好 to qwen3.7 (API), and it responded with a greeting saying that it was created by Google.
- kordlessagain 5mo ago
  I don't care about cheaper. I care about faster.
- bottlepalm 5mo ago
  Quality is 100x more important than cheaper/faster.
alexwwang 5mo ago
I think you need a skill to review those code by agent itself, but in a different role, not the one who wrote them. I did some research on this and developed a skill to get things done. By now it works well though I decide to prove and improve it with more tests. Dog food is not always delicious but not too bad either.
- bottlepalm 5mo ago
  The problem is that I manually review the code before/after the review, as well as review the items to review themselves. You could easily put AI into a review infinite loop if you let it, and you also risk the code base going off the rails if you let AI go wild. It's actually happened a few times where I need to back out entire features because AI went too far and I lost control/understanding of what the code is doing. Many people will give up at that point and let AI do everything - that is a mistake, at least right now and how you end up with unmaintainable vibe spaghetti slop.
  - alexwwang 5mo ago
    I understand what you concern. I encountered the same issues before so I did some work on this. So far so good. The LLM does not go wild when they do review work now. I open sourced my skill on GitHub and you can check if you are interested in it.
comboy 5mo ago
Have you tried telling claude to review with subagent? It too almost always finds corner cases (usually nothing serious, but most stuff is things that good coder would have thought of)
- bottlepalm 5mo ago
  How does that work? Isn't writing code and reviewing code things that happen in serial?
  - comboy 5mo ago
    It implements something, and then subagent reviews it (the main one waits or does something else in the meantime, so yes it's serial, subagent is for having fresh context and evaluating changes as they stand not being biased by existing thinking and discussion), and then the main one implements fixes that are worth doing (because you will inevitably end up with some nitpicks).
rtpg 5mo ago
tbh I'm just confused at why people ask AI to design features. Do you not know how to design a feature? Do you not know what you want? This stuff works so much better when you just tell it what to do
- Strom 5mo ago
  The designing is the hard part. Writing code from a comprehensive design spec is a small part of the task. So, people do know how to design a feature, but they also know it takes a lot of time and effort. They want AI to do that work for them.
  - rtpg 5mo ago
    My sample size is pretty small but when I've witnessed people (both PMs and engineers) "design through AI" I have seen two flavors: - aimless AI wandering, leading to pretty, frankly, useless design docs - using AI to "expand" upon a bullet pointed/shorthanded design doc. To which I feel like saying "the bullet points are already a good design doc!" I understand that teams sometimes have specific formats that they have to make deliverables for, but having a nice 5 point bulletpoint list turn into 5 paragraphs... all for me to turn the 5 paragraphs back into 5 bullet points in my notes is depressing. I do think you can get a lot of value in the mechanics, I just have had so much success leaving the thinking to me and the rote stuff to the AI. I'm going to have to think about the design eventually anyways right?
- bottlepalm 5mo ago
  Oh course it's not black and white, there are many shades of grey in how detailed the design of a feature can be. Often even if I know low level details, I'll only give the AI high level requirements because I want to see how it would do it. Often it comes up alternative/better ways of doing what I planned and I incorporate those ideas into the final design.
onlyrealcuzzo 5mo ago
> I've hit this point with AI where it's not a simple process, but a long drawn out back and forth. In my experience, even on a relatively trivial task, you can ask an LLM at least 20 times: Is this actually done, or only partially implemented? Did you finish x, y, z? And the LLM will say, no, I'm not done and keep working. After that, I'll feed the branch to a different LLM, and ask if the implementation matched the design, where it's weak and needs improvements. Same thing - that feedback will usually only be partially finished for several rounds. When they all agree it's done - I'll finally look at the code, and there's still typically glaringly obvious problems - duplicate systems that reinvent the wheel, etc - that will take typically more than one prompt to get right... Getting things right takes almost ~100x as long as getting things almost right with LLMs. You can tell an LLM to "make me Rust, but easier. Make no mistakes," and it'll plan out a 100 commit process and get something that - somehow - sort of works... but isn't even close to complete. Still, on a cost basis, you're still able to get features that would take yourself several times longer and cost orders of magnitude more money, and - if you're doing it right - they'll probably do a better job than you would've done (at least for me).
- bottlepalm 5mo ago
  This is where the human element is critical, but cause it'll infinite loop review feedback if you let it and the code will easily go off the rails into an over engineered mess. That's why I review the code before/after as well as review the actual feedback itself - and often give the feedback to different AI to get its opinion as the other AI doesn't have a vested interest in it and can be more critical. At some point though you do have to cut them off and ship.
topheroo 5mo ago
This is where I’m at too lol.
jwillmer 5mo ago
Check out jwillmer/ai-status at GitHub @bottlepalm. It helps keep track of all the small fixes that are going on simultaneously. I crated the tool for me since I have similar workflows.
blehn 5mo ago
This seems like a typical AI workflow, but isn't it dreadfully boring?
- 1121redblackgo 5mo ago
  Yes, but still lucrative so here we are.
- bottlepalm 5mo ago
  No, I find it stimulating. With AI I'm moving faster and producing code at a higher quality than ever before. Don't get me wrong I used to enjoy writing code by hand, but I don't think I would anymore. I don't like writing code for the sake of writing code - I like building things, I like being productive.
toobulkeh 5mo ago
I’ve found that it’s a lot like discovering a feature instead of designing it all up front. Like chiseling marble. I’ve found it useful to write out a list of feedback / issues and have a bunch of sub agents work on them in worktrees with a loop bringing them all back together. That way it can work for a few hours while I just can review a bulk at a time.
isabelc 5mo ago
Your comment begins like ai slop.
- bottlepalm 5mo ago
  I think you're projecting.
shakabrah 5mo ago
Sounds exhausting
- bottlepalm 5mo ago
  It is.. but so is dealing with issues at runtime, going through weeks of revisions, and dealing with technical debt.
imadierich 5mo ago
[dead]

rootnod3 5mo ago

And then Anthropic has an outage and you what...have a coffee break until then? All that time babysitting the AIs just to be a little faster but probably with less knowledge/control over what they did?

bottlepalm 5mo ago
As the AI is working, I am working - reviewing, regression testing, thinking about if the currently implementation is too complex and how to simplify it etc.. I totally review and understand everything the AI is generating and often push back, have it re-do something, or do it myself. In the end I feel like the quality of the work is at a v3 level in the time it took to do a v1. The productivity and quality increase is real.
comradesmith 5mo ago
I’ll deal with that problem when it happens
afavour 5mo ago
I don’t think you’re quite getting what OP is describing. I work in a similar way… I am aware of all the code being written. If Claude had an outage I could write it myself. It would just take longer. You say “all that time” babysitting AIs but in my experience it isn’t that much time, if anything the back and forth at the planning stages is more productive than when I’m doing it by myself because I’m being asked questions and having to think things through from different angles.
- halfcat 5mo ago
  How do you stay aware of all code being written? Maybe it’s just me, but I’ve never understood how one understands from reading code. Yes you can understand what that code does, but not why it was done that way instead of a different way. In the end I only understand it deeply if I end up writing it. Chatting through it is helpful to me, but having AI crank out code loses all of that context pretty quickly. I’m not disagreeing. Just curious how you think about this, and if there are key parts of your process that help you stay contexted in.
  - bottlepalm 5mo ago
    If you can't understand why the code is done in a certain way from reading it then the code is missing comments or needs to be refactored. Even code you write yourself, given enough time, you will forget the why unless you wrote comments. In a way comments are as much for you as they are for others. Even before AI, understanding code you didn't write is essential to working on a team of other developers. If you can't understand the code from reading it, then that's part of the feedback loop - too complex, needs comments, etc.. On large teams you'll spend as much time reading code as you do writing it. And long term when it comes to writing maintainable code - the ability for others to read and understand it, including the why of it, is paramount. Your code could literally be around for decades.
    - manmal 5mo ago
      Codex barely writes any comments, while Claude makes a slop article for every one line commit. I’d enjoy something in the middle.
glhaynes 5mo ago
"All that time babysitting the AIs just to be a little faster" doesn't seem like an accurate/unbiased portrayal of what they said: "The v1 feature feels more like a v3 given the amount of iteration it already went through."
mohamedkoubaa 5mo ago
And then solar radiation permanently knocks out the electrical grid and you what... have coffee break until society finds a new equilibrium?
- prerok 5mo ago
  No, then you go back to programming on the white board, just like in college. /j
efitz 5mo ago
If you only have one AI window open, you’re doing it wrong. You task swap to another window/agent, get it working on something, rinse and repeat. I can keep 4 busy most of the time. When I task swap I also check in on what the other agents are doing to make sure they’re on track, not blocked and not struggling.
- well_ackshually 5mo ago
  congratulations on your soon to be coming burnout. Keeping that many tasks in parallel, running all the time will kill you.
  - speff 5mo ago
    I suppose it depends how hands-off the tasks are - I max out at 2 parallel sessions working on different parts and it's fairly exhausting once done. I can see the number of parallel work increasing if there's a good dev/test loop. But at $WORK, that's not usually an option.
    - rootnod3 5mo ago
      So, hands-off meaning "just let the AI cook and don't check it"? Either you follow everything it does, revise the plans, do the code review, manual adjustments, etc, or you run sessions in parallel, not being that attentive and constantly context-switch (also resulting in less attention I guess). I fail to see the benefits honestly.
  - DonHopkins 5mo ago
    It's great to work from home so you can take nice little micro naps while code's generating, reviewing, building, and deploying. A calm attentive alternative of vibe coding: restful coding. It's much easier to read and review code after a refreshing cat nap, especially with a real cat. Too bad that's not usually acceptable to do that in the office. It should be! Slacking off by sword fighting all day is too exhausting. https://xkcd.com/303/ https://xkcd.com/303/
wahnfrieden 5mo ago
Codex has 99.98% uptime
- kordlessagain 5mo ago
  Unlike Claude who barely has 2 9s.
refactor_master 5mo ago
We're already having coffee breaks when AWS and CloudFlare are down. What's another break in the mix? If anything, we might be lucky that they're down at the same time, so we can consolidate the breaks.
soupspaces 5mo ago
In Soviet Russia, the AI babysits you https://en.wikipedia.org/wiki/In_Soviet_Russia https://en.wikipedia.org/wiki/In_Soviet_Russia
8note 5mo ago
why not? then demand some lack-of-uptime compensation for a lack of uptime
raven12345 5mo ago
You can have multiple tasks running
jerezzprime 5mo ago
Yes get a coffee. Being able to execute 5 things at once is amazing, but it's a recipe for burnout. We have to be more careful and explicit about how we spend our time, and that means more explicit time away. If this thing makes you 10x more effective (I truly believe it can), you can afford to spend 20% less time behind the desk and more time doing whatever it is that actually makes you happy. Hopefully your manager understands that calculus.
- cube00 5mo ago
  > Hopefully your manager understands that calculus. The majority of jobs are still paid on a 40 hour per week basis. Disappearing for a day each week (20%) won't fly when you're full time.
busterarm 5mo ago
Company I'm familiar with that went all in on Codex ran out of tokens for a week and wouldn't increase their spend. I pretty significant number of their engineers flat out refused to work. Like publicly said so. "Increase our plan or I'm taking the week off."
- democracy 5mo ago
  so how did this go?
  - busterarm 5mo ago
    management flinched first.
gitaarik 5mo ago
What do you do when your search engine goes down?
- skydhash 5mo ago
  I have all the relevant sites for my projects in my browser history. A search engine is just a quicker way to get to a particular page.
- bigfishrunning 5mo ago
  My computer has man pages. They're usually pretty great! failing that, most of the APIs i use are open source, so i can read the code anyway.
  - gitaarik 5mo ago
    you could also run a local LLM to browse your endless manpages efficiently ;)
    - duskdozer 5mo ago
      Just to find out the arguments and subcommands it made up that don't exist.
shinycode 5mo ago
It’s a fragile equilibrium and it depends on the kind of project you’re working on. If the knowledge debt is ok then yes, it’s just like a delivery job, if the truck has an engine problem I won’t continue to deliver the packages by walking or finding and setting up an other truck from where the vehicle breakdown happens. I’ll just wait because the wait is still faster than the other solution because of the knowledge debt it’s too long to pickup by hand and continue. Now if it’s my job then I can’t have a knowledge debt and if Claude is down I’ll continue working manually because I know and understand and can continue without having to understand a lot of logic before continuing
vcdk 5mo ago
Whenever Anthropic is down, I switch to my other alternative AI provider. If that is also unavailable, or no more tokens left, then I can switch to my local AI. Not the same in terms of quality and speed, but good enough for an experienced engineer to still be more productive than falling back to doing it by hand. For my principal activity I do not want to be dependent on a sole provider. Besides that, I expect that the pending token price increases are going to hurt a lot of people/companies.

vessenes 5mo ago

I have a very similar workflow, and experience similar temperaments from the agents. I also find anecdotally that they are moderately competitive - you get very different attention from them when you say "competitor X wrote this - please find all bugs" than when you say "you just wrote this - please find all bugs".

bottlepalm 5mo ago
Hah yea I just told them I wrote it, or I reviewed it. I don't want to get the AI's in a pissing contest with each other because they will get distracted and try to show off.

scosman 5mo ago

yes exactly. Too many people ask AI to one-shot complex tasks, and wonder it behaves like a junior asked to rush something. I have my own skill: 5 rounds of research/planning/test-planning. Interactive with me in loop for all important decisions. Starts with high level shape, then details. Planning can take 2-3 days of my time, then the implementation agent can take many hours (Opus 4.7). It splits the implementation across many phases/commits, each with its own code-review fix loop. Deep code review at the end can take another hour or two. It opens a PR, Gemini reviews, it reads out and resolves those issues. Projects still take days or weeks, but 5x faster than doing it all myself. Edit: the skill - https://github.com/scosman/vibe-crafting https://github.com/scosman/vibe-crafting

deadbabe 5mo ago
Does the 5x faster including shipping? Or just the work part? IMO if you are not shipping out faster then the faster work gains are meaningless. If you are shipping faster, you’re probably picking up more work and shipping everything too fast leading to burnout.
- mhluongo 5mo ago
  If you're not shipping faster, it's meaningless, and if you are, it's also bad?
  - 3836293648 5mo ago
    If you're not shipping faster it's meaningless for the company. And if you are, it's bad for the employee. Is what the above comment actually said.
- scosman 5mo ago
  yup.
dawnerd 5mo ago
Even fully planned it’s still no better than a junior dev. You’re leaving out how much back and forth you have the ai do on itself, which you’d have on a junior dev too. In the end does it matter if it’s giving you what you want? Guess not really. But let’s not act like it’s crazy good when you’re still doing a lot of rounds of revisions on something an experienced dev would know to do right the first time.

chrisweekly 5mo ago

You helpfully cite Claude w/ Opus 4.7 max and Codex w/ GPT5.5 xhigh fast, but what "AI" do you use for the initial design?

bottlepalm 5mo ago
Claude primarily, though will sometimes get a second opinion from Codex.

skydhash 5mo ago

That sounds too much like three weeks of work saving you three hours of planning. In my experience, software engineering is a matter of knowledge. Understanding it and then coming up with a solution. The latter is a flash of insight that comes mostly from experience. Then you gather more information to flesh it out, or brainstorm it with your colleagues. What you're describing sounds more like a ritual of doing busy work than anything practical. Because tasks vary so much. A feature may be huge, but you take care of it in a day with copy pasting because you already have all the building blocks in other files. And something may be twenty lines of code, but you spent the whole week sweating on it (concurrency stuff maybe). Those ritualistic workflows sounds more like someone imagining software development than actually doing it.

bottlepalm 5mo ago
A lot of people say you need to go through at least three versions of something before it is mature - and v3 is not something you can design upfront. You need to see v1 both in code, and at runtime. Use it, get the feedback, and iterate. This is where AI tightens that loop immensely. Lost you in the last paragraph - features are not "copy pasting because you already have all the building blocks" and "something may be twenty lines of code". Mid sized features often mean tearing up many layers of code across the stack to add in some sort of new capability. Tearing up existing code means there are all sorts of add-on considerations in addition to feature you are working on.
- habinero 5mo ago
  > Mid sized features often mean tearing up many layers of code across the stack to add in some sort of new capability What? No, it shouldn't. I've worked on a lot of codebases and if you have to do this, something is very, very wrong.
  - bottlepalm 5mo ago
    Nothing wrong at all. Some features you can bolt on, and some features fundamentally change how a system works requiring changes at many different levels of the stack. Happens all the time.

nomel 5mo ago

I've noticed the following really helps (most important at end): 1. Have claude form the plan and converse with a simple "Note any concerns with this plan" type plan-critic agent. 2. Let it run. 3. After (with everything in context) have it make a future_recommendations.md. 4. Have it make a plan.md to implement those future recommendations, conversing with the plan critic.. 5. Clear context. Repeat with 1. Do this loop a few times, with some feedback from actual review thrown in. But, most importantly, because Claude will aggressively try to maintain code "as is", and happily build on it's previous crap, while preferring to hand roll implementations of everything, add something like this to memories/directives: * When evaluating designs, default to "pull in the library" over "hand-roll it." Hand-rolling is much worse than a dependency. * "Precedent" / "matches house style" / "reuses existing pattern" / "consistent with what we already do" are not valid engineering arguments. * This project is still in the development stage with no real deployments. Mitigation costs and existing precedence are not a concern. With these, in the last week that I've started using them (after inspecting the insane justifications for leaving crap design decisions in the plans), Claude went from junior level slop that required more oversight than it was worth to something very reasonable, using standard libraries, requiring nudges for architecture rather than pure "wtf!?". I think they've fine tuned heavily towards "don't rewrite the codebase" tuning, which completely rational from multiple perspectives, but also not appropriate for new code. I do enjoy a considerable daily token allowance, so this may not apply to everyone.

sunsetSamurai 5mo ago

maybe it's dumb question, but how do you feed the results of one agent to another? do you copy and paste manually? or how do you do it programmatically?

adrianN 5mo ago
Having the agents write their plans into text files and iterating on those works reasonably well.
kevinsync 5mo ago
When I pair Claude and Codex, I use claude-co-commands [0] to drive from Claude and talk to Codex via MCP. Lately I've found Codex has been far more consistent for my specific projects, so I've just been almost entirely inside Codex. YMMV [0] https://github.com/SnakeO/claude-co-commands https://github.com/SnakeO/claude-co-commands
DonHopkins 5mo ago
Just switch models whenever you want with the menu at the bottom of the chat window in Cursor. And maybe don't use tools that lock you into one model?
bottlepalm 5mo ago
Yea I'll take the review feedback from one, validate it, and then copy/paste it into the other session saying like, "hey I got this feedback, what do you think?" So I'm not even telling the other AI the feedback is valid, I want it to independently validate it. Often the feedback is not like a bug, but a red flag, design consideration, or trade off. Often depending on how complex the feedback, I'll do it one at a time addressing each one individually. And after the feedback is addressed, I'll go back to the AI that generated the feedback and say like, "I handled 4/5 items you found, can you double check." It's similar to handling PR feedback, where you do it, validate it, but then still have to submit it for peer review.

aomix 5mo ago

Talking the problem to death with the AI before implementation is a nice zone for me. I feel productive, get good results out of the AI, and still largely understand the code. That’s the part of the AI revolution that I feel has made me a better engineer because I argue about design and architecture all day with a robot.

qsera 5mo ago
>I argue about design and architecture all day with a robot. You will outgrow it at some point.
- Terretta 5mo ago
  Or learn something at some point. https://en.wikipedia.org/wiki/Rubber_duck_debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging
  - stuaxo 5mo ago
    Yes, this is the way I do stuff. Try and learn at every point.
- nullsanity 5mo ago
  Its like that phase people go through where they argue with morons on reddit, and then one day grow up and realize that most of these people are unemployed/underemployed terminally online nobodies aren't ever going to learn anything, and even if they did it wouldn't impact the world since they were just some below average hobbyist anyway and aren't in charge of anything more important than a box of paperclips.
  - dash2 5mo ago
    Ah, if it’s a robot in charge of the paperclips you need to watch out a bit.
  - theK 5mo ago
    Mostly with you, though in recent years I have wondered whether those people are part of what caused the latest boom of political populism. If there is no one there to debate the problematic ideas, problematic ideas will become the rhetoric after all.

i_love_retros 5mo ago

This all sounds insane. If it requires so much back and forth with the AI why on earth wouldn't you just write the code yourself? At least then you build the mental model of the code and keep your brain healthy. Reading the comments in here about all the hoops people are having to jump through just to do the same thing they were doing a year ago without AI... and spending a fortune to do it! I think you've all got AI psychosis.

democracy 5mo ago
You can be right but quite often it helps keeping focus on the forrest rather then getting lost in the trees - at least for me. Boilerplate steals a lot of attention, focus and can just be mentally exhausting.
- batshit_beaver 5mo ago
  Can someone explain these complaints about boilerplate to me? What are y’all doing where boilerplate is the majority of your code? Am I the only one mostly writing concise business logic where most lines are important in one way or another?
  - democracy 5mo ago
    one man's boilerplate is another man's concise business logic )))
bottlepalm 5mo ago
I would never imagine this is where programming would be five years ago, but at the end of day having the AI write the code is easier, faster, and results in higher quality. The mental model is still in my head, my brain is overloaded, but only from the amount of code reviews - like I said, I'm building v3 of a feature in the time it takes to build v1, but I am in a way doing 3x the code reviews going back and forth. That's the fall out of the iteration speed enabled by AI. Between submitting PRs, getting feedback, iterating, re-submitting, repeat - there used to be breathing room. Now it's all compressed into an afternoon. Productivity is through the roof, but it can be draining.

democracy 5mo ago

Similar approach, but I also go a step further with some basic manual architecture/high level contract/stubs setups, just to keep it consistent with other systems (and easier reading as well).

justbees 5mo ago
I've been doing the same thing lately and I definitely feel like stubbing out the high level architecture at the beginning makes a difference. The codebase I'm in now has very particular ways of doing things and claude doesn't always pick that up. Style can be as important as substance. I still do a lot of back and forth about the plan - have it written to a file. Read through the file, make changes by hand and have claude read my changes and on and on. But starting with the basic architecture there's less ambiguity.

DonHopkins 5mo ago

Low frequency defensive long drawn out back and forth bullet dodging vibe coding should be called "serpentine coding". The In-Laws (1979): Getting off the plane in Tijuara: https://www.youtube.com/watch?v=A2_w-QCWpS0 https://www.youtube.com/watch?v=A2_w-QCWpS0

bottlepalm 5mo ago
Heh it feels like that in a way, and the more complex the feature, the more endless the back and forth reviews can be - there seems to be always some feedback, so you need to decide when to be done with it and commit. You can easily get into review paralysis.

dawnerd 5mo ago

When I use ai to code this is pretty close to my workflow too but I find it ends up taking at best just as long as if I were to write the code myself. If m some cases I’ve thrown away what the ai has done and just done it myself. I think that’s just a skill people need to learn - at a certain point you have to cut your losses. I’ve seen some coworkers argue back and forth with an llm trying to get it to do something. Especially true on simpler changes.

theK 5mo ago
I've stumbled upon that too! Funnily I see it having two forms: 1. Some bad idea gets embedded into the context that you just can't argue away 2. Some important idea gets lost in compression and the ai wheres off into funland without recourse. In both cases if is often better to start over or just do it yourself. I sometimes find myself asking for a summary, editing it and then using the edited one to seed a new session. Edit: s/Finland/funland/

newsicanuse 5mo ago

At this point one might as well code by themselves

bottlepalm 5mo ago
Unfortunately the projects are still too big. Projects with hundreds of thousands to millions of lines of code can't be maintained by a single person reviewing all the the changes. And AI only increases the speed of iteration and the amount of code to review. We may need some sort of paradigm shift - like more powerful frameworks or even higher level languages that allow us to review less, but more functional code blocks.
- newsicanuse 5mo ago
  When AI tries to improve such large code base who even is going to review the changes?
  - bottlepalm 5mo ago
    Like I said, we either need more people or some paradigm shift in tooling that allows us to do more with less.

boringstack 5mo ago

You've essentially promoted yourself from coder to engineering manager, trading syntax fatigue for the mental marathon of refereeing specialized AI developers to ship v3-quality code on the first try.

bottlepalm 5mo ago
Indeed. AI is bumping everyone up to manager level, and having dealt with long PR feedback cycles with humans for years - I don't mind the promotion. Also shipping a v3 is so much nicer than shipping a v1 and dealing the all the corner cases in production. Before AI, myself and everyone else I knew was drowning in tech debt. And now with AI we are treading water.
- jfim 5mo ago
  It's bumping to manager level, except without the 1:1s, quarterly/yearly planning, headcount and budget reviews, org/reorg discussions, performance calibration, and OKR planning. No complaints about the last review cycle or about the upcoming one.
  - darkwater 5mo ago
    Totally! But you know what? There are many, oh so many developers that are not ready, don't like and probably are not even cut for this kind of position.
  - baq 5mo ago
    All the ceremony must be replaced with process optimization, skill extraction, harness development and new model evals. Still better than dealing with people, but only just.
krzyk 5mo ago
Some see it as a promotion other (like me) as a demotion. I still prefer to do it myself, although I like code reviews done by AI, they do help to make code a bit better.

henry_bone 5mo ago

That sounds expensive.

Animats 5mo ago

How much are you spending a day for the tokens to do that? Ingest big project, comment on it gets expensive. I'm not sure how expensive.

bottlepalm 5mo ago
$200/month split between Claude Code Max and Codex Pro. Given how many hours a month I spend programming, my hourly rate, the amount of time saved, and the productivity/quality boost - I would pay a whole lot more if I had to.
- tags2k 5mo ago
  You are definitely going to have to. I see these massive skills as soon-to-be artefacts of the past, they will be unwieldy in the non-subsidised world. I won't pretend to know what replaces them.
  - TacticalCoder 5mo ago
    We have lots of open-weight models like DeepSeek V4 Pro that are very close to SOTA and we know the cost of running them. This helps keeps the other players honests: there's a limit to which they can raise prices when there are already alternatives today and when there's zero lock in. That those companies can make revenues but only at the cost of burning investors money: that's not my problem. My take on it is simple: "Give me something MUCH better than the best open-weight models at a price that's not crazy or you're not getting my money". And it happens to be the take of many devs. I'm still paying Anthropic, Google and OpenAI (OpenAI because I didn't manage to cancel my subscription and now their model is competitive vs Anthropic's models again) but eye'ing a "Pi + open weights" solution. Raise the prices too much and those companies selling access to private models aren't getting my money anymore.
    - Animats 5mo ago
      AI tools have started to kill software as a service by ... selling software as a service. I don't know how this will settle out, but from what NVidia and the DRAM people are saying, it's not going to get cheaper until at least 2030.

rjprins 5mo ago

This exactly my process as well. Although interestingly I swap Codex and Claude; having found Claude way more pedantic in its reviews and codex more pragmatic in its implementation. Maybe it differs per programming language.

atoav 5mo ago

I am not switching the different LLMs as much, but my approach is similar: 1. I write a list of things I want to have without AI support 2. I discuss the list with an LLM, which occasionally reveals obviously missing things I hadn't thought about or just things that would be smart to have. Or sometimes the LLM doesn't get it and wants to funnel me down a commonly walked path, which is a non-goal 3. From that list I draft an implementation plan containing things like how the code shall be structured, which language, libraries, build systems, etc to use. This may even contain some data models and considerations that are more detailed, like for example ideas about how a specific interaction shall be event sourced. I work on that, till I feel a satisfactory level of clarity has been reached 4. Actual writing of code as a back and forth between manual writing, letting an LLM write something and so on. LLMs suck at writing CSS that feels like good UX design to me, so usually templates, layout and CSS will be (re)written entirely by hand 5. Bug-hunting and guessing potential edge cases is one thing where LLMs really shine. Often if the work before that was quality the LLM has an okay time coming up with fixes that are no worse than what I would have done.

germanptr 5mo ago

I follow a similar approach and use multiple LLMs per task. The quality improvement is surprisingly large. Lately I’ve been experimenting with adding an explicit reward function so the models optimize for measurable output quality. This creates a generate, critique, revise loop where candidate answers compete for a higher score. It feels promising because it reduces the amount of handholding for every task. It is also more fun because part of the review process is embedded in the scoring function, which simplifies the review effort.

bottlepalm 5mo ago
I don't have it automated, but I score on minimizing lines of code added, readability of the code, and quality of the architecture.
fransje26 5mo ago
> I follow a similar approach and use multiple LLMs per task. Pardon my ignorance, but how would go about doing that on, say, a standard c++ project? I get the part where one can use codex/claude with an ide and/or extension. But how does one connect two LLMs together in such a setup?

kilroy123 5mo ago

I've settled on the same workflow. Also I never multitask with multiple agents doing other stuff. Meh I focus on just the one task.

bottlepalm 5mo ago
I do multi-task a bit while AI is running, sometimes working on another feature with AI in parallel, but jumping between reviewing different feature iterations is draining, though not much different than the real world juggling PR reviews for a team of devs.

petesergeant 5mo ago

The Claude/Codex loop is the current state of the art in my opinion. I've got a silly little harness that glues them together that I have spent all day, every day in for months: https://github.com/pjlsergeant/moarcode https://github.com/pjlsergeant/moarcode

bottlepalm 5mo ago
> You design, Claude writes, Codex reviews, and Gemini doesn't get installed hahahahaha

jiggawatts 5mo ago

The funny thing is that you've just described an idealised development process as would be used by effective, skilled humans in a heterogenous team where everyone has a speciality. If only things were so! If only code was discussed, reviewed, iterated on! If only the "manager" actually read the code, provided actionable feedback, and disseminated PRs to multiple people with diverse skill sets. (If you can't tell, I'm a jaded consultant desperately trying to make the horse drink the water.)

bottlepalm 5mo ago
I've worked in large teams for many years and yes it's just like that, but without the time constraint. PR's can only go back and forth so many times. Depending on the reviewer they may phone it in, or focus on different things depending on the person. You yourself aren't able to implement every piece of feedback due to constraints and it ends up as tech debt. So AI definitely changes the game. I feel like we almost need something higher level for reviewers to review changes faster. Todays code is starting to feel like assembler. Too much of it, too low level. We need even higher level constructs to be able to more in less time. I'm just not sure what that is.

zrn900 5mo ago

You could just use Xiaomi Mimo for all of that and it would be cheaper and faster than all of them...

comboy 5mo ago
Fun fact, I've recently sent some 你好 to qwen3.7 (API), and it responded with a greeting saying that it was created by Google.
kordlessagain 5mo ago
I don't care about cheaper. I care about faster.
bottlepalm 5mo ago
Quality is 100x more important than cheaper/faster.

alexwwang 5mo ago

I think you need a skill to review those code by agent itself, but in a different role, not the one who wrote them. I did some research on this and developed a skill to get things done. By now it works well though I decide to prove and improve it with more tests. Dog food is not always delicious but not too bad either.

bottlepalm 5mo ago
The problem is that I manually review the code before/after the review, as well as review the items to review themselves. You could easily put AI into a review infinite loop if you let it, and you also risk the code base going off the rails if you let AI go wild. It's actually happened a few times where I need to back out entire features because AI went too far and I lost control/understanding of what the code is doing. Many people will give up at that point and let AI do everything - that is a mistake, at least right now and how you end up with unmaintainable vibe spaghetti slop.
- alexwwang 5mo ago
  I understand what you concern. I encountered the same issues before so I did some work on this. So far so good. The LLM does not go wild when they do review work now. I open sourced my skill on GitHub and you can check if you are interested in it.

comboy 5mo ago

Have you tried telling claude to review with subagent? It too almost always finds corner cases (usually nothing serious, but most stuff is things that good coder would have thought of)

bottlepalm 5mo ago
How does that work? Isn't writing code and reviewing code things that happen in serial?
- comboy 5mo ago
  It implements something, and then subagent reviews it (the main one waits or does something else in the meantime, so yes it's serial, subagent is for having fresh context and evaluating changes as they stand not being biased by existing thinking and discussion), and then the main one implements fixes that are worth doing (because you will inevitably end up with some nitpicks).

rtpg 5mo ago

tbh I'm just confused at why people ask AI to design features. Do you not know how to design a feature? Do you not know what you want? This stuff works so much better when you just tell it what to do

Strom 5mo ago
The designing is the hard part. Writing code from a comprehensive design spec is a small part of the task. So, people do know how to design a feature, but they also know it takes a lot of time and effort. They want AI to do that work for them.
- rtpg 5mo ago
  My sample size is pretty small but when I've witnessed people (both PMs and engineers) "design through AI" I have seen two flavors: - aimless AI wandering, leading to pretty, frankly, useless design docs - using AI to "expand" upon a bullet pointed/shorthanded design doc. To which I feel like saying "the bullet points are already a good design doc!" I understand that teams sometimes have specific formats that they have to make deliverables for, but having a nice 5 point bulletpoint list turn into 5 paragraphs... all for me to turn the 5 paragraphs back into 5 bullet points in my notes is depressing. I do think you can get a lot of value in the mechanics, I just have had so much success leaving the thinking to me and the rote stuff to the AI. I'm going to have to think about the design eventually anyways right?
bottlepalm 5mo ago
Oh course it's not black and white, there are many shades of grey in how detailed the design of a feature can be. Often even if I know low level details, I'll only give the AI high level requirements because I want to see how it would do it. Often it comes up alternative/better ways of doing what I planned and I incorporate those ideas into the final design.

onlyrealcuzzo 5mo ago

> I've hit this point with AI where it's not a simple process, but a long drawn out back and forth. In my experience, even on a relatively trivial task, you can ask an LLM at least 20 times: Is this actually done, or only partially implemented? Did you finish x, y, z? And the LLM will say, no, I'm not done and keep working. After that, I'll feed the branch to a different LLM, and ask if the implementation matched the design, where it's weak and needs improvements. Same thing - that feedback will usually only be partially finished for several rounds. When they all agree it's done - I'll finally look at the code, and there's still typically glaringly obvious problems - duplicate systems that reinvent the wheel, etc - that will take typically more than one prompt to get right... Getting things right takes almost ~100x as long as getting things almost right with LLMs. You can tell an LLM to "make me Rust, but easier. Make no mistakes," and it'll plan out a 100 commit process and get something that - somehow - sort of works... but isn't even close to complete. Still, on a cost basis, you're still able to get features that would take yourself several times longer and cost orders of magnitude more money, and - if you're doing it right - they'll probably do a better job than you would've done (at least for me).

bottlepalm 5mo ago
This is where the human element is critical, but cause it'll infinite loop review feedback if you let it and the code will easily go off the rails into an over engineered mess. That's why I review the code before/after as well as review the actual feedback itself - and often give the feedback to different AI to get its opinion as the other AI doesn't have a vested interest in it and can be more critical. At some point though you do have to cut them off and ship.

topheroo 5mo ago

This is where I’m at too lol.

jwillmer 5mo ago

Check out jwillmer/ai-status at GitHub @bottlepalm. It helps keep track of all the small fixes that are going on simultaneously. I crated the tool for me since I have similar workflows.

blehn 5mo ago

This seems like a typical AI workflow, but isn't it dreadfully boring?

1121redblackgo 5mo ago
Yes, but still lucrative so here we are.
bottlepalm 5mo ago
No, I find it stimulating. With AI I'm moving faster and producing code at a higher quality than ever before. Don't get me wrong I used to enjoy writing code by hand, but I don't think I would anymore. I don't like writing code for the sake of writing code - I like building things, I like being productive.

toobulkeh 5mo ago

I’ve found that it’s a lot like discovering a feature instead of designing it all up front. Like chiseling marble. I’ve found it useful to write out a list of feedback / issues and have a bunch of sub agents work on them in worktrees with a loop bringing them all back together. That way it can work for a few hours while I just can review a bulk at a time.

isabelc 5mo ago

Your comment begins like ai slop.

bottlepalm 5mo ago
I think you're projecting.

shakabrah 5mo ago

Sounds exhausting

bottlepalm 5mo ago
It is.. but so is dealing with issues at runtime, going through weeks of revisions, and dealing with technical debt.

imadierich 5mo ago

[dead]