Post

Jon Klaric
Jon Klaric@complex_maths·
I think not reading the code *can* be okay in certain limited circumstances *IF* you have excellent test coverage and probably an example/previous implementation too. But yeah, we’re not at the point where we can trust full agentic development (and even if the models are good enough, most people aren’t that good at specifying precisely what they want yet).
English
1
0
1
151
Denislav Gavrilov
Denislav Gavrilov@kuberdenis·
@dreamsofcode_io i think keeping an eye out for how the structure looks is mostly enough: file names, directory structure, diff sizes and when something starts looking off, explore immediately
English
2
0
3
258
Lyf
Lyf@LyfsDiary·
@dreamsofcode_io Autonomous junior dev works provided you're acting as the senior dev and scrutinising the code thoroughly. Kinda like mentoring the dev. It won't work if you're acting as the client.
English
1
0
1
39
Lumyo
Lumyo@LumyoDev·
@dreamsofcode_io This started as a reply to you but ended up being it's own long post lol
Lumyo@LumyoDev

I've been treating AI work from the beginning as the work of an intern, and that has worked out pretty well. Sometimes if the feature is complex I first do a pass of light scaffolding where i start to structure the code how I want it, and leave placeholders. LLMs thrives around structure, as they are designed to recognize patterns. From my experience, if you design a whole new feature and the AI can't really find proper structure around it in your codebase, result quality will be much lower. I then make Codex do most of the implementation work, and do a very light review myself, to make sure the code is not unnecessarily bloated. If codex doesn't structure the code the way I imagined and I can think of a more efficient way to do it, I'll guide it. Then in a new session I ask codex to review the changes compared to the base branch, most of the time he will find issues, in which case I make him fix what's worth fixing, always making sure the fix doesn't lead to unnecessary bloat through a very light review I then trigger a new review in a new session, and keep repeating this until there are no more issue worth fixing. When codex is done fixing issues, I then usually make Claude do a pass of review. Claude is usually much more nitpicky and often a lot of his findings are not really worth fixing. So I feed the output to Codex, and ask it to review what is valid and worth fixing. In some case, it will highlight a valid problem than Claude found and Codex missed. Once all those steps are completed and both Codex and Claude don't find any meaningful issue anymore, I'll do a manual very in-depth review myself, in the same manner I would review the PR of an intern. Then another person from the team will also do another pass of manual review on my PR before it is merged. Ultimately, I think it also depends on what type of software you are working. I could probably live with few less pass of reviews that I am currently doing if I wasnt working on a financial app like @KyanExchange where there is no room for mistake.

English
1
0
3
246
homeserversltd
homeserversltd@homeserversltd·
@dreamsofcode_io Wrangle them pneuma! As many juniors at it takes! Throw them on the heap until it works as intended! We will use as many bodies as it takes
English
0
0
0
15
ZerdaluWorks
ZerdaluWorks@zerdaluworks·
@dreamsofcode_io Is it even possible to establish true mental alignment between a human and AI? AI has no shared history with you. It doesn’t know your experiences, instincts, or how you arrive at solutions.
English
0
0
1
28
sam
sam@metruzanca·
@dreamsofcode_io My autonomous junior has messed up migrations one too many times in side projects. Especially when it comes to generating timestamps for run order.
English
0
0
1
32
Dinuka
Dinuka@desilvakdn·
@dreamsofcode_io autonomous agent hype skipped the part where someone still has to own the output
English
0
0
2
73
Paylaş