Parker Rex
All videos
Parker Rex

How to Actually Setup Your AI Coding Environment (VSCode, V0, Augment, GCP)

May 28, 2025

Watch on YouTube@parkerrex

Parker walks through his actual AI coding environment, why tool-hopping ruins momentum, and the primitives he uses to keep things portable, fast, and scalable across tools like VSCode, Augment, and GCP.

A portable, tool-agnostic workflow#

  • The core idea: don’t chase the latest tool. anchor your workflow in portable patterns you can carry across environments.
  • Markdown-driven prompts and file structures let you switch underlying tools without changing how you think about problems.
  • The goal: be a “markdown god,” not a tool hopper—your patterns travel with you.

The core stack: VS Code, Augment, GCP#

  • VS Code is the daily driver
  • No fork needed, performance is solid, and Microsoft’s open approach (open source, extensible APIs) matters for long-term viability.
  • Future-friendly: mid-June API/extension improvements planned; potential to build custom modes and tool calls inside VS Code.
  • Augment as the context engine
  • Best balance of performance and memory) with built-in memories.
  • Focuses on context rather than forcing you into a particular UI or vibe codebase.
  • Other tools in consideration
  • Cursor and Windsurf: not daily drivers for Parker anymore.
  • Klein (extensions): still watched for innovation, but not relied on as a sole driver.
  • Envim is mentioned but seen as less central than Augment for this setup.

Augment: context, memory, and background agents#

  • Augment’s background agents are a standout: no obvious performance issues, can tailor the shell/script layer, and emphasize context retention.
  • The vibe is “agent-driven, not just editor-driven.” This aligns with Parker’s goal of scalable, memory-aware workflows.
  • The pattern: use augment to keep long-running context across tasks, so you don’t lose state between steps.

The AI architecture: prompts, folders, and a CLI#

  • Folder layout (thisai folder)
  • Prompts drive the workflow; prompts are in GitHub instructions and organized for portability.
  • Key prompts:
  • Idea prompt: steelman or challenge an idea’s value; portable across tools.
  • PRD instructions: turn ideas into a practical product requirements outline.
  • PRD Plus: add mental-model scrutiny and cross-context checks.
  • Architecture instructions: architecture patterns, language-specific guidance (Python, TypeScript), and canonical design patterns (singleton, factory, facade, etc.).
  • Doing vs backlog: a bridge from high-level ideas to concrete tasks.
  • A self-contained CLI for memory and workflow
  • Runs steps, tracks progress in a local lock file, and keeps your context cohesive across runs.
  • Designed to be tool-agnostic: you can swap underlying tooling while preserving the workflow.
  • Token awareness and management
  • 16,000-token task instructions in one piece; use a token-count extension to stay aware of limits and optimize prompts.

Example prompt structure (high level):

  • Idea prompt -> PRD instructions -> PRD Plus -> Architecture instructions -> Task instructions -> Implementation backlog

Prompt portability: patterns that survive tool changes#

  • The idea is to build prompts that survive tool swaps:
  • System prompts, role definitions, inputs/outputs, clear examples.
  • File-tree awareness (when using augment) to shape context around current/project state.
  • This approach reduces the need to fine-tune around a specific toolset (e.g., tan stack start/router) and favors well-documented, broadly adopted patterns.

MCPs on Docker: repeatable automation#

  • MCPs (multi-chain problem Solvers) work best in Docker for consistency.
  • Parker’s current picks:
  • Sequential Thinking
  • GitHub MCP server
  • Playwright (paired with a prompt for navigation/testing)
  • Future candidate: Context 7 (needs a Dockerfile; a caution due to some docs quirks, but valuable if you can stabilize it)
  • Why Docker? Keeps environments predictable across machines and reduces “works on my machine” friction.

Workflow decisions and tradeoffs#

  • Taskmaster is used in some setups but Parker finds it can degrade quality for larger projects when you over-index on pushing context into a single pass.
  • Cloud-based code (Claude Code) is tempting but not Parker’s default; he’s leaned away from it unless augment-based flow starts underperforming.
  • Browser-based flows (e.g., Gemini) are a fallback path for quick data operations, but not Parker’s day-to-day coding engine.
  • When coding AI apps, Parker prefers reliable, well-documented stacks and strong integration with the Google stack (Vertex AI) and Next.js for web apps.
  • For DevOps and infra, a beefy but cost-effective machine (Netcup, Debian-based) paired with PM2, Nginx, and Discord-based observability is the current setup.

Infra and deployment notes#

  • Cloud and compute choices
  • Prefer GCP Vertex AI and related AI/ML tools for AI workloads.
  • Next.js for web apps and remote agent integration; strong community support and ecosystem.
  • FastAPI when you need a rich AI/ML backend with robust Python tooling.
  • DevOps and observability
  • PM2 runners, Nginx, and Discord bots for operational alerts.
  • Python-centric stacks align well with Google’s tooling and AI APIs.
  • Practical note: there’s a tradeoff between raw compute cost and the complexity of maintaining a custom stack. Parker’s current setup emphasizes cost-effective, maintainable components with strong docs.

Echoes of the setup in practice#

  • The “thisai” folder pattern and the prompts you maintain can drive most AI-assisted coding workflows, regardless of tool, as long as you keep the prompts portable.
  • Augment’s memory and background agents put contextual intelligence at the core, reducing the overhead of constantly reinventing the wheel for every project.
  • The goal is leverage, not glorified tooling. Pick the pieces that scale with you and your projects.

Takeaways you can apply#

  • Build portable prompts and a consistent file structure you can carry to any tool.
  • Use Augment (or an equivalent context engine) to keep long-running context and memories, instead of trying to fine-tune everything per tool.
  • Favor well-documented, widely supported stacks (e.g., Next.js, FastAPI, GCP Vertex) over niche, less-documented ecosystems.
  • Run MCPs in Docker to ensure repeatability and reliability across environments.
  • Start with a solid core (VS Code + Augment + GCP) and iterate on sub-stacks (Playwright, GitHub MCP, etc.) as needed.

If you want deeper context on Parker’s broader take on LLMs driving tech choices, check out the daily channel for further thoughts and contrasts.

Transcript

Are you suffering from tool hopper syndrome? Are you trying too many AI tools? I've got just no. Okay, so this is my current dev setup. I've been hopping around different tools. I've been using AI since the first SDK came out pretty much every single day to try to figure out how to get the most amount of leverage out of it in coding, marketing, and business. And I want to talk about some primitives so that this won't be something that is outdated tomorrow because of the pace at which these things come out. I think that's important. That's what I'm focusing on now, having gotten, you know, the symptoms of that syndrome. But yeah, so do you want to be a tool hopper or do you want to be a markdown god? Because that's really there's the same thing where you could technically switch a tool, but it won't change as long as you can bring your markdown patterns and prompts with you. So I also think that this plays into something bigger, which isn't a video that I just post on my daily channel. This is a main channel. I do three videos a week, Monday, Wednesday, Friday on here. And then over there I do other videos where I talk about how LM don't care about your feelings and how they are driving people's technology choices if they want to get the most leverage out of background agents without having to spend all the time and resources on fine-tuning tools to their codebase. Big if there used all the ones in here except Rode. So I didn't use this one extensively. I've tried it but I have not used it much for good things. Sure. But when I look at this list, it's everyone has its strength and its weakness. And I'm leaning towards two now where cool. You have them bucketed where at the top you could call them. You have the Sorry, I didn't even put in the other fork. You have Windsurf and Cursor, which are the forks. Never really used Windurf. I used it a little bit at the beginning, but stopped using it. They don't have Cloud 4 natively, which is kind of wild. After the acquisition, they got out of the club. But for Zed, very fast. It's got rust. It flies. It's got native notifications. Very nice, but it was behind the ball for a very long time. And I don't know. I just don't stick to it. I love them, but not enough that their differences make the change for me. Wind surf. No thank you. Cursor. Now, I started using this when it was still in beta. I got one of those magical emails asking me to be a part of their team. I don't think they want to be to be an engineer. Maybe like a dev rail guy, but forever ago turned it down and ended up just using the product. I had already been using it. So longtime cursor user, but I've noticed since they started releasing background agents and basically after.5, it's gotten really slow and sluggish, and I just feel like there's too much stuff going on that I've stopped using it. Now, that doesn't mean it's bad. That doesn't mean I don't occasionally open it up, but it's not my daily driver. VS Code now is my daily driver for a couple of reasons. One is there's no fork. So, I find the performance of it just to be a lot better. Also, them open sourcing it is awesome. I think that's a great thing. They're doing that a lot of like with a lot of different tools at Microsoft. That's slated to come out in mid June is what they've announced publicly. And they also have different APIs that are open. So when I do get to the point where if I wanted to write a generative language tool built in like think of the custom modes and cursor on steroids. So I don't even have cursor. Yeah, I do have it open. But if you open up cursor and you selected model and then you have modes, you can make a custom mode that basically injects something in that prompt. That's very cluji. Doesn't work very well. Now in an ideal world, you could actually build the tools in. So it's like a tool call and you could just have it in a drop down. That's what the APIs are doing at VS Code. So those are really nice. And then also they have an instructions system pattern. So if I open it up and I go into GitHub and then I go into instructions, anything that's marked withinstructions will allow for you to then call that in their instructions. So if I did like instructions, I can see new instructions file. I can also reference those over in my chat. I'm using augment for context. I think that's the best one. I'll talk about that in a second. I've used Envim with augment very cluji. Now when it comes to the extensions, I think Klein still leads the pack on innovation. I think they're the Snapchat stories equivalent of AI tools. I've talked about this before. I think their guys on the team are awesome and they're also incentivized to move faster because they don't have a bazillion dollars to light on fire. So, I still check in on them. I'm in their Discord. I'm in a bunch of the Discords, but you know, I like to see what's going on in there. And then, oh, I struck the wrong one. Then, augment. This is the one I'll be talking about a lot more in depth in future videos, but its background agent seems to be the best one. It doesn't have performance issues. you can change just the shell script and it just their focus is on the context. So while everybody's going towards vibe code and embracing it like they actually have like literally like hats that say get blame vibe vibes which I think is funny. So they're going after the skilled developer. They're really leaning into their context engine. They have memories built in. So this has been the daily driver for me is just using that. Now there's other things I want to talk about with my workflows and how I think about the feature dev stuff. So over on the lefth hand side you can see I have a folder and thisai folder is driven by the prompts that I have. So I have different prompts and in them they're inside of the GitHub instructions. But I have an idea prompt. So let's move this out of the way. And that idea prompt this is open source by the way. I'm not gatekeeping prompts. It's not that special. But this is after me using a bunch of different ones and coming up with what I think to be the best. So this would be the first one. And it basically steelman's why your idea is good or bad. Has an example in it as well. So when I talk about making it portable, you can take these to any tool and they will work right because you're just doing a raw call to it. It's giving it system prompt, examples, roles, responsibilities, inputs, all that outputs. Then you have PRD instructions. So then you're taking the idea from the previous step and putting in here. So the output of the previous goes into here. You're just prompt chaining them. And then you have PRD plus. So PRD plus is an additional step. It's kind of like you'd have Peter Teal or someone that's like a mental jouster that's trying to break your brain on this. And it's using all the relative paths. So there's things in here that bring in context on top of if you used augment, which I recommend for this, where it'll do file trees. So if you're going zero to one, it'll have suggested file trees. If you're going one to one point in, it'll have current file tree, projected file tree. Then you have architecture instructions. So this is one that is trained. It's prompted for Python and TypeScript. So you have all the stuff in here of popular architecture principles. Here's the example of the placeholder with a proposed file structure, the system patterns, the different ways of doing the pattern. So this a singleton, a factory, facade, observer, strategy, decorated, repository, dependency injection, then you have Python specific ones, you have TypeScript specific ones, and then the component relationships, implementation paths, all these things. And so you're building more and more out of these. These will then go into your doing folder. So I built a CLI around this. It's open source and part of the VI repo which you can go star. Some of them are public and everyone that's a member has PR access to any of the projects that we're working on. But yeah, the idea with this was I made just a CLI so it is again like tool agnostic and you could just say okay next and then you could call which step you're in and it keeps it in a little lock file for memory. But going back to this then you can see you have the architecture instructions then the system instructions. So this is a self-healing file. So it's actually unnecessary if you're using augment because augment has memories. But this is what that's doing if you didn't use augment where it's the single source of truth and then it'll actually go and kick things out to the instructions and and basically make a system rule. So it's the canonical source for the project system architecture design patterns and technical guidelines. So then that would be tagged in the previous ones if you had it. And then finally, you get the task instructions. And yeah, it's a big boy. This has 16,000 tokens. If you didn't know, there's a nice extension for this called token count, which you can check out. But this gives you a lot better details than Taskmaster because it has you basically just want more of this orangey color in your files because it means it's specific. It's adding the ticks. It's telling you what exactly you expect. And then when you actually go to the implementation, then it's off to the races. So this plays into another concept where I talked about on my daily upload that if you didn't have a framework that's wellnown that's trained on these things, then you have to go spend time fine-tuning your tools to let's say tan stack start. I just spent 3 weeks learning all tanstack start just to run a bunch of agents and realize wow like this is going to be so inefficient. I need to pick something that's more popular that's more well doumented. Even if I took tanstack router and tan tech start combine them together and give it to it and still bias is so heavy towards other tech that it just runs in circles. So that's on that pattern and then when I'm actually doing implementation then I'll have the backlog. These are just things that are ideas that I could take from idea through the other steps. Now then I'd go into okay these are the ones that I'm doing. This is like an a bridged version. This is what I'm actually working on right now. This is just the task list, but you can see all the different aspects of it. And I'm curious because again, augment like actually just did this without me using all the prompts and it's pretty dang good. Like I I didn't do the chain instead of it just basically took a bridged versions of it and example files. So I just tagged an example of what I wanted and then it went through and it's just flying. And then I put in done for the things that are completed. I have guides in here. So, this is something I'm going to be adding. But brand colors, this is it. This is all I have for now. But I'll be adding in shadows. I'll be adding in fonts. I'll be adding in font weights and the way that we handle different screen sizes. Do you have a hamburger? Do you not? And like these primitives to how things work, how do you handle hovers, all that. And then I have lm.txt. So llm.txt is what it sounds like, right? where you just have the chunk of the relevant information. So, this is only 10,000 almost tokens and this is just off of SSR. I didn't know how to do it in Python and like basically traversing fast API and next and superbase. I've never had a superbase fast API stack before. I've just done that with tan stack start. Then I have discord pi and fast api. So that's what I'll then help inform it with. Now, I'm going to take a quick break. I know that's a lot. Now, let's talk about MCPs. So, MCPs I found to be much more effective when you run them on Docker. And you might not have known that, but you can run them on Docker and then they just always work and they're consistent. So, the ones that I'm using are the Sequential Thinking, the GitHub MCP server, and Playright. So, Playright gets paired with a prompt, and that's in my instructions folder for tests. It is not in this folder. It's in a different project, but basically you can have it go and navigate to things and it's a lot better than the alternatives like Puppeteer because it doesn't just work in one browser. It works in a bunch of them. And so I found that to be really helpful and I'll be adding that into the stack. And then the other MCP that I want to add, but I just haven't done it yet, is let me remember. Oh yeah, context 7. I'm thinking of doing this one. There's an extra step here where I actually have to write the Docker file. That's why I didn't do it yet. But yeah, I just noticed context 7 it the only part that sketches me out with context 7 is that some of the time like the docs will have like duplicate. I don't know like I I've had like bad experiences with it. So I thought about just standing up that builder io project that has like the context crawler in it wherever that was. But yeah, so what else is there to cover on my dev workflow? I use Taskmaster, but you'll notice when you take you don't need it if you've done this Taskmaster stuff yourself because it'll just reduce the quality of it and it's like you're taking all this context that you have and then you're firing it off to something and then you're hoping that it comes back with all of it and it just I find most of the time that it's not good. I think for smaller projects it's great but yeah, I know a lot of people love cloud code. I have veered away from it, but if my augment VS Code thing starts not working as well as I hope and my background agents aren't as great as I hope, I'll give it another shot. But for now, I have no desire to codeex. Gave it a shot. No. And then finally, you basically have the browser way of doing things, which is, oh, am I going to use like repo mix and dump things and dump back into Gemini? Did that for a second. The only thing I've really used Grock for was setting up this GCP bucket, which was not even anything to do with coding. It's more just like random config stuff so that I could have a pedabyte of data stuck here. And then this was the MVP for Echo, which is my YouTube automation software. But that's it for the setup. Let me see. Is there anything else? If you look around, if you learned anything in this video, make sure you like it. Make sure you subscribe to the channel, of course. And then if you want to join VI before we drop all this stuff, you should go join right now. If you want to get it expensed by your business, just shoot me an email. But yeah, these are going to be my elements for the build basically is because of the LLMs and because I'm not going to go fine-tune a bunch of stuff I'm landing on. If I need a lot of AI API related stuff, then go with fast API because of the rich AI and ML ecosystem there. If I need any sort of web apps, I'm just going to go with next because I just know it like the back of my hand. It's really easy to work with and I trust remote agents with it. Although you do need to have guardrails and your CI/CD and tests. Any sort of AI cloud stuff, I'm leaning heavily on GCP. The Vertex thing, the whole suite of products they have there is just bananas. And then for DevOps, I'm going to be going I got a beefy machine that's like usually $180 worth of compute per month on Digital Ocean, but it's $15 from a company called Netcup. Now, you have to get past the fact that it's in Debian and that the system boots up in German and that it's a German based company and that like the whole website looks like a piece of crap, but like the specs on the machine are awesome. And then you just ask GPT like how do I turn this from German to booting into English? And once you get past that, you basically get like 10x the compute for the price. And that'll be PM2 actions with runners, engine X, Discord, observability. So bots basically that will ping me in there when things are going on. And yeah, having Python matters a lot because of the Google stack. There's a lot of interesting stuff going on there, both in the generative AI marketing and the generative AI agents, the agent ADK. So yeah, that's the folder pattern that I talked about and that's it for the video. I'll catch you guys in the next one. Make sure you like the video and if you want to go more into my whole thoughts on LLMs being the dictators of tech choices, then go watch my daily channel. See?