DEV Community: Joseph Barron

How Software Development is Changing Forever, and How You'll Need to Change With It

Joseph Barron — Wed, 08 Jan 2025 08:53:46 +0000

I'm sorry, you'll probably find this is a really long article. From the title, you probably think I'm either about to about to profess the infinite glory of AI — or proclaim how it will gradually end the world and take your job.

But I promise that's not what this is. In fact, since you're reading this here on Dev.to, I promise to tell you why you're likely to do well in a post-AI world.

For as long as programming has existed, one thing has remained constant: it’s always been about writing code. Despite how computing has changed over decades, one thing has remained the same... we write code, and the machine follows our instructions.

Today, tools like Copilot, Cursor, and ChatGPT are turning that process on its head. AI doesn’t just follow instructions; it helps create them. You describe what you need, and it spits out code that gets you halfway there—sometimes further.

It feels unbelievable.

But it raises unsettling questions. If AI gets better at writing code, what’s left for developers? Is this the end of a decades-old career—or the beginning of something far greater?

The best programmers I know are not intimidated by the hallucination-riddled outputs of ChatGPT and Claude. But the history of computing suggests that these programmers shouldn't be so confident that the world won't demand that they adapt anyways.

The Next Big Abstraction in Computing

Each shift in the evolution of how we produce software has been a story of abstraction. The amount of data needed to build an application has not decreased over time, it's gotten larger. But the words we use to describe that data have become more expressive and succinct.

Assembly Language: No more punch card systems or painstakingly producing machine code by hand. With assembly, developers could write instructions using a more human-readable syntax, abstracting away the binary intricacies of hardware. This meant they could shift focus from managing individual bytes to designing and building more complex systems—operating systems, rudimentary user interfaces, and early software applications. It was a big first step toward programming as we know it today: enabling humans to communicate with machines without needing to speak like one.
Compiled Languages: Portable, high-level code revolutionized programming. Instead of writing instructions specific to a machine’s hardware, developers could write code in high-level languages like FORTRAN or C, which compilers translated into optimized machine code. This abstraction allowed developers to focus on solving complex problems rather than worrying about hardware-specific details. The result? The rise of portable, scalable applications—from enterprise systems to the software that powers our everyday lives. It wasn’t just about making programming easier; it was about opening the door to larger, more ambitious projects that transformed industries.
Interpreted Languages: Languages like Python and JavaScript took abstraction a step further, prioritizing ease of use, flexibility, and platform independence. With interpreted languages, developers didn’t need to compile code into machine instructions—they could write and run programs dynamically, often with instant feedback. This democratized programming, making it accessible to people who didn’t have traditional technical backgrounds. Despite being notorious for quirks and inefficiencies, these languages fueled the web and app revolutions, enabling entire ecosystems of innovation. Today, countless communities thrive around building micro-SaaS apps, games, and experimental projects that wouldn’t have been possible without these accessible tools.

If history has taught us anything, it’s that new tools don’t eliminate jobs—they create them.

A guy in 1957: "A compiler could never outperform my hand-crafted machine code."

Programming originally meant managing every detail—manually allocating memory, writing low-level code tailored to specific hardware, and understanding every intricacy of the machine. A skillset that was incredibly niche and difficult to acquire. Today's students can effortlessly render their React pièce de résistance in any environment that can run a browser, without worrying about the nitty gritty details. Each leap in abstraction has not only made programming complex systems easier but has also unlocked countless new opportunities, expanding what’s possible with far less effort.

I believe AI-assisted coding fits neatly into this ongoing story of abstractions. Each transition in the evolution of programming has shared a central theme: that code can be represented as data. Every paradigm shift has been about abstracting how we describe and manipulate that data. Large language models take this abstraction one step further: they allow us to represent code (and anything else generative AI can produce) in the form of natural language.

Natural Language: Generative LLMs have unlocked a form of software development that was previously relegated to niche artisan programming languages: the ability to build applications using plain English. Well, almost. While these models can “autocomplete” their way to appearing technically proficient, achieving reliable and precise outputs still requires significant technical expertise. However, their advancing capabilities give us a preview of an inevitable future where natural language programming is the de-facto way to produce software.

What Changes for Developers?

Unlike many of the previous paradigm shifts in computing, AI is not just abstracting code... it is also abstracting effort itself. A strong developer can describe in detail what they need, and an AI can nearly handle the rest. "Agentic" tools are becoming capable of brainstorming and planning somewhat autonomously—at least, they give the appearance of doing so. The code these programs write won't necessarily pass the sniff test of the top programmers (in fact, the code might not even run), but it doesn't seem like we're far away from getting consistent and reliable outputs.

AI also isn’t a deterministic tool in the toolbox, like a compiler. There's a degree of chaos and unpredictably that, when combined with its approximate knowledge of many things, enables it to act as a pretty good collaborator. Even if you don't use the code it writes directly, you might find it's a wonderful rubber-duck, capable of bouncing ideas back and forth, willing to iterate on any ridiculous thought you have. Its ability to parse large amounts of documentation quickly is useful when researching how to go about building a system. And that means the role of the developer will evolve in a new way.

In the future, the developers with the highest job security won’t necessarily be the ones most deeply familiar with language features, APIs, and libraries. AI—even in its current impressive-but-primitive state—can already approximate much of that information with surprising accuracy.

Instead, the developers who stand to gain the most will be those who excel at the things AI will (hopefully) struggle with for a long time. AI, at least as of today, cannot hold an entire business context in its memory. It doesn’t understand the domain. It doesn’t grasp the customer, the roadmap, the budget, the politics, the culture, the positioning, the strategy—or the team’s past failures and victories. It doesn’t exist in the world, building relationships with the people navigating the ship it’s been prompted to help steer. And despite its generative capabilities, it has little meaningful awareness of the industry it’s operating in.

ChatGPT's weakness is it doesn't comment on Jeff-the-product-director's cool leather jacket to build rapport.

The developer who seeks to exploit this inherent weakness in AI's ability to build and understand complex relationships will shift their priorities. It will no longer be worth exerting so much effort to write code, because large language models will eventually sufficiently abstract the production of reliable code via natural language. From a programming perspective, it will suffice for the developer to be just expert enough within their technical domain to ensure that the machine does not make any critical technical mistakes.

More importantly, the developer who is adaptable will leverage their deep understanding of the business domain—an area where AI simply has no ability to compete, at least for the time being. The developer who has genuine interest and empathy for the end-users, the business, and the people working in it, will use AI to build the most effective solutions with 1/10th the effort compared to those who staunchly remain traditional coders—who, in the eyes of the business, will miss the forest for the trees pursuing the dopamine-rush of a puzzle well-solved by their own hands.

The developers who thrive will be the ones who learn how to collaborate with AI, taking advantage of all of its strengths and its weaknesses.

What Skills Will Developers Need?

If AI shifts the nature of programming from "writing code" to "articulating solutions," then the skills developers value today will evolve to universally encompass the soft-skills honed by those who've had time to build software engineering experience in the pre-AI corporate world.

Initially, the safest group will be senior engineers and managers already celebrated for delivering measurable business impact. They will reap the early benefits of this shift, standing just inches from the sheer edge of a suddenly expanding value chasm that separates them from the incoming junior developers who have had no opportunity to build technical experience or domain knowledge. These newcomers have the grave misfortune of trying to cross a bridge that is suddenly falling apart beneath them.

But even senior engineers won’t be safe forever. The critical move for senior and junior engineers alike will be to lean heavily on their unique strengths over AI, and offload everything else.

The ability to articulate a problem clearly and break it down into actionable logical steps will be a key differentiating skill. AI can generate code, but it can’t understand ambiguous or poorly framed requirements. Developers must be highly effective translators of business needs into prompts that AI can act on effectively. They must provide the right amount of technical context so as to not let the AI run amok by either under- or over-engineering a terrible implementation.

While AI can write individual components of a system, it can’t yet design how all those parts fit together, at least very well. In my personal experience, it loses sight of the bigger picture quickly, and is an indecisive pushover when evaluating important decisions. Developers will need to focus on architecture and integration, ensuring that the pieces generated by AI fit within the broader system and align with organizational goals.

We need to refactor this rectangle right here, or we all die instantly.

Developers will need to rigorously evaluate and refine AI outputs, ensuring they are efficient, secure, and aligned with business objectives. This will involve a mix of technical expertise and gut intuition honed through experience with production systems.

The developer who builds trust with stakeholders, understands user pain points, and advocates for solutions that align with company values will have a clear edge. These are not skills an AI can replicate (yet), and they will set the best developers apart. (And arguably, they already do.)

The measure of success as a developer has never been, and still won't be, how many lines of code you can push—it will be how much impact you can drive. The winners in this new landscape will be those who:

Ship solutions that actually solve user problems.
Build resilient systems that scale with the needs of the business.
Use AI as a multiplier, not a crutch.

This is a shift from a craftsman mentality to a strategist mentality. The best developers will spend less time manually refactoring and testing, and more time solving meaningful problems. The skill of traditionally writing code will become less and less intrinsically valuable, except in cases where peak technical performance is vital to the business or product strategy.

AI Will Replace Developers Who Don't Adapt

Here’s the truth: the role of developers isn’t going away, but what developers do day-to-day will change dramatically. The tasks that are repetitive, time-consuming, and easily described will be automated. That’s not a threat—it’s an opportunity.

Developers who embrace this change will have more time to focus on things that truly matter. Crafting seamless experiences. Discovering innovative solutions. Solving real world problems.

But those who resist—who double down on manual processes or dismiss the potential of these tools—risk being left behind. AI isn’t waiting for anyone to catch up. If you find yourself scoffing at the imperfect code AI generates today, remember: there was once a great programmer who believed they would always write better assembly than a compiler. We know how that story ended.

The beauty of this shift is that it lowers barriers and opens the door for anyone willing to learn. Generative AI is a tool—not a replacement—and like every paradigm shift before it, those who embrace it will amplify their problem-solving capabilities. Whether you’re a junior developer just starting out or a seasoned architect, AI offers a way to do more, faster, and with greater focus on what truly matters.

But succeeding in this new era requires adaptation. You can’t approach AI as just another tool for automation. It’s a collaborator. Learn how to guide it effectively—how to frame problems, validate outputs, and iterate on solutions. Shift your focus from the mechanics of coding to the broader picture: understanding users, designing systems, and aligning with strategy.

AI is abstracting effort itself, freeing developers to put their energy where it counts: driving real impact. If you can master this transition, you won’t just keep up—you’ll be able to change the world.

AI Will Amplify Builders—But Replace Manual Work

The highest-performing developers won’t just write code; they’ll use AI to redefine how businesses operate. By leveraging their technical skills in collaboration with AI, they’ll automate the definition and translation of business and user needs, analyze unstructured data to uncover opportunities, and pinpoint inefficiencies in processes. These developers won’t just automate workflows—they’ll effectively automate the organization itself.

It’s not far-fetched to imagine Sam Altman’s prediction of a one-person unicorn becoming reality within the next decade.

For those in non-technical roles, this should be a wake-up call. Developers using AI won’t just stick to their traditional domains—they’ll expand into others, from marketing and operations to design and even product leadership. Not maliciously, and not intentionally to displace people, but because AI will give them (or the companies that employ them) the tools to radically change manual processes that were once untouchable.

What If I’m Not a Developer?

The solution is simple: learn to build. Not necessarily to code like a software engineer, but to design and build systems that solve problems. Start now, before the gap widens.

AI is transforming the nature of work. Any process that can be automated profitably, likely will be. This isn’t speculation—it’s the trajectory of technological progress. The people who understand how to create, build, and solve problems with these tools will race ahead, automating tasks, increasing productivity, and unlocking entirely new opportunities.

If you’re in a non-technical role, you might think: "I don’t need to learn to code. AI will handle it for me." That’s partially true—AI tools are lowering the barriers to entry and making it easier to get started. But the people who thrive in this era will be the ones who understand and are well-practiced in the fundamentals of how to build a solution from nothing.

AI isn’t magic. It doesn’t understand your business, your customers, or your goals. It still relies on human input—on people who can frame problems, validate outputs, and integrate solutions. Developers already know how to do this, and they’re collaborating with AI to push boundaries. You can do it too—it just takes practice and a willingness to adapt.

Thanks for reading my first article on Dev.to. I genuinely believe the future is bright for all professionals who embrace AI—not just as a tool, but as a partner in solving meaningful problems.

This paradigm shift isn’t the end of programmers, but it's likely the beginning of a new era of programming. Careers will evolve rapidly. The only constant is change. The key to thriving in this world is adaptability.

Go build something. It doesn’t matter if you’re an experienced developer or someone who’s never written a line of code. Spend an hour exploring what’s possible. Use AI to solve a problem, automate a tedious task, or create something just for fun.

The people out there experimenting, learning, and building today—whether they have technical experience or not—are the ones who will thrive tomorrow.

Be one of them.

The Problem with Handling Node.js Errors in TypeScript (and the workaround)

Joseph Barron — Wed, 25 Nov 2020 11:06:52 +0000

The Setup

So, I was recently using Node's url module within TypeScript to be able to do some simple validation of user-provided URLs. According to the docs, when an invalid URL is supplied to the URL class, it throws a TypeError. Great! This is exactly what I wanted.

Next, all I had to do was catch that particular TypeError and give a helpful message to the user to let them know their URL was no good. Easy, all I need to do is write a try-catch statement and check the error's code. Of course, the specific error code to look for is documented on an entirely different page for some reason. It was actually easier for me to just spin up a terminal and write a gibberish string into a new URL() call myself to determine that I was looking for "ERR_INVALID_URL".

The Problematic Code

try {
    const validUrl = new URL(url).href;
} catch (e) {
    if (e instanceof TypeError) {
        if (e.code === "ERR_INVALID_URL") {
            // Property 'code' does not exist on
            // type 'TypeError'. ts(2339)
        }
    }
}

Huh? What do you mean? The docs clearly stated that an Error in Node should have a code property, and TypeError extends Error... This didn't make sense.

I used VS Code's nifty "Go to Definition" feature to find the type definition for TypeError, which opened node_modules\typescript\lib\lib.es5.d.ts. I then found my way to the definition for the Error interface...

/* node_modules\typescript\lib\lib.es5.d.ts */
interface Error {
    name: string;
    message: string;
    stack?: string;
}

Oh! This was the interface of an Error you'd find in a browser environment.

But I was working with Node, and I already had the @types/node package installed... I had falsely assumed that this would somehow magically tell the TypeScript linter that I was catching a Node Error. How was I supposed to get TypeScript to infer that the TypeError I was handling most likely extended Node's Error class, and had the extra code property I was looking for?

Search Engine Spelunking

After some confused finagling with my tsconfig.json and VS Code settings, I quickly gave up and went to Google. I soon after learned two things via random answers on StackOverflow:

The type definition for the NodeJS Error class is declared in node_modules\@types\node\globals.d.ts -- and was accessible as NodeJS.ErrnoException. I wasn't sure where this was officially documented, but alright!

/* node_modules\@types\node\globals.d.ts */
interface ErrnoException extends Error {
        errno?: number;
        code?: string;
        path?: string;
        syscall?: string;
        stack?: string;
}

It was possible to use TypeScript's type guards to create a function that I could use to check the error at runtime, so that I (and TypeScript) could be absolutely sure that this variable was a Node Error.

The example function from StackOverflow looked sort of like this:

function isError(error: any): error is NodeJS.ErrnoException {
    return error instanceof Error;
}

At a glance, this seemed like it would work... The function was running an instanceof check and used a "type predicate" (the error is NodeJS.ErrnoException part) to help TypeScript to do the type inference I was looking for. I could finally access the code property on the error without any dreaded red squiggly lines.

if (isError(e) && e instanceof TypeError) {
    if (e.code === "ERR_INVALID_URL") {
        // Hooray?
    }
}

But, I wasn't totally satisfied. For one, there was nothing stopping me from passing things that weren't errors to isError(). This was easily fixed by changing the the first argument of isError() to expect Error instead of any.

Secondly, it also felt inherently silly to have to run two instanceof checks every time I wanted to handle an error. (Truthfully, it's not the worst thing in the world... but I believe that TypeScript should require developers to make as few runtime code changes as possible when transitioning from JavaScript.)

The Solution

After some experimenting, I managed to come up with the following function, which I tested with a couple of custom error classes to ensure that any additionally defined properties were preserved.

It turned out that the key was to make a generic function which acted as a typeguarded version of instanceof for Node.JS error handling, by doing the following things:

Accepted two arguments that would be similar to the left-hand and right-hand sides of the instanceof operator.
Enforced the first argument was of the Error class or a subclass.
Enforced the second argument was a constructor for an Error or a subclass of Error.
Ran the instanceof check.
Used a type predicate to intersect the type of the first argument with the instance type of the error constructor in the second argument, as well as NodeJS.ErrnoException so that type inference would work as expected when used.

/**
 * A typeguarded version of `instanceof Error` for NodeJS.
 * @author Joseph JDBar Barron
 * @link https://dev.to/jdbar
 */
export function instanceOfNodeError<T extends new (...args: any) => Error>(
    value: Error,
    errorType: T
): value is InstanceType<T> & NodeJS.ErrnoException {
    return value instanceof errorType;
}

Examples

Original Use Case

try {
    const validUrl = new URL(url).href;
} catch (e) {
    if (instanceOfNodeError(e, TypeError)) {
        if (e.code === "ERR_INVALID_URL") {
            // Hooray!
        }
    }
}

Usage with Custom Error Classes

// Create our custom error classes.
class CoolError extends Error {
    foo: string = "Hello world.";
}

class VeryCoolError extends CoolError {
    bar: string = "Goodbye world.";
}

// Try throwing an error.
try {
    throw new CoolError();
} catch (e) {
    if (instanceOfNodeError(e, CoolError)) {
        // typeof e: CoolError & NodeJS.ErrnoException
        console.log(e.foo);
    } else if (instanceOfNodeError(e, VeryCoolError)) {
        // typeof e: VeryCoolError & NodeJS.ErrnoException
        console.log(e.foo, e.bar);
    } else {
        // typeof e: any
        console.log(e);
    }
}

// Try passing something that's not an error.
const c = NaN;
if (instanceOfNodeError(c, CoolError)) {
    // Argument of type 'number' is not assignable to\
    // parameter of type 'Error'. ts(2345)
    console.log(c.foo);
}

const d = new CoolError();
if (instanceOfNodeError(d, Number)) {
    // Argument of type 'NumberConstructor' is not assignable
    // to parameter of type 'new (...args: any) => Error'.
    console.log(d.foo);
}

You might be wondering why in that one else clause, the type of e was any... well, TypeScript can't guarantee the type of e is anything in particular, because JavaScript lets you throw literally anything. Thanks JavaScript...

Summary

After utilizing both generics and type guards, I managed to get TypeScript to correctly infer the shape of the errors I was handling in a Node.js environment without performing redundant instanceof checks. However, the solution still wasn't perfect, since I probably did sacrifice some amount of compute overhead and space on the call stack to be able to call the instanceOfNodeError() function compared to the bog-standard instanceof call I would have done in JavaScript.

It's possible that in the future, there could be an update to the @types/node package that would merge the NodeJS.ErrnoException type with the global Error type.

One could argue that since not all errors in Node.js will have the code property (or the other properties on the ErrnoException type), that it doesn't make sense to do such a reckless merging of types. However, I don't see a lot of harm when all of the properties of ErrnoException are marked optional.

Otherwise, they have to be manually added to any modules that might throw an Error with the properties of ErrnoException, per the details of this rather old commit responsible for implementing it within the fs module. However, this still leaves us with a problem when these ErrnoException errors can be thrown by the constructors of classes in Node.js, like the URL class does.

For that, the only alternative fix I could think of would be for TypeScript to add some sort of throws syntax for function/constructor signatures -- which there seems to be an open issue for from 2016 in the microsoft/TypeScript GitHub repo.