I recently had to dig into the Apache Kafka codebase to try to figure out how it allocates topic partitions across log directories on a broker with multiple log directories. I had observed that Kafka allocates partitions evenly across brokers, but failed to allocate partitions evenly within a single broker.
Luckily, Kafka is written in Scala and I write Scala, so it was actually quite easy to read and understand the code. This is the benefit of your tools being written in the language you use, when you need to debug them you can just read the code. This is why the Kubernetes community is mostly Golang for example, there’s a benefit to everyone sharing tooling to lower the switching costs between repos.
Regardless of lamnguage, grokking a large codebase is HARD. It takes a lot of time, as you learn the style, click through functions, understand how everything is structured. It’s hard, and time consuming loading all of this information into a human brain, which is why most engineers don’t do it, even if they would benefit - they just don’t have the time.
This has all changed now that GPT-4 is released. Imagine the following prompt:
“GPT, here’s the code for my application. Please generate me a diagram of the data flows, as well as a README. Return back the code with short comments added for every function call”
This will reduce so much developer toil, being able to auto document code. I’m a visual learner and need architecture diagrams, but not everybody I’ve worked with them finds them useful. Very soon the cost of producing documentation in various flavors drops to 0, and we can all learn something the way that works best for our brains.
What’s holding us back is the context windows - an 8k context window is ok, 32k better, but we need 500k context windows before anything like this is possible for the complex codebases where it’s really needed.
Do we even need code
If we can auto generate documentation, why can’t it automatically generate the codebase from documentation? This is my thesis - in the future a majority of software will be a highly specific natural language prompts, checked into source code, with actual source code that is transpiled from the prompt with some GPT type wrapper. It just feels obvious at this point.
Obviously this won’t be true for legacy, complex codebases, etc. But for your average SaaS app that doesn’t have scaling concerns? It’s going to be a codebase generated by a prompt.
The build process will be something like:
- Write the unit and integration tests
- Generate the code
- Run the tests, make sure it all passes
- Bundle/Compile the resulting app
However it’s going to take a long time (a year or two) for GPT to get that good. Also for large, complex, or legacy codebases this won’t be true. GPT offers an insane opportunity to make working in these codebases better that the IDE companies will take advantage of (or fail the market).
All I’m trying to get across is how much engineering is going to change, in a relatively short time. It’s vague to me, but it’s coming. This is the equivalent of the invention of the internet - buckle up friends.