Layered Architecture Enforcement - Harness engineering: Leveraging Codex in an agent-first world

Types to Config to Repo to Service to Runtime to UI dependency rules, Provider patterns, separation of concerns, mechanical enforcement in CI

The community views this layered architecture as a modernized take on classic patterns like Hexagonal Architecture, emphasizing strict, unidirectional dependencies that prevent "spaghetti code" through mechanical CI enforcement. While some readers found the specific implementation of "Provider" patterns difficult to grasp without concrete examples, they noted that these constraints are becoming essential prerequisites for teams utilizing AI coding agents to prevent rapid architectural decay. By employing static analysis to ensure layers like the UI cannot bypass intermediate services to access configurations, developers can maintain structural integrity in dynamic languages that lack built-in architectural guards. Ultimately, the consensus highlights that while this level of rigor was traditionally reserved for massive engineering teams, it is now a foundational tool for managing the high volume of code generated by modern automation.

View on HN · Topics

I agree. I followed this article for a repo I'm working on, and I had a very hard time inferring how, specifically, they implemented "providers" and enforced import layers. A sample repo would've been nice.

View on HN · Topics

> The diagram below shows the rule: within each business domain (e.g. App Settings), code can only depend “forward” through a fixed set of layers (Types → Config → Repo → Service → Runtime → UI). Cross-cutting concerns (auth, connectors, telemetry, feature flags) enter through a single explicit interface: Providers. Anything else is disallowed and enforced mechanically.

Can anyone give me a simplified explanation of what they’re saying here? Having some trouble understanding.

View on HN · Topics

As other commenters have clarified, it's about layering, separation of concerns etc. Goes by many names. One such terminology here: https://en.wikipedia.org/wiki/Hexagonal_architecture_(softwa... . DI frameworks use terminology like "Provider": https://en.wikipedia.org/wiki/Dependency_injection#Injectors

View on HN · Topics

They're describing a layered architecture enforced by some script in CI.

For example, if you had a `backend`, `common`, and `frontend` package, you would be OK having backend/frontend depending on common, but you wouldn't want common depending on backend/frontend or backend/frontend depending on each other.

If you think about JavaScript, there is nothing stopping your dependency graph from becoming spaghetti. It sounds like they built static analysis to enforce rules.

Some languages have this built in like Java (Project Jigsaw), Go, and Rust. JavaScript, Python, etc. have no such feature.

It's really nothing special -- it has existed before. It just becomes a _lot_ more important with agents since they produce a lot of code, and it is good to have lots of static analysis when heavily utilizing agents.

They mention this in the article:

> This is the kind of architecture you usually postpone until you have hundreds of engineers. With coding agents, it’s an early prerequisite: the constraints are what allows speed without decay or architectural drift.

View on HN · Topics

IIUC its just strict separation of concerns

Eg UI cannot reach down and directly read config files

Configs must be only read by (im assuming) a storage interface layer called repo

There’s a strict directionality of dependency

Somewhat similar to ports and adaptors but presumably more strictly enforced by deterministic linters