DEV Community: Elliot Nelson

True Scalability & Responsibility with AI

Elliot Nelson — Tue, 29 Jul 2025 18:30:00 +0000

I was reading a blog post recently about "scaling up your productivity with AI" (I'm sure you've seen many); for whatever reason, this time the phrase really struck me. I'm increasingly convinced that AI, as we currently use it, does not truly "scale" developers. This isn't a tech problem: no matter how good the AI model becomes, it's impossible for 1 human + 1 AI to be equivalent to 2 humans.

Delegation: Tasks vs. Responsibility

To truly scale, it's not enough to just delegate tasks, you also need to delegate responsibility for those tasks.

Imagine a manager who runs a small development team of six people. This manager makes commitments to their customers -- perhaps "we aim for less than X defects a month" or "we address P0 bugs within 48 hours". These commitments represent the manager's responsibilities. Similarly, the individual contributors have their own lower-level responsibilities: follow best practices, run appropriate test plans, peer review changes before they merge, and so on.

But what if the manager, instead of delegating the lower-level responsibilities to the engineers, kept them all for themselves? Even with six people it would immediately be overwhelming: to be personally responsible for reviewing every pull request, ensuring requirements had been followed, and so on.

When a developer uses AI assistants, they are often able to move faster -- maybe twice as fast, or five times as fast, for some particular task. But they have not scaled, because they retain all of the responsibility for all of the work they and their AI assistant have produced, and this responsibility only grows as the amount of work grows.

Delegation & Augmentation

I've seen a number of articles now about the shift from AI as a "tool" (increasing personal productivity for developers) to "teammate" (taking a more fundamental role within the team). In other words, AI isn't just augmenting your developer's productivity, we can actually delegate tasks to them. AI technology is moving fast, but right now, this idea feels like nonsense to me.

Do you have a manager in your organization that feels comfortable taking personal responsibility for the decisions their "AI employees" make? If not, no actual delegation is taking place, and AI is only augmenting the abilities of the people the manager can actually delegate to (their developers).

Today, an "AI teammate" is just a fig leaf for increased scope of ownership for the human teammates, along with everything that entails (architectural knowledge, on-call shifts, code reviews, and so on). Claiming you can treat an AI like it is a coworker might be fun -- until something happens that requires true accountability and your imaginary friend is nowhere to be found.

Takeaways

There's a hard cap to the cognitive burden humans can carry, and the amount of output you are responsible for directly increases that burden. You can probably increase a developer's speed by 10x using AI, at least temporarily. However, "10x'ing" the responsibility of a developer over the long term is going to result in engineer burnout (or silent failures).

As we continue to integrate AI into our tools and processes, we need to be mindful of the difference between acceleration and true scalability, or risk making organizational changes that aren't sustainable.

Striving for Asynchronous Work

Elliot Nelson — Thu, 29 Apr 2021 20:00:53 +0000

Scroll through your recent Slack history and look for conversations that begin like this:

"Who do I ask to spin up a new client pipeline?"
"I have a new developer on my team, how do they get access to the VPN?"
"How do I create a new team in JIRA?"
"Where is that documentation for upgrading node on a service?"
"I have a question about [THING], what team owns that?"

Even if your company is full of friendly, helpful people, and all of these questions get resolved a few minutes later, these questions should ring warning bells. Each of these questions is turning an inherently asynchronous process into a synchronous one -- someone that was actively working on a task (onboarding a new software engineer, creating a new pipeline, etc.) has stopped working on that task to ask a question, and likely won't be able to continue again until someone appears to answer it.

In a small company with just a few teams, where everyone is in the same time zone, those few minutes of extra waiting don't seem like a big deal. But as a company grows, both in team size and in number of time zones, the number of questions and the amount of time waited can explode. In a company that has become remote, that spans 3, 4, maybe even 10 time zones, stopping and asking a question on Slack isn't just a few minute wait; it often means that task is now blocked until the next day.

If your company is full of synchronous workflows, a software engineer's day quickly becomes an exhausting series of task-switching exercises, pushing a little bit further on each of their many blocked tasks, rarely being able to pursue the thread of a single task to completion. It's hard to be happy as a developer when you end the day feeling like you haven't accomplished something -- it will kill your productivity just as quickly as a slow CI build or broken bug workflow will.

If you recognize some of the questions above in your own company's chat log, prioritize fixing it! What needs to be fixed depends on what kind of questions are being asked and why people are blocked.

Technical Solutions

You've always intended to create an automated script, or service, or Jenkins job to do this task for developers, but in the meantime, it's easier to tell people "just slack Bob the name of your new service and he'll set it up for you". This kind of issue often naturally gets resolved technically, because Bob gets sick of doing it manually, but maybe it's time for the team to prioritize that automated workflow, or CI pipeline generator, or whatever other tools your company needs.

Documentation

You automated all your stuff years ago, but people are still blocked in Slack just because they don't know it exists. Make sure the services you offer your software engineers are documented, and that links to that documentation exist in a place that makes sense. Ask people where they looked, or what they searched for, and bridge those gaps for next time. Build automated replies in Slack if you have to! Do whatever you can to connect people with the information they need, without waiting for another human to show up and help them.

Consensus Building

This is a special case that often happens to engineers new to a company -- you need to write a script, or build a tool, or add a feature to a product, so you ask a seemingly innocuous question. "I see repos with both Mocha and Jest, which do people prefer here?", or, "The generator says I can use Terraform or CloudFormation, is there a preference?"

Instead of an answer, you find yourself in the middle of a heated debate, with conflicting responses from people more senior than yourself. In this case it's blocking you from even getting started on your task, but it might block you in the middle too -- for example, you put up a PR with code changes recommended by one team lead, only to be blocked by a different team lead demanding a different approach.

This issue is common on rapidly growing teams and you should consider it especially alarming, as it has the potential to be exponentially frustrating and tense for engineers caught in the crossfire. Take the people with strong opinions and get them into a room or a meeting to hash it out, or task a key decision maker with gathering opinions and making a decision; however you accomplish it, it's critical to prevent these kinds of situations from becoming the norm at your company.

And more...

Here's a thought exercise I like: imagine you wake up at 4am and can't sleep, so you decide to get a few hours of work done early. Look at your current work backlog -- what tasks could you do, alone, right now? What tasks need to wait until one (or several) of your coworkers are online?

Some tasks do require "synchronous communication", like sitting down with team members to brainstorm or chatting about a proposed feature. But for those that aren't inherently synchronous, what would be required to make it asynchronous? Is it a technical solution, is it missing documentation? Whatever it is, chipping away at those edges in your company will slowly and surely reduce the number of times your developers end up blocked each day, increasing their happiness and their productivity.

Photo by Jon Tyson on Unsplash

Unit testing async functions

Elliot Nelson — Tue, 30 Mar 2021 20:07:39 +0000

If you're just getting comfortable writing async functions in JavaScript (or using Promises in general), a potential stumbling block you might run into is writing proper unit tests for them.

The good news is that as long as your test framework provides a way to write expectations for resolved values and rejected values (usually Errors), adjusting your unit tests should be relatively simple. To give some examples, I'll show some simple positive and negative unit tests for async functions using three popular test frameworks - Jasmine, Jest, and Mocha + Chai.

Code under test

Before we start testing, we need an example of an asynchronous function to test, right? Let's check if a string is a palindrome:

async function palindrome(value) {
    if (typeof value !== 'string') {
        throw new Error(`${value} is not a string`);
    }
    let chars = value.toLowerCase().replace(/[^a-z]+/g, '');
    return [...chars].reverse().join('') === chars;
}

(This function doesn't have to be asynchronous, but let's consider it a stand-in -- perhaps our real palindrome checker is on a server and the palindrome() function actually makes a REST call, etc.)

Jasmine

Jasmine has been around a long time and remains one of my favorite test frameworks -- it's tiny, fast, and has no dependencies. It comes out of the box with async matchers, although you need to remember that asynchronous expectations in Jasmine must be made using the special expectAsync function instead of the usual expect function.

describe('palindrome', () => {
    it('returns true if the string is a palindrome', async () => {
        // You can await for value, then do a normal expect
        expect(await palindrome(`Madam, I'm Adam`)).toBe(true);

        // Or, you can do an asynchronous expectation
        await expectAsync(palindrome(`Madam, I'm Adam`)).toBeResolvedTo(true);
    });

    it('raises an error if the value is not a string', async () => {
        await expectAsync(palindrome(37)).toBeRejectedWithError(/.+ is not a string/);
    });
});

For positive expectations, I prefer awaiting for a value first and then using a standard expect -- this is more flexible, because you can use any Jasmine matcher (like toBeInstanceOf, toContain, etc.). If you use the asynchronous expect, you can only make an equality comparison.

For negative expectations, you don't have the option of waiting for a value (the rejected promise would fail the test). In this example I've used a regular expression, but we can also pass a string or an Error object (the API for .toBeRejectedWithError is consistent with Jamine's .toThrowError).

Jest

Jest is the opposite of Jasmine, with its huge install footprint and slower runtime, but is immensely popular nowadays (especially for React testing). Like Jasmine, Jest comes with async matchers out of the box.

describe('palindrome', () => {
    it('returns true if the string is a palindrome', async () => {
        // You can await for value, then do a normal expect
        expect(await palindrome(`Step on no pets`)).toBe(true);

        // Or, you can do an asynchronous expectation
        await expect(palindrome(`Step on no pets`)).resolves.toBe(true);
    });

    it('raises an error if the value is not a string', async () => {
        await expect(palindrome(37)).rejects.toThrow(/.+ is not a string/);
    });
});

Notice how in Jest, you can await expect for asynchronous expectations (there's not a separate function), and instead of using separate matchers, you can use the chaining functions .resolves or .rejects to "unwrap" a Promise and then use a normal expectation matcher. I think this is one of the better matching APIs out there.

Mocha + Chai

Mocha is a popular test framework that doesn't bundle its own assert/expect library, which makes it very flexible but also requires installing a few more packages to setup your test environment.

For this example, I am using Mocha, plus Chai for its BDD expect syntax and the chai-as-promised plugin for asynchronous matchers.

describe('palindrome', () => {
    it('returns true if the string is a palindrome', async () => {
        // You can await for value, then do a normal expect
        expect(await palindrome(`Never odd or even`)).to.equal(true);

        // Or, you can do an asynchronous expectation
        await expect(palindrome(`Never odd or even`)).to.eventually.equal(true);
    });

    it('raises an error if the value is not a string', async () => {
        await expect(palindrome(37)).to.be.rejectedWith(/.+ is not a string/);
    });
});

For positive expectations, the chai-as-promised library gives you the .eventually chain, which works just like Jest's .resolves chain and allows you to append any other regular matcher. For negative expectations, it works more like Jasmine -- there's a special rejectedWith matcher. Just like the other two frameworks, you can pass an Error object, a string, or a regular expression.

Summary

Of the three test frameworks above, I think Jest has the best, most consistent style for writing asynchronous expectations. Personally, I'll drop back to Mocha or Jasmine for small tools and libraries, because I like the smaller footprint, but all 3 frameworks are quite close -- the same functionality and testing patterns are available in all, and your choice boils down to which particular flavor of syntax sugar you prefer.

Is there a test runner or framework you prefer (maybe one not mentioned above)? Let me know!

Photo by Franki Chamaki on Unsplash

Repeating Yourself Is OK (especially in tests)

Elliot Nelson — Mon, 22 Mar 2021 20:45:53 +0000

When writing unit tests in languages like Ruby and JavaScript, a well-tested function often has more (maybe even 2-3x more) total lines of unit tests than it does code.

Because we have all this unit test code, when we notice lines that are repeated many times, it can be tempting to pull all those lines out and create helper functions or test wrappers. However, this desire to avoid repetition can easily lead us to the Wrong Abstraction.

A bad abstraction is a problem anywhere, but in unit tests it is especially bad, because that slick little helper function -- the one that over time has grown to take 5 arguments and contains several nested if statements -- doesn't get tested itself. When the code intended to test the code has its own logic (if statements, switch/case blocks, etc.), it's impossible to tell whether it's testing the code-under-test properly.

What's important is that "DRY" (Don't Repeat Yourself) is not an end goal in itself, it is only one tool to use in the pursuit of code that is readable and maintainable. If DRYing your code actually makes it harder to read and maintain, then it isn't serving its purpose.

For example:

// This example is in Jasmine; feel free to imagine it in
// Jest, Mocha, RSpec, Cucumber, etc.
describe('restartServer', function () {
  it('resets keepalive', async function () {
    server.stop.and.resolveWith();
    server.start.and.resolveWith();
    await instance.restartServer();
    expect(server.stop).toHaveBeenCalled();
    expect(server.start).toHaveBeenCalled();
    expect(instance.keepalive).toEqual(0);
  });
});

In my opinion, even if you have 20 more unit tests just like this one that test various different aspects of server restart behavior, it's usually not worth it to try and DRY up those stub lines.

To some of you this might seem to fly in the face of normal coding practice, but, let's look at some common situations:

A unit test unexpectedly fails. The developer goes to the test in question -- everything this test needs to run is on the screen in front them. No jumping around different code files or functions, it's all right there.
Someone adds a line of code to the function and they need a new unit test. Copy and paste an existing test, make some tweaks, and the task is done.
Someone makes a logic change to the function, causing the stop() call to be skipped in some cases. Half of the unit tests break, the rest continue working, and the developer fixes the unit tests that broke by fixing those expectations. (What doesn't happen? The typical Wrong Abstraction pattern: adding yet another boolean argument to the Big Helper Function and making yet another expectation conditional...)

My stance is that almost always, attempting to "DRY" unit test code comes with significant disadvantages to readability and maintainability -- almost in reverse proportion to the usual advantages it gives you in your code-under-test.

What do you think?

Cover image by Ben Allan.