In December 1957, IBM launched the IBM 608, the first commercially available computer built exclusively with transistors — about 3,000 of them — marking a significant advance over vacuum tubes (or valves). Fast forward a few years, and we’re discussing chips with billions of transistors, predictions about when we’ll reach 1 trillion, critiques of the validity of Moore’s Law, and Sam Altman seeking trillions in investment to transform the semiconductor industry.

But the goal of this text is definitely not to analyze the chip industry. Instead, it’s to offer some reflections on how we communicate with these computers, which, since the IBM 608, have essentially been a (steadily growing) collection of transistors. Like lights turning on and off to indicate their states, this dynamic enables us to perform everything from calculations, simple logic, and loops to the most complex computational programs.

You’ve probably heard that, at the end of the day, it’s all about “0s and 1s.” But it’s also true that these 0s and 1s can manifest in many ways. For instance, at one extreme, you could type each zero and one manually (good luck with that). On the other hand, you could use an AI tool powered by natural language processing technologies to describe the website of your dreams. Both approaches ultimately translate to binary for the computer, but the level of abstraction you use has significant implications for the final outcome of the project. It’s in this middle ground that technology meets business: to understand these abstractions and to consider performance metrics, scalability, customization, security, development speed, access to talent, and desired business outcomes when determining a tech stack that makes sense for a specific use case.

The inspiration for this text came from a colleague who recently shared with me a framework called R2R by SciPhi, a startup accelerated by YCombinator, for creating RAG applications with LLMs.

Frameworks are simply another kind of abstraction — what we might call intra-language abstraction — that may even incorporate resources beyond the language in which they’re built, much like libraries.

Let’s start with the simple example of libraries. Someone has put in the work to create a set of resources like functions, classes, and modules that you can reuse in your program. You didn’t write those functions, think about the best way to create them, or likely even know precisely the algorithm being executed when you call a particular function. This is yet another example of abstraction.

The same is true for frameworks like Angular, Vue.js, Flask, and others, but with additional constraints. Instead of providing blocks like libraries do, frameworks give you a castle with a few blocks missing, allowing you to complete it as you wish. In other words, predefined flows (a.k.a. Inversion of Control), unlike libraries, where the developer controls the flows. Again, numerous decisions have been made for you, and the developer trades the ability to customize every last bit for the speed and agility that the framework’s pre-built castle offers.

The way I’ve described it might make it seem like abstractions always compromise application quality by constraining developers and that more customization is always better. But abstractions usually bring speed and security.

Imagine a scientist who discovers a cure for cancer, allowing all doctors to administer that treatment to their patients. Similarly, the creators of abstractions offer alternatives — using their large teams, years of work, and millions of dollars in investment — so that developers without the same experience or resources can build more secure applications (the predefinitions can be a blessing) and do so faster.

Ask a developer what it would be like to build a neural network without Keras, develop LLM applications without LangChain, perform data science without NumPy or Pandas, or create a front end without Angular. If an abstraction provides a solution that delivers functionality and a level of performance suited to your project’s needs, there’s no reason not to use it.

There is, however, one reason we often act otherwise. When studying technology, it’s easy to develop a fascination with the complex; we start gravitating toward applications that let us explore our curiosity and push the limits of technical possibilities.

Before you know it, you’re building a simple calculator in C with your own compiler. Maturity is needed to decide which technologies to work with and what level of abstraction is necessary, putting the use case and the end-user experience at the center. Cannons for wars, electric rackets for flies.

Let’s talk about two other ways abstraction can occur: through APIs and in infrastructure.

APIs are another interesting form of abstraction because they allow changes in implementation without requiring developers to learn from scratch how to extract data from a modified application or redo a web scraping algorithm when an interface changes.

For instance, accessing Salesforce or Hotmart data, enabling payments with Stripe or PayPal, or even facilitating essential activities like database communication and user authentication.

Cloud and infrastructure also rely on abstractions. One developer might prefer using AWS’s console to configure infrastructure, another might insist on using Terraform code, and yet another might argue that the provider’s CLI is essential.

Who’s right will depend on various factors, all tied to the specific use case. But the principle remains: we continue to operate along a spectrum of abstractions, from a nearly preconfigured cloud product to teams making detailed decisions about the hardware to use.

Now think about the structure of a modern application, involving APIs, libraries, multiple languages, frameworks, cloud or server infrastructure, and other components. It becomes clear how much abstraction is required for developers to produce applications at a pace and efficiency that makes business sense.

Next, let’s explore two phenomena that summarize the benefits and necessity of abstractions.

Two complementary phenomena are observed in the tech world: hyper-specialization and interdependence.

The first refers to the tendency of a group of programmers to focus on building a highly specific resource, optimizing it to the highest possible level of performance for a particular use case. Thanks to this phenomenon, we have libraries like NumPy, languages like R, and APIs like OpenAI’s.

The second phenomenon, almost a consequence of the first, is the interdependence that arises in the field. Since you specialize in a specific area, you need to rely on colleagues specializing in other areas to combine technologies into an end-to-end application. This also means many of the abstraction decisions for these technologies weren’t made by you, and your team will have to live with them or face the technical challenges (and associated costs in time and talent) of delving deeper into the abstraction layers to make desired changes.

The good news is that, for most use cases, technologies with abstraction decisions that suit — or nearly perfectly suit — what we want to build already exist, enabling the creation of applications at a cost that makes business sense.

You don’t need to invest the billions OpenAI has spent to access a generative model. We’re also seeing the emergence of foundational models tailored to specific use cases — yet another example of hyper-specialization and interdependence.

Therefore, understanding the decisions made at various levels of abstraction is valuable for grasping the limitations, possibilities, and ideal use cases for each technology. But these abstractions certainly don’t imply an inability to develop.

In this vein, another trend — or, more accurately, another level of abstraction — is gaining traction: no-code and low-code technologies. Examples include Zapier and Make for app automation and integration, Bubble for full-stack web apps, Flutterflow for native mobile apps, Tableau (by Salesforce) for BI, Xano for backend, and Framer for websites, among others.

These tools follow the same logic as libraries, frameworks, and other abstractions discussed here, even allowing extensions or connections with more traditional stacks, whether for backend or frontend, to expand functionality and performance.

These tools provide predefinitions that, on the one hand, accelerate and lower the cost of development for their intended use cases but, like other abstractions, may impose limitations when expanding to other use cases. The benefit is that, in the right context, they yield business results that would be difficult to achieve starting from scratch.

For this reason, they often outperform applications built using traditional coding. It’s up to the professional, as in other cases, to understand the possibilities of each tool and choose the one that best fits.

For those who want to delve into the tech world, understanding abstractions helps clarify their role in the ecosystem. Maybe you’re the engineer striving to keep Moore’s Law alive by cramming more trillions of transistors onto chips or optimizing search systems down to the last wire at Google. Perhaps you aspire to be like the cancer researcher, creating the next big framework, language, or library. Or maybe your place is building great products available via API, helping developers improve their applications.

Alternatively, you might want to get your hands dirty and understand all these tools to design end-to-end applications that leverage these abstractions to deliver the “final level of abstraction”: the user’s hands, where a button click triggers seemingly magical events, with no thought given to what a function might be.

And, my favorite case, perhaps you’re a businessperson who realizes that opportunities and challenges increasingly hinge on the limitations and advancements of technology (or you just want to be less annoying to your dev team, which is also valid).

In any case, everything I’ve mentioned here is already part of your life, your companies, and your products.

Finally, two quotes summarize the evolution we’re discussing. The first is from Chris Wanstrath, co-founder and former CEO of GitHub, who said in 2017 at the GitHub Universe conference, “We think the future of coding is no coding at all.” More recently, Jensen Huang, CEO of Nvidia, remarked, “It is our job to create computing technology such that nobody has to program.”

I interpret these statements as a bet on the evolution of abstractions, making development easier every day, democratizing technology, and enabling more efficient and secure projects.

This will be an incredible reality for those who are highly technical — the “cancer researchers” — as they will help drive this change. It will also be a magical era for those who want to incorporate technology into their businesses, create new digital products, and take yet another step toward the inevitable.

Are you thinking about how to improve your business results with tech? Astra can help you navigate this decision better. Click here to schedule your call with us.