Reuse before invention
Enterprise software is built within a larger environment. Identity and access management, logging, shared integrations, design systems, approved dependencies, and security practices already exist. Allowing every coding agent to choose or recreate these independently would produce inconsistent applications and an expanding maintenance burden.
The SHAPE Framework therefore starts from enterprise-approved assets and patterns. A project should use those capabilities where they meet the requirement and seek approval before introducing a materially new dependency or architecture decision.
Approved platforms and patterns
An enterprise may support several approved application stacks rather than a single universal technology choice. For example, an organization may maintain distinct approved approaches for browser-based applications, mobile applications, ERP extensions, and integration services. Each approach can have its own starter repositories, libraries, authentication patterns, components, and agent-readable guidance.
A project selects the applicable stack from these approved options, taking its needs and constraints into account. The coding agent should implement within that choice instead of introducing a different ecosystem for convenience. If no approved option fits a genuine requirement, the architect and relevant enterprise owners evaluate the exception under existing policy.
The SHAPE Framework does not prescribe any particular programming language, web framework, hosting provider, database, or integration product. Those choices belong to the enterprise's technical standards and to the project's documented architecture.
Libraries and common capabilities
Shared libraries and services can provide authentication, authorization, validation, logging, observability, error handling, and other recurring needs. Their documentation should explain correct usage, known constraints, and supported extension points. Reuse helps specialists review a smaller collection of familiar solutions.
Design systems and components
Approved UI components and design rules let agents assemble consistent applications without inventing a new button, form behavior, or visual convention for each screen. A new component or variant should meet a genuine need and follow the organization's governance for shared assets.
Local versus shared changes
Not every useful project-specific component should become an enterprise standard. The architect should consider whether a candidate is reusable, understandable, maintainable, secure, and compatible with existing assets. Shared adoption requires deliberate stewardship; copying one project's accidental choices everywhere is not reuse.
Agent-readable guidance
An approved component or service is more useful to coding agents when it comes with concise instructions, examples, and constraints. The organization can improve agent performance by making its actual standards legible and easy to locate. These instructions supplement technical access restrictions; they do not replace them.
Continuous improvement
Project experience can reveal missing components, weak instructions, or repeated friction. Short retrospectives between the Product Engineer and architect identify improvements worth preserving locally or proposing as shared assets. Over time, enterprise materials can become more complete without becoming a rigid catalog of rules for every possible case.