Pt 1 - AI Slop Wrangling in Nx Workspaces - The Four Core Domains™

Impressed with the amount of code slung by the bot, I asked, "Do I understand or trust the result?"  Why is this crossing concerns with NestJs services and request / response streams?  This isn’t the correct place to unpack and send header information.  How is this going to hold up in the future?

How much risk was introduced because patterns and implementations of business features weren’t properly abstracted?  Guess I’m stuck with Stripe and AWS infra forever, huh?

But now a less experienced software engineer is armed with tools that can modify thousands of files and it kinda looks right.  That’s a lot of trust and review to our best guess engine companions.

You could say I’m risk averse, but like everything there are tradeoffs to decisions.  So how do we ensure the coding agents stay within our guardrails and the architecture is enforced?

Coding agents outpacing human oversight requires strict adherence to architecture.  We want our agents producing code that is both human readable and structurally sound.  To achieve this, we developed the Mutable Ideas Workspace (Miws™ - “Meee-Workspace) and The Core Four™, a set of plugins that extend Nx Workspace module boundaries, generators, and lint rules. By enforcing these guardrails, we ensure that the code generated remains structured, maintainable, and ‘slop-free’.

The Core Four™

Token maxing until a few months ago meant delivering features at max speed and probably with prompts lacking context.  What a moment of terror and gratification that a coding agent can sling the necessary code to realize new features.

But where did my coding agent add the code?  Did it repeat something that could’ve been used from another library?

The Core Four segregates four areas of concern, software patterns, tech implementations of software patterns, capabilities that are reused throughout the organization, and the business applications.  The Miws™ plugins create The Core Four™’s hierarchical boundaries by extending Nx’s module boundary linting rules.

Patterns

The bottom most layer describes the fundamental behavior of what our software can do.  It is the blueprint for implementations used in the layers above it.

The patterns domain’s projects are slim, containing the service contracts and interfaces that define what a pattern must do. By strictly forbidding imports from libraries like Angular or NestJs, we ensure that our core logic remains framework-agnostic. This creates a 'pure' layer that is immune to framework churn and provides a stable foundation for the implementations above it.  The patterns domain knows nothing about the other Core Four™ domains.

This frees teams from vendor lock-in when implementations need to change.  Adhere to the contract as you migrate away from the previous vendor’s service and you minimize the changes.  Easy for humans to understand small changes and less token usage for the coding agents.

Tech

The tech layer describes how our software interacts with infrastructure and vendor code as implementations for a pattern.  When introducing this layer frameworks and libraries should be chosen for the repository.

Framework specific projects living in the tech domain will be dependent on the allowed projects for a given framework plugin.  For instance, the @miws/nest-plugin generates projects that have specific intent and what should be included, such as nest-infrastructure projects.  Within the nest-infrastructure project, vendor capabilities are exposed by invoking methods by the pattern domain’s service contract.

This offers framework isolation and vendor interchangeability.  When the coding agent needs to change vendors or add infrastructure for a particular pattern, it relies on these framework plugins not just for generation, but for architectural enforcement ensuring the new code strictly adheres to module boundaries and cannot deviate into unauthorized domains.

Capability

The capability layer exposes common features used across one or more business applications. It answers the question, "Can we do something?" without concerning itself with the logic of "should we." For example, if Social Sprinkler needs to create a post, it doesn't need to know about the underlying infrastructure of the file upload or the API authentication; it simply invokes the UploadFile or PublishPost capability for a specific social media channel.

This layer acts as an abstraction API for our Business applications.  By composing raw Tech implementations into reusable, high-level capabilities, we create a stable interface that business logic can consume. This drastically reduces the surface area for errors: when a coding agent works at the business level, it is no longer manually stitching together low-level infrastructure.  It is simply orchestrating high-level capabilities that we *know* work, ensuring that our business rules remain the only thing the Business domain has to worry about

Business

Specific business tasks and use cases exist in this layer.  My Social Media publishing application, Social Sprinkler, owns the business rules around scheduling posts, the number of social media accounts allowed to be connected, and the number of posts scheduled and posted for a customer’s subscription level.

This is where the coding agents receive the requirements for the project.  With established boundaries from framework plugins, tech implementations, and common capabilities, choosing the composable pieces to achieve business goals is easier.  At this level, coding agents aren’t rewriting Google Cloud Storage uploading.  It’s writing business rules keeping the architecture intact.

The outcome is undeniable, we have transitioned from merely supervising agent-generated slop to intentionally directing the delivery of high-level business value.

Summary

Coding agents follow a path of least resistance to achieve an outcome. But I had to ask myself these questions:

1. Do I understand the intent?
2. Is there consistency in how things are written and organized?

The Core Four™ simplifies the mental model to call bullshit on coding agents making it adhere to guardrails. While we understand the speed of delivering new features multiplied, you are responsible for what's written and deployed.