How my LLM coding subscriptions escalated

It started very innocently.

1. Free ChatGPT
Back then it was already called vibecoding, but I still didn’t really believe in LLMs for real coding tasks.
I mostly used it instead of Google. A bit more advanced Google.

I clearly remember questions like:

"Our designer has an animation idea (attached file) — what’s the best way to implement this in Flutter?”

Useful, but very exploratory. No real trust yet.

2. ChatGPT Plus ($20, on my girlfriend’s account)
I still didn’t fully trust GPT to write code for me.
But the Pro subscription helped in a different way:

– longer conversations
– architectural discussions
– switching between models and access to latest models
– sanity-checking ideas

It felt more like a whiteboard discussion than coding assistance.

3. Free Cursor (≈ 1 month)
Copy-pasting from ChatGPT into my project got annoying very fast.
Most real tasks need context across multiple files.

I was already coding in VS Code anyway, so Cursor felt like a smart wrapper on top of my usual workflow, not a completely new tool.

I mostly used Cursor via tab completion — it honestly felt like it was reading my mind.
Occasionally I asked the side-panel agent questions, but not that often.

4. Cursor Pro ($20)
The free tier wasn’t enough anymore:

– small request limits
– even tab completion stops working after some time

I stayed on it for a few months and slowly adapted.
More and more routine tasks moved to the agent.

I learned about rules, connected MCPs (Figma MCP is 🔥 for frontend).
Cursor also kept adding bonus credits — roughly +$80–90 on top of a single monthly subscription.

I still mostly used it for routine tasks — cases where:
– everything is clear
– I can quickly validate the result
– and fix things manually if needed

5. Cursor $20 + Claude Code $20
I kept hitting Cursor’s limits and decided to try the already hyped Claude Code in parallel.

I had heard about skills and sub-agents, but never really touched them (now they are also available in latest Cursor version).
I spent ~45 minutes experimenting non-stop, building my first custom skill... and hit the 5-hour limit before it was even ready.
Opus 4.5, thinking mode.

Pain.
Sadness.
Now what?

6. Cursor $20 + Claude Code $100
Relatively recently, I upgraded to the 10× Claude Code plan.

If you want to actually experiment with agents, sub-agents, skills, and hooks — iterate, break things, rebuild — upgrading the subscription starts to make sense.

My current setup:
– simple tasks → Cursor (with composer-1). Works surprisingly well.
– more complex tasks → Claude Code (Sonnet 4.5 or Opus 4.5)

What is your setup?

AI can ship your UI faster — unless your Figma is chaos

Implementing mobile layouts is boring work. You're essentially a human compiler — copying padding values, font sizes, and color codes from Figma to your IDE. No creativity, no challenge, just routine.

I tried using Cursor with design screenshots. It would generate something similar, but never accurate enough:

- Inconsistent spacing values
- Wrong font sizes and weights
- Slightly off colors (`#2A2A2A` instead of `#1F1F1F`)
- Design icons replaced with similar ones from MaterialIcons

Then I discovered Figma MCP and everything changed.

Yes, it costs €12/month, but it's worth every cent.

Figma MCP is a bridge between Figma and your coding agent. It provides tools that allow the agent to extract actual design data — variables, styles, and metadata from selected frames. It also provides screenshots so the agent can understand the visual semantics. Combined, the agent gets both the precise design tokens and the visual context.

The results are significantly better.

But here's the critical part — and this is where most setups fail:

The designer must follow atomic design principles

Your designer needs to:

1. Create design tokens (atoms) — colors, fonts, spacings as variables
2. Build components (molecules) from these tokens
3. Compose screens from these components

Think of it as a proper design system hierarchy.

My workflow

As a Flutter developer, I use the AI agent with Figma MCP for the entire process:

1. Tokens → AppTheme
The agent generates color tokens (like primary500, error300`), typography (`heading1, body2`), and spacing (`spacing8, `spacing16`) with matching names from Figma.

2. Components → Reusable widgets
The agent creates Flutter widgets using these tokens.

3. Screens → Complete layouts
I feed the agent context: “tokens are in AppTheme class, components are in `lib/src/core/uikit`” or use a custom skill, and it generates screens using the existing code structure.

The key is naming consistency. When Figma tokens and Flutter code use identical names, the agent can reference them correctly.

Is it pixel-perfect?

No. I still need to review the generated code and make adjustments.

There's a way to make it more reliable using Flutter golden tests — the agent generates a component, compares it to the Figma screenshot, and if pixels don't match, it fixes the code and compares again. But this feels like overengineering for now. The feedback cycle can take too long for simple components.

Manual review is faster.

Garbage in, garbage out

I'm fortunate that my girlfriend creates proper design systems with clean component structure and consistent tokens. This saves me hours of manual implementation.

But I've worked with many designers who focus only on visual appeal without considering implementation. Their Figma files have random spacing values, inconsistent colors, and “components” that aren't actually reusable.

These designs look good but don't generate good code.

TL;DR

This approach eliminates the tedious part of mobile development. But it requires structured design files, not just pretty mockups.

Good design systems are the difference between AI generating production-ready code and AI generating something you'll need to fix manually anyway.

The question I ask at every interview

Once, at one of my first interviews for a mobile dev position, I was asked: what does "good code" mean to you? Since then, I often ask candidates the same question at the end of interviews. Not to evaluate — more out of curiosity.

The answer is almost always the same: readable, extensible, testable. SOLID, DRY, clean architecture. Juniors, mids, seniors — almost everyone says the same thing.

I used to think the same way. I'd agonize over layer structure, debate patterns, refactor before the feature even worked. It felt like the "right" way to code.
Now, with more experience, architecture just happens. You set up a foundation, work within it, adjust as you go. You don't overthink — you just know what fits. And once that's no longer something you struggle with, the real question surfaces: how fast can I deliver this feature? Not "is this abstraction elegant enough" but "is this in prod and solving the user's problem."

AI is reinforcing this mindset. An LLM can understand your codebase and write new code within its patterns. The architecture doesn't suffer — but the delivery speed multiplies.

That said — in real production work, AI doesn't magically make everything 10x faster. The bottleneck was never really the code itself. It's communication: unclear requirements, waiting for designs, going back and forth with the client. AI eliminates the slowest part of coding, but it exposes what was always the real problem — everything around the code. Which only reinforces my point: obsessing over code perfection was always misplaced energy. But that's a topic for another post.

So if someone asked me that same interview question today, I'd answer: good code is code that solved the problem, reached the user, and did it on time. Cleanliness is a means, not an end.

A while back I started diving into system design.

I got curious about how large-scale modern systems work, how and why their architecture is shaped the way it is. Decided to step outside the mobile dev bubble (wrote about that in my previous post).

I love learning and consume a ton of educational content now: books, conference talks, articles, all mixed together. But what really clicks for me is smart people who explain complex things simply.

So here are 3 lectures I want to recommend: Oleg Bunin's talks from HighLoad++ 2017 (1, 2, 3) as a solid foundation for system design. He walks through different approaches to scaling high-load systems one by one, then gradually moves into practice. Sure, some things are dated by now, but the fundamentals hold up.

I know that at least some of my friends who are really cool engineers are reading this. If you know similar resources that explain system design in a clear way, please share, I'd really appreciate it 🙏

Fun fact: back then (in 2017) VK had only about 20 developers 🫡