DEV Community: Nikolai Noskov

I Haven't Written Code by Hand for a Year. And I'm Not Going Back.

Nikolai Noskov — Fri, 06 Feb 2026 16:35:02 +0000

Note: This article was originally written in Russian and adapted for international audience. Original version on Habr

Hey dev.to! I'm a freelance developer from Russia. This is my take on AI-assisted development — not theory, but a year of real production experience.

TL;DR: Freelance developer, 2 years of experience, no CS degree. Grew income 6x in two years using LLM-first development. 100% of my code is now generated by AI. Projects in production, clients happy, team growing. Here's how it actually works — and why most skeptics haven't even tried it.

1. Numbers That Won't Convince Anyone

Two years ago I started freelancing at around $400/month. Now — $2,500/month. 6x growth. For context — that's solid money for Russia, roughly equivalent to a senior developer salary in Moscow.

I don't have a CS degree — just free online courses. Never worked at FAANG (or Yandex, our local equivalent), never wrote compilers, never contributed to major open source projects (though I'm itching to).

I build Telegram bots, Mini Apps, marketplace seller assistants, RAG systems, business automation. Small to medium projects for SMBs. Not enterprise — I've had a couple enterprise clients approach me, but we couldn't agree on terms. Probably for the best.

A year ago I stopped writing code by hand. Completely. And I don't recommend my interns do it either.

At first it was just iterative fixes — letting LLM handle unclear parts. Then I started providing more project context to chat-based models. Then came Cursor, Claude Code, Codex CLI. I wrote about my methodology in detail elsewhere — this post is more about the philosophy.

There was fear. Not doubt about the approach — actual fear. Like being afraid to forget how to walk. But it turned out — you need to stop walking to learn how to fly.

2. Concrete Cases

Let me be specific:

Marketplace Seller Assistant — $4,500. Bot that handles inventory, sales tracking, and reviews for Wildberries (think Russian Amazon). Sends notifications for new orders, pickups, cancellations, returns. Tracks critical stock levels relative to sales dynamics. Filters review notifications by star rating. Includes warehouse statistics, GPT-powered analytics with graphs over custom time windows. Competitor parsing, semantic core extraction from product descriptions for SEO. And the cherry on top — RAG for database queries via Postgres vectorization.

This isn't a landing page. It's an inventory management system with analytics, integrations, and AI features.

Virtual Try-On Bot — $1,300. Bot accesses product catalog with photos. User uploads their photo, GPT validates it, then we use an AI try-on service to show the product on them. User gets direct marketplace links plus size recommendations based on their measurements.

Online Backgammon in Telegram Mini App — $4,000. With betting in TON cryptocurrency via smart contracts — escrow contract that holds the bet pool and sends winnings to the winner minus platform commission. Yes, the kind of project where "boldness and madness win," as one commenter put it.

Prototypes for each stage — often with mocks — delivered in 1-2 weeks. Not months.

These are projects from the last 3 months. 100% of the code generated by LLM. All in production. Clients satisfied. Ongoing maintenance and expansion.

3. Honest About Failures

There was one serious failure that affected production. But the problem wasn't LLM — it was process.

Client showed me requirements — I quoted $5,000. Too expensive, they said. Can we do cheaper? So I cut everything to a narrow MVP (removed smart contracts, monitoring, switched backend from Go to TypeScript, bunch of other stuff). New price: $1,800.

I didn't set clear boundaries in the spec. Client started requesting things not mentioned initially. I kept agreeing — yeah, I was being an idiot. We lost context, documentation became outdated because we started building new features on top of an unfinished core. The core itself started falling apart and was hard to restore.

My mistake — agreeing without setting boundaries. Explained to the client that we shouldn't deviate from the spec like that. Resolved it, learned my lesson.

There were also cases where I missed deadlines due to wrong instructions for the AI. For example, not specifying in documentation that we strictly don't touch old code — only add new. Without this constraint, old logic started breaking, error cycles began.

Key insight: don't let AI constantly fix its own errors. You need to inject new context yourself, test hypotheses. That's the difference — a non-developer can't even guess where the bug is buried.

4. What Skeptics Say

Under my posts and in comments on other LLM-development articles — same arguments every time. Let me address specific quotes.

"Not checking code after LLM — that's bold. No documentation will save you from hallucinations"

Hallucinations exist. Bugs exist. And humans don't have bugs? The difference is I spend 10% of time on code generation and 90% on testing and debugging. Those 10% used to be not hours, but weeks. Documentation isn't protection from bugs — it's a way to maintain context and avoid loops. Without it, LLM starts circling through the same digested swamp.

"Obviously these are projects where error cost is negligible. Better not vibe-code an inventory management system"

But we do build inventory management systems via LLM — with statistics, analytics, RAG. Everything works. Question for the skeptic: have you tried building such projects with LLM yourself? From actual experience?

"I would never trust LLM with a critical project. Errors can surface from unexpected angles. The owner will suffer serious losses"

I've been running on this scheme for a year. There were complaints — but all resolved quickly. Within normal development error range. In terms of time and financial output — I see only positives. But I won't forget the warnings.

"If you're carefully checking the code — you spend more time than writing it yourself. You'll be slower than an experienced programmer"

Not true. I had experience with manual development, completed many projects and smoothly transitioned to LLM. By all metrics — time and financial output — I see only positives. Bot in 3 hours instead of 3-4 days. Landing page with backend in 3 hours instead of a week. This isn't theory — it's my reality.

"When the team has no awareness of the codebase, all decisions are 'fix it now', and there's no architecture in sight — things will go south"

Agreed. That's exactly why AI-driven doesn't mean without humans. Engineer is essential. LLM won't replace architectural understanding. But it will become the primary tool. Look at the dynamics: in 2023-24 I couldn't even imagine things like Cursor and Claude Code. What will exist in another two years?

"This won't last. We'll forget how to write code quickly by hand"

What does "won't last" mean? What's the practical point of coding by hand? It's slower for clients — they value speed, that's the main competitive advantage. They're willing to pay more for that speed.

At first I was tormented by thoughts that this is wrong, that I'll forget how to read and write code. But then I realized: it's analogous to how wooden abacuses were replaced by calculators, and calculators by Excel. This is progress. Resisting it costs you — in every sense.

5. About Interns

I hire beginners with minimal experience — primarily because their minds aren't cluttered with patterns, no rigid frameworks. People for whom this isn't their main activity — I can't yet afford to pay them full salaries. We agree on terms where they spend no more than 8 hours per week.

I get on calls and show them specifically on my project examples, on concrete tasks — live — how to manage AI. Then I give them real tasks. Always real, never toy projects. I get results, review, identify errors — and explain how to avoid them. Again, using LLM.

Two months is enough for people to become independent. So I don't spend much attention on them anymore. ROI is excellent.

One intern initially denied using LLM, was embarrassed about it. But when I showed how to work with documentation and tests — things took off. Now thinks like an engineer and architect, not a code-typing machine.

I have a student intern studying CS — they aggressively tell them in university that code must be written strictly by hand, that any projects suspected of generation will be rejected. So at first she also hid this fact, wrote slowly — until I clearly said: LLM only.

Now my intern builds a landing page with backend integration in 3 hours. I just explained the methodology. Used to be a week of work. She has free time for studies and even side freelance projects — how she works elsewhere is her business, but on our projects everything goes through AI.

When needed — I pay for interns' Cursor subscriptions, or CLI tools — Codex or Claude Code + show them how to set up Gemini CLI for free. I personally run on Claude Code, sometimes add Codex — that's enough.

Interesting observation: monthly LLM spending correlates with income. I spend no more than 2 subscriptions per month.

6. About Fear and Comfort Zone

Here's what really interests me: why do people with 10-15 years of experience, who've seen technology changes, frameworks, paradigms — suddenly dig in right here?

Simple answer: fear.

Not fear of technology. Fear that skills will depreciate — that years spent honing syntax, patterns, algorithms — will turn out not so important. That some guy without a degree from free online courses will do the same thing faster.

It's uncomfortable and painful. I understand. But it's not a reason to deny reality. Those who do everything through LLM will only grow in numbers.

I read comments: "yeah, probably cool, but I won't risk it on my projects." Or "too expensive." Or "let's wait until the technology matures." Or just "watching with curiosity, eating popcorn" (these are all real quotes from Russian dev community).

This isn't risk analysis. It's fear rationalization. Armchair analytics from those who haven't tried but already know it won't work.

I had no choice. No degree, no connections, no safety net of a salary. I just had to do it. Take it and do it — and it worked.

People develop linearly. One year of experience, two years, ten years. Gradually, predictably, on track. For example — setting a goal to read 1 more book per month than last, increase income by $500 per year — these are examples of linear development. The thing is, linear development hits physical limits — that's when it's time to change approaches, systems — need to increase not quantity, but quality.

The world develops exponentially. Three years ago ChatGPT wrote one-line Python functions. Two years ago — edited large files and found bugs. Now — Claude Code, Cursor, Codex. Entire systems in hours.

Think about this dynamic. Three years. Not thirty, not ten. Three.

Programmers used to be the ones driving this exponential growth. People created technologies that changed the world. Now a technology has appeared that we risk falling behind. It's not a threat — it's a paradigm shift.

A person developing linearly in an exponential world — degrades relative to that world. Not because they're stupid. The world just accelerates faster than they can keep up.

7. What Remains for the Engineer

Important point, so there are no illusions.

LLM doesn't replace understanding. You need to know what client-server architecture is. What HTTP requests are. How databases work. What microservices are. Why one solution is better than another. Without this — no Claude will help you. It's an amplifier, not a replacement. An army of juniors that needs an architect.

Expertise hasn't gone anywhere. It's shifted. Now the main skill is context management, documentation, design. Ability to hold the whole system in your head and decompose it into manageable pieces.

Honestly — this is harder than writing code by hand.

Seriously. Requires constant concentration, control, understanding what's happening under the hood. Not giving in to the temptation to let error resolution run on autopilot, not specifying clear constraints for a specific project. As my friend says — "head like a house of advisors." This becomes the main requirement.

AI-driven doesn't mean "without human." Engineer is essential. LLM just becomes the primary tool. Paradigm shift of tools — not singularity.

There won't be magic wands. There won't be AGI that does everything for you (not in the near future anyway). But there will be a tool that's already necessary to master — because it's the primary tool of an already-arrived future.

Last year the question wasn't this urgent. Now — it is.

Don't get on this train now — you're already late. You can sit in comments and explain why it won't work. Eat popcorn and watch. Or you can try.

I'm not evangelizing. Not selling courses. Not saying my path is the only one.

I just do. Show results. Write about it.

The world doesn't wait. It never did.

If you're interested in my methodology — I wrote in detail about documentation, TDD, and context management. Happy to share in comments.

Ready for tomatoes. As practice shows — it only adds views.

Feel free to ask questions — I'll answer what I can about working from Russia, LLM tools availability, or anything else.

I Don't Write Code Anymore. My Income Tripled. Here's the System Behind It.

Nikolai Noskov — Fri, 23 Jan 2026 10:22:10 +0000

Note: This article was originally written in Russian and adapted for international audience. Original version on Habr

Let me start with something that might get me roasted: I don't read code. I don't write it either, except for occasional debug logs. Everything I ship is generated by LLMs.

Before you close this tab, hear me out. This isn't another "AI will replace developers" hot take. It's the opposite, actually.

Over the last six months, my income nearly tripled. I brought on two junior developers. I'm handling bigger projects than ever. And paradoxically, I'm doing more engineering work than before, not less.

People keep calling this "vibe coding." I hate that term. What I do requires more discipline, more architectural thinking, and more systematic rigor than when I wrote every line myself.

Let me show you the system.

Quick background

I'm a freelance developer, 2 years in. Mostly Telegram bots and mini-apps, sometimes landing pages, smart contracts, or pentests. I work through freelance platforms, think Upwork/Fiverr equivalents.

Six months ago, I went all-in on LLM-assisted development. Not as an experiment. As my entire workflow.

Here's what happened:

Income: ~3x growth
Team: Found 2 junior devs who now work the same way
Project size: Went from small gigs to multi-month enterprise projects
Client satisfaction: Not a single complaint about quality

But getting here wasn't straightforward. I burned through a lot of failed approaches first.

The evolution: why chat-based AI didn't scale

Phase 1: The naive approach

Like everyone else, I started using ChatGPT for isolated tasks. Generate a function here, debug an error there. It worked... for small stuff.

As projects grew, this fell apart fast. I was constantly copy-pasting context, reminding the AI what files existed, re-explaining project structure. It was like having a brilliant colleague with amnesia who needed everything re-explained every 10 minutes.

Phase 2: Cursor, better but still broken

Switching to Cursor (AI-native IDE) solved the context problem. The AI could see my files. Great.

New problem: project structure started drifting. The AI would fix one thing and break another. Old bugs came back. Without explicit guidance, the codebase slowly turned into spaghetti.

That's when it clicked: the AI needed constraints. It needed a source of truth that wasn't the code itself.

The system: documentation as foundation

Here's the insight that changed everything: documentation isn't just for humans anymore. It's the primary interface between you and the AI.

I now create three layers of documentation for every project:

Layer 1: Client-facing specs

Stages broken down by what the client can actually see and touch. Not "backend first, frontend second", clients can't evaluate a backend. Instead: "User authentication flow," "Dashboard with live data," "Export feature."

Each stage has a price and timeline. Transparent. Clients love it.

Layer 2: Technical specs

Architecture decisions, data flows, integration points. Written in plain language, no code examples. This matters.

Why no code? Because code will change constantly. If your documentation contains code snippets, it becomes outdated the moment the AI adapts something. You end up with conflicting sources of truth.

Everything described in words. If I can't explain it without code, I don't understand it well enough.

Layer 3: Stage-specific deep dives

For each stage, I create ~4 documents:

Stage objectives and mechanics
Error log (more on this later)
API documentation (external services we're hitting)
Data structures and sources

For a 2-month project with 5 stages, I end up with ~20 markdown files. Sounds like overkill? It's not. This is what keeps the AI, and my own memory, on track.

Here's what a component checklist looks like in practice:

## Implemented Components

### Backend:
- `Cabinet` model with `spreadsheet_id` field
- `ExportService` with table update methods
- API endpoints for saving and updating
- Celery tasks for automatic export
- Google Sheets API integration

### Bot:
- "Export to Google Sheets" button in main menu
- Table binding handler
- FSM states for workflow
- Manual table updates
- User instructions

### Infrastructure:
- Celery Beat for scheduled runs
- Service Account configured
- Environment variables set
- Logging for all operations

The AI references this constantly. When it drifts, I point it back here.

The secret weapon: error documentation

This one technique probably saved me dozens of hours.

When a bug doesn't resolve in 2-3 iterations, and I see the AI starting to loop, trying the same fixes, going in circles, I stop and create an error document.

## Bug: Export fails silently on large datasets

### Known facts:
- Works fine for <1000 rows
- Fails without error message for >5000 rows
- Memory usage spikes before failure

### Attempted solutions:
- Increased timeout (no effect)
- Batch processing with 500-row chunks (partial fix, still fails at 8000+)
- Streaming approach (testing now)

### Hypotheses:
- Memory limit on serverless function?
- Google Sheets API rate limiting?

This document becomes the reference point. The AI won't suggest already-failed solutions because they're documented. I won't forget what we tried. The loop breaks.

I keep these even after fixing the bug. They save time on future projects with similar issues.

TDD: your safety net when you don't read code

Here's my time breakdown on a typical project:

5-10% actual code generation (AI does this fast, but it's always buggy)
25% writing documentation
15% writing tests
50% fixing errors, manual testing, client feedback

Notice something? Tests are the second source of truth, alongside documentation.

Documentation describes what should happen. Tests verify what actually happens. When these two align, I have confidence the code works, even though I haven't read it line by line.

TDD isn't new. But with LLMs, it becomes necessary. You're not reviewing every line of code. Tests catch what your eyes don't.

Context management: the art of fresh starts

LLMs degrade over long conversations. They start hallucinating, forgetting earlier decisions, contradicting themselves. You've seen this.

My solution: aggressive context compartmentalization.

New stage = new chat/agent
New feature within a stage = new chat
New bug = new chat
Architecture decisions = dedicated "architect" chat

Creating new chats is painless when you have documentation. Just feed the relevant .md files to a fresh agent, and it's up to speed in seconds.

The loop-breaking technique:

When an AI gets stuck in a loop, it's usually because it's churning through the same context over and over. The fix isn't better prompting, it's injecting new context.

Options:

Google the problem, paste in a StackOverflow answer or docs page
Ask a different LLM for suggestions, then feed those to your main chat
Throw in a wild hypothesis, even if it's wrong, it can shake loose new thinking

The more atomic your work units, the less this happens. Small, focused tasks = fewer catastrophic loops.

My current toolstack

For documentation and planning:

ChatGPT, Claude, Grok, I use whatever's available
Long conversations to hash out specs before touching code
Output: .md files that become project foundation

For implementation:

Claude Code (current favorite), works well in terminal, renewable limits
Cursor + Gemini CLI, Gemini is free but loops more often; sometimes it just... gives up mid-task
Cursor with Claude Sonnet for complex stuff, auto-select for simple tasks

Hot take on LLM spending:

If you know how to work with LLMs effectively, don't cheap out. My rough numbers: 80% increase in LLM costs led to 60% increase in income. Other factors contributed, sure, but the correlation is real.

Good tools pay for themselves fast.

What still sucks

Let's be honest about the limitations.

Smart contracts, especially TON: LLMs struggle hard here. Not enough training data, too many edge cases. I still have to dig through documentation manually and find examples myself.

TypeScript vs Python: Models are noticeably weaker with TypeScript. More hallucinated types, more incorrect generics.

The 1-in-5 problem: About 20% of my projects hit these rough spots. They all reach release eventually, but some require significantly more manual intervention.

My workarounds:

Keep documentation from old projects, reuse solutions that worked
Maintain a personal library of code patterns for tricky areas
Know when to stop fighting the AI and just write the code yourself

The team angle

I found two juniors who now work this way. One is still ramping up. The other has been with me for three months and it's working great.

Funny thing: at first he was embarrassed about using LLMs. Felt like "cheating." Then I showed him the documentation system, the testing discipline, the context management. He realized this isn't easier, it's just different.

Now he thinks like an engineer and architect, not a code typist. That's the shift.

What clients think: Not once has a client asked if I use AI. I don't hide it, but they don't care. They care that the product works, it's delivered on time, and the quality is solid. All true.

The real skill: engineering hasn't gone anywhere

Let me be clear: this methodology doesn't work if you don't understand development.

You still need to know:

How databases actually work
How requests flow through a system
Why one architecture is better than another for a specific use case
What trade-offs you're making

LLMs don't replace this knowledge. They leverage it. The AI is an amplifier, if you feed it garbage thinking, you get garbage code at scale.

The difference? I'm no longer a human compiler, translating logic into syntax. I'm a full-time architect who happens to have a very fast (and somewhat unreliable) junior dev typing for me.

If you don't understand what's happening under the hood, no amount of documentation or Claude subscription will save you. The system works because there's an engineer behind it.

So why isn't this "vibe coding"?

"Vibe coding" implies casual, low-effort, go-with-the-flow development. Vibes.

What I actually do:

Maintain 20+ documentation files per project
Write tests for code I haven't read
Constantly manage and reset AI context
Architect systems at a higher level than ever before
Debug through systematic elimination, not intuition

This requires more concentration than traditional coding, not less. The mental overhead of keeping documentation accurate, asking the right questions, catching AI drift before it compounds, it's exhausting in a different way.

You know what actual vibe coding is for me now? When I have free time, no deadlines, and I just... write code. By hand. For fun. Feel the keystrokes. Watch the logic flow.

That's become the luxury. The meditative escape from real work.

Traditional coding went from "the job" to "the hobby."

I'm not sure how to feel about that yet.

TL;DR

Documentation is your contract with the AI, no code examples, just clear descriptions of logic and architecture
TDD isn't optional, tests are your eyes when you're not reading code
Compartmentalize aggressively, new task = new chat, feed it relevant docs
Document your errors, break loops by creating a reference point for failed solutions
You need engineering fundamentals, AI amplifies competence, including incompetence
Invest in good tools, if you're effective with LLMs, premium subscriptions pay for themselves

Let's connect

I write more about LLM-assisted development and building a freelance dev business on my Telegram channel: @post_devcore (content is in Russian, but I'm considering English posts too).

What's your experience with AI-assisted development? Have you found workflows that actually scale, or is it still chaos? Drop a comment, I'm genuinely curious how others are handling this.

First time posting on dev.to, feedback on the article itself is also welcome!