The Rise of AI-Assisted Programming: Will AI Really Replace Developers?

I remember the exact moment I got scared.

It was late, I was building a data table component I'd built maybe thirty times before, and I typed a comment describing what I wanted. Three seconds later the whole thing appeared — sorting, pagination, the works. It wasn't perfect. But it was good. Good enough that my brain went, "oh. oh no."

That was a while ago now. Since then I've had time to sit with the feeling, use these tools every single day, watch juniors learn with them, and watch a few teams get burned by them. So let's talk properly about AI-assisted programming — not the LinkedIn hype version, and not the doom version either.

Spoiler: the answer to "will AI replace developers" is more interesting than yes or no.

What Actually Changed in the Last Few Years

Autocomplete has existed forever. What's different now is that the suggestions understand intent, not just syntax.

Modern coding assistants read your open files, your imports, your naming conventions, sometimes your whole repo. They don't just finish the line — they propose the function, the test, the migration, and occasionally an entire feature branch. Agentic tools can now run your test suite, read the failure, and patch itself in a loop.

The numbers floating around are genuinely striking. GitHub's own research has claimed developers using Copilot completed a scripted task around 55% faster. Various enterprise surveys put perceived productivity gains anywhere from 20% to 40%.

But — and this is the part that gets clipped out of the headlines — other studies have found something more uncomfortable. A 2025 METR study of experienced open-source developers working on their own mature codebases found they were actually about 19% slower with AI tools, even though they believed they'd been faster.

Both things are true. That contradiction is the whole story, honestly.

Where AI is genuinely, undeniably faster

• Boilerplate. CRUD endpoints, form validation, config files, DTOs.
• Unfamiliar syntax. Writing a regex, a bash one-liner, a Dockerfile you'd otherwise Google.
• Test scaffolding. Especially the tedious edge cases you'd skip when tired.
• Translation. Python to Go, jQuery to React, SQL to an ORM query.
• Explaining code. Paste a horrifying legacy function, get a plain-English summary.
• First drafts of documentation, which let's be real, nobody was writing anyway.

Where it quietly wastes your time

• Large codebases with heavy internal conventions the model has never seen.
• Subtle business logic — it'll write confident code that's subtly, expensively wrong.
• Debugging race conditions and performance issues that need real system understanding.
• Anything where the hard part was deciding what to build, not typing it.

The Skill Nobody Warned Us About: Reviewing

Here's the shift I don't think we talk about enough.

Writing code and reviewing code use different mental muscles. Writing is generative — you hold the problem in your head and build outward. Reviewing is critical — you hold someone else's assumptions and hunt for the crack.

AI-assisted programming quietly turns you from mostly-writer into mostly-reviewer. And reviewing is tiring in a different way. You can review three hundred lines of plausible-looking AI output and miss the one place it used <= instead of <, because your brain is in "looks fine" mode rather than "I built this and I know why every line is here" mode.

This is where the real danger lives. Not job loss. Comprehension debt.

Comprehension debt, explained

Technical debt is code you know is bad. Comprehension debt is code in your repo that nobody on the team actually understands. It passed review because it looked reasonable. It passed tests because the AI also wrote the tests, using the same wrong assumptions.

Six months later something breaks in production at 3am and nobody can explain why that caching layer exists. That's the bill coming due.

The fix isn't complicated, it's just unglamorous: don't merge code you can't explain out loud. That's the whole rule. If you can't describe what a block does and why it's there, you're not done reviewing it.

So... Will AI Replace Human Developers?

Let me reframe it, because "replace" is doing a lot of heavy lifting in that question.

Think about what a developer actually does in a week. Maybe — generously — 30% is typing code. The rest is: understanding a vague request from a stakeholder, figuring out what they actually meant, deciding on tradeoffs, negotiating scope, reading existing systems, debugging, reviewing, deploying, and cleaning up when something explodes.

AI is spectacular at the 30%. It's mediocre-to-useless at most of the rest, because the rest requires context that lives in human conversations, not in your repo.

Nobody has ever handed me a perfectly specified problem. Real requests sound like: "Can we make the checkout less confusing?" Turning that into a decision is the job. It always was.

What's genuinely at risk

I'd be lying if I said nothing changes. The roles under real pressure are the ones where the output was volume of standard code:

• Generic template-conversion work (PSD-to-HTML style tasks).
• Simple, repetitive landing page and brochure-site building.
• Basic data entry scripting and one-off spreadsheet automation.
• Very junior roles defined purely as "implement this exact ticket."

In Indonesia specifically, this hits the lower end of the freelance market first. If your pitch on a marketplace was "I'll build your company profile site for two juta," you're now competing with a client who can prompt a decent one themselves in an afternoon. That's real, and pretending otherwise isn't kind.

What's getting more valuable

• System design. Someone has to decide the architecture the AI writes into.
• Debugging and observability. More generated code means more mystery bugs.
• Security review. AI reproduces insecure patterns from its training data constantly.
• Domain expertise. A dev who deeply understands logistics, or fintech regulation, or healthcare workflows is worth more than ever.
• Communication. Translating between business and technical stays stubbornly human.

The pattern is clear: judgment appreciates, typing depreciates.

The Junior Developer Problem

This one worries me more than anything else, and I want to be honest about it.

Traditionally you learned by struggling. You'd hit an error, not understand it, read Stack Overflow for forty minutes, try four wrong things, and finally get it. That struggle was inefficient — and it was also how the knowledge got welded into your brain.

Now a junior hits an error, pastes it, gets a fix, and moves on in thirty seconds. Faster output. Shallower learning. They ship more and understand less, and they often can't tell the difference, because the code works.

If you're early in your career, do this

1. Try first, ask second. Give yourself fifteen honest minutes on a problem before prompting. The struggle is the curriculum.
2. Always ask "why." When you get a fix, ask the AI to explain the root cause. Then explain it back in your own words.
3. Build one thing per month with zero AI. Small. Ugly. Entirely yours. This is your gym.
4. Read code more than you generate it. Pick an open-source repo you admire and just... read.
5. Learn fundamentals deliberately. HTTP, data structures, how databases index things, how memory works. AI is weakest exactly where fundamentals matter, and those don't go stale.

Juniors who use AI as a tutor will accelerate enormously. Juniors who use it as a crutch will plateau at year two and not understand why they keep getting stuck.

How to Actually Work Well With These Tools

Practical stuff I've settled into after a lot of trial and error.

Give context, not commands

"Write a login function" gets you generic slop. Compare:

"Write an Express login handler. We use PostgreSQL with the pg library, bcrypt for hashing, and JWT stored in an httpOnly cookie. Rate limit to 5 attempts per 15 minutes per IP. Return 401 with a generic message on failure — don't reveal whether the email exists. Match the error-handling style in the file I have open."

Same tool. Wildly different output. The specificity is the skill.

Work in small chunks

Ask for one function, review it, then ask for the next. Requesting an entire feature at once produces a wall of code that's psychologically hard to review honestly — you'll skim it and hope. Small diffs keep you actually in control.

Never trust it on security or money

Auth flows, payment logic, permission checks, anything touching PII. Use AI for a draft if you like, then review it like a stranger wrote it while drunk. Because functionally, that's the situation.

Keep a project context file

Most modern tools support a rules or context file in your repo. Put your conventions there — folder structure, naming, preferred libraries, testing approach. Ten minutes of setup, and every suggestion afterward fits your codebase instead of some average of GitHub.

An Honest Look at the Tools

GitHub Copilot

Pros: Best-in-class inline completion, works in basically every editor, mature and stable. The one I'd recommend to someone who wants one thing that just works.
Cons: Weaker at large multi-file refactors than the agent-first tools. Free tier is limited. [AFFILIATE LINK PLACEHOLDER]

Cursor

Pros: Whole-codebase awareness is genuinely a different experience — multi-file edits feel like pair programming with someone who's read everything.
Cons: It's a whole separate editor, so you're rebuilding your setup. Can get expensive on heavy use, and it's very easy to over-rely on. [AFFILIATE LINK PLACEHOLDER]

Claude Code / CLI agents

Pros: Excellent for terminal-native workflows, big refactors, and reasoning through gnarly bugs across many files.
Cons: Steeper learning curve, and agentic runs can burn tokens fast if you're not watching. Not ideal as a beginner's first tool.

A note on cost in IDR

Most of these run around USD 10–20 per month, so roughly 160–330 ribu. For a working dev that's trivially worth it. For a student, it's real money — start with free tiers, and check whether you qualify for GitHub's free student pack. Plenty of people are productive on the free options alone.

What I Actually Think Happens Next

My honest prediction, for whatever it's worth: the number of people writing software goes up, not down.

Every time programming got easier — compilers, high-level languages, frameworks, cloud — people predicted fewer developers. Every time, we got more, because cheaper software meant more things were worth building. Automating spreadsheets for a twelve-person business in Semarang was never economical before. Now it might be.

What changes is the shape of the work. Less typing, more deciding. Less "how do I write this," more "should this exist, and what breaks if it does." Teams get smaller and more senior. The bar for "junior" rises uncomfortably.

Is that scary? A bit, ya. But developers have never actually been paid to type. We've been paid to solve problems reliably, and that job just got a very fast, very confident, occasionaly wrong assistant.

Your Next Steps

1. Pick one tool and use it daily for a month. Opinions formed from headlines are worthless here.
2. Set a personal rule: nothing merges that you can't explain to a colleague.
3. Audit your own work. What percentage is stuff AI does well? If it's over half, deliberately start building the other skills.
4. Go deep on one domain. Fintech, logistics, healthtech, whatever. Context is the moat.
5. Keep one no-AI project alive. Same reason people still lift weights in a world with forklifts.

AI isn't coming for developers who think. It's coming for tasks. Move up the stack toward judgment, and honestly, this is one of the most interesting times to be doing this job.