| ▲ | planb 3 hours ago |
| I have good results with this prompt after every larger change: Now do a final code check. Is everything tidy and do the components adhere to the principle of separations-of-concerns. Is everything in an understandable and maintainable state? Do we make any assumptions that may not be true anymore? Is any code left over from previous edits or experiments that does not belong into the codebase? Is the documentation still representing the current state of code? |
|
| ▲ | Benjammer 2 hours ago | parent | next [-] |
| I usually just say “make sure this code is professional and ready to deliver as a senior engineer” and it usually infers all that stuff you said plus more things as well. I try to give it the goal and let it decide what to do. One thing I usually keep having to point out directly is to remove all “progress tracking” code comments and make sure all comments are appropriate for long term maintenance in the code base. Claude tends to leave comments like “button click causes save now, no longer uses onBlur” when the code really never used onBlur, that was just a thing Claude wanted to do earlier in the same task/branch and I redirected it at some point. |
| |
| ▲ | mnicky 2 hours ago | parent [-] | | For things the agent forgets to obey often, at least in Claude Code, there are also "output styles" that are more deeply embedded - into a system prompt - and agent is also periodically reminded of them during the session: https://code.claude.com/docs/en/output-styles I haven't used them so far but maybe these would work better than basic instructions for such cases. | | |
| ▲ | hungryhobbit 2 hours ago | parent | next [-] | | In practice output styles are just more context (equivalent to CLAUDE.md or memory) ... but with a slightly increased weight. | |
| ▲ | sznio an hour ago | parent | prev [-] | | didn't know of that. I'll switch it to learning mode at work, wondering how long it's going to last. |
|
|
|
| ▲ | Ancalagon 2 hours ago | parent | prev | next [-] |
| Just pull the slot machine lever |
| |
| ▲ | senordevnyc 2 hours ago | parent [-] | | Yeah, I miss the days of having perfectly deterministic humans writing our code. | | |
| ▲ | jplusequalt an hour ago | parent [-] | | >Yeah, I miss the days of having perfectly deterministic humans writing our code If most people by your account are subpar programmers before AI, why do you believe they'll suddenly be better with AI? Also, these comments always come off more than a bit anti-social. It's like hating your coworkers correlates strongly with AI-adoption. |
|
|
|
| ▲ | RALaBarge an hour ago | parent | prev | next [-] |
| I like to also compliment the model on its very fashionable shoes as well, they love the flattery. |
|
| ▲ | cyanydeez 3 hours ago | parent | prev | next [-] |
| good, but this is just a verbose "make no mistakes"; it'd probably make more sense to just setup a nightly cron job that loops through the prior days' work and writes some morning tasks of the same character. The models will interpret this willynilly; but nonetheless, it's often a better than doing nothing. |
| |
| ▲ | weitendorf 2 hours ago | parent [-] | | It means the same thing to you, but not to the whole spectrum of people using AI. You literally see it on Reddit all the time where people are complaining about the same model either over-engineering or doing too much, vs it being requiring too much steering or not being autonomous or capable enough to hand off tasks to on its own. The reason prompting it to review its own work for loose ends, record any new undocumented or noteworthy behavior, suggest changes to tests/processes to make it go more smoothly the next time, etc is that it’s prescriptive and process-oriented (and thus easily verifiable/done in-context) rather than descriptive and outcome oriented (which to do properly could require way more context than the model has, because it doesn’t know what it doesn’t know about your particular work, only what it’s seen so far). Even promoting it to do these after-the-fact vs as an upfront requirement can have a big impact IMO. If you make “maintainability” part of the task before it’s seen the real work it will focus on general “best practices” crap rather than the real work, so either way if this is something you care about it doing you have to give it guidance for how you want it done. If you were to review the logs of a model after the fact, you’d also not really save on input tokens unless you compressed the context or sharded it out, which can easily miss the small details that constitute the difference between “what actually happened” vs “how the LLM models this general class of problems” unless the first pass involves the entire context anyway. That said I do think there’s a lot of value in building some kind of pipeline for validating and aggregating these “learnings” across sessions. | | |
| ▲ | cyanydeez a minute ago | parent [-] | | the problem is when you ask it to review it's own work in it's own context is you've already primed it to sniff it's own farts and say everythings fine. |
|
|
|
| ▲ | chopete3 3 hours ago | parent | prev [-] |
| This is a good example of AI native thinking. Teach AI everything and ask it if it has learnt throughly learnt. The results are surprisingly good. I am following similar steps from this article
https://www.lucasfcosta.com/blog/backpressure-is-all-you-nee... |