DEV Community: sep83

No More Hallucinated Citations: A Domain-Specific RAG System with Ollama, ChromaDB and AI Agents

sep83 — Mon, 11 May 2026 02:27:38 +0000

TL;DR: I built a full-stack knowledge pipeline around a corpus of 2,514 academic PDFs focused on urban art. The system combines ChromaDB vector search, Ollama-powered semantic analysis, a FastAPI REST layer, and six AI agents (slash commands in Claude Code) that orchestrate research workflows end-to-end. The result: zero hallucinated citations, dense evidence-backed documents, and a workflow that scales to any specialized domain.

The Problem: LLMs Hallucinate Academic Citations

If you've ever used an LLM to help write a research proposal or academic paper, you've probably hit this wall: the model confidently produces author names, journal titles, and publication years — none of which exist.

The standard advice is "don't use AI for citations." But that advice ignores a better question: what if you gave the model an authoritative, queryable corpus instead of relying on its training data?

That's exactly what this system does.

The Stack at a Glance

PDFs (2,514 docs, 4 languages)
        │
        ▼
  [Ingestion Pipeline]
   pdfplumber → chunking → metadata extraction
        │
        ▼
  [Dual Storage]
   MariaDB (corpus.db) ──── ChromaDB (59,030 chunks)
   metadata + citations      vector embeddings
        │
        ▼
  [Analysis Layer]
   Ollama (self-hosted LLM) — semantic relevance scoring,
   research_hint generation, debate mapping
        │
        ▼
  [REST API — FastAPI]
   /search · /consulta · /fragmentos · /autores
   /debate · /translate · /recientes · /document/{id}
        │
        ▼
  [AI Agent Layer — Claude Code slash commands]
   /mapeador · /evidencia · /auditor · /propuesta · /articulo · /vigilante

Everything runs locally. No data leaves the machine. The corpus, embeddings, LLM inference, and API are all self-hosted.

Part 1 — The Corpus

Ingestion

The corpus started with a focused collection of academic PDFs on urban art and graffiti: peer-reviewed articles, book chapters, conference proceedings, and policy documents spanning English, Spanish, Portuguese, and French.

Each document goes through a pipeline:

# Simplified ingestion flow
doc = extract_text_pdfplumber(pdf_path)
chunks = split_into_paragraphs(doc, max_tokens=512, overlap=64)

for chunk in chunks:
    metadata = extract_metadata(chunk)  # author, year, DOI, language
    embedding = embed(chunk.text)       # via Ollama nomic-embed-text
    chromadb.add(chunk.text, embedding, metadata)
    mariadb.insert(chunk, metadata)     # full text + APA citation

The chunking strategy matters enormously here. Fixed-size token splitting loses paragraph context. Instead, I split on paragraph boundaries with a 64-token overlap between chunks, which preserves semantic coherence while keeping retrieval granular.

What Gets Stored

Each chunk in MariaDB carries:

Field	Description
`paragraph`	Full text of the chunk
`page`	Page number in the original PDF
`citation_apa`	Pre-formatted APA 7 citation
`citation_mla`	Pre-formatted MLA citation
`doc_id`	Unique document identifier
`relevancia`	Ollama-assigned relevance score (1–5)
`research_hint`	≤240-char synthesis of the chunk's contribution
`categoria_tematica`	Thematic category (e.g., `graffiti_core`, `tecnologia`)
`anio`	Publication year
`idioma`	Language code

The relevancia field is generated once at ingestion time by asking Ollama to score each chunk's relevance to the corpus domain. This pre-computation means searches can filter by quality without running LLM inference at query time.

Current State

Total documents:    2,514
Chunks in ChromaDB: 59,030
RAG coverage:       99.8%
Languages:          EN (62.3%), ES (14.3%), PT (12.7%), FR (2.7%), others

Part 2 — The Retrieval Layer

Hybrid Search

A common mistake in RAG systems is relying solely on cosine similarity. Semantic similarity isn't the same as relevance — a chunk can be about the right topic but still be a weak citation (methodologically unsound, pre-2010, tangential argument).

The system uses a hybrid relevance_score that combines three signals:

relevance_score = (
    0.5 × cosine_similarity(query_embedding, chunk_embedding)
  + 0.3 × ollama_relevancia          # pre-computed quality score
  + 0.2 × recency_weight(year)       # normalized publication year
)

This produces meaningfully different rankings from pure vector search — and in practice surfaces much better citations for academic use.

The API Endpoints

The FastAPI layer exposes the corpus as a set of purpose-built endpoints:

# Semantic search — fast, no LLM at query time
GET /search?q=urban+heritage+documentation&top_k=20&style=apa

# Full RAG — slower, synthesizes an answer with citations
POST /consulta
{
  "pregunta": "What methods exist for documenting ephemeral urban art?",
  "top_k": 10,
  "anio_desde": 2015,
  "idioma": "en"
}

# Verbatim fragments for direct quotation
GET /fragmentos?concepto=ephemeral+art+preservation&top_k=8

# Author and debate mapping
GET /autores?tema=digital+documentation+street+art
GET /debate?tema=vandalism+vs+heritage

# Export for bibliography sections
GET /search/export?q=graffiti+cultural+heritage&format=bib&top_k=100

# Translation of non-native-language chunks
POST /translate
{"paragraph": "...", "target_lang": "es"}

Each endpoint returns structured data including paragraph, page, citation_apa, relevance_score, research_hint, and doc_id. The doc_id is critical — it makes every citation traceable back to a specific PDF page.

Example Response from `/fragmentos`

{
  "results": [
    {
      "paragraph": "Street art occupies a paradoxical position in urban space: simultaneously celebrated as cultural expression and prosecuted as criminal damage, its ephemerality is not accidental but constitutive of its meaning...",
      "page": 47,
      "citation_apa": "Brighenti, A. M. (2010). At the wall: Graffiti writers, urban territoriality, and the public domain. Space and Culture, 13(3), 315–332. https://doi.org/10.1177/1206331210365283",
      "relevance_score": 0.91,
      "research_hint": "Argues ephemerality is constitutive of street art's meaning, not a deficiency — critical for patrimony arguments.",
      "doc_id": "brighenti_2010_wall"
    }
  ]
}

Notice the research_hint — this is Ollama's pre-computed synthesis of why the chunk matters, not just what it says. It's what makes the agent layer possible.

Part 3 — The Agent Layer

The real productivity multiplier isn't the API — it's the agents built on top of it.

Six Claude Code slash commands orchestrate the research workflow. Each agent is a Markdown file in .claude/commands/ that instructs Claude Code to call the corpus API in a specific sequence and produce structured output files.

The Agent Map

/vigilante   — session start: check deadlines, detect new corpus documents
/mapeador    — map the corpus for a topic (calls /autores + /debate + /search ×2 + /consulta ×2)
/evidencia   — build an evidence table for a specific section
/propuesta   — full proposal generator (orchestrates mapeador + evidencia + redaction)
/articulo    — full IMRAD academic article generator
/auditor     — audit any .md file, classifying claims as [✓ VERIFIED] / [⚠ WEAK] / [✗ PENDING]

The `/mapeador` Agent — Eliminating 6 Manual API Calls

The most impactful agent. Before it existed, mapping the corpus for a new topic meant manually calling six endpoints, collecting outputs, and synthesizing them into a coherent picture. With /mapeador, one command does all of this:

/mapeador "ephemeral urban art documentation" B

The agent:

Calls GET /autores?tema=... — maps the key authors and schools of thought
Calls GET /debate?tema=... — surfaces competing positions
Calls GET /search?q=...&top_k=20 with two different query formulations
Calls POST /consulta twice with methodologically distinct questions
Synthesizes all results into mapa-corpus-<slug>.md

Output structure:

# Corpus Map — Ephemeral Urban Art Documentation

## Key Authors
- Brighenti (2010) — territoriality and ephemerality
- Iveson (2010) — public space and street art legitimacy
...

## Academic Debate
Position A: Documentation preserves — [corpus evidence]
Position B: Documentation alters meaning — [corpus evidence]
...

## Evidence Bank (top 20 sources)
| citation_apa | relevance_score | research_hint |
|---|---|---|
...

## State of the Art Synthesis
[Generated by Ollama via /consulta — 400-600 words, cited]

## Identified Gaps
- [PENDING — no corpus support]: ...

This takes about 3 minutes and replaces what used to be 45–90 minutes of manual API work.

The `/auditor` Agent — Zero Hallucinations Guarantee

After any document is written, /auditor runs through every substantive claim and classifies it:

/auditor propuestas/minciencias/2026-grafpin/propuesta.md

Output example:

## Audit — 2026-05-10

| Claim | Endpoint Checked | Status | Note |
|---|---|---|---|
| "Street art is recognized as intangible cultural heritage in 12 countries" | /search?q=intangible cultural heritage street art | [✗ PENDING] | No corpus support for "12 countries" |
| "Brighenti (2010) argues ephemerality is constitutive..." | /fragmentos?concepto=ephemeral constitutive meaning | [✓ VERIFIED] | relevance_score: 0.91, page 47 |
| "Computer vision achieves 87% accuracy in graffiti style detection" | /search?q=computer vision graffiti accuracy | [⚠ WEAK] | One source, pre-2018 |

Rule: if more than 40% of claims are [✗ PENDING], the document doesn't ship. This single constraint eliminates hallucination from the research output.

Part 4 — Multi-Query RAG Strategy

One underrated technique in this system: always formulate 3–4 query variants before calling /consulta.

The same concept produces very different corpus results depending on phrasing:

queries = [
    "ephemeral art documentation methods",           # EN — technical angle
    "documentación arte urbano efímero patrimonio",  # ES — heritage angle
    "street art preservation digital archive",       # EN — infrastructure angle
    "graffiti documentation urban memory loss"       # EN — urgency angle
]

Each formulation retrieves a different subset of the corpus. The agent layer handles this automatically — /mapeador uses two /search calls and two /consulta calls with different formulations, then merges the evidence.

The practical impact: query coverage increases from ~65% (single query) to ~92% (four-query merge) for complex topics.

Part 5 — Why This Applies to Any Domain

The urban art corpus is just one instantiation. The architecture generalizes completely:

Component	What to change for a new domain
PDF corpus	Replace with domain PDFs
Thematic categories	Redefine `categoria_tematica` for your taxonomy
Ollama relevance prompt	Update to score relevance to the new domain
Agent prompts	Update the research questions in each slash command
API filters	Add domain-specific facets (e.g., `species`, `jurisdiction`, `drug_class`)

I've seen this pattern applied to:

Legal research: case law corpora with jurisdiction and year filters
Medical literature: clinical trial PDFs with PICO-structure extraction
Policy analysis: government documents with agency and date filters

The key insight is that domain specificity is a feature, not a limitation. A general-purpose RAG system optimized for everything is often not great at any one thing. A corpus built around a specific domain, with relevance scoring tuned to that domain, produces dramatically better retrieval.

Challenges and Lessons Learned

1. Chunk size is a first-class design decision

Too small (< 200 tokens): loses context, retrieval precision drops.
Too large (> 700 tokens): embeds multiple ideas, relevance scores become noisy.
The sweet spot for academic text: 400–512 tokens with paragraph boundary alignment.

2. Pre-compute expensive operations at ingestion time

Running Ollama at query time for every search would make the system unusable. Pre-computing relevancia and research_hint at ingestion means query-time latency stays under 200ms for /search and under 8 seconds for the full /consulta RAG pipeline.

3. The citation must be traceable to a page

citation_apa without page and doc_id is not an academic citation — it's a claim. Storing both means every output of the system can be verified by opening the original PDF.

4. Agents need failure modes, not just success paths

When the corpus doesn't support a claim, the agents mark it [PENDING] rather than hallucinating support. This requires explicit prompting: "if you cannot find corpus evidence, write [PENDING — verify corpus] and do not fabricate a source."

5. Multi-language corpora need language-aware retrieval

Embedding models trained primarily on English produce lower-quality embeddings for Spanish and Portuguese text. Using nomic-embed-text (multilingual-capable) and adding language filters (idioma field) to all queries significantly improves cross-language retrieval.

Results

Since deploying this system:

Zero hallucinated citations in output documents (validated by /auditor on every deliverable)
Research proposal drafts in 3–4 hours vs. 2–3 days manually
Evidence density: 1.8 citations per paragraph on average (up from ~0.4 with manual research)
Corpus growth: The system accepts new PDFs at any time — ingestion takes ~30 seconds per document

What's Next

A few things on the roadmap:

Citation graph: linking documents by shared references to surface clusters of highly-cited foundational work
Temporal drift detection: alerting when a claim that was [✓ VERIFIED] against the corpus in 2024 now has contradicting evidence from 2025+ additions
Cross-corpus queries: combining this corpus with data from the Grafpin platform itself (geolocated urban art documentation) to answer questions that require both academic literature and empirical field data

The Core Idea

The goal was never to automate research. It was to make the evidence layer of research reliable.

LLMs are extraordinary at synthesis, argument construction, and adapting tone for different audiences. They are unreliable as bibliographic databases. The solution isn't to avoid LLMs — it's to give them a trustworthy, queryable knowledge base so they can focus on what they're actually good at.

A domain-specific RAG corpus, properly indexed and exposed through a well-designed API, changes the LLM's role from source of truth to engine of reasoning. That's a much better place for both the model and the researcher to be.

The system described here is operational and actively used for academic research on urban art preservation. The platform it supports, Grafpin, documents geolocated street art in cities across Latin America.

Stack: Python · FastAPI · ChromaDB · MariaDB · Ollama · Claude Code · pdfplumber

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.