Acknowledge the problem, don’t just solve the solution.
Out there exists a problem, and to solve that can exist a number of solutions. You might create a solution that best fits your vision. But as you can see, the inherent reality is that solutions are trivial. They can be substituted for another solution. And a solution can exist without any usage or adaptation of it. Like a way to prove a theorem that no one uses and defaults to using other proofs.
So when you are creating software to solve a problem or to address any yearning that the customer has, you have to understand that you can create a solution that is absolutely correct, but it might not have any usage or adaptation.
The least potent and worst-performing solutions are ones that are solutions for the sake of being a solution. They want to just solve the problem instead understanding it too.
That’s what happened with Rohkun. Where I am trying to fix problems that occur in your codebase when you code like a degenerate using AI tools. Those problems would have never occurred if you were a disciplined coder. The solution I gave requires people to use the map that Rohkun creates and act like disciplined coders. We did all that just to not address the primary bottleneck: the user themself is not acting properly.
So you need something that will work despite the user being a degenerate. You have to remember the classic joke that the error is sitting between the keyboard and chair. Nothing’s wrong with the software or hardware. You have to solve for the user’s behavior and the problem that is there.
See the person you are selling the product for has a problem because of the specific context that they have around them. Just because they entered your product’s boundary does not mean that context has changed. And if your product acts as a solution for a different context than which the person using the app is in, then you are going to have absolutely abysmal usage and adaptation.
Thus, with a surface-level understanding of the problem, you will just create any solutions. You have to seek deeper knowledge about the problem and the context surrounding it. What exactly led to it? What are the first principles behind it?
If it is a messy workflow, then is it because there are untrained users? Is it because their keyboards are broken? Is it because they are too busy to type out? You can create any type of workflow optimization software, but here the only software that will be successful is one that acknowledges this reality and designs itself accordingly.
The problem exists within a context that won’t disappear just because your product shows up. Your solution/product has to address both the problem and the context, and for that, you need to have a deep understanding of your ICP.
You cannot say that if the user does that, if the user does this, if the user educates himself, if the user follows the SOP, if, if, if, so many if’s. Reminds me of Megumi, the potential man.
Develop your solution for what ‘is’ and expect zero changes from the side of your user, and yet make it all work.
Keyboards can be an example where they know you cannot always type correctly, you are going to have spelling mistakes. The keyboard on its own is technically enough, but surrounding the context around the user, it’s not enough. That’s why we have autocorrect. AutoCorrect accounts for your inability to always type correctly, and thus makes the keyboard application actually fit for your problem. Thus, has high adoption and usage. Still used more than speech-to-text.
Its like you need special equipment to ski, you sell skiing equipment but they are not the size of customer nor their style. you have the solution but its not for them. Or how you make tshirts but it has the sports team they hate, so even with the need of tshirt it is incompatible with them
From Claude
The Context Doesn’t Disappear
Your point about context persistence is crucial. When someone uses “AI tools like a degenerate,” they’re operating in a context of:
- Time pressure (why they’re using AI to go fast)
- Lack of systematic thinking (why the code becomes messy)
- Probably solo work or weak code review culture
- Optimizing for shipping over understanding
A solution that requires them to “just be disciplined” is asking them to exit their context. They can’t. That context is why they have the problem.
The Actual Problem Architecture
The real problem isn’t “codebase is messy.”
The real problem is: “A person under time pressure, using AI to move fast, with weak systematic thinking, creates unmaintainable code—and then cannot navigate or fix it because they never understood it in the first place.”
Your solution required the bottleneck (the user’s behavior) to change. It required them to:
- Stop and study the map
- Develop discipline they don’t have
- Change their workflow
But they’re still under time pressure. Still optimizing for shipping. Still the same person. The context that created the problem is unchanged.
What a Real Solution Looks Like
A real solution would work despite the user being “a degenerate.” It would:
- Expect zero behavior change from the user
- Work within their existing chaotic workflow (fast AI-assisted coding, minimal planning)
- Compensate for their lack of discipline rather than requiring it
- Make the right thing the easiest thing in their actual context