[ClassAndBurn]

Others' concerns are valid; the separation of concerns makes infra changes safer and easier to understand. Infra-tooling is slow because of the inherent risk of managing stateful services.

Mixing the infra and application logic is the obvious path forward, though. Just as most applications don't need more than Rails and a single Postgres, most apps don't need customized infra. Simplifying the 80% unlocks cycles for more creative work. Suppose you are successful enough to have to define custom infra at some point. That's good for you. That's a great problem to have.

AI is going to standardize architectures going forward. Providing a simple set of tools in the same code as the logic makes the planner easier for Copilots and reduces the context windows. Terraform and application code have implicit dependencies. Colocating them lets you define explicit dependencies that are more understandable.

[tholm]

Thanks for the insight, your last point on reducing context windows for AI is exactly what Nitric is trying to achieve for humans as well reduced cognitive complexity for 80% of the work (from your second point).

I can see a path forward for Nitric as platform engineering solution where standardization of architecture is achieved (with the aid of AI as well), through building Nitric custom providers: https://nitric.io/docs/reference/providers/custom/building-c...

[rk2]

It is worth noting that the Nitric team (whom I work with) aren't suggesting that Nitric is an alternative for every Terraform project out there.

However, there are many use-cases without bespoke infra needs where it does suit.

Our hope is that people who genuinely are looking for assistance with their cloud deployment needs evaluate Nitric against their own projects requirements.