Lasha's blog

How I Code These Days

tl;dr: I don’t code the way I used to. These days, AI is part of my workflow — but not in the “vibe coding” sense. I use it as a collaborator, a judgment-free partner, and a multiplier for my own engineering skills.

How I Feed on New Ways of Coding

I’ve been coding long enough to notice that my habits keep changing. I feed on new ways of coding. Sometimes that means picking up a new editor trick, sometimes a new framework, and lately it means coding with AI in the mix.

What surprised me most isn’t just the speed boost — it’s how AI changes the experience of programming. It’s like having a patient, judgment-free pair programmer always open in a separate window. I can ask it the “stupid” questions I’d never dare post on Stack Overflow. I can say, “Explain this Unix command like I’m five,” and it will.

That might sound small, but it completely changes how I approach new languages or tools. For the first time in years, being a beginner feels fun again.

This article is my attempt to capture what that looks like in practice — not vibe coding, not outsourcing everything, but something I think of as AI-augmented engineering.

My Approach to Coding with AI

The way I code today isn’t for everyone. It’s not aimed at beginners who are still learning loops and syntax. It’s for developers who already understand architecture, patterns, and quality.

That’s why I didn’t call this piece “How I Vibe Code These Days.” There’s a fundamental difference between vibe coding and AI-augmented engineering.

My goal is not to let AI “do the coding for me.” My goal is to learn how to scale my engineering capabilities. I keep asking myself:

This isn’t about speed at all costs. I think there are two ways to go fast:

  1. Fail fast — iterate quickly, learn quickly, but often leave a messy codebase behind.
  2. Build strong foundations — think first, design well, accept the initial slowdown, and end up faster in the long run.

I’ve tried both. I’ve seen others try both. And the truth is: despite the slowdown at the start, the second approach wins every time. You end up more agile and sustainable in the long run.

Even at FAANG scale, engineers are reporting the same lesson. One senior SWE described their workflow as starting with a technical design document that gets shredded in review by senior engineers before any coding begins. That’s front-loading the pain. And it’s exactly the same philosophy I follow: AI works best when the foundation is solid.

Why This Matters

Before I explain how I code with AI today, let me emphasize something: you are part of the equation.

I see it as:

you_engineer * AI = 3x you

You bring the skills, the patterns, the architectural judgment. AI multiplies that. But without your direction, you don’t get good code — you just get faster bad code.

It’s the same mistake people make about leadership. Empowerment doesn’t mean “do whatever.” It means guiding and reviewing so the team produces the right outcome. The same applies here: AI-augmented engineering requires you, the engineer, to steer and review.

That means reviewing not just the plan but also the code produced by agents. Unless you’re working on a throwaway prototype, skipping that step will haunt you later.

This is the line between AI-augmented engineering and AI-vibe-led engineering. The first makes you better. The second just makes a mess faster.

My Dev Setup

I’ve completely moved away from traditional IDEs like Cursor in favor of a terminal-based workflow. While this might sound extreme, it actually unlocks the kind of productivity I’m striving for.

My stack:

The magic isn’t in the tools themselves, but how they combine. I can spin up isolated dev environments for each feature branch, complete with their own Claude Code instances, database connections, and dev servers.

The real win is context switching. I can jump between three different features almost instantly, without losing flow. That keeps me in the zone.

Running Claude Code

I use git worktrees to run Claude Code instances in parallel on separate branches. Each gets its own folder, configs, and Tmux window — so agents don’t step on each other.

I also have user-based memory configured for Claude Code, which lets each instance “remember” context across sessions. That makes it far easier to keep continuity across tasks without starting from scratch. If you’re curious, I’ve documented my setup here: Claude user memory config.

I have a script that:

  1. Creates a new git worktree
  2. Copies over ignored files (env vars, configs)
  3. Launches a new Tmux window with Vim, Claude Code, and servers running

It’s basically “press one button, get a full dev environment.”

👉 If you’re curious, check out this article by Tadas Antanavicius, co-creator of Pulse MCP. It explains the setup in detail.

Puppeteer and PostgreSQL MCP

AI works best when it can test its own output.

That’s why I connected Puppeteer and PostgreSQL as MCPs (Model Context Protocol) to Claude Code.

When AI can test and debug its own work, the quality goes up dramatically. I’ve seen output improve by an order of magnitude.

How I Actually Code

Here’s my workflow:

  1. Plan together — I sit down with Claude Code and outline the feature, details, and requirements.
  2. Lay the foundation — I create the structure: classes, interfaces, patterns, test cases.
  3. Let AI build — Only after the foundation is set do I let Claude Code implement.

Sometimes I’ll also flip this around and use AI in a Test Driven Development (TDD) style. Let it write the first draft of tests, then implement the code against those tests. This is exactly how some big teams are starting to use AI — not as the coder of record, but as a tireless assistant in TDD.

AI also helps in reviews. It won’t replace my judgment, but it’s surprisingly good at surfacing inconsistencies or pointing out missing edge cases. Think of it as a second reviewer who never gets tired.

Wrapping Up

Claude Code was an inflection point for me. It enabled me to parallelize work and speed it up anywhere from 1.5x to 4x. I’ve built features in hours that would’ve taken me days.

And here’s the key part: I’m not ashamed of the code. It’s solid.

I learned the hard way that skipping review is a mistake. Reviewing isn’t just a safety net — it’s what makes this workflow sustainable. Over time, reviews teach you how to prompt better, organize work smarter, and parallelize effectively.

It doesn’t come free. It takes practice. But it pays off.

If you want to try it, start small. Add one feature with AI in the loop. Document as you go. Then expand.

The Future of Programming (and Why Nobody Knows Anything)

I’m fascinated and cautious about where programming is heading with AI.

Some say AI is the end of programming. Maybe. Maybe not. Honestly? Nobody knows.

That’s rule number one: no one — not me, not the smartest researchers, not the loudest influencers — actually knows what programming will look like even six months from now. Right now we’re probably at peak hype. It feels like drawing a line through the first two dots on a chart and declaring it’s going up forever. Sometimes it just flattens.

That’s why my advice to junior programmers is simple: don’t learn programming to predict the job market. Learn it because you enjoy it. If it turns out to be a hobby later, you won’t regret it.

On “Vibe Coding”

AI has introduced this new idea of “vibe coding” — where you ask AI to generate code, then you poke at it until it works.

I’m skeptical.

Here’s why: learning requires doing. You don’t learn guitar by watching YouTube videos; you learn by putting your fingers on the strings. Same with programming. If you never type the code yourself, the skill just doesn’t stick.

I’ve felt it personally: when I let AI write too much, I can almost feel competence draining out of my fingers.

To me, vibe coding is perfect for non-programmers. It’s like Excel for accountants — it lets them build things without becoming full-time developers. That’s wonderful. But it doesn’t make you a programmer.

And as for “prompt engineering” — the idea that editing AI output is somehow a superior skill? I think that’s a pipe dream. Editing is the reward for being a good writer, not a replacement for learning to write.

Right now, AI even fails like a junior developer: fix one thing and it breaks three others. It produces a shiny veneer, but underneath, it’s full of flaws. That’s why vibe coding is dangerous if you actually want to learn.

Closing Thoughts

AI is not replacing programming just yet. It’s reshaping it. Maybe one day, manual coding will fade from the mainstream — or maybe we’ll still be here, fighting with indexes and debugging broken builds.

Nobody knows. And that’s the point.

What I do know is this:

Because the future of programming might be uncertain, but the joy of building things is not.