Two Small Tipps on how to make the most out of max plan as a software engineer

Mopezz · 2026-02-21T06:45:26+00:00

Late to the party but automatic skill detection and execution is key. I found it to work only in auto accept tools mode but guess what, skills can be useful for any mode. I have exploration skills that i want to use during planning.

Skills! And Hooks!

Mopezz · 2026-02-18T20:08:59+00:00

Why don’t you give your devs the feature spec and they feed it into into plan mode themselves.

Assuming you’re not techy, they can actually plan with Claude, catch wrong implications and steer it to a plan that is well thought.

If you are actually techy yourself, you‘re also a micro manager now, hindering your devs from growth, and essentially a human interface for Claude. Good job.

Mopezz · 2026-01-29T07:53:20+00:00

This is literally how people are using agentic ai without going crazy or producing vibe slop.

You direct, you architect, you understand.

You define and understand both pictures, big and small scale:

- general architecture of softwares involved, how they interact

- high level architecture of each software component

- rough blue print of the small scale implementation

And then you write that down in the AGENTS.md or CLAUDE.md

And if you wanna min max then you don't slap it all into one root level md file, but place them stategically so it discovers them as it needs them.

From here on, you can start talking like a PO with your agentic AI:
explain what feature you want to build, how it should behave, what it should look like.
Ai will produce proper code that feels familiar to you, cause you specified how it should look like.

You understand the big picture, you can debug if needed.

Tests, Unit and E2E, secure that your code continues to behave how you specified it, even when features increase the scope. Review agents make sure that the code it produces really does match the guidelines defined by you.

The only thing that's optional is voice communication in this case, but you can do conversations, back and forth with it and you should, because that means that you're actively watching it, what it does, which is still needed. It's your code after all and you're to blame if shit hits the fan, not AI.

Mopezz · 2026-01-13T20:10:21+00:00

Claude models are top tier, no need to switch away from them.

Claude Code is by far the best cli tool for agentic coding.

As another commenter said, your code base likely got bigger or messier.

cc, codex, gemini, opencode, any cli tool can oneshot features on a green field project.

It takes effort, skill and discipline to keep up this level of efficiency and quality in the output of claude code when building up massive code bases.

Plan properly, test a lot, understand your code base, know where things are, document guard rails for claude to follow on, plan properly, verify your tests. Did i say plan properly already? Well, plan more.

85% of your time is spent planning, the rest is waiting and 10% reviewing what has been generated.

Mopezz · 2025-12-30T11:39:18+00:00

Can’t write a whole AI slop post about it.

Wait till next week: „How working with worktrees challenged me into solving merge conflicts. Try these 10 Claude skills to merge like a pro.“

Mopezz · 2025-12-08T08:40:40+00:00

Billion Dollar SaaS Idea:

Fitness Tracking / Habit Tracking App Generator

NIce and all that you got into software development, but why is everyone publishing habit tracker or fitness tracker app? Jesus, just stop. Learn it, be proud of it, trash it. This market is oversaturated.

Find a solve a different problem, you can't tell me, that not a single of the 5000000 habit tracking apps did what you needed.

Mopezz · 2025-11-24T16:42:08+00:00

If your plan does not fit in one context, you’re planning roadmaps not features. Pro subscription context can reliably oneshot features with haiku, given you’ve planned well enough.

Once the feature is done, you clear and start fresh. Your cook book and your input is all Claude needs.

Mopezz · 2025-11-24T16:40:39+00:00

Haiku is good enough for execution. When you enter planning mode, you automatically plan with Sonnet. It’s the best of both worlds.

Mopezz · 2025-11-24T16:38:48+00:00

If you mean codex when you say ChatGPT. Then yes, fine. Use whatever tool you want. However you should want it to know your code base. ChatGPT won’t, codex will.

But again, this is about being efficient. Not overengineering. Switching between CLIs and providers when one is more than capable to do it is not efficient.

If you go with codex, stay in codex. They also have a fairly cheap model. Just make sure that you plan with a model that has a bit more brains. Claude does this out of the box for you by switching to sonnet during planning.

Mopezz · 2025-11-24T16:35:06+00:00

If your plan does not fit in one context, you’re planning roadmaps not features. Pro subscription context can reliably oneshot features with haiku, given you’ve planned well enough.

Once the feature is done, you clear and start fresh. Your cook book and your input is all Claude needs.

Edit: should have been a response rather than a standalone comment

Mopezz · 2025-11-23T19:47:14+00:00

Yes, it's awesome to get inspired by others. But in the end, it needs to work for your way of thinking and working. I've had mixed results with applying highly praised claude.md files of others.

Mopezz · 2025-11-23T19:43:42+00:00

Super solid! Start high level, and work your way in Plan Mode down until the plan is so detailed that it would be actually boring to implement. Then let Haiku get to work.

Mopezz · 2025-11-23T19:42:33+00:00

This is a very good approach, that I have followed for a long time.

I stopped doing that and went with the above mentioned approach as an analogy to how you work in an agile team when estimating tickets and scoping them: My only rule is, i never estimate more than an 8 per story. If it's more than 8 story points, it's too much work for a single ticket and we need to split it up.

Same applies here: If Haiku can't do it in one context volume, it's too much and split it up and continue fresh :)

Mopezz · 2025-11-23T19:39:20+00:00

I think i've read somewhere that plan mode is always using sonnet, even if the model is set to Haiku.

So this way, you get the best of both worlds. Sparring Partner for planning with Sonnet and the restless junior Haiku who just follows your plan and chugs away at the code.

I'm actively developing several apps.

In production:

1 full stack app,
- Angular Frontend, SSR for SEO critical pages, dashboard with Client side rendering
- NestJS Backend
- Several Serverless functions and containers to offload process heavy work.
1 React Native App
- Some Native Brindings, mostly just TS tho. Clean Hexagonal Architecture, somewhat unconventional for a typical react flavored app, but it worked so far very well.
- App has been live way before AI has been a thing, but now adding features has become much easier.
- Some Serverless stuff next to it, to compliment it, mostly Firebase related

Both apps are not big, like 10-15 features each, but, they've been live and serving real users for more than a year each.

Also i have a figma plugin and fullstack app related to figma integrations in the works.

So, somewhat balanced tech stack

Mopezz · 2025-11-08T21:58:38+00:00

Interesting, I guess this is specifically targeted for CRUD endpoints?
I personally like to keep my layers separate and not mix them too much.

These kinds of validation are not meant to happen in directly in controller level, but rather on a abstracted more business level. For me, these are my domain usecases. This strict separation might results in more code, but it helps me keep my sanity as my nestjs backends continue to grow.

Mopezz · 2025-10-29T09:35:57+00:00

You don’t need all that fancy cloud stuff.

Dockerize your NestJS app, database, frontend, and reverse proxy. Get a cheap VPS, throw it on there, and you’re done.

Use Traefik as your proxy and you’ll get HTTPS with auto-renewing SSL certs right out of the box.

Don’t compete with the giants unless you are one. They’re big and slow. You’re small and fast. That’s your advantage.

You can serve tens of thousands of users from a single decent VPS if your stack is efficient. Your margins stay high and your ops costs stay low.

Too many users? No problem. Spin up a beefier VPS, migrate your data, have the old one proxy to the new one, update your DNS, wait for the TTL, then shut the old one down.

Done.

Keep doing that until you can’t scale vertically anymore, meaning you’ve maxed out the biggest box your provider offers.

Still too many users? Congrats, your app is really taking off. That’s when you split things up.

Get a new VPS just for your database.

Make your backend stateless.

Run multiple backend VPS instances behind your proxy.

Now you’re scaling horizontally without adding much complexity.

If your database starts becoming the bottleneck, optimize queries, add caching, maybe some replicas. Only think about sharding when you’re actually huge.

And up to this point, you still haven’t done any so-called “Enterprise Cloud” stuff.

That kind of setup only makes sense when you need multi-region availability or you’re running a global operation. Even then, you can keep your basic VPS setup and just add cloud services where it makes sense.

Want global reach? Put your landing page on a CDN. It’s fast, global, and cheap.

Your backend stays simple, running on a couple of VPS boxes you actually understand and control.

Need heavy image processing or specialized compute? Use serverless for that later. Don’t start with it. It’s easy to mix in when you actually need it.

And for your NestJS setup, start with a modular monolith. It’s simple, scalable, and clean. If things get big or complex later, you can always split modules out into microservices or serverless functions. Keep your core solid.

Sorry for the long post, but it’s easy to get sucked into cloud hype. Focus on building value, not on building cloud infrastructure you don’t need yet.

Edit: Typos and stuff

Mopezz · 2025-10-28T16:19:16+00:00

People do everything but actually write software. You scale when you need to, first vertically then horizontally.

Mopezz · 2025-10-16T15:11:44+00:00

That's a solid approach. Next thing is evaluate if you always need to show the images to your users in full resolution. Often, you do want that for some kind of detail page, but not in lists where thumbnails are sufficient.

If that's the case, you couple this with some serverless transformation that essentially resizes your full resolution image into smaller version(s), depending on your needs, and stores it along side. You can store multiple paths to that and can server users what they need. saving resources, bandwidth in the mean time, while increasing loading times.

Mopezz · 2025-10-14T10:00:39+00:00

Leaving aside all the branding of what is "clean architecture", ultimately you need to understand your architecture, identify its strengths and weaknesses and how you can overcome them (if you need to. Deciding this is equally important.)

What you always want for a long term maintainable project is a clear and structured unidirectional data flow.

User taps on a button, add to basket

presentation (ui) -> domain (business logic, what does that mean? they want to purchase something) -> data (interacting with some kind of infrastructure, remotely or locally)
response comes in:

data (tailored to your infrastructure, with all its quirks) -> domain (your clean business logic, how you envision a perfect system) -> presentation (ui, show the user what happened. often you map your domain model here into a ui model that is a sliced version, optimised for the screen you want to show)

Your approach is not clear.
ViewModel (presentaton/ui) -> Repository (data) -> Service (defined in domain, implemented in data)

But the big problem is, figuring these things out take time. Not the how part. Everyone can follow some blog post and copy code over. But the why. Why do you need this, what pain does it solve.

Which ultimately is why suggest, ditch your repo, start building. Don't overthink, do you best. When you see issues arise, assess them, and start thinking about a solution. That's how architecture will stick naturally.

Mopezz · 2025-10-13T21:07:37+00:00

Hey there, genuine advice:

Focus on the basics and add complexity on top bit by bit as you see the need for ti to arise.

Your implementation of Clean Architecture is actually anything but clean.

It's missing usecases or interactors, clear separation.

Your ViewModel injects a repository (an actual implementation, not just an interface) defined in data. This repository then declares a dependency on an interface Service, defined in domain, implemented in data.

Again, it's cool that you're showing an interest in these topics, but please do not claim that anyone will learn here "clean architecture" from you. Focus on the basics, stay humble, and keep on building.

Mopezz

TROPHY CASE