I’m still confused by the whole “vibe coding” concept. When I’m working with Claude or Codex, I push back constantly, especially during the planning phase. We go back and forth on architecture, product decisions, and implementation before any code gets written. Ironically, I spend far less time reviewing the code itself than I do challenging the plan. So I’m curious… Do vibe coders just let the AI rip and hope the database schema, migrations, architecture, and everything else work out? Or is “vibe coding” mostly being used to build demos and static websites rather than real production applications?

The problem is there is a lot of poor developers out there

Token maxing is real for me. I have two Claude Code subscriptions, and I get a little anxious when one is nearing its weekly reset with a decent amount of usage left. I’ll start ramping up bigger features, more testing, or performance work to try to use as much of it as I can before the reset. I know that probably isn’t the best reason to choose what to work on next. But I still catch myself doing it. There’s this feeling that I’m wasting something I already paid for if I leave capacity unused. Then I end up choosing more work partly because the usage is there. I just haven’t figured out how to switch that part of my brain off.

I’m getting less interested in building a completely separate workflow for every model. I use both Claude Code and Codex. I want the same core skills and project instructions to come with me when I switch between them. Mostly because I use T3 Code now. If I’ve already worked out how I want something done, I don’t want to rebuild that whole process because I’m using a different agent today. That is why I spend a lot of time making sure my agent files and workflows are agnostic

I just passed the CCAR-F and you’re right. The only way to “study” is take a bunch of practice exams since Anthropic doesn’t give any material

“I didn’t know php existed until yesterday morning” These are the type of experts random companies hire as cto

It’s all dev stuff so it can be recovered. Now from my personal machine, I’m nervous but it hasn’t done anything bad with computer use yet lol

I give my agent a lot of access to my dev environment before I start testing the feature myself. It can access the dev database and the data in it. I give it the temporary API credentials it needs and the information to actually exercise the application. I want it to use that access. If things are already breaking in the environment it’s supposed to be working in, I expect the agent to investigate and work through those problems before handing it back to me. I don’t want my first round of testing to be discovering that it never had what it needed to try the feature properly.

AirPods have to be one of my favorite pieces of tech of all time.

Reiterating off my last post ... I don’t think every small change needs a huge planning session. Sometimes I’d spend more time explaining the task than it feels worth. But for bigger work, I’m trying to be more ambitious about what I hand to the agent. I’m used to going from an epic to stories and then down to individual tasks. Now I’m interested in starting with the epic itself, with the designs and requirements already worked through. Have the agent keep checking the implementation against that plan, work through what’s missing, and get the larger structure in place. Then iterate on the features and design from there. I still want the planning. I just don’t always want to be the person handing over every tiny task separately. I think there’s a lot of room to experiment with how big an assignment we can give these agents.

Planning is your edge for if your agent is able to complete large features without help. I try to get most of my involvement out of the way before the agent starts implementing. Usually I’m asking for a pretty big feature. So we work through the design, talk about edge cases, and I ask whether there’s anything important we haven’t covered. I want the plan laid out before I tell it to go. Then I give it the access it needs in my dev environment. Computer use, the dev database, instructions for creating test users. Once that’s in place, I tell it to work autonomously and come back when it’s complete. That’s the workflow I’m aiming for. I want to spend my attention figuring out what we’re building with the agent, then give it all the access it needs to be successful

My personal model benchmark is honestly still mostly a vibe check. I’ll look at Artificial Analysis first. A strong ranking holds some weight for me. Then I look at what people are saying about actually using the model. If it’s OpenAI or Anthropic, I already have subscriptions, so I’m probably going to try it regardless. For another provider, I need a little more convincing. Then I’ll give it something I’ve already done with a model I liked. A lot of the time that’s a 3D world or a 3D design, using the same prompt so I have something familiar to compare.

Great tips brother!

This really is the secret

I have a hard time giving the exact same model another chance once I’ve decided I don’t like working with it. That’s where I am with Sol 6.1. Most of the time I’d rather use Opus 5.5 and wait for the next OpenAI release. Every once in a while I’ll use Sol through T3 Code for an orchestrated code review because I’m already paying for the subscription. But it’s not usually the model I think to reach for anymore. I kind of just forget about it until there’s a new release to try.

I still get nervous when an AI agent writes the code and then writes the tests for that code. If I didn’t write the implementation, reading through the unit tests isn’t automatically easier. I’m still trying to figure out whether the agent is checking the right thing or just giving me something that looks convincing. I have some of that same hesitation with integration tests, although not as much. Where I feel a lot more confident is a full Playwright flow or an agent actually using the product with computer use. I can follow what’s happening in the application and compare it with what I wanted. That doesn’t mean those checks catch everything. But they’re much easier for me to judge than unit tests I’m not confident I can assess. Seems like the best option right now

It's so freaking cool how we can just build things that we've always wanted to build.

start simple! always go with especially in the AI world

lol - this is some juniors reality

congrats!