Back in March 2024, tech circles blew up with the announcement of Cognition Labs’ Devin. Marketed as “The First AI Software Engineer”, Devin is an autonomous agent, apparently capable of making contributions to codebases through solving GitHub issues, or chatting with a user. Around the same time, Magic.dev had announced a $23 million funding round, with a similar goal of building an AI coworker for developers.
Reception was highly mixed. Some saw these tools as an existential threat to their well-being and livelihood. Others were skeptical, alleging that the company had significantly fluffed the agent’s capabilities through selective demos. Regardless of stance, however, Devin and Magic.dev shocked the industry in a way which begged significant questions about the nature of software development and automation.
On one hand, it seems relatively evident that with advancements in technology, significant changes to workflows can be expected. Tools will incorporate generative AI in the hopes of increasing productivity. However, there is a significant difference between a tool which extends the creativity of a developer, and an autonomous entity which acts as a replacement. That’s what I want to get to the bottom of. Can software engineering be fully automated? Will human developers cease to exist, or will the nature of the job simply look different?
Set in stone
To start, let’s look at what tools actually are. In my view, tools are essentially functional machines, which serve a particular function in a system. A shovel, for example, serves the function of digging, which is useful towards an end-goal. A tool, however, ultimately requires an agent to use it. A tool can only act to affect the environment by the will of its user. An agent, however, can create and orchestrate tools, towards an agency, or goal.
Perhaps there is some precedent to this uncharted territory. What if we go all the way back to the very first tools? The Stone Age, that is. Tool creation usually starts with discovery. Driven by experimentation or accident, someone stumbles upon a phenomenon, and wonders if it could be controlled towards a goal.
Sharp stones or naturally broken rocks could be found in the landscape, and early humans would have noticed their utility for working with meat, or other materials. Perhaps one day a genius inventor had a problem, and decided to hit two rocks together in case that helped solve it. Somehow, at least, we got knapping, which is a process of lithic reduction, where you hit a rock against another rock to remove flakes.
Crude tools could be fashioned out of stones through knapping, and so humans could process plant fibers, hides, and bones more effectively. These tools helped increase the efficiency of these tasks, granting humans an evolutionary advantage through greater access to nutrients and environmental control. Later, someone came up with the Swiss-army knife of paleolithic tools: the hand axe.
Hand axes were diverse in function, with a sharp, bifacial edge that allowed for scraping, digging, and nimble movement. Chopping, scraping, cutting, digging, butchering, and even hunting were within the impressive repertoire of the hand-axe. The hand axe is an early example of specialized technologies converging into a more general tool, with respective strengths intact. This allowed effort, time, and stone to be spent more efficiently, albeit with a marginal cost to the performance of the tool in specific areas.
Over time, the hand axe became more refined, with iterative improvements made by tool crafters. They became increasingly symmetrical, had thinner profiles, and kept more consistent shapes. Masters of the craft would make beautiful artifacts, providing some of the first examples of intentional human design.
(Check out this really cool 3D image of an Acheulean Handaxe crafted around a fossil.)
Humans did, however, eventually find that they could create more versatile tools through new techniques. Stone tool production grew increasingly efficient, and core processes became standardized. The Levallois (la-va-lu-wa) technique, for example, allowed one single rock core to be used in the production of multiple uniform flakes. This standardization created a firm industrial foundation to be built upon and expanded, with specialization now more practical due to the more efficient use of stone.
For example, scrapers could be fashioned from Levallois flakes, and were more specialized towards the scraping of animal hides than something like a general purpose hand axe. They were lighter, sharper, and easier to hold in the hand for their specific purpose. This increased specialization of a tool towards a specific task allowed greater efficiency in that specific area. Animal hides were processed more quickly, with less waste. Better prepared, thinner hides could be sewn together to create more insulated clothes.
Later, tool designs became more modular, crafted from a combination of standard base-parts. Hafted tools (tools with handles) such as spears, use modular components in the creation of a specialized whole. This allows for increased efficiency of tool production over time, as a variety of tools can be built from the same standardized components. Modular design also allows components to be swapped out with less effort, so you could add a more specialized spearhead or replace a broken handle.
So on the nature of tools, there are various aspects. Technology is in some ways discovered, as existing phenomena (including natural ones) are observed, and inspire humans to attempt to control the phenomena towards a goal, such as the solution of a problem. A tool adapts based on environmental pressures, striving for efficiency. Efficiency drives further innovation, and iterative improvements occur as creators of tools refine their processes.
Standardization allows a platform for extension towards specialization. Any given tool falls on a continuum between specialization and generality, with environmental pressures affecting preference between. Specialization requires additional cost with a more beneficial outcome in a given area, whereas generality allows a wider array of functions at the expense of performance in specifics.
Modularity adds a new dimension to tools, as components can be produced at scale, then combined in various orders. These components can also be swapped in and out of the tool, allowing for increased ease of improvement. Modern tools follow the same general patterns. Innovation, adaptation, efficiency, standardization, specialization, modularity. These are characteristics of tools and tool creation.
Language models do follow these patterns. However, the nature of the function is more complex. Language models exist to replicate human language, which can mean replication of the logic found within it. This includes decisions and planning, but we have to remember that an approximation of a decision or a plan, does not constitute a replacement.
The so-called “foundation” models (GPT, Gemini, Claude, LLama, etc.) might be sort of like a hand ax. General purpose by design, and built to serve not just a specific function, but a range of functions, which is resource efficient. They might also be compared to the Levallois technique in some way, since they provide a platform for extensibility and specialization.
However, language models do seem like tools in and of themselves. Just because I create a robot that can use a screwdriver, doesn’t mean the robot isn’t still a tool. It’s just a more complex tool now.
Tools don’t care
As a developer, when I go about my job, it involves using a lot of tools. Text editors, browsers, operating systems, programming languages, etc., all come together into a cohesive system which can be leveraged towards a specific end goal. If I want to build a product, for example, I act as an orchestrator of various tools to achieve that. The tools are mechanistic, and act according to how they’re used. When I type, words appear on the screen.
The words don’t, however, come from the keyboard, but rather from somewhere in the couple of brain cells that I have left. To put it another way, the tools don’t care. They don’t have any goal independent of my own. Rather, they act as extensions of my own abilities, allowing me to create things. Tools don’t tend to make decisions, rather they let me make the decisions, and then perform operations based on those.
But that’s a blurry line. What’s so weird about large language models, is that they seem to actually be capable of making decisions. If I ask a GPT-4o to select the correct action to solve a given task, there is a good chance it will if instructed properly. So, that’s where we get the idea of autonomous agents based on LLMs. Now, we have automated systems which are capable of performing reasoning, and therefore working independently towards complex goals.
BUT! This isn’t the same as being an agent. Of course, to avoid arguing over semantics, I will grant that you can certainly make an agent out of an LLM. An “agent”, in this case, being an autonomous entity capable of working towards a goal. However, I’d argue that this goal does not constitute an innate “agency” in the same way as humans, because the agency is an extension of the user of the agent, not the machine itself.
Therefore, an “agent”, in this particular case, is still a tool. Albeit, a more complex tool within which echoes exist of a human creator. A language model, however, is just math. It is a static entity, not capable of adaptation or evolution. Therefore, it will always exist as an extension of that which uses it, not as an agent within its environment in and of itself.
On this measure, an octopus, or a walnut tree have more agency than an LLM wrapper. Organisms have an innate agency which drives their decisions and interactions with the environment. LLM-based agents, on the other hand, can only act as tools to be orchestrated by a conductor. They don’t care, we do. That’s important.
This philosophical distinction may seem a bit arbitrary, but when you think about what it is that human software engineers actually do, it’s not. I’ve talked about this before in my post about Why AI Art Doesn’t Exist. A professional human is hired not to perform a task like an agent, but to hold responsibility over a specific area of value. In other words, we are hired to care.
When there’s a bug in production, it’s on me to fix it. If I have a robot that I can instruct to fix the bug for me, then that’s great, but it’s still my job. Robots will be capable of solving tasks with significant accuracy, but they won’t be capable of taking responsibility like a human, because they simply do not care.
The Future
So then what can we expect the future of software engineering to look like, more precisely? Well, unfortunately the future is historically elusive. However, if we abstract some patterns forward, we might get a hint. First of all, no one wants to automate software engineers more than software engineers.
Automation essentially means using technology to perform a task with minimal human intervention. My high school computer science teacher used to tell us to be “smart and lazy”. Software engineering is full of tasks, so the question is whether these can be completed with minimal human intervention? The answer is yes, and they often are. Software developers use a variety of automated systems to create and manage complex applications, without having to do work manually.
Obviously, manual work is still very much required. However, can we expect that with technological advancements, the proportion of work done by humans versus automated systems will decrease? This is the more difficult question, and I actually don’t know that I think it will. It’s relatively simple to imagine that many tasks will be automated. Developer agents aren’t very good yet, so it’s difficult at the moment to automate more complex tasks like feature creation, complex bug fixes, or development on a legacy codebase.
However, that will probably change. I can imagine that as systems get better, many coding tasks performed by developers will be automated. While there will likely always be edge cases which require human intervention, if humans can do more with less, then this would spell out huge productivity gains. This doesn’t necessarily mean less work for those humans though.
If a machine can do 90% of your current tasks, then 90% of your current job is automated, sure. However, that just means that you can focus 90% more time on the previous 10%. I imagine this looks a lot like orchestrating various robots to perform tasks, under developer managers, who review code and guide the bots to make improvements. Human developers may look more like conductors.
That’s my intuition, at least, for now. There’s also an argument to be made that the current technological line is a dead end for autonomous development with the accuracy that corporations expect. Language models hallucinate, and cause issues. Language models are non-deterministic in practice, and so tasks requiring high degrees of accuracy might require a human developer.
This is, however, all speculation at this point. The main point to highlight in my view is the responsibility which a human developer upholds. While learning to use new technologies is often beneficial, ultimately I won’t be trusting an artificial intelligence with the value center of my business anytime soon.
Author’s Note
This is a sort of existential question which actually has a lot of practical utility to answer. Obviously I went down a bit of a rabbit hole with stone tools, but I hope you found that fun. However the idea of software engineering being automated, or what exactly that looks like long-term, is a fascinating one. I’ll probably explore this idea more in the future, and talk more about agents.
I actually built a simple agent as a sort of experiment myself, and you can check that out here. It’s all open source and easy to use yourself, so if you find that kind of thing interesting, you might be compelled to try it!
As always, thank you so much for reading, and I’ll see you next time. Goodbye.
Credits
Thumbnail:
Bilal Azhar at https://substack.com/@intelligenceimaginarium
Music: Track - Feeling Good by Pufino, Source - https://freetouse.com/music, Free Music No Copyright (Safe)