# ADR 000006 No Shortcuts GitBook

**Date:** May 2026\
**Status:** Accepted\
**Decider:** NikiDigitals\
**Version:** GitBook — Thinking Layer

***

## The Principle

This project starts from zero. No prior development experience. No cloud infrastructure background. No data engineering knowledge. Five years from now, the goal is to have built a production-grade, AI-augmented enterprise resource planning system and to understand every layer of it well enough to design it again from scratch, explain every decision to a senior technical audience, and teach it to someone else.

That outcome is only possible if understanding precedes building at every stage.

## The Decision

No layer of LES is built before it is understood. This is not a guideline. It is the governing principle of the entire project.

## Why This Is Harder Than It Sounds

The temptation in any technical project is to copy, paste, and move on. Tutorials make this easy. AI tools make it easier. It is entirely possible to deploy a cloud database without understanding what a database is, to write an API without understanding what an API does, to build an agent without understanding how it reasons.

The result is a system that works until it breaks, and breaks in ways that cannot be diagnosed, because the person who built it does not understand what is happening beneath the surface. That is not a portfolio. That is a liability.

The alternative — understanding each concept before applying it — is slower at the start. It requires sitting with confusion, asking questions that feel basic, and resisting the pressure to produce output before the input has been properly processed. But the compounding effect is significant. Every concept properly understood makes the next concept easier to grasp. By Phase 3, the intelligence layer, the foundations laid in Phase 0 are paying returns that no shortcut could have produced.

## What This Looks Like in Practice

Learning sessions precede build sessions for every new concept or technology. If something is not understood, the session stops — not to look up the answer quickly, but to genuinely understand why the answer is what it is. Documentation captures the understanding, not just the output. The journal records not what was built but what was learned.

This principle applies to everything: cloud infrastructure, data modelling, API design, development patterns, AI agent architecture, security frameworks. There are no exceptions because the exceptions are always where the understanding gaps become system vulnerabilities.

## The Long View

Five years of building with genuine understanding produces something that cannot be faked: the ability to sit in a room with senior finance transformation professionals and talk about system design with authority. Not because the right words were memorised, but because the right things were actually built and actually understood. That is what this project is for.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://nikidigitals.gitbook.io/les/03-architecture/decision-log/phase-0-foundation/adr-000006-no-shortcuts-gitbook.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
