Forem: sep83

Building Software with AI Orchestration: A Spec-Driven and Memory-Enhanced Development Model

sep83 — Wed, 01 Apr 2026 13:22:56 +0000

Spec-Driven Development in the Age of AI

How Orchestrated Agents, Memory Systems, and Specification-First Thinking Are Transforming Software Engineering

Software development is undergoing the most significant transformation since the invention of high-level languages.

What once depended on manual coding and human memory is becoming a specification-driven, AI-assisted, memory-orchestrated workflow.

In this model, the developer is no longer the primary writer of code but the author of logic, while AI generates predictable, structured, architecture-compliant implementations.

This article summarizes the development model I use today in production systems—an ecosystem built on:

Specification-driven development (SDD)
Multi-agent AI orchestration
Persistent project memory
Architecture-aware code generation
Human-led reasoning instead of manual typing

1. The Core Shift: From Coding to Writing Specifications

Traditional development used to follow this pattern:

“Write code → Test → Fix → Rewrite → Document.”

But now, it looks more like:

“Describe what must exist → The system generates it.”

This shift happened because modern AI systems can produce:

Cleaner code
More consistent architecture
Faster iterations
Strict rule compliance
Fewer human errors

Our role changed from writing syntax to writing intent.

Today, we write:

Requirements
Acceptance criteria
Data structures
Architectural constraints
Process flows

And the AI transforms those specifications into working code.

We are no longer “coding”—we are engineering logic.

2. The Orchestrator: The Brain That Coordinates AI Agents

At the center of this development model is an orchestrator agent:

a coordinator that determines when and how other agents should act.

Example Orchestration Flow

Orchestrator
├── DB Agent — explores schema, creates SQL, validates identifiers
├── Architecture Agent — designs layers, workflows, ViewModels, endpoints
├── Code Agent — generates code according to the approved design
└── Reviewer Agent — performs adversarial auditing before completion

Each agent has a scoped responsibility.

No single agent makes decisions outside its domain.

The orchestrator enforces:

Order of execution
Architectural rules
Boundaries and permissions
Required approvals

This eliminates chaos and ensures predictable automation.

3. Memory Systems: The Backbone of Long-Term Consistency

Human memory cannot maintain the full state of a system with multiple modules, databases, and cross-cutting rules.

AI memory systems solve this.

Persistent memory stores:

Architectural decisions
Database mappings
Context about modules
Business rules
Naming conventions
Patterns and anti-patterns
Constraints introduced weeks or months earlier

This ensures the AI always has the context needed to remain consistent.

Why memory matters:

No repeated explanations
No architectural drift
Stable reasoning across long development cycles
Automatic recall of rules and conventions

Memory turns AI into a reliable engineering partner—not just a stateless tool.

4. Specification-Driven Development (SDD)

Everything generated by the system begins with a specification:

Requirement → Use Case → Architecture → Implementation → Review

The system follows rules such as:

A feature cannot be implemented without a Use Case.
Every Use Case must include acceptance criteria.
Architecture must be produced before code generation.
All generated code must trace back to the spec.
Deviations require explicit classification:

[TECH-ADJUST YYYY-MM-DD]

This creates auditable development, where every feature has:

Purpose
Scope
Rules
Acceptance criteria
Implementation map

This is crucial for government systems, enterprise workflows, and large multi-team projects.

5. AI-Generated Code: High Quality by Default

In this model, the human no longer writes:

Controllers
SQL queries
Entities
ViewModels
Services
Validations
Data access code

Instead:

The architecture agent defines the structure.
The code agent generates the implementation.
The reviewer agent validates compliance.

All code follows rules like:

Consistent naming
Layered architecture
Bounded contexts
Separation of concerns
Mandatory patterns for DB access
Approved conventions

AI-generated code becomes:

Predictable
Maintainable
Documentation-aligned
Easier to audit
Faster to evolve

6. Why This Model Works

✔️ Consistency

Everything follows one architecture, one rule set, one direction.

✔️ Speed

Features that took days are now done in hours.

✔️ Quality

Architecture violations become nearly impossible.

✔️ Traceability

You always know why something exists.

✔️ Scalability

This model scales across large systems with multiple modules and databases.

✔️ Human Evolution

Developers become analysts, architects, and authors—not typists.

7. The New Developer Skill Set

In this new era, developers must excel at:

Writing precise specifications
Structuring requirements
Designing data flows
Thinking architecturally
Reviewing AI output critically
Managing automated agents
Documenting reasoning

Your value is no longer measured by “lines of code,”

but by clarity of thought and quality of technical instructions.

8. Conclusion — A New Era of Software Engineering

We are moving from:

Manual coding → Automated generation

Developers as coders → Developers as writers and architects

Ad-hoc memory → Persistent project memory

Single-model prompting → Multi-agent orchestration

This is not theoretical.

This is the workflow I use daily in real industrial systems, involving multi-module architectures, government databases, validation flows, and large-scale project structures.

AI now builds the code.

We build the rules, the intentions, and the architecture.

This collaboration produces software that is:

Faster to build
Easier to maintain
More robust
More auditable
More consistent

Welcome to the new reality:

Developers are writers. Machines are builders.

Spec-Driven Development and Prompt Engineering: New Terms, Same Foundations?

sep83 — Sat, 21 Mar 2026 02:47:49 +0000

In recent years, terms like "spec-driven development" and "prompt
engineering" have gained popularity alongside the rise of AI-assisted
coding tools. They are often presented as new paradigms that redefine
how software is built. However, a closer look reveals that these
concepts are not entirely new---they are, in many ways, a continuation
of long-established practices under different names.

The Core Idea Has Always Existed

At the heart of software development has always been a simple principle:

Define what the system should do before deciding how to implement
it.

This principle is embodied in:

Requirements engineering
Software design methodologies
Model-driven development

The idea of writing structured specifications and refining them
iteratively is not new. It has been a foundational part of software
engineering for decades.

What Has Actually Changed?

The real shift is not in the methodology, but in execution.

Traditionally:

Human → Requirements → Code → Software

Today, with AI:

Human → Specifications → AI → Code → Software

The difference lies in who writes the code. The machine now performs
a task that previously required significant human effort.

The Rise of "Prompt Engineering"

The term prompt engineering suggests a new engineering discipline.
However, in practice, it often refers to:

Writing clear and structured instructions
Iterating on inputs to improve outputs
Understanding system behavior through experimentation

These activities resemble:

Technical writing
Requirements refinement
Interface interaction design

While they require skill, calling them "engineering" may stretch the
traditional definition of the term.

Is It Really Engineering?

Engineering typically implies:

A strong theoretical foundation
Systematic methodologies
Application of scientific and mathematical principles

Not every structured activity qualifies as engineering. We do not refer
to tasks like procurement or observation as engineering, even if they
involve processes and optimization.

By that standard, labeling every interaction with AI as "engineering"
risks diluting the meaning of the term.

Spec-Driven Development ≠ New Paradigm

"Spec-driven development" is often presented as a modern approach. In
reality, it closely mirrors traditional requirements engineering, with
one key difference:

The implementation phase is now automated.

The process itself---defining, refining, and validating
requirements---remains unchanged.

The Role of AI: Acceleration, Not Reinvention

AI has dramatically reduced the time required to move from idea to
implementation. Tasks that once took weeks can now be completed in
minutes.

However, this acceleration does not fundamentally alter the development
lifecycle. It enhances it.

Looking Ahead

As AI systems evolve, they may:

Understand context more deeply
Infer intent with minimal input
Reduce the need for explicit specifications

If that happens, even current practices like prompt engineering and
spec-driven development may become obsolete.

Final Thoughts

The emergence of new terminology often reflects shifts in tools rather
than in core principles. While AI has transformed how quickly software
can be built, it has not replaced the foundational need for clear
requirements.

In that sense, spec-driven development is less a revolution and more
an evolution---one that automates implementation but leaves the
underlying discipline intact.

Beyond RBAC: Designing Scalable Access Control Without Role Explosion

sep83 — Sun, 15 Feb 2026 17:08:14 +0000

Role-Based Access Control (RBAC) is often the first authorization model developers reach for—and for good reason. It is simple, intuitive, and easy to explain. But as systems evolve, RBAC frequently becomes a bottleneck rather than a solution.

This article explores why traditional RBAC fails at scale, compares it with other common authorization approaches, and presents a generalized hybrid pattern that avoids role explosion while preserving clarity, flexibility, and auditability.

The goal is not to replace RBAC, but to use it correctly.

Traditional RBAC: Strengths and Limits

At its core, RBAC maps roles to permissions:

ADMIN  → create, read, update, delete
EDITOR → create, read, update
VIEWER → read

This works well when:

All users of a role behave the same way
Permissions are uniform across resources
The system is small or single-tenant

However, RBAC quietly assumes something that rarely remains true:

A role fully defines what a user can do everywhere.

Once this assumption breaks, problems appear.

The Role Explosion Problem

As soon as permissions depend on context, roles start multiplying:

Editor for project A
Editor for project B
Reviewer who can approve but not edit
Viewer who can export but not modify

Each variation becomes a new role. Over time:

Roles lose semantic meaning
Authorization becomes harder to reason about
Changes require migrations instead of configuration

This phenomenon is known as role explosion, and it is the most common failure mode of RBAC.

Common Alternatives (And Why They Struggle)

RBAC with Custom Logic

A frequent workaround is adding conditional checks in code:

role allows action
AND resource belongs to user
AND state is valid

This approach works short-term, but:

Authorization logic becomes scattered
Rules are implicit and hard to audit
Behavior depends on code paths, not data

Attribute-Based Access Control (ABAC)

ABAC evaluates policies based on attributes:

user.department == resource.department
AND user.level >= resource.required_level
AND action in allowed_actions

ABAC is powerful, but often:

Hard to debug
Hard to explain
Easy to over-engineer

It shines in policy-heavy environments, but is excessive for many applications.

Access Control Lists (ACLs)

ACLs attach permissions directly to resources:

Resource X:
  User A → read, edit
  User B → read

They provide excellent granularity, but:

Scale poorly with many users
Make global permission reasoning difficult
Lack a clear notion of user capability

A Balanced Pattern: Capability vs Scope

A more scalable approach separates capability from scope.

Core Principle

Access is granted only if both conditions are true:

Access = Role allows action
      AND Assignment grants action on resource

This creates a conjunctive authorization model that is strict, flexible, and auditable.

Roles as Capability Ceilings

Roles answer one question only:

What types of actions can this user ever perform?

They are:

Global
Few in number
Stable over time

Roles should not encode:

Resource ownership
Project membership
Temporary responsibilities

They define a maximum authority, not actual access.

Assignments as the Granularity Layer

Fine-grained permissions are handled through explicit assignments:

Bound to a specific user
Bound to a specific resource
Containing an explicit list of allowed actions
Optionally enriched with metadata (who assigned it, status, expiration)

Assignments answer:

What is this user allowed to do here?

The same user can have different permissions on different resources—without changing roles.

Why This Pattern Scales

No Role Explosion

New requirements create new assignments, not new roles.

Built-in Separation of Duties

If a role cannot approve, no assignment can override that.

Clear Audit Trail

Every permission is explicit, inspectable, and traceable.

Simpler Mental Model

Roles define potential, assignments define reality.

A Generic Authorization Flow

A typical authorization check follows a predictable sequence:

Is the user in the correct context or boundary?
Does the role allow this action type?
Is there an assignment for this resource?
Does the assignment include the action?

Each step is independent, testable, and explainable.

When to Use This Pattern

This model is a good fit when:

Permissions vary per resource
Users collaborate on subsets of shared data
Separation of duties matters
Auditability is required
You want to avoid hardcoding rules

It may be unnecessary when:

The system is small or single-tenant
All users of a role behave identically
Only a few permission levels exist

Key Takeaways

Roles should express capability, not scope
Granularity belongs in data, not role names
Conjunctive authorization improves safety and clarity
Authorization rules should be auditable, not implicit
Design access control with growth in mind

Good access control is not about more rules—it’s about clearer boundaries.

Back to Lovelace: Software Without Unnecessary Abstractions

sep83 — Sun, 08 Feb 2026 18:04:24 +0000

A return to intentional code in the age of artificial intelligence

For decades, software engineering has followed a trajectory that equates progress with layers: more frameworks, more abstractions, more automation hidden behind conventions. This trajectory was not accidental. It was a response to very real problems—growing teams, inconsistent coding practices, fragile systems, and the human cost of maintaining large codebases.

But the context has changed.

With the rise of artificial intelligence as an active participant in software development, many of the original reasons for heavy frameworks and runtime abstractions are no longer dominant. This article proposes a deliberate shift in perspective that I call “Back to Lovelace”: a return to explicit, intentional, and minimal software design—augmented by AI, not obscured by it.

The original problem frameworks tried to solve

In the early days of software, performance and correctness depended far more on how code was written than on the language itself. A well-written program in a low-level or high-level language could be equally efficient. The real problem was never the language—it was inconsistency.

As projects grew and teams expanded, individual styles and interpretations led to fragmentation. Frameworks emerged primarily as a social solution, not a technical one. They imposed:

conventions,
folder structures,
lifecycle rules,
and architectural patterns.

Frameworks created a shared mental model so teams could collaborate at scale. Performance and clarity were often sacrificed in favor of uniformity and governance.

That tradeoff made sense—then.

AI changes the equation

Artificial intelligence fundamentally alters the development process in a way we rarely acknowledge explicitly.

AI does not improvise architecture. It executes instructions.

Given clear rules, constraints, and intent, AI can generate:

consistent structure,
repeatable patterns,
readable and maintainable code,
without personal bias or stylistic drift.

In other words, AI eliminates much of the human chaos that frameworks were designed to control.

Today, the most valuable input is not a framework—it is a well-defined prompt that encodes architectural intent.

Back to Lovelace: what the name means

Ada Lovelace understood something fundamental long before modern software existed: machines do not create intent—humans do. Machines execute formalized ideas with precision.

“Back to Lovelace” does not mean returning to primitive tools. It means returning to:

explicit logic,
transparent execution,
and intentional design.

AI becomes the executor of structure, not the source of abstraction.

Minimal standards instead of heavy frameworks

The proposal is not an absence of structure. It is minimal, explicit structure.

Patterns such as MVC, MVVM, or layered architectures have existed for decades. They are not inventions of frameworks. Frameworks merely codified them—often with additional runtime complexity.

A minimal standard is enough:

/controllers
/services
/models

Controllers handle transport and I/O
Services encapsulate business logic
Models represent domain data

No magic. No reflection-heavy lifecycles. No hidden execution paths.

AI-generated scaffolding can apply these conventions consistently without introducing runtime abstractions.

Scalability is an infrastructure problem, not a framework problem

Modern scalability is achieved through:

container replication,
load balancers,
horizontal scaling,
stateless services,
observability and monitoring.

Duplicating a well-designed service across containers solves the majority of real-world scaling needs.

Frameworks do not provide scalability. Infrastructure does.

If a system genuinely requires a radically different model—massive throughput, extreme latency constraints, or global distribution—it should be designed that way from the beginning, not retrofitted through abstractions.

SQL as a first-class citizen

One of the clearest casualties of over-abstraction has been the database layer.

Explicit SQL:

communicates intent clearly,
exposes real relationships,
is auditable and optimizable,
reflects the true domain model.

Even complex SQL tells a story. An experienced engineer can understand where data comes from, how it is transformed, and why it exists.

ORMs, especially general-purpose runtime ORMs, often obscure this narrative. Views, stored procedures, and optimized queries become difficult or unnatural to express. The abstraction replaces the domain instead of serving it.

In complex systems, this is not simplification—it is distortion.

The myth of constant migration

Automatic migrations were designed for a time when changing database engines was common.

That world no longer exists.

Today we:

choose a database engine deliberately,
containerize it,
and evolve schemas incrementally.

Microservices and APIs further reduce the need for large-scale schema migrations. Services own their data. Interfaces, not schemas, define boundaries.

Migration is now an exception—not a foundation.

Typing is not abstraction—it is intent

Strong typing does not hide behavior. It clarifies it.

Types:

define contracts,
reduce ambiguity,
guide both humans and AI,
prevent entire classes of errors.

In an AI-assisted workflow, typing becomes even more valuable. It anchors generated code to explicit expectations.

Typing aligns perfectly with the Back to Lovelace philosophy.

The decline of runtime ORMs

Runtime ORMs introduce:

latency,
hidden queries,
unpredictable performance,
cognitive overhead.

They struggle with advanced database features such as:

views,
stored procedures,
fine-grained optimization.

Modern systems benefit more from:

explicit SQL,
query builders where appropriate,
compile-time checks,
and clear data boundaries.

ORMs are not inherently evil—but as default runtime layers, their relevance is fading.

Small systems, composed into large ones

The future is not monolith versus microservices.

The future is intentional composition:

small services,
clear APIs,
explicit responsibilities,
minimal abstractions.

Serverless, microservices, and specialized APIs are not about fragmentation—they are about clarity.

Large systems should emerge from the combination of simple, understandable parts.

Conclusion: progress through subtraction

Back to Lovelace is not nostalgia.

It is an acknowledgment that:

AI reduces the need for human-enforced abstractions,
clarity beats cleverness,
infrastructure scales systems—not frameworks,
and explicit code is easier to reason about than magical behavior.

The future of software is not more layers.

It is fewer assumptions, clearer intent, and machines executing exactly what we mean.

That is not regression.

That is progress.