The four heights
The same task, four distances: today's deadline, the next reviewer, the stuck moment, the pattern.
Execute — do the immediate task
+Refactor the input-event handler that accumulated 1,200 lines in player_input.cpp. Extract clear…
Execute — do the immediate task
+Refactor the input-event handler that accumulated 1,200 lines in player_input.cpp. Extract clear subfunctions, keep behavior identical, and send the cleaned file to Noor in QA and to me for integration testing. Do the refactor in small commits and verify unit tests pass; aim to finish by Wednesday.
Pasted it? When the reply comes back, push once: ask it to sharpen the weakest part. — Did this prompt help?
Improve — make it easier to accept
+Before I hand the refactor to Noor in QA, make it easy to approve — preserve the public function…
Improve — make it easier to accept
+Before I hand the refactor to Noor in QA, make it easy to approve — preserve the public function signatures, add a brief header that explains responsibilities of each new helper, surface the single behavioral change (if any) up front, and mark any edge cases that would make a reviewer hesitate to approve.
Pasted it? When the reply comes back, push once: ask it to sharpen the weakest part. — Did this prompt help?
Decide — diagnose the stuck moment
+I opened player_input.cpp and found 1,200 lines of intertwined logic handling game, UI, and debug…
Decide — diagnose the stuck moment
+The input handler has become a fragile 1,200-line monster
I opened player_input.cpp and found 1,200 lines of intertwined logic handling game, UI, and debug input. I’m worried that extracting helpers will change timing and break exotic key combos players use. I don’t know which pieces are safe to pull out first. What should I extract first to lower risk and how do I validate I didn’t alter behavior?
Pasted it? When the reply comes back, push once: ask it to sharpen the weakest part. — Did this prompt help?
Become — change the pattern
+We keep ending up with huge, fragile functions after every feature sprint because developers patch…
Become — change the pattern
+Large functions keep returning after quick fixes
We keep ending up with huge, fragile functions after every feature sprint because developers patch behavior quickly for deadlines. I spend time repeatedly refactoring the same file. Which habit should I change across the team to keep code decomposed, and what simple rules for PRs and code reviews will stop monolithic growth?
Pasted it? When the reply comes back, push once: ask it to sharpen the weakest part. — Did this prompt help?
Next to this one
Other programming language work people do in C++.
Every task here came from the work, not from a feature list — which is why the prompts name what you want done and never the button that does it. The tool changes; the work does not.
Copyright © LLOS.ai · 2026 — original pedagogy, voice, and design — all rights reserved.
The rest of the map
Same library, five ways in.