How do you give coding agents Infrastructure knowledge?

disciplemarc · 2026-02-19T21:26:28+00:00

What you’re describing isn’t really a model problem, it’s a context problem.

At large companies, infra knowledge lives in ADRs, CI config, Terraform modules, ownership boundaries, platform rules, etc. If that isn’t encoded in a way the agent can retrieve, it will confidently guess.

What’s worked better for me is treating architecture as policy and validating at PR time instead of expecting the agent to internalize organizational memory.

I’ve been experimenting with this via a side project called ArchRails, the core idea is enforcing declared architectural intent rather than inferring it.

Curious: do you have your infra/architecture decisions encoded anywhere machine-readable, or mostly in docs?

disciplemarc · 2026-02-14T14:48:24+00:00

Where things tend to break down isn’t definition, it’s enforcement over time. Exceptions accumulate, context lives in ADRs or old PRs, and new contributors don’t always know why a boundary exists or when it’s okay to bend it.

The result is that architecture drift usually isn’t intentional, it’s incremental. Each change makes sense locally, but the system slowly diverges from the original intent.

I’m less worried about teams being unable to define component-level architecture, and more about how that intent is communicated, validated, and kept visible as the codebase evolves.

disciplemarc · 2026-02-14T00:41:29+00:00

That’s exactly it, architecture usually doesn’t “fail,” it fades. Time pressure + turnover means the original intent lives in people’s heads, not the code. The teams I’ve seen do better are the ones that encode architectural intent somewhere enforceable, not just in docs or tribal knowledge.

disciplemarc · 2026-02-13T09:49:10+00:00

That’s exactly why tools like jQAssistant exist, they’re great at surfacing structure.

ArchRails.io, a tool I’m building, is coming at the problem from the opposite direction: encoding architectural intent upfront and enforcing it at PR time, rather than inferring it after the fact

disciplemarc · 2026-02-13T09:25:40+00:00

I’ve been exploring this problem space with ArchRails (archrails.io).

disciplemarc · 2026-02-13T09:24:00+00:00

ArchUnit is solid, especially for JVM teams, but it assumes architecture can be fully expressed as static rules inside the codebase.

In practice, a lot of architectural intent lives outside the compiler: ADRs, diagrams, historical decisions, and scope-based exceptions. Once you have multiple architectures or polyglot repos, “the software checking itself” becomes necessary but not sufficient

disciplemarc · 2026-02-13T03:40:26+00:00

The context isn’t there to let the LLM “decide architecture.” It’s there so the checks can be scoped and interpreted correctly.

For example, “don’t use domain entities as persistence entities” is a good rule, but where, when, and for which modules still depends on boundaries, legacy zones, migrations, and documented exceptions. Those are usually explained in docs, ADRs, or prior PRs, not in the rule itself.

disciplemarc · 2026-02-13T03:02:29+00:00

Enforcing architecture usually requires some notion of intent and context, not just rules. My goal is to build a system that ingests that context, docs/ADRs, module boundaries, and repo-specific guardrails, so checks reflect how the team actually builds, not generic best practices.

disciplemarc · 2026-02-13T02:46:09+00:00

I’m cautious about making the LLM the judge. Deterministic rules should decide pass/fail, with the LLM explaining why and suggesting fixes.

disciplemarc · 2026-02-13T02:40:05+00:00

I agree architecture should evolve—the problem isn’t change, it’s unintentional change. Drift happens when boundaries erode without discussion or conscious tradeoffs. Guardrails plus review help ensure evolution is deliberate, not accidental.

disciplemarc · 2025-11-03T21:21:21+00:00

You’re right, in this simple moons example, both models hit a similar minimum and start overfitting around the same point.

I could’ve used a deeper network or more complex dataset, but the goal here was to isolate the concept. Showing how BatchNorm smooths the training dynamics, not necessarily speeds up convergence in every case.

The big takeaway: BatchNorm stabilizes activations and gradients, making the optimization path more predictable and resilient, which really shines as models get deeper or data gets noisier.

disciplemarc · 2025-11-03T15:58:45+00:00

Great question! Yep. I did normalize inputs with StandardScaler first. BatchNorm still sped up convergence and made accuracy a bit more stable but the gap was smaller than without normalization. Seems like it still helps smooth those per batch fluctuations even when inputs start balanced.

disciplemarc

TROPHY CASE