A Journey with ChatGPT — Create My Digital Clone

I started a fascinating journey with ChatGPT to explore using it to help develop a software system architecture.

DALL-E

While on that journey, I want to bring into one system the combination of three key ideas:

• AI-Native, to borrow a term from this post by Lars Buttler and this one by Andrew Brewer.
• Hybrid AI (combining the best of symbolic AI and machine learning)
• Personal AI (as defined similar to that used by the product site personal.ai — “A Digital Version of You”

The focus of the journey evolved towards the creation of a framework for building digital clones which, for the purpose of this journey, I am calling Echo.

Echo is to be based on these three key concepts with a purpose to provide the tools I need to build a clone of myself.

Brewer provided this definition that relates to the first of our key concepts:

“AI-Native refers to systems, platforms, or technologies that are inherently designed to leverage artificial intelligence algorithms and techniques throughout their development and operation. Unlike traditional systems that incorporate AI as an afterthought or as an add-on feature, AI-Native solutions are built with AI at the very foundation, enabling them to possess enhanced intelligence, adaptability, and autonomy.”

And Lars provided views of the implications for the long term of products based on systems built to that definition.

For the second of the key concepts, we can start with what Jordi Linares provides in his summation of the arguments surrounding Hybrid AI. In that article, he points to this definition from here:

“Hybrid AI brings together the best aspects of neural networks and symbolic AI. Combining huge data sets (visual and audio, textual, emails, chat logs, etc.) allows neural networks to extract patterns. Then, rule-based AI systems can manipulate the retrieved information by using algorithms to manipulate symbols.”

For the third of the key concepts, we can reference the thesis that spawned the commercial product personal.ai:

“… with the mission to build an AI for each individual to augment human biological memory; the vision to change how we humans fundamentally retain, recall, and relive our own memories. At the core are the principles that represent who we are and what we are building: meaningful, authentic, transparent and inclusive. We feel responsible for spearheading this mission in creating a personal AI for everyone.”

I share their passion for the personal nature of this endeavor. But if you dig deeply into their goals, there is a distinction. I could use their tool to build a personal agent to help me do my job better.

But my goal is more like building a clone of certain aspects of myself that you could use — not something to make me better but something to basically eliminate me.

I want to build a clone that has a certain “resume” that may be useful enough to you or someone else. Yes, I can, and do program. But I also have experience doing a lot of other things that would show up in my resume. An interesting clone of me would encompass more than some subset of my ability to program.

My clone would have a persona, a set of skills, a name, and ways of communicating (email, text, website, etc).

For my journey, I bring the desire for the Hybrid AI concept into this because it is my belief that neural networks (including the very Large Language Models like GPT-4) alone cannot achieve the combination of the other two concepts (Native AI and Personal AI). The Hybrid concept supports adding expert system dynamic rule bases into the mix.

We are experiencing a revolution reminiscent of technology leapfrogs in the past, perhaps even more extreme, with the focus framed around AI in some form or another.

My background makes me especially interested in the talk about AI replacing most of our programmers.

I do not think that using AI to generate code is the approach to replacing programmers in large numbers. I also think that as long as we focus mostly on esoteric things like which language (Python, Haskell, Rust, Dojo, etc.) to pair with which LLM model for each application, we will just create more programming jobs — probably with added design and coding complexity.

Replacing programmers will be done primarily by eliminating programming. Read on to understand why I feel this way, why I think at some point that might be practical, and how I am exploring these ideas using AI.

I am a founder of a small contract development and consulting shop that has me at the culmination of forty-plus years of many and varied technological journeys.

Obviously, during this long period we have seen vast changes for how we do business with computers. The tech advances have been huge. There were those things focused on developer productivity, such as compilers, frameworks, operating systems, and design methods. Then there were those innovations focused on end users to make them more productive (spreadsheets, word processors, etc.) — along with the internet, the world wide web, and some “no-code” tools.

If you look at the history of a lot of these advancements, fear accompanied them as well. Many things that we completely take for granted today did, in fact, eliminate some jobs and certainly changed the character of even more. But I doubt if very many people seriously yearn for the “good old days” before spreadsheets and the web. These advances resulted in productivity improvements and better employment/business opportunities.

Does anyone remember when there was a forecast that if things didn’t change, every man, woman, and child was going to have to be a telephone switch plug-board operator in order to support the exponential growth in telephone usage? I helped design and build some of the telecom systems that completely did away with those jobs. However devastating that might have been, the technology behind the advances that did away with that many jobs also fostered the invention of many of the things we take for granted today and also fostered many more jobs.

So we reached a point where it seemed like everyone was going to learn to program. The growth in the number of programmers is truly amazing (more on this later) and seemed like it had become unsustainable.

Well, now we forecast programmers are going to be eliminated by this new technology in a manner similar to the fate of telephone plug-board operators.

I started believing quite a few years ago that towards the end of my career, someone (I had hoped it would be me) would eliminate programming as I knew it at the time (via automation of some sort).

Even as long as 20 years ago, I developed a fascination for AI (as rule-based, blackboard architecture “expert” systems) and believed that someday I would replace myself by “codifying” my expertise in a set of rules as my “final” development project. Well, as time passed, I realized that was probably a bit of an ambitious thought. But back then there was enough hype surrounding AI to feed that kind of thought.

I watched AI progress from its earlier enlightenment period through what became called the AI winter (a subsequent period of disillusionment), I felt that, at some point, the processing power that was holding it back would become available. To quote a Jason Bell article, “Will ChatGPT Trigger the Next AI Winter?”:

“We’ve been through two major AI winters, where interest, adoption and funding in AI technology declines. Between 1974 and 1980, and again 1987–1993 AI popularity slumped.”

During those periods, we had primarily two forms of AI (expert systems and neural networks). They each found interim niches, with expert systems being used successfully for business rules for various industries (insurance companies, healthcare, etc.) while neural net tech was finding application in many basic pattern matching opportunities (recommendation engines, optical recognition, language translation, etc.).

Since I had a long-standing passion for building something smart enough to replace myself, I found reasons to keep up with the general use of these tools in my projects.

Even with my desire to help bring about the demise of at least the low-level programmers, I do not believe that the current machine-learning surge that we have seen over the past couple of years is going to bring that about.

Low-code and no-code approaches to eliminate programming are probably closer in philosophy to that ideal, but as we have seen this technology hasn’t even made a dent in the viability of programming as a career.

There are several factors for why this is so.

The machine-learning, neural net (LLMs, etc.) approach to life is, at its root, a pattern matcher with behavior tied to extensive training. What you see going on now with the higher-level tools being created that leverage large language models (LLMs) is a recognition that they are fantastic at deciphering natural language and accessing/leveraging vast stores of published information, but not much else. Retraining and fine-tuning these models is incredibly expensive and time-consuming, meaning they are always out of date.

GPT-4 models, as well as others, added several techniques to allow them to be part of a broader application solution, “escaping” back to the application layer to have access to databases, unstructured files/data, as well as traditional application logic (all of which must leverage a programmer). Higher-layer programming libraries (e.g., Langchain) have evolved to take advantage of these ideas, making it easier for programmers to chain sequences of operations making use of LLMs in various steps of these sequences — easier for programmers anyway.

Programmers are using the LLMs (and these “chaining” toolsets) to generate code. There are even some interesting cases where the code being generated is used to build higher-level AI chaining applications- applications building applications.

The concept that using an LLM to generate code to replace programmers ignores the fact that the generated code will need to be assimilated into some ultimate solution by something akin to a programmer, designer, etc. who also designed the overall application to begin with (at least in the path we are currently on).

I think there might be more of a near-term threat by this to outsource development companies in India, Vietnam, etc. since they predicate their current business models on eliminating in-house developers via cheap labor. But I suspect even this level of programmer replacement is still somewhat of a dream.

By some accounts, there are over 27 million programmers worldwide, growing on the order of 20% per year. Perhaps, as interesting, is that the TIOBE index put assembly language — ahead of PHP, Go, Swift, and Rust. I find this interesting because we have had good compilers to generate assembly and machine code since the late sixties and expanded in the seventies (Fortran, C/C++, etc.) and yet there is still a fairly strong need for people skilled in developing assembly code.

People like me, who started off in a world where most development was in assembly and machine code, did eventually transition into one or more of the myriad of higher-level languages.

But these higher-level compilers, interpreters, and no-code environments have not eliminated our jobs — even Cobol programmers (because of the huge amount of legacy code out there in the business/financial sectors estimated to be in excess of 200 billion lines).

What does this say about my earlier dream that I could replace myself with some smart tool? Also, why did the creation of compilers seem to foster more of an upsurge in the number of programmers rather than a decline? Why haven’t we seen a huge decline in the number of programmers with so much “off-the-shelf” software (open-source libraries, etc.)? And what does the spate of news lately about the layoffs occurring in large companies say about what is going on with AI and other factors?

Back when I first started, programmers wrote all of their own code and there wasn’t a Google to help search out something off-the-shelf. First principles (ala Knuth algorithms, etc.) and/or original innovations were used to build stuff back then. Now, we have more productivity tools but still more programmers. I asked ChatGPT how many programmers there were in the early eighties and the summary of its response:

“It’s reasonable to assume that there were several hundred thousand to possibly over a million individuals involved in some form of programming in the early 1980s, spanning professional, academic, and hobbyist contexts.”

So, the world’s population has doubled since the early eighties and yet the number of programmers is up by a multiple of 20 to 50 (depending on who you believe). We have had a vast increase in the number of productivity tools for programmers and yet the world’s need for them has reached a point where we need over 20 times the number we had back then (when we had no tools to speak of), and seem to be growing at a compound rate of 20% per year.

Again, I asked ChatGPT for an estimate of the number of lines of code in the 1980s vs. today.

The short story of its response was on the order of billions in the 1980s vs. trillions today (interestingly consistent with the order of increase in number of programmers).

I think deeper analysis would show that today’s programmers each deal with a similar number of lines of code (LOC) as those of yesteryear, but to quote ChatGPT again:

“It’s worth noting, though, that software from the early 1980s was typically much more concise because of the constraints of hardware. Developers often had to optimize for space, resulting in smaller, more efficient code. High-level languages and libraries that mask a lot of code behind the scenes were less prevalent, meaning that developers often wrote more ‘manual’ code for tasks that might require fewer lines today.”

My interpretation of that: the code we are writing today is higher level (because of languages and libraries) but we each still handle about the same order-of-magnitude number of lines of code per programmer. Interesting. I also should note that back then there were a fair number of Cobol, Fortran, and Basic programmers — meaning, not all of it was in assembly.

According to a summary in “Layoffs.fyi”, from the beginning of January through August 2023, there have been about 227,621 (about 1% of the world’s programmer population) against 164,744 layoffs in all of 2022. Note that most of this layoff activity is really before widespread effect because of AI code generators and related tools. Also, note that in 2022 there were more than one million hired in that same information sector (down about 10% from 2021, but still significantly higher than the number of reported layoffs).

I suspect 2023 will end up similar in the sense that there will be significant new hires offsetting some of this layoff activity and also suspect that little of what we have seen so far relates to AI replacing programmers.

So, the summary of that is:

• We really have seen little evidence that AI has caused attrition separate from what is going on related to our macroeconomic slowdown (yet).
• A lot of the really large companies over-hired (especially during the pandemic) and have had to retrench at least a little this year (in my opinion).
• We still have additional economic risks that will affect employment more than AI does. In fact, it wouldn’t surprise me if the buzz around AI has forestalled some of the slowdown that was forecasted for 2023 and has actually saved some programmer jobs (ironically).

Back to the original premise. Do I believe AI can cause a significant change in the way programming is done? Yes, but not by simply being a better method to generate code.

Using the simple code generation approach is going to continue the trend we have been on since the 1980s, resulting in an upward trend in the number of programmers. Why? Because we would still be programming and, in fact, in even more complex environments. We may reduce the number of low-level programmers (similar to what happened to assembly programmers) but we will not eliminate the programming job. The total number would still go up.

My assumption that the number of programmers will still go up takes into account the fact that we will be using AI for generating code, improving methods for design, documenting, and testing. And we will continue to see an increase in high-quality libraries.

To actually eliminate programmers (similar to eliminating telephone plug board operators) will take a truly fundamental shift that actually eliminates programming rather than improving how it gets done.

What does that mean? To answer that, we should observe that programming is “the writing or preparation of computer programs” (definition from Oxford Languages). A computer program “is a sequence or set of instructions in a programming language for a computer to execute” (Wikipedia). All forms of programming today require translation (aka compiling or interpreting) of source code into machine instructions. Most programming we are talking about is producing the source code containing that sequence of instructions, whether it’s done manually by a human or automated via tools like AI and/or low-code/no-code processes.

So, to “eliminate programming” (in order to eliminate programmers) means getting rid of the need to produce source code.

That is the fundamental change that I think it is going to take to really eliminate programmers in any significant number. There may be several approaches to that.

Our first key concept as defined above (AI-Native), the main takeaway from Brewer’s article was a system where AI was not added as an afterthought. The telecom company Ericcson provides a whitepaper called “Defining AI native: A key enabler for advanced intelligent telecom networks” that “presents a number of views on the artificial intelligence (AI) native concept and discusses the background and context of AI native implementations. A maturity model is introduced for specialists to determine at which level of AI native maturity a certain artifact is at”. One takeaway from that article:

“….an AI native implementation leverages a data-driven and knowledge-based ecosystem, where data/knowledge is consumed and produced to realize new AI-based functionality or augment and replace static, rule-based mechanisms with learning and adaptive AI when needed.”

When I hear that term (AI-Native), it also evokes an idea that the way we interact with computers shifts from writing requirements or code that gets translated into machine code to one where the computer “understands” our natural language-expressed intention for what it is supposed to do and that all of our interaction with Echo is done with natural language — no translation to an intermediary form the human has to handle. This could be expressed as a goal:

Build an entire infrastructure that relies entirely on natural language to perceive and act on user intent rather than relying on AI to generate any form of intermediate expression (source code, etc.) that the user is responsible to understand and handle.

AI is intrinsic to the system and natural language is the interface.

This brings us to the point where we need to address: who is the user and what is his natural language?

There is a body of work going on now to use AI to process user requirements expressed in some form of natural language and generate architecture, detailed design, and code with automated testing. Clearly, the user for this would have to be someone akin to a programmer.

There is also the body of work we call no-code that has historically implied a point/click/drag user interface metaphor with a necessarily niche, constrained viewpoint of life. The user for this would be someone specifically tied to that niche.

This won’t eliminate programmers either since we will employ tons of them to build niche environments. Also, these no-code environments themselves can represent fairly complex user learning requirements as the niche gets applied to broader domains. You can look at the Shopify developer ecosystem for just one example. Shopify provides a no-code framework for building an ecommerce online store but has nevertheless fostered “over 700,000 app developers, designers, and Shopify partners” in addition to their own 900+ developers — all in support of a “no-code” framework. WordPress powers close to half of the websites on the internet and can allow non-programmers to put up simple web sites and blogs, it has also fostered an ecosystem of a huge number of developers to support its users. More about that framework is available here.

There have been tools along these lines for years (even before today’s AI) without making a dent in the proliferation of programmers.

To create any effect with a computer, somewhere along the line, there has to be one or more “domain experts” involved. This is also called a “subject-matter-expert”, which is a person with specialized knowledge in a particular area. Programmers are typically only domain experts in programming.

So, building any complex application requires shifting the knowledge from the domain experts to the programmers in some manner.

I was lucky enough early in my career to get several firsthand experiences with the enormous benefits of any fundamental shift that keeps the traditional programmer out of that process.

Meet the domain expert where he is, and communicate with him in his most natural, comfortable form.

The current prior art has many examples of attempts to conform to this philosophy, including business rules executed by rule engines to represent insurance compliance or medical diagnostic rules. Obviously, getting an insurance compliance expert or doctor to understand how to deal with software wouldn’t make much sense, so the industry has moved forward to help them in these and similar niches.

What is happening now is that we are moving toward tackling the support of a much broader base of experts whose natural language looks more like English, Spanish, etc.

The problem here is that the successes we have seen with the more niche solutions we have done in the past involved the practical confinement of the experts to constrained, domain-specific language like business rules, or no-code environments which also are constrained.

The experts we want to approach now are more comfortable expressing their needs in their native tongue (i.e., English) as their natural language, with as little taxonomy and syntactical confinement as possible.

Why do we have this need? Because the base of domains and experts we really want to deal with is much broader than anything attempted in the past. We want to deal with different experts spread across many domains (insurance, healthcare, shipping, eCommerce, art, science, software, etc.).

We don’t want to build niche systems (if the goal is to eliminate programmers).

This begs for an adventuresome paradigm shift.

Part of this shift relates to our first key concept: “AI-Native”. Our paradigm will not involve using AI to write code but eliminate the need for writing code — a very important distinction.

Note that this parallels the use of AI for image generation, where there is a direct application of natural language to the desired result. That is like what we want from Echo for all appropriate computer applications.

Here are some factors to consider when making this shift:

• Natural language is the primary (perhaps exclusive) interface with this world (input and output).
• Machine learning, with its pattern-matching “skill”, along with all other forms of retrieval-agumented generation are too limiting. At present, that conbination is very good at translation and completion, but not very creative with severe domain understanding and learning limitations.
• Echo must have an execution method that bypasses high-level language representation while keeping behavior and algorithmic control in the hands of the domain expert (starting with me).
• Dynamic rule-based representations of domain expertise are important (rather than relying on frequent or niche retraining of a neural network).
• The architecture of Echo will support many communicating and cooperating “agents”, resurrecting the expert system blackboard idea. Echo will endow agents with their own domain expertise and the ability to learn within their domain, supporting both rule-based and machine-learning agents.
• What we currently consider debugging and testing would need to be native, exposed, and controlled only by natural language — part of the dialog between the domain expert and the Echo system. An important aspect of this will be explainability that is currently missing from most LLM applications.
• The entire underlying “intelligence” (combination of ML and rule-based agents) must be dynamic (changed via learning and expert user input/feedback).

This is a large undertaking, but I believe most of the elements to start down this path exist and, in fact, a lot of the ongoing effort in this sector is dancing around these concepts already — just not holistic enough yet.

I believe an important factor in that list is the fact that the debugging and fixing involved must be at the natural language level in the same vein that we now require source-level debuggers for higher-level languages.

The result, at least as a thought experiment, is that Echo eliminates programming as we currently know it. So there are two classes of user for Echo: any expert (starting with me) to create a digital clone and then anyone that eventually uses that clone.

Why me? My primary contribution to this is mostly the long-standing goal of creating a smart tool to replace a significant part of me. This, plus the belief that we need to push the boundaries of a “hybrid AI” framework (one combining things like rule-base and ML tech). I come at this with a lot of experience building systems, applications, and tools. Coupling my interests, skills, and deficits with a desire to push the boundary of what tools like GPT-4 currently can do:

I started a path creating an architecture for Echo by guiding ChatGPT as my assistant, fully documenting that journey as I proceed.

This will accomplish several things for me. I will learn more about ChatGPT’s limitations with how best to augment “him/her” and how “he/she” can augment me. I will learn more about the application of hybrid AI architectures/techniques and where the boundaries are for each (ML and rule-based).

And I will have fun at the same time.

A series of articles will chronicle the steps (and probably miss-steps) along the path. These will mostly be in the form of discussions with ChatGPT with guidance from me as we go along. I am picking him as my partner in this endeavor because he seems to be a fairly efficient search tool for things related to the current state of the art and he has no existing prejudice about how to proceed. I have also had great success with his help building simple applications and doing basic research.

This journey is not a discussion of Artificial General Intelligence (AGI) or Super-AGI. Those concepts are quite distinct and more complicated from the much simpler context of my interest in “eliminating programmers” (or, at least replicating part of myself). LLMs like GPT-4 are not intelligent and, at this stage, aren’t close to replicating me. They represent to me a vast library with a great search tool to access information from that library. And I intend to exploit that to its fullest on this journey. But at the end of the day, even with that vast training, they still don’t know all that I know. Plus, they are missing some very key intelligence characteristics related to reasoning, planning, goals, etc. towards the creation of truly new things.

I am very experienced at what I do, but what I do (and what any of you do as an expert at something) is very limited in the broad landscape. Meaning, that even though I have been at this for over forty years, I cannot replace all programmers (certainly not as a group and not even most individually). I am “trained” on certain tasks coupled with a fairly decent ability to learn new things. For that training, I am paid quite well.

I’ve managed a lot of architects and programmers in my career, and they were all different. I think the task of creating a robot general programmer/architect is too difficult today and probably not worth the effort anyway. I’ve actually never met one that was all that general. To create one to behave as I would might be closer to reality and, even for that, maybe it would be paid quite well too. I could envision an ecosystem where people like me trained a robot to perform a job and then other people hired it (through me as the creator of course) and then called me when it messed up — funny thought anyway.

Therefore, all I am asking from my clone journey is a thing that has assimilated most of my experience and the ability to learn somewhat beyond that. If I had that, I would no longer suffer the limitation of working on one or two projects at a time because I could clone myself many times over — even though each clone probably would be no better than I am (albeit I can hope it is more focused, faster, and less distractable).

There are a lot of things about me it doesn’t really need to learn or have goals for (sleeping, eating, mating, making money, playing, zoning out, etc.). So, we are talking about a much simpler version of myself. And maybe a platform to make a simple version of you if it ends up being general enough.

What I know is that if I built a robot that could only do precisely what I can do in the limited context of “my day job” then I would consider that robot intelligent enough for this experiment. I have been wanting to work on this for many years and only now feel that I have the tools to start. I will probably have to create many more tools myself, but we have a start.

When I started the journey, I felt that what I was pushing for was a method of transforming the way we harness AI (as it exists today, of course) in such a way that the tool represented something that no LLM is trained on (yet): my knowledge and your knowledge (or, anything unpublished for that matter). The current techniques for pushing down that path seemed too cumbersome (fine-tuning, vector databases, etc.) — at least by themselves as tamed by programmers skilled in the art.

Lastly, I am editing elements of this journey most mornings as a daily startup activity and therefore constantly influenced by the flurry of activity in the AI tech space. Hell, it seems to take an hour or so each morning just to catch up with what happened yesterday.

Anyway, this morning while I was catching up, I ran across an article by Steve Yegge (“We’re Gonna Need a Bigger Moat”) that did two things for me. It provided a nice summary of how we got here (as of his May 11 article anyway). And it gave me an additional way of articulating why my goal for this clone journey might be important.

I think knowledge is our moat.

Here I mean the “moat” discussed by Steve in that article. That's the thing that makes my endeavor different than yours (or OpenAI, Microsoft, Google, etc.). Each of us (who is experienced deeply in something) has accumulated a wealth of knowledge, most of which is not normally represented in any collection of LLMs and the custom application databases that are built to use them.

It is the ability to transfer the salient parts of that knowledge via natural language that I hope for this journey

I am coupling that thought with the belief that we will require a great deal more creativity to pull that off than just fine-tuned AI transformers.

ChatGPT and I have completed the basic high-level design and the amount of detail is a bit much for sharing as a bunch of Medium articles (my first choice), so I am moving to the creation of an ebook so I can more easily capture all of the dialog with ChatGPT and all of my thoughts that went into the design. I also applied for a provisional patent that is based on the design.

The code resulting from this will be released under a permissive open source license, and the provisional patent filing idea is consistent with the “anti-patent” idea I discussed in one of my previous articles, “Open Source: Patent Land Mines?”. My goal is to make sure this work ends up being truly open and does what I can to block others from taking out patents that thwart that goal.