# Infrastructure Is Waiting for Its IDE Moment In November 1983, Borland started selling [Turbo Pascal](https://www.theregister.com/2023/12/04/40_years_of_turbo_pascal/) by mail order for $49.95. Rival Pascal compilers cost several hundred dollars and made you work like a shipping clerk: write code in an editor, save, quit, run the compiler from the command line, read the errors, reopen the editor, hunt for the offending line, repeat. Turbo Pascal put the editor and the compiler in one program and compiled in memory, in seconds. The loop collapsed. A generation of developers learned to program inside that loop, and the category it created eventually got a name: the integrated development environment. My claim: infrastructure tooling in 2026 is where programming tools were in 1982. We have the loose parts. An editor. A compiler-shaped thing that turns text files into cloud resources. A debugger that's mostly `kubectl describe`, browser tabs, and prayer. What's missing is the integration, and Infrastructure as Code (IaC) won't become it. IaC was a detour on the way to infrastructure's IDE moment. ## How code got its environment The history of developer tools is one long compression of the feedback loop. In the batch era you handed a deck of punch cards to an operator and got a printout back hours later, which meant a typo cost you an afternoon. Interactive editors shortened that to minutes. Turbo Pascal shortened it to a keystroke, and it did that through integration rather than raw speed: the editor knew where the compiler stopped and put your cursor on the broken line. Then the tools started to understand the code. Microsoft shipped [Visual Basic 1.0 in 1991](https://en.wikipedia.org/wiki/Visual_Basic_(classic)) and you could drag a button onto a form instead of computing its coordinates. IBM open-sourced [Eclipse in November 2001](https://en.wikipedia.org/wiki/Eclipse_(software)), and with it came the thing that defines a modern IDE: a live semantic model of the program being edited, held in memory and updated on every keystroke. The syntax tree. The symbol table. The type graph. Rename a function in Eclipse and every call site across forty files updates correctly, because the tool knows what a function is. That's the part people miss when they wave off IDEs as bloated editors. An IDE is a model of your program that happens to have an editor attached. Nobody would go back. We still argue about vim versus VS Code, but no one argues for compiling from a printout. ## Infrastructure is still batch computing Now look at how we change infrastructure. AWS shipped [CloudFormation on February 25, 2011](https://aws.amazon.com/about-aws/whats-new/2011/02/25/introducing-aws-cloudformation). HashiCorp announced [Terraform on July 28, 2014](https://www.hashicorp.com/en/blog/terraform-announcement). Both were genuine progress over clicking through consoles, and I don't want to pretend otherwise. But look at the workflow they encode: write text, submit the job, wait, read the printout. `terraform plan`, wait. Then `terraform apply`, wait longer, and hope the apply agrees with the plan. When it doesn't, you get output like `Error: Provider produced inconsistent final plan`, which is the 2026 equivalent of the operator handing back your deck with a rejection slip. The loop is minutes when things work and hours when they don't. Your mental model lives in three places at once: the text files, a state file that summarizes what the tool did last time, and the actual cloud, and any two of those can disagree without the third finding out. We named that problem drift, which makes it sound like weather instead of what it is: the tool doesn't hold a model of reality, it holds a cached guess. Fourteen hours once disappeared here into a Kubernetes service-mesh race condition, and most of them went to a question no tool in the stack could answer: what talks to what, and in which order. Debugging felt like archaeology. That's not a debugging experience anyone tolerates in application code anymore. ## The detour IaC's core bet was that if you represent infrastructure as text, all of text's tooling comes free: git, diff, code review, grep. The bet partially paid out. Text gave us version control. It felt like progress. What text couldn't give us is semantics, and semantics is where every gain since Turbo Pascal has come from. There's no go-to-definition for a security group. No rename refactor for a VPC: renaming a resource in Terraform means `terraform state mv`, run by hand, with the safety rail of a backup you hopefully took. No red squiggle when two subnets overlap; you find out at apply time, twenty minutes in, when the API rejects the change. A modern IDE catches a bad rename before you finish typing it, while our infrastructure tools catch a bad CIDR after the deploy has half-finished, which is the most expensive possible moment to learn anything. The lesson from the IDE era isn't that text was the wrong storage format. The lesson is that text is the wrong interaction surface. Editors didn't win by editing characters better; they won by holding a model and letting the text be an artifact of it. ## The strongest case for text files The best counterargument deserves a fair hearing: text files are the one representation everyone can read, review, and audit. Git history is an audit trail regulators accept. Pull requests are how teams reason about change. GitOps built an entire operational philosophy on "if it's not in the repo, it doesn't exist," and plenty of teams run production on that philosophy every day. All of that is true, and any tool that takes versioning or review away from engineers deserves to be rejected, because the discipline of the pull request is the one part of this workflow that has consistently earned its keep. But notice what the IDE did to source code. Nothing. Java in Eclipse is still text in git. What changed was the layer you touch: when you rename a function, the IDE rewrites forty files and you review the diff afterwards, and nobody performs that rename with sed or wants to. The model does the operation; the text records it. Infrastructure can work the same way: a deterministic graph you operate on, which serializes to something diffable and reviewable that CI can still gate. You keep the audit trail. What you lose is the part where a human simulates a graph traversal in their head during an outage. ## Naming the category This is why we build the way we do. ICE, our **Integrated Cloud Environment**, is a desktop app in development around one idea: the tool you touch should hold a deterministic, graph-based model of your infrastructure across AWS, GCP, and Azure, the way Eclipse holds a model of your Java. The name picks the fight on purpose. I won't claim we've finished it, and I won't claim we'll be the only ones to try. Categories are bigger than the companies that name them; Borland didn't end up owning the IDE either. Someone is going to build the integrated environment for infrastructure, and the graph model is the bet we've placed on how. Turbo Pascal's real product was never the compiler. It was the loop, because once compilation got fast and integrated enough, developers started attempting things they wouldn't have risked when every mistake cost an afternoon. Forty-three years later my compiler answers in milliseconds and my infrastructure still answers in printouts. What would you attempt if changing a production VPC felt as safe as renaming a function? --- Related: [Integrated Cloud Environment](/dev-tools/integrated-cloud-environment), where we first introduced ICE. More about what we're building at [light-cloud.com](https://light-cloud.com).