1. AI is meant to make us go faster, reviews are slow, the AI is smart, let it go.

2. There are plenty of AI maximizers who only think we should be writing design docs and letting the AI go to town on it.

Maybe, this might be a great time to start a company. Maximize the benefits of AI while you can without someone who has never written a line of code telling you that your job is going to disappear in 12 months.

All the incentives are against someone who wants to use AI in a reasonable way, right now.

I have been using Argus in anger for a few days, it needs some updates, but being "run on your own desktop" software means it can be a lot simpler than a full product, which is nice. Next feature I am pushing to get implemented: I want Reviewboard-like intra-push diffs. I have a force-push heavy workflow and GH PR view doesn't let you see the diff of what was pushed vs what I last reviewed, and that is a feature that all the data is there and I want it.

1. I want to deploy to a testing environment where I may want to use different users, different sized services, or even mock services so I don't have to pay for them? 2. I want to develop in an isolated environment (maybe without internet or simply I'm trying to develop a narrow feature that doesn't require the rest of the infrastructure)? 3. How does it handle security elements like VPCs, IAM roles, all these things that are the context my application runs in that I don't necessarily want to couple to my application code?

As comparison, if a programming language forced you to split your software into multiple executables when you got to a certain number of functions, I think, almost universally, we would say that it's not a production language. That is a stupid limitation and forcing development work on users because of stupid limitations is disqualifying.

But for TF, even if we are refactoring it because the tool is doing it, we tell ourselves that it's a good idea anyways because of good software practices. But splitting infrastructure over multiple root modules is, in my analogy, the same as being forced to do it over multiple executables. It comes with a lot of unnecessary limitations.

With Stategraph, you can choose to split your infrastructure over multiple root modules, if that is what you want to do, not because you don't have a choice.

V1 of Stategraph is a drop-in TF/Tofu replacement, but once it's there, you can see a path to something more like k8s operators, without having to do any migration of infrastructure.

I know that isn't everyone's view, but I do hope posts like this, even if not technicaly deep, at least let people know that there are lots of options out there.

That depends. There are many organizations (we talk to them) which have plans and applies that take 5 - 10s of minutes, some even close to an hour. That's a problem. We talked to one customer that a dev can make a change in the morning and depending on the week might have to wait until the next day to get their plan, and then another day to apply it, assuming there are no issues.

If you're in that position you have two options:

1. Just accept it and wait. 2. Refactor your root module to independent root modules.

(2) is what a lot of people do, but it's not cheap, that's a whole project. It's also a workflow change.

Stategraph is trying to offer a third option: if your changes don't overlap, each dev can run independently with no contention.

Even if one doesn't think contention over state is a big deal, I hope that one can agree that a solution that just removes that contention at very little cost is worth considering.

This blog post shows the elements of OCaml that motivate us to use it. Is it complete? No. Maybe it should be more explicit that we like using OCaml, and these technical aspects aren't unique but certainly benefits we see.

As you said, the common practice is to use locks on state to guarantee that operations don't step on each other. This works, however the cost is that if it takes 5 minutes to perform an operation, only one person can be doing an operation at a time, so if 5 devs are modifying infrastructure, the last one has to wait 25 minutes just to get back the plan, even if those 5 people are not changing overlapping resources in the state.

The way that most people deal with this is they take their infrastructure and break it up across multiple root modules, and then when those root modules, break it up again, etc.

Stategraph is solving the problem of getting all of the performance benefits of breaking up your root modules without breaking up your root modules. It dynamically determines which resources each of those 5 devs are operation on and, if the resources do not overlap, can run them in parallel.

That means Stategraph is manipulating state in a bit more sophisticated way than standard Terraform/Tofu, and we need to be careful we don't get it wrong.

Additionally, Stategraph should Just Work with your existing TF codebase. You important the state and you're off to the races.

Once all of your state is in Stategraph, though, moving state around really becomes a question of what name those piece of state should have. So, if you want to merge two root modules, it could be the case that you can check "do my resource names overlap?" If no, you can tell Stategraph to merge the states and then copy your code into a single root module and go. Otherwise, you need to do some resource renaming.

While we don't have all the details in place, I think it is quite likely that Stategraph will support metadata on your resources, perhaps with a new block. This way you could provide namespaces to collections of resources, and that could make merging even easier. But, there is a bit to figure out before that is a reality or determined to be the best way to go.

With Stategraph, you'll get all the benefits and isolation of separate state files, but when you changed resources, you'll get meaningful plans around all of the infrastructure they impact, not just the statically defined boundaries of a state file.