Where will automation plug in? 1 of three in our Coding automation series.

Take into consideration your washer. You place clothes in, set the dial, pour in detergent, and bam—clean clothes. Your washer just saved you an hour of scrubbing (and possibly did it higher than you could possibly have).

Now, let’s return in time. Imagine you’re taking a look at the world’s first washer. Do you wish to use it?

Now, you may stop to ask:

• How do I take advantage of it? Do I must be an electrical engineer to show it on, or change the settings?
• How do I comprehend it worked? Perhaps a fast check for previous stains. And if I set it to cold water but got hot, I’ll feel the temperature difference.
• How often does it work, and what happens when it doesn’t? Even when it’s infrequently, it’s really bad if it shreds my clothes, but okay if I just need to run it again.

Today, your washer meets all these criteria for you, whether or not you concentrate on it.

You may discover any task to automate using an identical line of questioning. The duty must:

1. .
2. .
3. Unless the automation is far more reliable than a human.

Let’s apply these traits to software. We’ll dig one level deeper to attract corollaries.

We used “easy” above to explain the washer, but “easy” is just not the one solution to be useful. We use “low-cost” here since it’s more general. For software to be low-cost to specify, it might probably either be:

• , OR

We use the word “low-cost” here for similar reasons. To ensure that it to be low-cost to envision code:

1. The checker should have the talents to envision code. Note, they don’t have to have the option to write code. (Economically speaking, this point is inherently easier to satisfy.)

2. The software should be easy to envision. Meaning either:

• , OR

Unless the automation is far more reliable than a human.

If there’s a sort of automation that will cause severe problems, but works lots higher than a human, it may be acceptable. We’re not going to call any names, but you most likely know of not less than one widely debated use case.

For a whole lot of software, it’s not life-or-death. Especially on this planet of B2B SaaS. (Sorry not sorry.) Even so, there are particular parts of software where we’d like high reliability and accuracy.

As a general rule of thumb:

• Internal-facing software is less critical than external-facing software.
• A bit of product is less critical than a bit of infrastructure.

Now that we’ve established the traits we’re on the lookout for, let’s put our knowledge to make use of. Let’s use the traits to predict where we’ll see coding automation.

Example 1: today

Let’s first take the attitude of an engineer. Let’s consider what can satisfy these constraints:

• Low-cost to specify—Quick and straightforward for an engineer to specify.
• Low-cost to envision—The output is small in scope.
• Have minor consequences if not done to specification.

These bullets describe the realm of coding assistants like Github Copilot. Some possible outputs:

• The body of a function, given the function signature.
• A small function, given a comment docblock.
• Example test data, given a natural language description of the info structure.

Example 2: tomorrow

Now, let’s take the attitude of a non-engineer. What can satisfy these constraints?

• Low-cost to specify—Possible for a non-engineer to specify.
• Low-cost to envision—The specs are loose/imprecise.
• Have minor consequences if not done to specification.

Listed here are some ideas we considered:

• A starter home page for marketing.
• A modified version of checkers to play with friends.
• A bot that finds and books a reservation for dinner tonight, somewhere “interesting”—“interesting” loosely defined by the user.
• A bot that books desks for workers after they visit an office.

Take a minute. What other ideas are you able to give you?

On this post we’ve focused on tasks, and the traits of tasks that make them candidates for automation.

But inevitably, what we will automate changes how we shape the world. After the washer was invented, we designed clothes to be machine-washable.

It’d occur to you that the three traits roughly map to different parts of the software development cycle: specification (problem understanding and definition), checking (QA), consequences (impact evaluation).

How will this impact software development workflows? Which skills and roles will we’d like? For instance, QA engineers exist today. Conventional wisdom predicts that the variety of QA engineers will decline. But could the role of the QA engineer not only persist, but grow due to generative AI?

We’ll explore this query in a next post on this series.

Low-cost to specify, low-cost to envision, minor consequences. What exists in your day-to-day work that matches this bill?

More interestingly: What are you able to dream of, that doesn’t exist yet, but suits this bill?

Take into consideration coding automation today like that very first washer. That’s where we’re.

Next up… post 2 of three of our Coding automation series. Stay tuned.