The Bright Future Of Developers

The rise of agentic coding tools like Claude Code and GitHub Copilot Agent is reshaping software development. As the founder of a web development agency, I’ve witnessed firsthand the impact of these tools on our workflow. This is a revolution, with impressive productivity boosts. Many developers fear this change. I think they should embrace it.

The Rise Of Natural Language Developers

If you haven’t been paying attention, AI coding tools have crossed a threshold in the past months. Claude Code, Cursor, GitHub Copilot Agent – these aren’t your autocomplete on steroids anymore. They don’t get locked after a few prompts, they find their way in large code bases, they follow your coding conventions, and they manage to translate business logic into working code in record time.

This creates a new category of developer. Let’s call them Natural Language Developers. They’re not just “developers using AI tools.” They’re a fundamentally different breed. They think in systems and specifications, not syntax and semicolons. They solve the same problems but through an entirely different interface. Just like we distinguish between frontend and backend developers, between DevOps and QA engineers, we need to recognize this new specialization.

Natural language developers don’t write SELECT ... HAVING. They don’t Google “how to center a div vertically.” Instead, they specify business requirements and constraints, review the AI’s approach (not the syntax), test that the system behaves correctly, and iterate on the specification when needed.

Traditional vs Natural Language: An Example

Let me show you an example with an authentication system. A traditional developer would start by writing 30+ lines of code to register a new user:

import bcrypt from 'bcrypt';
import jwt from 'jsonwebtoken';
import { User } from './models';

export async function register(email, password) {
  const existingUser = await User.findOne({ email });
  if (existingUser) {
    throw new Error('User already exists');
  }
  
  const salt = await bcrypt.genSalt(10);
  const hashedPassword = await bcrypt.hash(password, salt);
  
  const user = await User.create({
    email,
    password: hashedPassword,
    createdAt: new Date()
  });
  
  // Generate token
  const token = jwt.sign(
    { userId: user.id, email: user.email },
    process.env.JWT_SECRET,
    { expiresIn: '7d' }
  );
  
  return { user, token };
}

Time spent: 30 minutes, including reading the docs for the jwt and bcrypt packages, seeding the database, testing and debugging. That’s a good first step, although the code is missing error handling, input validation, and rate limiting.

A natural language developer, on the other hand, would open Claude Code and type:

Create secure authentication with:
- Email/password registration and login
- JWT tokens expiring after 7 days
- Proper error handling for existing users
- MongoDB/Mongoose for database
- Rate limiting to prevent brute force attacks
- Email verification flow

The AI would generate not just the registration function, but the entire authentication module with login, password reset, email verification, and rate limiting. All following current best practices.

Time spent: 10 minutes.

The natural language developer might not know what “brute force attacks” technically means, but they know it’s required from the security checklist.

The result? Same functionality, fraction of the time, and often better code (the AI doesn’t forget error handling or skip input validation).

The Pattern of Programming Evolution

If you’re a developer, you might be feeling uneasy. “We can’t trust code written by AI,” you think, “especially an authentication system!”. We’ve seen this pattern before.

In the 1970s, “real programmers” wrote assembly. When C appeared, they scoffed. “C programmers aren’t real developers,” they said. “They don’t understand what the machine is doing.” But C programmers, thanks to structured programming, lexical variable scope and recursion, could build sophisticated systems that were out of reach for assembly developers.

Then came the memory management revolution. C programmers spent hours tracking pointer errors, managing every malloc() and free(). When Java introduced garbage collection, they cried: “This is terrible! How can you not know when memory is freed? The performance overhead!” Yet Java developers, freed from an entire class of problems, could tackle the challenge of building complex web applications with object-oriented programming.

Today, no JavaScript developer reviews the V8 bytecode their code produces. When you write array.map(x => x * 2), do you think about machine instructions? CPU cache misses? 99% of web developers have never managed memory manually. They build Netflix-scale applications without thinking about pointers.

Each abstraction freed developers from lower-level problems and let them focus on solving higher-level problems. Assembly programmers worried about registers. C programmers worried about memory. JavaScript developers worry about state management and API design.

Now it’s happening again – but this time, we’re abstracting away syntax itself.

Every major leap in programming follows the same pattern:

1. Resistance: “That’s not real programming”
2. Productivity explosion: Early adopters deliver software faster than ever before
3. Acceptance: Developers adapt, new developers come to the market, and the new way becomes the standard way
4. New problems emerge: Higher-level challenges replace lower-level ones

Each transition seemed like “dumbing down” the profession. Each made us incomparably more productive.

We’re at step 1. The productivity gains are already undeniable. In my opinion, steps 2-4 are inevitable.

Skills That Matter Now

Natural Language Developers need distinct competencies. These aren’t “soft skills” – they’re technical abilities that coding schools must now teach.

1. Specification Writing

Compare these prompts:

❌ Bad: “Make a login form”

✅ Good: “Create responsive login with email validation (RFC 5322), password strength indicator, remember me checkbox, ARIA labels for accessibility, and frontend password hashing before submission. Upon login error, display a user-friendly message and allow for quick correction. Use the same error message for missing email and wrong password”

This example underlines the difference between “Vibe Coding” and “Delegating to AI.” The devil is in the details, and if you let the AI invent these details, there’s a 100% chance that they won’t match the specifics of your application.

2. System Design

❌ Bad: “The system is super slow”

✅ Good: “The sync initialization process takes too long, causing delays in user interactions. Re-evaluate the bootstrapping strategy and consider using async workers and lazy loading to improve responsiveness.”

Coding agents struggle with generalization in general, and seeing the “big picture” in particular. We still need human oversight to connect the dots, with an architect mindset. This implies good technical understanding of microservices vs monoliths, database normalization, API design, security patterns, etc.

3. Development Process

❌ Bad: “The emailing agent fails to address customers with late payments. Fix it.”

✅ Good: “Generate a test dataset with all the possible customer situations (registered, late payment, cancelled, etc.). Then, build a comprehensive email template that covers each scenario. Write some unit tests to prove it.”

What developers have learned over the years (TDD, software craftsmanship, etc.) is still necessary and will speed up the development process a great deal.

4. Iterative Refinement

❌ Bad: “Build a mobile voice recorder that fills up candidate assessment forms”

✅ Good:

1. Build a zod schema for the candidate assessment form
2. Add the ability to fill the form based on a text transcription and the Zod schema
3. Add a function to transcribe an audio recording to a text transcription
4. Add a simple voice recording UI with play/pause
5. Integrate the recorder with the transcription service
6. Integrate the transcription with the form and render the results
7. Make the entire flow asynchronous, allowing for real-time updates
8. Make the UI responsive

This one may be a bit counterintuitive. AI agents rarely nail complex tasks first try. The best way to improve their output is to ask them to achieve a simple task first, then add features little by little. How to order these features also requires a good understanding of the possible implementations.

5. Behavior Testing

describe('Payment System', () => {
  it('handles concurrent payments correctly', async () => {
    // Launch 100 parallel attempts
    // Verify only one succeeds
  });
});

Behavior-driven development is about to become an absolute must. I tend to think that writing BDD tests is the only part of our software that we should NOT delegate to AI.

Many traditional developers already have these skills ; they’re the most likely to excel in this new landscape.

New Problems for a New Era

When developers stopped worrying about memory management, they started working on distributed systems, microservices, API design, and state management. Similarly, Natural Language Developers will probably face entirely new challenges. Some of these are emerging now:

• Low Reliability: AI agents fail at least ~5% of the time. Not syntax errors you can catch with a linter – logic errors, subtle misunderstandings, edge cases the AI missed. How does a program recover from an AI mistake? Should you run several agents on the same task and wait for a quorum to agree on the best solution? Should you use an AI judge to review other AIs’ work?

• Security: It’s currently super easy to bypass the guardrails of LLMs to have them explain how to make a bomb. Prompt injection is a reality. To put it differently, an application built by an AI should be considered vulnerable by nature. Natural Language Developers will need to implement new control flows to keep the user safe even though their tools are compromised.

• Specification Versioning: Natural Language Developers express features via chat conversations. How do we review and track those evolving specs to prevent regressions? Traditional “documentation as code” breaks down if developers rarely open source files. We need a versioned, plain‑English, living spec synced to the dialogue history—Git‑style diffs, but for intent.

• Agent Orchestration: Natural Language Developers already ask multiple AI agents to work on different parts of a system (e.g., building the API, creating the admin interface, setting up the database, writing tests, deploying to production). In production, several agents collaborate in real time. We’ll need tools and good practices for that. Like conducting an AI orchestra where each musician is brilliant alone but needs coordination to create harmony.

Every day, a new challenge emerges from the intersection of AI capabilities and software development needs. I think that’s the proof that there will be a growing demand for developers who can effectively communicate with and manage these AI systems.

The Three-Tier Future

So it seems the skills of traditional developers will still be in demand. Where does that lead us? In the next few years, we can expect to see three distinct types of developers:

Natural Language Developers (70%)

They speak “specification,” not code. They understand systems, architecture, and business logic, but might not know const vs let.

Their toolkit:

• Claude Code, Cursor, or similar AI agents
• Natural language specification skills
• System design understanding
• Domain expertise

AI-Augmented Traditional Developers (25%)

Can code but primarily work through AI. They review AI-generated code, debug complex issues, and step in when Tier 1 hits walls.

Their toolkit:

• Traditional IDEs with AI integration
• Code review and debugging skills
• Mastery of at least one programming language
• Deep understanding of low-level problems (e.g., memory management, concurrency)
• Knowledge of software architecture patterns

I am here, just like my co-workers.

Foundation Developers (5%)

Someone needs to maintain V8, write drivers, build the AI agents themselves. They work on foundational layers everything else builds upon. The assembly programmers of our era.

This isn’t a hierarchy – it’s an ecosystem. We need all three.

I also expect demand for every kind of developer to surge. As software creation becomes cheaper and more accessible, the buy‑versus‑build balance will shift toward building. Anyone who used Excel or no-code tools will be able to create software solutions tailored to their needs. Natural language development isn’t about making programming easier – it’s about making it more accessible.

Of course, the future is highly uncertain and I’m probably wrong. But I think that a future where developers continue to write 100% of their code is as unlikely as a future where human developers are completely replaced by AI.

The Code Was Never the Point

Natural Language Developers are coming. I don’t think traditional developers should fear this change. We all follow the same purpose: to create software that solves problems. There will be enough work for everyone.

I’m not a tech enthusiast, and I’m very skeptical of the AI hype in general. I am also reluctant to use a technology that amplifies bias, is based on copyright theft, emits way too much greenhouse gas, and is in the hands of already powerful corporations. But this revolution is happening whether we like it or not.

I’ve been programming for 30 years. I have written code in BASIC, Pascal, Java, PHP, JavaScript and Go. I have debugged race conditions, optimized databases, designed APIs. And I’m excited about what’s coming. Not because it makes my skills obsolete – but because it frees me from the mundane and gives me superpowers to solve bigger and more important problems.

The irony? We might be writing the last human code in history.