Pain and victory over AI. In an attempt to make my own online service, I found a way to save on tokens and keep the code clean.
After trying to make different mobile applications, testing them on my phone, and so on, I still couldn't achieve what I wanted, and in some places I even got confused about the functionality and user scenarios. And I realized that in order to get something of more or less high quality, which you can then work with precisely, and perhaps with pens, you need to set instructions very precisely and limit the agent's imagination. And how do I set the exact instructions if I'm completely zero in mobile development? Well, yes, to ask the AI... but what to ask? In general, there are more questions than answers. At first, I tortured the AI to write me precise instructions indicating all the functionality, etc. that I wanted to see in the application. He did the job I thought he would, he wrote beautifully, a lot, intelligently, I didn't even understand half of it. Then I fed it all to TRAE in the form of promts and instructions and received another variation on the theme of my application.
After several attempts, I decided to look carefully for a tool that would allow me to at least visually design an application, so that based on this visualization I could explain to the AI what I want from it in principle, without paying attention to the technical aspects of the implementation. And it's much more convenient for me to look at the user flow with my eyes, rather than reading the descriptions and keeping everything in mind. I searched for a long time and painfully, but all the time I came across either an all-in-one harvester (for a lot of money), or Obsidian-type text notes, which are also very versatile, but not the same. Yes, there is Figma, and you can do something there: interactive, beautiful presentation to the customer... And then what? In the real world, first TK, then Miro or an analog to spread out the screens and look at the user flow, then design, and only then code, tests, and so on. I even tested their AI in Figma and tried to make a web application (on a free tariff, you can indulge once). On my test, he made a working front and even wrote something to the database, but with jambs, and then repaired the backend himself and merged all the tokens in half an hour without fixing anything. Let Figma remain a tool for design and prototyping, and not a combine harvester, as they are trying to make it now, I'm sorry, it hurts.
After eating all this, I came up with an idea. If something is missing, it must be done. Naturally, I started from the beginning: I just described what I want, how I see it, and how it should work. It was about a web service for generating rules, on the basis of which any model should program as much as possible within the framework, and I will depict what and how to program visually and schematically. In general, the idea is simple: We draw the screen elements on the canvas, connect them with arrows (custom flow) and click the "Export" button. At the output, we get a set of rules for a specific application: a description of screens, elements, and transitions between them. I won't describe exactly how I achieved this, but something worked out, and everything works without using third-party services in the rule generation process. It looks like this:
visual canva of my mobile rules
And in the process of creating it, I stepped on the same rake. Everyone who codes using AI, no matter where: in Trae, Cursor, or through Claude Code, knows the main "secret" of neural networks.: they get incredibly dumb over a long distance. They do a great job with one or two requests at the start (I'm talking about mobile apps, not the web), but as soon as you start to add functionality, that's it. On the tenth day, when the project grows, the AI begins to have "amnesia". You open a new chat, the old one has already run out of context, and the AI begins to reinvent the wheel. She doesn't know what you agreed on yesterday! Finds the first similar piece of code, inserts it there, runs the tests. Everything looks OK. In fact, there are three icon libraries, one huge main file where all the code is piled up, and a lot of small files that solve local problems, but are poorly related to global ones. The usual "write clean code" promptings no longer work. Universal sets of rules from the Internet don't help either. And this applies to any model where something more is being done than a five-page website or a mobile application.
And that's what I did when, after a couple of weeks, the AI started to move away so much, and the code grew so much that there was no trace left of the original agreements and I had to poke my nose at each new session so that he absorbed the project and could continue.
"An ingenious solution." I have rigidly prescribed in the IDE rules that as soon as the model changes something in the code or logic, it immediately writes or updates it in the MVP specification. It really saved my life.: I no longer had to explain the logic of new tasks every time. Yes, it eats up tokens, but as practice has shown, more tokens are consumed on refinements and reading of the entire code as the project grows than on studying brief instructions about the code and mechanics. The model herself ran into the rules, then into the specification, and in 10 seconds she knew the whole project by heart! I implemented the same technique in the rules that are generated for mobile applications, and taking into account the choice of a specific model. So I highly recommend that you create such a file and register this skill. I had an IDE rules file, almost standard, from the Internet, and now it's almost 300 lines of unique instructions, and the most important ones are:
## Specification Maintenance Rule
When product behavior changes, update the specification in the same work cycle.
After every code change that affects runtime behavior, model shape, validator behavior, export output, UI semantics, or catalog choices:
1. immediately check which specification files are affected
2. update those specification files in the same task before considering the work finished
3. do not leave spec follow-up as an optional later cleanup step
Update these three reference files first:
1. `Specification/12_element_reference.md` for element behavior, props, actions and panel nuances
2. `Specification/13_screen_and_modal_reference.md` for screens, modals, connections and flow rules
3. `Specification/14_project_settings_reference.md` for settings, services, permissions and export-sensitive configuration
If the change also affects core runtime contracts, update the matching base files too:
- `Specification/2_model_data.md`
- `Specification/CURRENT_SCOPE.md`
- `Specification/6_ui_and_canvas.md`
- `Specification/catalog/mvp_function_catalog.md`
Do not leave new runtime behavior documented only in code or only in chat history.
Before changing action logic, validation, export-sensitive behavior or panel semantics, re-read the matching reference files first instead of reconstructing rules from memory.## Specification Maintenance Rule
When product behavior changes, update the specification in the same work cycle.
After every code change that affects runtime behavior, model shape, validator behavior, export output, UI semantics, or catalog choices:
1. immediately check which specification files are affected
2. update those specification files in the same task before considering the work finished
3. do not leave spec follow-up as an optional later cleanup step
Update these three reference files first:
1. `Specification/12_element_reference.md` for element behavior, props, actions and panel nuances
2. `Specification/13_screen_and_modal_reference.md` for screens, modals, connections and flow rules
3. `Specification/14_project_settings_reference.md` for settings, services, permissions and export-sensitive configuration
If the change also affects core runtime contracts, update the matching base files too:
- `Specification/2_model_data.md`
- `Specification/CURRENT_SCOPE.md`
- `Specification/6_ui_and_canvas.md`
- `Specification/catalog/mvp_function_catalog.md`
Do not leave new runtime behavior documented only in code or only in chat history.
Before changing action logic, validation, export-sensitive behavior or panel semantics, re-read the matching reference files first instead of reconstructing rules from memory.
There are plans to do the same for web applications. It seems to me that this will greatly simplify the design of websites: it will be possible, without being distracted by the design, to see all the logic, linking and finding weaknesses, instead of keeping everything in mind. Thanks for your time, good luck to everyone.