For me, most things in life are about patterns. I put things in the same place, consistent uniform, sit on the same place on my couch, same apps on all my computers, etc. Same with how I work. I have a certain coding workflow that has worked for years and it's one of the main reasons I have 32" monitors. I sit down to work, open brave (or firefox on linux), open a terminal, and open an ide of choice. This creates a trigger for me to know "we coding today" vs "let's just pick something to do". I tell you all this so I can contrast with my new workflow. I've mentioned in my latest post on vibe coding that I've switched to Claude Code as my AI tool of choice. It works out well since it works within the terminal so I just keep multiple tabs open. Now my workflow is more open a web browser, open a terminal, open ide, and run `claude code`. Since I'm leaning more on AI tools to complete some task faster I also change how I approach development problems. ## Development approach Previously when coding I would do high level documentation in my Readme and keep a running list of things I wanted to do either in a text file on my system or using git issues. The thought process is take a task, break it into steps, write the code. With AI tools I can actually flip this logic and force myself to be more of a project manager (PM) as well as focusing on more of a test driven behavior approach. > You're going to ask if I write test. Not really unless I'm deep in db migrations. I'm a mobile developer. I test by running on the device in a certain workflow. That's pretty much key for me. Now I can open a new file (or notepad) and write out prompts that describe what I want to do. As I read back what i'm asking for, I can figure out what I'm really trying to achieve. A first draft might look like "Look at my flutter code for a list and rewrite for web". As I clear it up the final prompt might look something like "Look at my flutter code found in acheive /flutter/dashboard and translate it for web in my /web/dashboard folder. Make sure that you keep the firebase calls and CSS consistent for this view. The color references can be found in /flutter/colors. For any images use any package that is not resource intensive." You see that clarity?!?!?!?! I don't usually kept these prompts after I get what I want out of them, but if you want to track what works and what doesn't feel free to keep them in a /docs/prompts.md with results. That was a PM example, but if you wanted to be more test driven I'd write something similar to grokin. An example of that could be "As a user when I visit the website I would like to see a dashboard that shows a list of my items. The list should pull from firebase using the pattern seen in /flutter/dashboard. I should see colors consistent to my mobile app that can be referenced from /flutter/colors. These new files should be placed in /web/dashboard." Crispy right? There is something about prompting that makes how and what you write even more important and I think that has been lacking from the dev space for awhile. I've seen Jira tickets/trello cards written all kinds of way. What if I could just take those tickets and past them directly into the prompt. That would 10x my time to completion I'd think. That's my ongoing next step, clarification for issues. ## How do these things change how you approach new projects? Great question. I try to use chatgpt to give me a better initial project prompt after throwing things at the wall. I save that prompt to /docs/initial_prompt.md for reference. These ways of clearly stating what I want from inputs to outputs is key. I'm so use to "I want to do x" and then iterating behind the scenes later. This new approach of refining what I'm asking for so the tool can build as close to right the first time is time consuming now, but should get faster in the future. My git issues are no longer "Add x" but more of a test plan and/or a prompt to do along with doing whatever the thing is. I've also noticed that recently I start a lot more with the big picture and drill in vs starting with a small things and building out. Makes a big difference. This way of thinking is called "building with the end in mind" I think. The difference for me is that I can think "I want this thing", but now I'm also asking "what does that end thing look like?". It's not just a mobile app that does x. It's a mobile app that does a,b,c using y tool, and following z patterns for n audience. --- Maybe I'm saying all this to say I'm becoming more product focused. I'm not sure but I hope this helps give some perspective of how I see AI tools in my personal journey and give you some new ideas on how to word things better so you don't have to waste tokens on 100 iterations to solve a single problem.