Transcript
Phillip Mortimer: Today I want to talk to you about two seemingly unrelated topics, complexity and creativity in software engineering. I'm going to start with a wall of code. This is actually a legendary piece of code. It's written in C. Do we have any C developers who might know what this is or recognize it, or perhaps guess what it might do? This legendary piece of code is known as the J Incunabulum. Incunabulum meaning cradle or initial seed. This is the initial seed for a programming language known as J. It was written in a single afternoon in 1989 by the Canadian computer scientist and mathematician, Arthur Whitney. As you can see, it's very terse. It's very dense. It's very complex. It's very hard to read. This tiny piece of code is in fact a working interpreter for the programming language known as J. It includes an object model, memory management, a standard library, a parser, a lexer, and a read-eval-print loop. A full working interpreter on one side. It's quite remarkable.
Write-Only Code
The author of the J Incunabulum, Arthur Whitney, was famous for writing incredibly dense C code. Arthur's important. He'll come back later in this talk. First, I want to use his code to introduce the concept of write-only software, and to argue that in the age of AI, all code is write-only. That that, in fact, is not a bad thing. What do I mean by write-only code? Here's a wonderful quote from Eric S. Raymond, the American software developer and open-source advocate. He writes, write-only code is code so arcane, complex, or ill-structured that it cannot be modified or even comprehended by anyone but its author. Possibly not even by him or her. I'm sure we've all seen examples of this. Certain languages are write-only by design. They trade readability for incredible power and performance. Let me show you two examples. The first is APL, which stands rather grandly for A Programming Language.
The language was proposed by Ken Iverson in 1962 while he was working at IBM. It uses a mathematical notation to manipulate arrays. It was an interpreted language, which at the time was rather unusual, but meant that it was effective for rapid development and therefore became very popular in financial institutions in the '70s. I have personal experience writing code in APL. I spent 10 years working at Morgan Stanley, first in London, then in Tokyo, where I was a quantitative developer supporting the fixed income trading desk. Morgan Stanley implemented its fixed income risk systems in A+, a derivative of APL created by Arthur Whitney when he worked at Morgan Stanley some 20 years before me. That's how I first became familiar with his work. I hope you've all been studying this line of code carefully while I've been talking because I've got another quiz question for you.
What does this line of code do? It's probably harder than the first one. This implements a single generation of Conway's Game of Life on the Boolean matrix, omega. That's on the right. Note that in APL, there's no operator precedence, so you read everything right to left. This single expression implements what would be 40 or 50 lines of code in most other programming languages. I should point out, this code is not deliberately obfuscated. Arthur Whitney himself said, elegant code is always the shortest code. When you understand it, this code certainly is elegant and beautiful. As you can see, it very much meets the definition of a write-only software. You can write the code, but come back the next day and try and read it. Good luck.
The second example of a write-only language, perhaps the poster child for write-only software, is regular expressions, something I'm sure all of us are familiar with. Here's another piece of write-only code. It's my third and final quiz question. Anyone know what this might do? This is the easiest one. This is a date validation regular expression. It validates dates in U.S. date format, so MM/DD/YYYY. It's valid for all 4-digit years from the year 0 to the year 9999. Remarkably, it includes correct leap year handling, so any year divisible by 4, but not by 100, and that's also divisible by 400, without any procedural code. You can see the same pattern. A tiny piece of code, enormously powerful, completely unreadable. I've worked extensively with regular expressions too. After I left Morgan Stanley, I went back to school and studied machine learning at UCL. Eventually, I joined a startup called Accelex, where I worked on document intelligence solutions for private markets.
Our early prototype relied heavily on regular expressions. Working with regular expressions is not easy, which brings me to an important point. "Some people, when confronted with a problem, think, 'I know, I'll use regular expressions.' Now they have two problems." This is a wonderful quote from Jamie Zawinski, an early Netscape engineer. This applies more generally. Solving a problem with write-only code just gives you another problem to solve. In my career, I've unfortunately created more than my fair share of problems for myself. APL and regex represent a kind of complexity, a complexity that comes from extreme density. Having spent years writing code in APL and regex, I found two principles that apply when you're trying to deal with this kind of complexity. First, the tests define the behavior. When you write code that is too dense to read, the only way to understand what it does is through extensive test cases.
The tests become the documentation for your code. You read the input-output pairs, and that tells you what the code is supposed to do, because you can't read it very easily from the code itself. Second, the code is disposable. Because write-only code is so hard to debug, in fact, it's almost impossible to put a breakpoint in the middle of a long regular expression, for example, it's often easier to rewrite the code from scratch than it is to modify what you've already written. You keep the tests, throw away the code, and write it again. Tests define the behavior. Code is disposable. Keep those two principles in mind, because I would like to argue that now all software is write-only. All code is now write-only.
Perhaps many of you saw the blog post that Anthropic released when they announced Claude Opus 4.6. In that blog post, they described how Claude had developed its own C compiler in Rust autonomously over a period of two weeks. These are the statistics from that GitHub repo which contains that project, 500,000 lines of code added, 277,000 lines of code deleted across 4,000 commits. Now the interesting thing is, the code itself is not hard to read. In fact, AI is very good at writing well-documented, well-commented code with good docstrings. The code is far more readable than anything Arthur Whitney ever wrote. It's impossible for a human to review all of it, not because any of an individual line is incomprehensible, but because of the sheer volume of code that is being generated. AI writes code far more quickly than any human can read it. I would assert today, for this reason, all code is now write-only.
Not because of arcane notation like APL or extreme density like regex, but because of a new kind of complexity, the complexity of volume. Different cause, same result. The same two principles apply. The tests define the behavior, and the code is disposable. What are the implications of all this? Firstly, the pull request process is broken. There's no point having humans try to review AI-generated code line by line, because humans very quickly become the bottleneck. In fact, this reminds me of a problem in MLOps. When you train a machine learning model, you feed data into an algorithm, train the algorithm on that data, and the output is a set of model weights and some performance statistics that you've generated during your training run. Then you put those in a model registry. There's no pull request process in model training. No one goes in and says, your fifth tensor, the fourth column, the third row, that weight should be 0.77, not 0.73.
That's nonsense. It's a black box. What humans do is they review the performance statistics of the model. I think we need to move to this way of thinking about code. Evaluate the performance statistics and the outputs of your code, not the implementation. We should shift feedback left. Collaborate and review at the time of writing specifications and requirements, not at the implementation stage.
Managing Complexity
Here are some practical ways to manage this new write-only world. Number one, because the tests define the behavior, write really detailed tests. Claude and other models are perfectly capable of working autonomously and writing high-quality code to solve almost any problem in software engineering that you can throw at them today. In fact, if you ever watch Claude working and seen it using bash, grep, GitHub Actions CLI commands in the command line, you'll quickly realize that in many ways they're working at a level far beyond I've ever seen a human ever work, chaining together multiple commands using arcane arguments that most of us have never even heard of. Neither you nor the model can verify that the output is correct without extensive test cases. Write really detailed tests. One of the reasons that Claude could develop a C compiler autonomously over two weeks was that Nicholas Carlini, the Anthropic researcher who supervised that project, first collected as many high-quality C compiler test cases as he could find. Then he built a test harness using those test cases that guided Claude as it worked.
Next, automate your code reviews. If you use Claude to write your code, have Claude review your code. This is something we already do at Carta, where I now work following Carta's acquisition of Accelex. An AI code review is surprisingly effective. You might think, if a model made a mistake writing a piece of code, how can the same model detect that mistake when it's reviewing the code? It does, and it's amazingly effective. We've seen it time and time again. The review model has a different prompt, different instructions, and a different context, and that's enough to allow it to catch a large number of errors. I want to give you a concrete example of this in action. Yes, I've got another regular expression on the screen. When I was preparing this talk, a colleague of mine used AI to raise a pull request, which contained a regex, and AI code review caught a problem with that very regex.
I couldn't have picked a better example for this presentation. This is a real example, not this actual regex. I've simplified it, but it illustrates the point. The AI code review caught a problem with this, or a similar regex, known as catastrophic backtracking. Let me explain what that means, since I have a little bit of experience with regex. This regex will accept a word character \W, one or more times, +, followed by a space character, \S, zero or more times *, and then that whole expression, one or more times. Now the problem is, the presence of this optional space character means that for a run of n word characters, you can split or not split between any two characters. For the regex engine to assert a non-match, it needs to check 2 to the n-1 combinations, basically a binary counting problem. For a 20-character string, that's 500,000 combinations it needs to check. For a 30-character string, 500 million. For a 40-character string, the heat death of the universe occurs first. A potential problem that could lock your application and cause a denial of service. A real issue caught by AI code review on AI generated code.
Next, have your software heal itself. AI will write bugs, just like humans write bugs. You'll probably use some kind of observability platform like Datadog, Sentry, and so on. Probably you have millions of exceptions or thousands of exceptions every day, which raise alerts, most of which you ignore because you don't have time to look at them all. A really powerful thing to do is to have an AI coding agent listen to your observability platform, aggregate the alerts over some time window, and start to raise pull requests to fix the problems that it's seen, starting with the most common ones. Over time, your software autonomously heals itself. Eventually all you're left with are just the critical bugs that require human judgment, or perhaps a more complex and extensive refactor to fix. At Carta, we've implemented just such a system as a Claude skill, not quite yet fully autonomous, but it's already very effective.
At Carta, we also use trunk-based development, which means that we guard new features behind a feature flag. Over time, old feature flags accumulate if you don't consciously go in and clean them up. Behind those feature flags, which are turned on everywhere, sits thousands of lines of dead code. This is another wonderful bounded problem that lends itself really well to AI automation. My colleague Eric Vogl has implemented another Claude skill for this, which he calls the Feature Flag Reaper, hence the picture. So far, it has autonomously cleaned up more than 400 feature flags and tens of thousands of lines of dead code.
The wonderful thing about AI coding is it's the ultimate decoupling of intent from implementation. Decoupling intent from implementation is not a new idea in software architecture. Traditionally, it's achieved through abstraction, interfaces, or APIs. Now, it's at the highest possible level of abstraction, natural language. You only need to worry about the problem you're trying to solve. In other words, the code is disposable. Fifty years ago, C decoupled software from hardware. It allowed the same piece of code to be compiled down to work on multiple hardware target architectures. C is hard. It's low-level. It's potentially dangerous. C spawned an explosion of higher-level languages, which we all use today, most of which are actually implemented in C. We've closed the loop, because now AI decouples intent from implementation completely. It makes developers portable across programming languages. I've spent my career working primarily in three languages, A+, C++, and Python. Today, I'm regularly touching Terraform code, I can write UIs in React, and of course, I still write code in Python as well. Today, we are all full-stack developers.
Finally, a related trend. Monoliths are making a comeback. AI works best when all your code, business logic, and functionality sits in one place. At Carta, I spent the last few weeks collapsing Accelex's old document intelligence architecture down into a single service, because LLM calls are replacing what used to be single-task ML models deployed as independent services. Importantly, more generally, what used to only be possible with complex workflows built on top of complex software systems can now be implemented with a single agent running in a Python process calling LLMs via APIs. While software complexity is going up, architectural complexity is going down.
Creativity
Here's Jensen Huang. He said recently, intelligence has become a commodity. Software is writing itself. Software is reviewing itself. Software is healing itself. Architectural complexity is going down, so your infra engineers have got less to do as well. What's left for the software developer to do today? What's their role? I think the answer is creativity. I want to spend the rest of my time talking about what that means. What is creativity? Arthur Koestler, in his book, "The Act of Creation," described creativity as what he called by association, the sudden, unexpected collision or synthesis of two previously unrelated frames of reference. That's a rather highbrow definition. The advertising executive William Bernbach, in his popular book, "A Technique for Producing Ideas," put it more simply. "An idea is nothing more nor less than a new combination of old elements." Both of these definitions describe the synthesis of two previously unrelated concepts, leading to a new, broader understanding.
You could say a eureka moment or a flash of inspiration. There's a myth that creativity is the exclusive provenance of genius. We have a deeply ingrained cultural narrative that creativity is a rare gift that belongs to a special class of people touched by something the rest of us simply don't have. Only such people can have a critical insight that changes everything. It's a seductive narrative, but it's largely false. Attempting to prove that creativity is the exclusive provenance of genius, the psychologist Lewis Terman ran one of the longest studies in psychology at the beginning of the last century. Starting in the 1920s, he tracked 1,500 gifted children which he identified using an IQ test from a pool of nearly 170,000. Due to the fame of the study, those 1,500 children became known as termites. Thirty-five years later, Terman proudly announced that his gifted children had produced many scientific papers, novels, and other publications, thus validating his theory that creativity comes from genius. When others went back and looked at his study more carefully, they found that there was no control group. They looked at the 150,000 children that Terman had rejected, and they found something interesting. They found William Shockley, inventor of the transistor, and Luis Alvarez, who pioneered nuclear magnetic resonance, both of whom won a Nobel Prize for physics.
When we look at the great creators, we tend to remember only the transformative leap and forget the years of hard work that went before. The Wright brothers worked on human-powered flight for more than a decade before they first left the ground in 1903. More recently, I'm sure you've all seen OpenClaw, which has exploded in popularity as an AI agent that you can run on your phone. Before OpenClaw, its creator, Peter Steinberger, had published 43 open-source projects, none of which achieved anything like the success of OpenClaw. What better example of this than the man we started this talk with? Arthur Whitney wrote the J Incunabulum in an afternoon. It looks like a flash of genius, but it wasn't his first attempt at this problem, and it wasn't his last. Whitney had spent decades working with APL prior to writing that code. In fact, Ken Iverson, the creator of APL, was a family friend of the Whitney's, and Arthur first met him when he was 11 years old.
Now, APL had two portability problems. Firstly, its interpreter was written in assembly, and it was therefore tied to IBM mainframes. Secondly, it used a special character set which required a special keyboard, which we saw earlier in the Game of Life example. The Incunabulum was Whitney's attempt to solve both of those problems. An interpreter written in C, and therefore portable across hardware architectures, and a language that used just the standard ASCII character set. The J language was ultimately taken forward by others. Whitney moved on. He left Morgan Stanley, and he founded KX Systems, where he created another programming language, rather unimaginatively called K, that was even more radically terse, and with an interpreter so small that it fit in the cache of a CPU, and was therefore blindingly fast. He then built kdb+, a database, using the K language, and q, a SQL-like query language that could retrieve data from KDB.
These systems are still used throughout finance today, turning large amounts of data into large amounts of money for banks around the world. Whitney's journey from APL to A+, to J, to K, to q, spans over 30 years. Each language solved a new problem. Each one built on everything that came before. It was a process of continuous refinement, not a single eureka moment. What does that mean? The Wright brothers, glider to Kitty Hawk, Steinberger's OpenClaw, Whitney's APL to q. The pattern is the same. Creativity is iterative. Creativity is work. It's step-by-step improvement over long periods of time. Creativity is not a trait exclusive to genius. Anyone can create, you just need to start working.
Fostering Creativity
Let me offer some practical thoughts on how to foster creativity. Number one, overcome the cold start problem. I don't mean the few seconds it takes for your Lambda to spin up on its first invocation. I mean the cognitive leap that's required to actually begin. Here's a photograph from another part of my life. Despite being a computer scientist for most of my career, I've always had creative interests outside of work. When I lived in Tokyo, I played keyboard very badly, in a post-work band called VUMF. We started each performance with an improvised drumming piece, all four of us standing around the drums, creating something new. This was our way of overcoming the cold start problem of live music and getting into performance mode. I want to give you something more practical than just go play the drums. Here's a technique from Pixar, it's called the worst idea possible exercise.
If you've got a problem to solve, think of the worst possible solution to that problem and then flip it. The inverted idea is often a good one. Here's another one, which I'm sure we all use every day now, build the smallest version possible. Use AI to generate a rough prototype. Just get something down. Once something exists, momentum begins to build. At Carta, we've been doing something similar with AI. There are so many tools out there: Codex, Claude Code, Gemini, n8n, you name it. It's hard to know where to begin. There's really no good training or documentation at the moment. Everything is so new. It's paralyzing. We've been running hackathons, getting the whole company using n8n and Claude Code, just getting people over that first hurdle. Getting from 0 to 1 is often the most difficult but important step.
Second, embrace your constraints. You might think, I can't be creative. I don't have the resources. I don't have the time. I have deadlines to meet. Paradoxically, constraints unlock creativity. They remove the infinite possibilities of a blank canvas and force you to explore a bounded space. When we started Accelex, one of our core problems was reading data from tables in documents like this one. With enough time and resources, I would have followed the standard approach, page layout analysis, table detection, cell detection, and so on. The established top-down pipeline for table understanding from page to table to cell. I didn't have the time, so I made a bold assumption. If I could find a metric name, EBITDA, a date, 31st of December, 2024, and a number, and they aligned horizontally and vertically like this, then I assumed that they were in a table, even though I didn't really know that.
The more such metrics you could find together on a page, the more confident you were that you were actually reading a table. It worked. It worked surprisingly well for the large grid-like tables we were trying to read. It was enough to secure us our first client. When we'd secured our first client, that was enough to raise our series A, after which, of course, we went back and built the standard top-down pipeline. The constraint forced the creativity in the beginning.
Next, embrace solitude. That may sound unusual, particularly in the corporate world, where brainstorming is a default method of being creative. Brainstorming was invented by the advertising executive Alex Osborn in 1939. The idea is you get a group of people together, they suggest ideas to each other, which are then considered, often without criticism. It's been enormously popular ever since. Does it work? It's been tested scientifically, and the answer is, no, it doesn't work. When you compare a group of four people brainstorming with four people trying to generate ideas individually, the four individuals consistently generate 30% to 40% more ideas than the group. As the group size increases, that discrepancy gets worse. Here's Steve Wozniak. Most inventors and engineers I've met are like artists. In fact, the very best of them are artists, and artists work best alone. Don't be afraid to work alone. Concretely, how do you work alone on a problem?
Paul Graham, co-founder of Y Combinator, amongst other things, published a famous essay, "Maker's Schedule, Manager's Schedule." Managers operate in one-hour blocks. Their day is a sequence of meetings, and no single meeting is a particular cost. Makers, engineers, creative people need long, uninterrupted blocks, deep work. Try to arrange your calendar accordingly. If you can, group your meetings together at the start of the day or the end of the day. Block out a large period of time to work on a hard problem alone. I'm a night owl, and personally, I like to work late at night when everyone else has gone to bed. Perhaps others prefer to get up early in the morning. If you can work flexibly, give it a try.
We arrived at this problem by saying AI has solved the implementation problem, the only thing left is creativity. I want to go further than that. Every time in history that a new technology has enabled people to generate and create at a speed that was previously unimaginable, to produce write-only output, in other words, it has led to an explosion of creativity. Let me explain. Photography is the obvious example and is another creative interest of mine. In fact, this is one of my own photos from China that I took in 2008. Photography allowed the creation of images without manually painting every stroke or drawing every line. Initially, photography wasn't considered an art form. Its production was mechanical, optical, and chemical. No human hand was involved, and that didn't fit the sensibilities of the time. Eventually, photography was recognized as an art form in its own right. Perhaps more importantly, photography liberated painting.
Once photography could depict reality, painting no longer needed to. That liberation gave rise to impressionism, expressionism, and abstract art. In architecture, parametric design has had a similar effect. Architects no longer draw individual beams and bolts. They specify the constraints, the shape, the span, the load-bearing characteristics, the material. You could say the test defined the behavior, then the software generates the structure that satisfy those constraints. The Iraqi-British architect Zaha Hadid has used this to incredible effect. This is the KAFD metro station in Riyadh that was opened in 2024. It contains thousands of interlocking structures that no human could have drawn by hand. The technology didn't replace creativity, it amplified it. In music, Beethoven went completely deaf towards the end of his life. He could still write music on the score, but he couldn't hear it back. You could say he was composing in write-only mode. This period of forced write-only creation corresponded to some of his most radical and innovative works.
His famous 9th Symphony, his late piano sonatas that contained syncopated rhythms that predate jazz by more than 100 years, and minimalist textures that predate modern minimalist classical composers by more than 150 years. Deafness didn't diminish his creativity, it amplified it. Today, the digital audio workstation allows a single musician in a bedroom to create music with hundreds of tracks and thousands of effects. Something that would have required a full orchestra and a recording studio just 50 years ago. The creative explosion in popular and electronic music over the last decades is inseparable from this technology.
I'm sure many of you got to where you are today because you enjoy writing software. It's challenging, mentally stimulating work. Personally, I particularly enjoyed my time writing APL at Morgan Stanley. Many of my colleagues felt the same. It's an incredibly difficult and challenging language to master, but when you nail an elegant one-liner, like the Conway's Game of Life example I showed earlier, it's incredibly rewarding. The pace of change that swept over our industry recently has been rapid. The models that have been released over the last few months have shown a step change in capabilities that have left many of us in an existential crisis. What I've discovered is, although I like writing software, what I really like doing is solving problems and building. There's never been a better time to build with software than today. Intent and implementation are now completely decoupled. We are all full-stack developers.
All you need is a creative idea. Write-only code, from regex to APL to AI, each trades readability for power. Each demands that we let the tests define the behavior, treat the code as disposable, and focus on intent rather than implementation. Each time we've made this trade, in art, in architecture, in music, it hasn't diminished creativity, it has amplified it.
Closing Thoughts
I want to close with two thoughts from people with whom I've worked closely, and in whose footsteps I've followed. When I was working at Morgan Stanley, a famous quant named Jay Dweck was brought in from Goldman Sachs to lead the technology organization. Jay was an incredibly creative man himself, not only a brilliant quant, but also an accomplished violinist. Curiously, despite his illustrious career on Wall Street, Jay is perhaps most famous for building a violin-shaped swimming pool in the garden of his New York mansion at a cost of more than a million dollars. That's a story for another day. Jay said something I've never forgotten. "You use the verb, to write, when you're doing something creative. You write prose. You write music. You write screenplays. You write software." Arthur Whitney, when asked what writing software was most like, if it was not just engineering, replied with a single word, poetry. Writing software has always been a creative act, and in the age of AI, it's about to become even more so.
Questions and Answers
Participant 1: You've really emphasized the role that testing needs to play in all of this. If code is going to become write only, then we need to be able to verify it. It feels like we're very much in danger of also, as an industry, letting the AI write the tests. How do you think we can or should combat that risk? If we let the AI write the code and also let the AI verify it, then it strikes me that we're losing control of that ability to actually verify that it does what we want it to do.
Phillip Mortimer: I think ultimately, there's going to be some top level of behavior specifications that we will observe and we can verify. I think ultimately, we need to trust the AI as well, more than we do right now. AI will have to make AI write the tests as well as write the implementation. I think it's inevitable, given the speed at which AI can generate. In fact, also when Anthropic released Opus 4.6, in the model card that came with it in their white paper, they said their ability to test the capability of the model is limited and they're now relying increasingly on the model to test itself. Yes, it's a bit of a circular loop, but I think it's unavoidable.
Martell: Will the AI at some point become creative, and then what?
Phillip Mortimer: I think AI will become creative. In fact, there are some new benchmarks for creativity in AI that have just been released. It's something that people are measuring and people are trying to improve. I don't necessarily think that's a problem. I don't think there's like a finite amount of creativity in the world. It's ok for us to be creative and also for AI to be creative. It's not a zero-sum game.
Participant 2: I was curious to get your thoughts on the inner world where we have agents writing code, and write-only code, and more code than we can humanly comprehend. How do we control the sprawl of applications? How do we govern the sprawl of applications within our architecture?
Phillip Mortimer: Observability is always a key point in software engineering, and observability is a really key point in a new agentic world as well. I don't think it will necessarily build a significant amount of application sprawl. I think perhaps that's what people are doing at the moment. In many ways, in a new agentic world, the app is less important. Apps are what we built since 20 years ago to now, because that was the only way to solve problems. It's just take a workflow that was done manually and build a software solution to standardize that workflow. I think that's going to go away and that will be replaced with agents doing work on our behalf. I don't think we're going to be building huge numbers of new apps, even though now we can. I think what we'll be building is more agentic systems which perhaps, as I said in the talk, lead to less architectural sprawl.
Participant 3: I had a question around write-only code and the fact that we're thinking AI is writing the code, reviewing it, self-healing systems and all of that. Today, I think a majority of the code produced by agents is still readable code, like you mentioned. There's the AI stack, Next.js, like really high-level frameworks and things like that. In your opinion, are we going to move from that to AI going directly to really unreadable, low-level stuff?
Phillip Mortimer: Is the AI going to stop writing in the high-level language and then perhaps start writing directly in C or maybe even in assembly? I don't think so. I think, at the moment, most of the training data that these models are trained on is still in high-level languages. I think they would probably struggle to write code directly in assembly. Maybe they could manage in C. There are also reasons for these high-level languages to exist, because they make it quicker to build things on top of them. They have batteries included. They've got standard libraries. The AI would want to take advantage of that as well. I don't know why the AI would want to re-implement everything from scratch at a low level. Unless you explicitly told it, you have some very tight performance constraints that you need to meet, and therefore, please write everything in C. Unless you say that, it would make sense for the AI to take advantage of everything we humans have built over the last 25 years.
Participant 4: The way I think about things pre-AI is that we have code which is readable and reviewed by humans, and we have source control, and it's great because it gives us a way to gate what goes in, and it gives us the history. The way you talk about write-only code sounds to me like you think about code like we think of assembly today, in the sense that people review my code, they don't review what it compiles into. If code is the new assembly, and what matters is the intent, what techniques or technologies would you recommend for capturing intent and having people review intent rather than having people review the code?
Phillip Mortimer: This is something that I've seen debated a little bit. Should we be committing your plan files into GitHub? Should you be committing your specifications? There's a tool called Beads, I think, which is like Jira, but implemented as a CLI which AI can just get new tasks from, and it stores your specifications and your work items in a local database. I think for now it's an unanswered question. Perhaps in the future we will be version controlling our specifications and version controlling our plans rather than version controlling the code as we do now.
Participant 5: It was an amazing talk. Got me thinking about how it all fits with sustainability. I was wondering, what do you think about it? I see us engineers, we were natural barriers to control the amount of data that was created, and now with AI, it seems there are no limits whatsoever. Basically, we would pollute the world with endless data, also with code which is now only written, like you remove a lot, you add a lot, and it's all in the history.
Phillip Mortimer: I think the sustainability concerns are overblown, personally. I think if you look at many other industries like automotive or farming, they are far higher polluters than AI data centers. I also think, moving away perhaps from my topic of writing the code, more generally, I think the potential for AI is so enormous that it could potentially alleviate a lot of sustainability concerns right now. The way things are going, can you see a future in 5 years' time when a super intelligence solves nuclear fusion or invents a more efficient architecture for itself so these data centers that we have now aren't necessary, or perhaps even makes advances in medicine which we've already seen with AlphaFold? Perhaps now we have, obviously, this massive data center boom which has to have some environmental impacts, but if we look ahead 5, 10 years, I think we'll forget that and we'll only remember the incredible advances that AI is going to give us in power, healthcare, medicine, and many more fields.
Participant 5: Let's hope it's true.
See more presentations with transcripts
