1.7.1. Epilogue

This year marks my fourth year as a HashiCorp Ambassador. To be honest, I feel quite ashamed; I did very little work last year. I submitted my application this year with a "give it a shot" mindset, and I was incredibly moved to be accepted again. I thought to myself that I must do some substantial work this year no matter what. Consequently, I compiled the Rego rules I learned while writing the AVM Opa Policy rule library into a Rego 101 Chinese Tutorial. Initially, I considered formatting it as an e-book, but after evaluating the total content, I felt it was a bit too thin—too long for an article, yet too short for a book. Moreover, since Rego is a project by Styra, presenting it as a contribution to the HashiCorp Chinese community felt a bit like "selling dog meat under the sign of a sheep's head"—somewhat off-brand and disingenuous.

1.7.1.1. Toolchains and the Philosophy of Tools

Azure Verified Modules (AVM) is a project I have been heavily involved in for several years. From the very beginning, I collaborated across departments with overseas colleagues, working on everything from establishing code standards and processes to setting up test environments, designing and refining CI pipelines, and developing, upgrading, and maintaining various tools to get to where we are today. Like many "Azure-titled" Terraform modules before it, AVM likely started with frontline architects and engineers developing tools spontaneously to improve code reuse and accelerate delivery. However, issues arose during maintenance. The core constraint is that the vast majority of module contributors maintain these projects part-time. Expecting them to dedicate themselves fully to code maintenance and upgrades is unrealistic. At the same time, Infrastructure as Code (IaC) is a field that is constantly iterating and updating—cloud platform APIs upgrade, new products emerge, and Terraform itself keeps adding practical new features. Therefore, we urgently needed a lever. Through this lever, we could amplify human efficiency, allowing us to maintain an ever-growing number of modules with limited manpower and energy.

This lever is the toolchain. As we mentioned in "One Module, One Repository", open-source Terraform Module projects like Azure Verified Modules differ from the governance models of other common open-source software. They manage hundreds, even thousands, of repositories that are highly consistent in structure but different in implementation code, all of which must adhere to consistent high standards. Quantity leads to a qualitative change; any task that might seem insignificant when maintaining a single repository can become an incredibly complex problem when amplified hundreds of times. Relying solely on manpower or the responsibility of maintainers is unrealistic.

Traditional Linters can be used to detect and prevent typical coding anti-patterns before code is merged. However, when dealing with a project like AVM, passive detection and prevention are not enough. Sometimes, we must proactively perform customized modifications across hundreds of code repositories, such as adding telemetry code or uniformly upgrading Provider versions.

In this process, I realized that we need a large number of tools to serve as levers to amplify human power. This led to simple little tools like yorbox, as well as more complex ones like avmfix, grept, and mapotf. Historically, there has been a tendency in Chinese internet and software companies to undervalue tools. In the widespread "hierarchy of disdain," work involving high concurrency, underlying systems, backends, frameworks, or middleware is usually at the top, while work involving integration, interfaces, APIs, and tools is at the bottom. It is important to understand that humans are essentially creatures shaped and disciplined by tools. Our lifestyles and thinking patterns are heavily influenced and constrained by the tools we use. A simple example is the United States, where there are many small towns with layouts that look like copy-paste jobs, consisting of a Main Street with residential areas expanding from its flanks. These towns are shaped by the technology and tools of automobiles and highways; the lives and work of the residents are constrained by them. Another example is Japan, famous for its developed rail transit network. The layout of the Tokyo and Keihanshin metropolitan areas, and the lifestyle of their residents, are greatly influenced and shaped by rail transit. A more recent example is China's developed e-commerce ecosystem and food delivery industry, which have completely rewritten the offline commercial ecology of Chinese cities. The layouts of shopping malls and commercial centers are deeply affected by them. A very small number of top streamers, relying on the technology and tools of 4G/5G mobile internet live streaming, possess advertising and sales capabilities that rival state-level traditional media, changing people's consumption habits. In real life, the toolchains composed of various tools are the entry points for humans to access various technologies. Therefore, it is hard to imagine how a high-performance team can function without utilizing a vast array of tools to form a toolchain that amplifies their capabilities.

During this process, I found myself in a very interesting position. I have worked in operations, so I understand their pain points; I am also a software developer, so I know how to build software. HashiCorp has many aspects worth learning from and referencing in terms of tools. I am delighted to see Terraform grow from a nascent tool into a standard configuration for Fortune 500 companies using the cloud today, becoming the de facto standard for Infrastructure as Code, with related tools emerging one after another, creating a flourishing and competitive ecosystem.

The dispute between Terraform and OpenTofu is an event that pains me greatly. The community has split into two, and there is a gradual trend towards mutual incompatibility. One of my wishes in developing mapotf is that, since everyone is based on HCL tools, it is entirely possible for us to develop a meta-programming tool for HCL. This tool could provide neutral solutions to certain problems (such as dynamic ignore_changes lists) from which both communities could benefit. I even once fantasized about whether it would be possible for the two communities to shake hands and reconcile one day, reuniting as one. Regardless of whether this wish comes true, I hope that the technology of Infrastructure as Code continues to thrive.

1.7.1.2. The Language of Large Language Models

I extensively used Large Language Models (LLMs) in my work submitted for AVM, such as GitHub Copilot, ChatGPT, and Google Gemini. I used AI to help me write various script codes (since I am not very good at Bash scripts), to write unit tests for my code, or to draft documentation and explanations for my code and changes. But in reality, another motivation for my work on mapotf and Terraform is AI.

Currently, the vast majority of people interact with AI using natural language. However, given that AI is very good at writing computer code, you can certainly communicate with it via non-natural languages. There is currently a barrier to communication between the physical world and AI, and that barrier is humans. AI can only return its answers in text form, and these answers need to be interpreted or executed by humans themselves, or by various plugins installed for the AI by humans.

Let's review the two major characteristics of Terraform: a declarative language, meaning the author can delegate complex issues like state migration to the Provider developer and simply describe the desired state in simple, understandable code; and an open Provider architecture, meaning that anything with an API can have a Terraform Provider written for it, allowing it to be orchestrated using declarative code. Although Terraform is currently used mostly to orchestrate and operate various public clouds, private clouds, and software services running in the cloud, the term "infrastructure" has never been constrained to mean only software infrastructure. You can absolutely write Providers for various hardware equipped with APIs. In this way, if we use various engineering means to "teach" AI how to use Terraform code to describe its desired state of the real world, we can achieve direct AI manipulation and orchestration of the physical world. The complexity can be infinitely high because we can provide it with all sorts of Terraform modules. A concise piece of code might be enough to orchestrate anything from the layout of a factory production line to the resource allocation and strategic deployment of an enterprise or a nation. I foresee the emergence of a small number of people who are extremely adapted to AI. They will develop various toolchains and Domain-Specific Languages (DSLs) for AI, amplifying their own capabilities by thousands of times, leading to the rise of numerous "one-person companies" and "super individuals."

As we mentioned earlier, humans are essentially creatures shaped and disciplined by tools. Similarly, human intelligence is essentially something shaped and constrained by the tool of language. The solution to any computable problem must be describable by language; conversely, the boundary of language's descriptive capability is the boundary of human problem-solving capability. Therefore, we can derive this conjecture: an AI using natural language will not exceed the complexity of problems that humans can solve. However, a language that is not understandable by humans and contains a higher entropy density might be utilized by an intelligence that surpasses humans. We can combine various small tools into a toolchain and encapsulate that toolchain into a new tool. During the design and development of grept and mapotf, I also discovered that we can absolutely design a higher-level meta-language based on a certain language. Based on this meta-language, we can easily achieve things that look very complex at the lower language level (for example, from Terraform's perspective, implementing dynamic ignore_changes is complex, but from mapotf's perspective, it is easy). Therefore, I believe that to further liberate AI's productivity, we must design a series of Domain-Specific Languages for it, allowing it to perform deduction work using these new layers of tools. Put another way, the reasoning language used by a post-human AI in the future will likely be incomprehensible to us humans—just as no matter how hard you try, you cannot teach a Border Collie the derivation process of basic mathematical proofs.

1.7.1.3. Acknowledgments

A lot has happened in the past year. International relations have become increasingly tense, and the small environment I am in has started to become turbulent. The old order is disintegrating, and new players are eager to try their hand; old consensuses are being torn up page by page, and new viewpoints are being written in blood and fire. I hope that readers can remain calm and open-minded in this increasingly tumultuous environment, becoming the surfers of the era rather than being swept away by the waves. I would like to thank everyone for reading! Thanks to my family for their support! Thanks to my colleagues for their help! Thanks to all my friends for their kindness! And thanks to this era!