Whatsapp had 450 million monthly users and just 32 engineers when it was acquired. Imgur scaled to over 40 billion monthly image views with just seven engineers. Instagram had 30 million users and just 13 engineers when it was acquired for $1 billion dollars.

This is the new normal: fewer engineers and dollars to ship code to more users than ever before. The potential impact of the lone software engineer is soaring. How long before we have a billion-dollar acquisition offer for a one-engineer startup? How long before the role of an engineer, artisanally crafting custom solutions, vanishes altogether?

As the leverage of the individual software engineer increases, the barriers to becoming a code creator are falling fast. The same software foundation (open source software, development tools like Github, infrastructure as a service provided by the likes of Digital Ocean, and more) that allowed Whatsapp and Imgur to scale, means that experience and skill writing software become less important.

An individual can now scale a web app to millions of users with Digital Ocean, Heroku and AWS (perhaps coordinated by Mesosphere). It no longer requires a sophisticated understanding of MySQL parameters to scale a database on Google App Engine, just as it no longer requires a knowledge of the CPU chip it’s all chugging away on.

How long before we have a billion-dollar acquisition offer for a one-engineer startup?

The way to describe this software coding continuum might be pre-foundation – where in its extremist form, every piece of software started in Assembly — and post-foundation – where software is like Legos, just snap the pieces together.

Pre-foundation, even the simplest tasks took a tremendous amount of knowledge and labor, because you had to build up from the bottom. For a website this might have meant (going up the stack) a server OS you patched and managed yourself, running your homegrown or hand-tuned web server, caching system, database, account management system, rendering engine and front-end libraries, with your own hand built analytics platform, build process and bug reporting tool. If that sounds like a lot of stuff to manage, that’s because it was.

Post-foundation, one need only focus on the user-facing function at hand, working with only one level of abstraction. It will one day be laughable that building Facebook required tuning web server software, let alone building entire data centers. The other layers of the stack will be abstracted away entirely and writing software will continue to look more like assembling a collection of Github-hosted libraries and APIs.

We are now, thanks to the web and the open source community it created, rapidly hurtling towards a world with a software foundation. We are building a common core of software tools and platforms that allows one to write less code, accomplish more, and reach more users. We are moving towards software as Legos.

And yet, despite all of the tremendous progress, we are still in the beginning of this transition. Here is Brad Cox, the creator of Objective-C, writing 24 years ago:

Mature industries like plumbing are less complex than ours, not because software is intrinsically more complicated, but because they—and not we —have solved their complexity, nonconformity, and changeability problems by using a producer/consumer hierarchy to distribute these problems across time and organizational space. The plumbing supply market lets plumbers solve only the complexities of a single level of the producer/consumer hierarchy without having to think about lower levels, for example, by reinventing pipes, faucets, thermostats, and water pumps from first principles.

While Cox wrote this before Linux and Stackoverflow, he is still right. The modern engineer, while blessed with libraries and frameworks that remove complexity in order to focus on the problem at hand, is still constrained by the need to walk up and down a ladder of abstraction levels. Software engineering is not yet plumbing — or Legos — because our standards are incomplete, our libraries incompatible, scaling is still not free and our software still buggy. All require the creator to leave his or her rung on the ladder of abstraction.

But we are getting there, and software is eating software development. The foundation of open source based software platforms, infrastructure, knowledge and best practices continues to grow. I bet Stackoverflow alone has increased programming productivity by a few percentage points. Now add fifteen years of free or inexpensive developer tools (Github, too many IDEs to list), automated infrastructure (Mesosphere, AWS, Google App Engine, Heroku, DigitalOcean and more), databases (MySQL, MongoDB, PostgreSQL, Firebase and more), high level languages (Python, Ruby, PHP and more) and frameworks (Meteor, Angular, Django, Rails, Bootstrap and more): the faucets, pipes and water pumps of programming. All rooted in open source and all removing levels of detail that a creator making software for users shouldn’t have to care about.

Software engineering is not yet plumbing — or Legos — because our standards are incomplete, our libraries incompatible, scaling is still not free and our software still buggy.

Now, what does this mean for the 10x engineer? The “10x engineer” is still needed to build the foundation — building AWS or Mesos remains very difficult. But as we build out the common foundation, the skill and experience an individual needs to accomplish a task on top of the platform decreases.

A “10x engineer” is, afterall, an incredible misnomer. A 10x engineer is not necessarily 10 times more productive — they are just “next level” better engineers who in some contexts are 1.5x and sometimes 100x better, depending on the difficulty of the task and leverage of the outcome. But post software foundation, when software looks more like Legos and less like artisan craftsmanship, the relative output multiple of the “10x” engineer working on top of the foundation moves closer to one.

Thus software itself becomes the driving force of leveling the ability to write software to solve problems. This is a good thing: As software becomes a high-impact, low-skill trade, we decouple the technical ability and experience needed to write tricky software from the ability to solve problems for people.

We begin optimizing success for problem solvers and business builders, not those who happen to be both these things and have been programming since age 12. We unleash new categories of startups, from builders with new backgrounds and perspectives. We unleash thousands of new startups that can now be built because this friction is gone. And while we’ve been primarily talking about the web here, we’re already seeing the same phenomenon begin to happen in big data, bio-computation, artificial intelligence and other fields.

Today, if you have a great idea for a software product, you need to either be an engineer or find one. Tomorrow, that billion-dollar startup acquisition might not need an engineer at all.

The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation.

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments and certain publicly traded cryptocurrencies/ digital assets for which the issuer has not provided permission for a16z to disclose publicly) is available at https://a16z.com/investments/.

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.