Ask HN: I stopped fighting AI over-reliance and built a workflow around it
2 comments
Learning how to use documentation for/with AI has been the story of my last year+. I don't have the technical background you do but I've worked in product and project management, so I was never deep in code the way you've been.
I think the journey of figuring out how to actually create with AI has been as interesting as what I'm able to create. I wish I had documented more of my lessons-learned the way you have. The biggest challenge I've found is that, as you mentioned, AI often thinks more equals better. So I had to learn when "comprehensive" meant subtracting over adding. Of course, there was also the practical reason, that more documentation meant more tokens used up - more context consumed - for a given task.
As far as files and rules, since I like seeing things visually structured, I've had luck creating temporary html files that visually capture the structure (files and rules) of a given effort. I use that as my visual map and it's what I have Claude use for its own understanding. It reduces the need for reading entire docs but it also forces me and the AI to stay structured. I also mirror this in that (as of late) I use Cowork for the planning (i.e. the maintenance of that visual mapping) and Claude Code (in a completely separate instance) to run the task(s) and, in the end, pass the lessons-learned over to Cowork manually. Otherwise if they were one "mind" e.g. when I would use Claude Code to coordinate AND code, it would always add more information to its memory and it would get out of hand very quickly. Ultimately, the key for me was understanding how AI uses structure. For example, when I started using Linear a couple of months ago - prior to which I had no "formal" project management system, all of the tags and labels and 'projects' (as Linear uses the term) really helped manage efficiency in productivity. I use Linear's MCP to connect to Cowork directly and always start sessions with reading 'project' titles, labels, priorities, etc. before diving into details for a given effort.
I think the journey of figuring out how to actually create with AI has been as interesting as what I'm able to create. I wish I had documented more of my lessons-learned the way you have. The biggest challenge I've found is that, as you mentioned, AI often thinks more equals better. So I had to learn when "comprehensive" meant subtracting over adding. Of course, there was also the practical reason, that more documentation meant more tokens used up - more context consumed - for a given task.
As far as files and rules, since I like seeing things visually structured, I've had luck creating temporary html files that visually capture the structure (files and rules) of a given effort. I use that as my visual map and it's what I have Claude use for its own understanding. It reduces the need for reading entire docs but it also forces me and the AI to stay structured. I also mirror this in that (as of late) I use Cowork for the planning (i.e. the maintenance of that visual mapping) and Claude Code (in a completely separate instance) to run the task(s) and, in the end, pass the lessons-learned over to Cowork manually. Otherwise if they were one "mind" e.g. when I would use Claude Code to coordinate AND code, it would always add more information to its memory and it would get out of hand very quickly. Ultimately, the key for me was understanding how AI uses structure. For example, when I started using Linear a couple of months ago - prior to which I had no "formal" project management system, all of the tags and labels and 'projects' (as Linear uses the term) really helped manage efficiency in productivity. I use Linear's MCP to connect to Cowork directly and always start sessions with reading 'project' titles, labels, priorities, etc. before diving into details for a given effort.
Thats a great insight! You have no engineering background but your experience in management might help you to be more prepared for this era. Because what you described is literally management. You were managing people and now manage AI agents. I was writing code and now i manage things that write code. Different roads, same destination.
I wouldnt say that tech skills dont matter at this point because thats wrong. My experience is the only thing that helps me to say like "hey thats not the best solution for this, you better do this", or at least to doubt at AI's judgement and send him do a proper research about different ways to go... But the truth might be that managing skills worth more nowadays
I wouldnt say that tech skills dont matter at this point because thats wrong. My experience is the only thing that helps me to say like "hey thats not the best solution for this, you better do this", or at least to doubt at AI's judgement and send him do a proper research about different ways to go... But the truth might be that managing skills worth more nowadays
I think we have a sort-of-similar AI setup, except I use HTML files rather than markdown, and this is because I'm on macOS and it's easier to use "quick look" on HTML files than markdown (HTMl shows up nicely, markdown is just plain text). Also, I ask the AI to get rid of old documents and try to merge documents together, so that there's not as many documents cluttering up context.
As for motivation: I need to pay bills, all I can think is "I need to build more"... :'D
As for motivation: I need to pay bills, all I can think is "I need to build more"... :'D
Interesting, i guess there is no difference for AI if docs are HTML or MD, but a big difference for human eye. I am also on macOS but got used to read all that raw formatting... Also good point about merging docs, it hurts AI when they become too long. Its hard to determine though what data you want to remove. If you remove some dead code but it was useful - you will know about it very soon; but if you remove some useful documentation by accident - it may hurt later
Thats some kind of degradation. But the thing is that the quality is amazing. My productivity and speed increased significantly.
But there is a frustrating thing. The laziness started affect even review process. I feel like i dont want to spend time to read and check all the changes - i will better ask another AI to do it. And it works! I use Claude for like 95% of work, then switch to GPT to review everything properly. They have different personalities so you have different points of view. I consider GPT as a nerd - it catches a lot of gaps and inconsistencies that Claude misses. So i like to close them both in one room to debate.
What i really do care a lot is a comprehensive documentation. I spend a huge amount of time for planning and brainstorming with AI, then i document everything properly. All those MD files about architecture, composition recipes, cheat sheet… All of it should lie on surface, not to be buried somewhere deep in code. Every cold session starts with all the docs where everything is explained properly with references and examples to prevent AI to skim or give lazy answers. When i need to implement some big feature i structure a proper ready-to-execute plan so every next agent with fresh context reads it - analyzes what was done - figures out what is the task for this session - and goes ahead with all the changes, then report. It can be dozens of chats working sequentially on some big thing; in the end i will run some workflow to review all the implementation, then ask GPT to audit changes, and i will look myself only when AI approves that everything looks great. Then i can tell what and why has to be redone because i dont like how we have it now.
In my setup the documentation for AI outweighs the code (instruction files on every level, rule files that load by file type, subagents with roles, hooks around every edit). The most weightful part:
- A catalog of silent failures. 36 numbered traps that compile fine but render broken. Every entry is a real failure that shipped at least once: cause, symptom, fix.
- A "polish" rule. When you tell AI "make it better", its reflex is to ADD decorative stuff. So there is a written rule that polish means subtraction, with a list of patterns i rejected in real reviews.
- CI that fails when docs drift from code. The component registry is checked against source files. Because docs that lie are worse than no docs.
- A runtime verifier (WebMCP). An agent drives a real Chrome browser, clicks through the page, watches the console, takes screenshots at 3 viewports.
Basically I stopped writing code and started engineering the environment that writes the code. Every file exists because AI failed at something once, and i wrote it down so it wont happen again.
The biggest problem for me is motivation. I remember that feeling how you got stuck - cant figure out something for hours, searching right solution, trying, and then FUCK YEAH FINALLY, and the satisfaction: YOU NAILED IT. I dont have it anymore. I feel confident even in things where i have no expertise at all. Thats like: meh AI can handle it.
I think my system solves the quality question, but increases the laziness/motivation problem. I made it safe to be lazy.
So two questions:
1. How does your AI setup look like? I mean real files and rules, not just how you prompt.
2. Has anyone actually solved the motivation part?