Why I'm Building an Engineering Control Plane for AI-Assisted Development

AI coding tools are becoming increasingly capable. They can generate code, analyze repositories, run tests, and help developers move faster.

But as AI-assisted development grows, I keep coming back to a different question: How do we engineer the system around the AI - not just the code it produces?

That question is one of the reasons I'm building SYSTEM-ENGINEERING, an open-source project exploring the idea of an Engineering Control Plane for AI-assisted development.

The problem I'm exploring

Adding more agents or connecting more tools does not automatically create a reliable engineering workflow. A project also needs structure around the work:

• Orchestration: How should tasks be coordinated across specialized agents?
• Policies and contracts: How do we define what an agent can do, what it must respect, and when it should stop?
• Validation: How can we verify results instead of relying exclusively on an agent's claims?
• Memory and continuity: How can a project preserve relevant decisions and context across sessions?
• Project boundaries: How can shared engineering infrastructure support multiple projects without hardcoding project-specific assumptions?

These are architectural questions, not just prompt-engineering questions. I'm interested in exploring whether these concerns can be addressed through a reusable engineering layer instead of being scattered across individual prompts, scripts, and tools.

What is SYSTEM-ENGINEERING?

SYSTEM-ENGINEERING is my open-source effort to explore that engineering layer. The project focuses on the infrastructure and workflows surrounding AI-assisted software development: orchestration, explicit policies, validation, persistent context, and project continuity.

The goal is not to claim that AI-generated software can be made automatically reliable. The goal is to build better mechanisms for controlling, validating, and maintaining the process.

There are still architectural choices to evaluate, limitations to uncover, and parts that need real-world testing. I want the project to evolve through evidence and technical feedback rather than assumptions.

What I want to learn from the community

I'm looking for developers who are willing to examine the project critically. In particular, I'd appreciate feedback on:

• Architecture: Does the control-plane approach provide a useful separation of concerns, or does it introduce unnecessary complexity?
• Agent orchestration: What should be handled by the orchestration layer, and what should remain native to the underlying coding tools?
• Reliability: Which validation mechanisms are essential? Where should the system stop and ask for human intervention?
• Memory and continuity: What information should persist between sessions, and how can stale or conflicting context be handled?
• Developer experience: Is the project understandable, portable, and practical to install and extend?

I welcome bug reports, alternative designs, constructive criticism, and contributions. If you disagree with the architecture, explaining why would be just as valuable as suggesting an improvement.

Help shape the project

Repository: github.com/SHEMASOFT/SYSTEM-ENGINEERING

If you're interested, start by exploring the repository and its documentation. Try what is relevant to your environment, report what breaks, and tell me what you would design differently.

I'm especially interested in feedback grounded in actual testing, reproducible issues, and concrete architectural trade-offs.

This is an ongoing open-source engineering effort, not a claim that every problem has already been solved.

What do you think is the biggest missing layer in today's AI-assisted development workflows: orchestration, validation, memory, policy enforcement, or something else entirely? I'd like to hear your perspective.