George Stephenson

Start at the end: learning full stack development with AI

· softwarefull stack developmentspec-driven developmentdidactic prompting

In the past, when someone had an idea, they started coding it from line one. With AI coding agents, you can start at the end by building the entire project first. Bootstrap a project that interests you, then use it as your own personal sandbox. Learn by tweaking and tinkering, not wasting hours getting stuck.

In this article, I’ll take you through an example modern tech stack project, of the kind you might want to learn from across the frontend, backend, database and infrastructure, using the Full Stack Developer roadmap as a model. However, the principles apply to any stack and any project you can think of.

For my project, I decided on a simple idea called bestbooks.guide (GitHub). It’s a simple interactive website, with basic user features, like tracking which books you’ve read. It was easy to get up and running quickly, it’s something I’m interested in, and it can be extended in any number of ways.

The bestbooks.guide home page
The front page of bestbooks.guide

See Appendix A: Architecture Diagram for a detailed look at the bestbooks.guide tech stack.

Learning patterns

With the rate of progress of tech, software development requires lifelong learning, yet the rate of improvement in AI has made this increasingly daunting. Being able to generate limitless code is a good thing and a bad thing: there have never been more opportunities for learning, and yet more opportunities for complacency.

There are three main ways of learning that I think should be combined to learn anything properly:

  1. Learning by observing - watching lectures or courses, reading textbooks, listening to podcasts. The material should be substantive and good quality, which will require deep mental focus and effort. If the material is too easy, it could be a sign that it’s oversimplifying things, which can lull you into a false sense of security and teach bad habits1.
    • Find high-quality, authoritative sources of information to learn from, so that you don’t waste your time. You should find the material engaging and intellectually meaningful so that you will finish it. Avoid “content producers” on YouTube.
    • It’s also critical that you do not remain passive while absorbing the material, so that it is retained. This is where the other learning patterns come into play.
  2. Learning by writing - what’s come to be called the Feynman technique2. Writing notes is an effective way to retain information, if done in frequent small doses, and used to test your own understanding3. Write what you’re learning in your own words and test you remember it.
    • I like using markdown .md files and git for my note taking. This in itself is good practice for using version control effectively. The added bonus is that your notes are backed up and have an immutable version history. You can track your progress, hold yourself more accountable, but in any case your efforts will be rewarded with an artefact that you should feel proud of producing.
    • Use notes to test your memory and form habits, not just to copy verbatim. Often the reference you are learning from is a better source of information than your own notes - the benefit is in the writing rather than the utility.
  3. Learning by doing - putting things into practice is final confirmation that you understand something. Many of us like to jump to doing things immediately, and this post is in that spirit - I would only caution that for something as cerebral as software engineering, you need to combine it with theory and reading. While we’re going to start at the end, we’re not finishing at the end.
    • If you’re following a course or reading a textbook, do the exercises. In addition to writing notes, I like to fold exercise solutions into my markdown repositories too.
    • Start small and avoid heavy chores. If you get excited about a website or app idea that you want to build, think about how quickly you can ship it.
graph LR
    A[Learning by observing] -->|retained by| B[Learning by writing]
    B -->|practiced by| C[Learning by doing]
    C -->|enhanced by| A

Roadmaps

One great source of learning material is roadmap.sh.

A good strategy for learning anything about software or computers is to pick the roadmap that fits what you want to learn, and then apply the learning strategy above while you work through it.

Each node in a roadmap comes with example free resources. The idea is to complete one or two of these free resources, or find your own, applying all three learning patterns, then move onto the next node in the roadmap. Again I’d recommend making a repository that collects your notes, exercises and projects completed while learning the roadmap. This will help you to come up with your own “definition of done” that feels more meaningful than just reading to the end.

For this article, I’m using the Full Stack Developer roadmap. It’s beginner-friendly and generalisable to many developers.

How to use a computer

The focus of this article is on learning full stack dev by bootstrapping a project that interests you, with the power of AI coding agents. However, you are still required to use a computer Actually you can already get Claude Code to submit pull requests via voice command from your phone, but I digress. . If you are new to software development, there may be some tasks I take for granted that seem impenetrable for you.

To remedy this I would recommend a dose of therapy using the Unix philosophy, and installing a Unix-like operating system on your desktop computer such as Linux. Thankfully there are options for home treatment:

If you want to carry on using Windows desktop, installing Visual Studio Code is a good first step It would be remiss of me not to mention that you can also install Linux within Windows using WSL. However, my advice is to simplify your desktop for ease of use, and I don’t think blending two different operating systems is the way to do that. .

The reason I recommend Unix philosophy is that learning small, composable programs4 lends itself towards having a composable mind, with a skillset tailored for software engineering. Understanding the “everything is a file” approach for program interfaces makes seemingly impossible feats straightforward and understandable5.

Understanding how to manipulate simple and composable programs compounds over time, because this is literally how a coding agent harness like Claude Code works. If you have watched Claude Code at work and its use of tools confounds you, it is probably because you missed the fundamentals laid out above.

AI coding tools

At the time of writing, we’re in a period where AI models are advancing very rapidly. Models that were fairly rubbish a year or two ago now have successors that are pretty good. Frontier models are astonishingly good6.

I want to briefly mention the distinction between AI models, which are the mysterious enigmas where all the magic happens, and agentic coding harnesses, which are handwritten tools that babysit and coax the model into following a useful agentic workflow that persists over time. For example, Claude Opus is a model, and Claude Code is a harness.

If you’re new to this, I personally recommend Claude Code at the time of writing. The CLI tool is good, so is the VS Code plugin and the Claude Desktop app. However, there are several other competitive tools, like GitHub Copilot and Cursor, and the best tool is likely to change over time. There is a good Claude Code roadmap that will guide you through all its features. You don’t need to know everything, but understanding what is meant by context window management is a good start. I have completed this roadmap myself and recommend it.

In terms of models, we’re at a point where paying more money for a better model will get much better results. In the near future, I think open weight models that you run on your own laptop will be more than good enough. We’ve gone back to the mainframe computer era and we will enter the portable era again soon. In fact you can already do this, but we’re not quite at the point where it’s the best or most cost-effective option (a good GPU will set you back a bit). You may be aware that coding agents can make mistakes and hallucinate7. This has rapidly diminished as models have got better. If you’ve opted for Claude Code, I’d recommend you use it with the Opus or Fable models rather than Sonnet for this reason. A standard Pro subscription will get you a good amount of use out of Opus, but pay for what you can afford.

Bootstrapping your full stack project

If you have any experience with software development, you probably know how much of a problem yak shaving is. If you’ve got this far, you’re either already an experienced developer (congrats), or I sent you down several rabbit holes.

I’m actually trying to help. My proposal is that we can start the Full Stack Developer roadmap by first completing it, using AI coding agents. Then we can dive deeper into each of the key technologies making up this stack, which includes React, Node.js, PostgreSQL, AWS and Terraform.

If you’re comfortable, ask your AI coding agent or chatbot for suitable project ideas using the full tech stack in the roadmap. Ask it for ideas that are quick to ship and have the least chores to build and maintain. Pick the idea that most excites you. Games can be a bad idea for practising code. The code might be simple, but then you spend three months on art assets, gameplay and level design. This is no longer a targeted learning exercise, it’s a multi-disciplinary and time-consuming passion project. Understand what you’re getting into.

If you need smaller steps, look at the roadmap’s checkpoints. Ask Claude for ideas for a simple HTML/CSS static website, that demonstrates all the key features of HTML and CSS, without requiring other technologies. A blog is simple and useful.

Spec-Driven Development (SDD)

It’s not strictly required, but to get the most out of AI I recommend following spec-driven development (SDD). I like to call it plan-first development, because you write a plan first before you code anything.

This is emerging as one of the more widely adopted techniques in AI-assisted software development8. Claude Code comes with a Plan Mode9 for precisely this reason, and it’s intended that you use it to draft an agreed plan before you commit to a specific implementation.

I don’t want you to keep the plan private between yourself and Claude though: I want you to commit the plan to your project, in a /docs folder, living side-by-side with the code.

There are a few reasons I recommend it for our purposes:

For bestbooks.guide, here was the exact prompt I used, after creating a new GitHub repository:

I’ve started this repo for a website project that will be a curated and opinionated list of best books in different subjects.

Users can login and track their reading progress, rate and leave reviews, that sort of thing.

Could you help me by starting to write a design document or suite of documents. You can interview me and ask me questions back to start planning the key features

Note: (this isn’t for putting in the document, this is between you and me) this is a portfolio project and to practice the various parts of the tech stack it uses

Here’s what I want the tech stack to look like:

  • Repo hosted in GitHub
  • React and Tailwind CSS
  • Node.js backend
  • PostgreSQL database
  • RESTful APIs
  • JWT Auth
  • Redis
  • To be hosted in AWS: want to use Route53, SES, EC2, VPC, S3
  • Monitoring in Monit
  • GitHub Actions
  • Ansible configuration management
  • Terraform
  • Automated testing throughout with CI gates and excellent coverage

I want this to be well architected and follow best practices in July 2026 (research this) but I also want it to be simple to begin so we can ship it ASAP, and built with clean architecture so it’s easily extensible.

This was enough to get Claude Code to add a /docs folder with a list of design documents categorised by area: 01-product.md, 02-architecture.md, 03-data-model.md etc. For example, here’s the proposed repository layout in 02-architecture.md:

best-books-guide/
├── apps/
│   ├── web/                 # React + Vite + Tailwind SPA
│   └── api/                 # Fastify + Drizzle (see layering below)
├── packages/
│   └── shared/              # API contract types, shared constants, slug helpers
├── infra/
│   ├── terraform/
│   │   ├── bootstrap/       # state bucket + GitHub OIDC role (applied once, locally)
│   │   ├── envs/prod/       # root module for production
│   │   └── modules/         # network, compute, dns, email, storage
│   └── ansible/
│       ├── inventories/prod/
│       ├── roles/           # common, hardening, nodejs, postgresql, redis, nginx, monit, app
│       └── playbooks/       # site.yml (converge host), deploy.yml (app release)
├── docs/                    # this suite + adr/
├── .github/workflows/       # ci.yml, deploy.yml, terraform.yml, codeql.yml
├── CLAUDE.md  TODO.md  README.md  LICENSE

You don’t need to understand everything that’s going on here. But you can read it and contribute whatever opinion and understanding that you do have. You can ask questions, and Claude will answer:

What does that do? Why are we doing that way? Is this modern best practice in [current month]? Can you research it? Are there any better alternatives?

Once you’re happy with the plan, check also that Claude is happy with it too, knowing what it knows now. Then get Claude to update the README.md and CLAUDE.md.

Once that’s done, ask Claude to fully implement it. It might take some time, and there will be a few steps requiring your intervention, like signing up for AWS. But that’s it. With powerful enough models, you should be able to produce a finished working system with plan-first development.

How much time it took

Talk is cheap, so here are the real numbers, taken from the repository history.

   
First commit Saturday 11 July, 19:05
First recognisably working site Saturday 18 July, 22:10 (f320c78)
Feature-complete Sunday 19 July, 21:18 (50099cc)
Elapsed 8 days
Days I actually touched it 6
Recorded active time around 9 hours

“Recorded active time” is every commit, pull request and CI event clustered with a two-hour gap threshold. “Claude babysitting time” might be a more accurate description than actual active time. What those hours bought:

Area Lines Files
Backend - Fastify, Node.js, TypeScript 13,902 145
Frontend - React, Tailwind CSS, Vite 5,932 59
Ansible 1,355 43
Design documents 1,328 19
Terraform 1,319 39
Shared package 832 13
GitHub Actions workflows 307 5
Total 25,594 345

Of which 4,760 lines across 35 files are tests.

Now look at where the time actually went, because it is not where the lines are. Building the web pages was really pretty straightforward. The part that required the most intervention and had the most churn was, predictably, the AWS infrastructure, in particular Ansible, running our web server on a real VM, which Claude Code has imperfect knowledge about. Those 2,674 lines of Terraform and Ansible - a tenth of the codebase - consumed something close to half the wall-clock.

I would argue that this is where knowing how to use a computer really comes into its own. Claude Code’s interface - which is also the interface of developers - is using shell commands, on your local machine using the AWS CLI, and via SSH. Not all of this is really “coding” but it is coding-adjacent, and understanding these fundamentals is enough to induce Claude into building a feature-complete system.

What went wrong

Over the life of the repository, 52 of 261 CI runs failed - one in five - and nine of thirty-one production deploys failed outright. Here is what actually broke.

The deploy pipeline ate an entire evening. On Wednesday 15 July I merged the infrastructure and then spent two hours and twenty minutes watching deploys fail, eight of them, which was the whole session. First the release job could not authenticate to AWS at all:

##[error]Credentials could not be loaded, please check your action inputs:
Could not load credentials from any providers

The GitHub OIDC trust policy had been written, but was not correctly bound to the role. Then, after moving from an SSH key to SSM Session Manager, Ansible could reach the host but could not log in:

fatal: [bestbooks-prod]: UNREACHABLE! => ubuntu@i-0dc5e6872fb8112d6:
Permission denied (publickey).

Twice. In between, Monit had been configured beautifully and was not actually running, which took its own commit to notice. These are all the bits that aren’t code, and the bits Claude struggles with most.

A placeholder reached production. The M2 deploy ran the database migration against a hostname that was, literally, the word base:

Error: getaddrinfo EAI_AGAIN base
  code: 'EAI_AGAIN', syscall: 'getaddrinfo', hostname: 'base'

Something had templated DATABASE_URL badly, and nothing between the design document and the production host noticed, because every test supplied its connection string a different way. This is the archetypal AI bug: internally consistent, green in CI, blows up the instant it touches reality.

It failed the quality gates it had written for itself. I asked for “excellent coverage”; Claude proposed 80% globally and 90% on the API application layer, I agreed, and it went into CI. It then failed that gate repeatedly:

ERROR: Coverage for branches (64.72%) does not meet global threshold (80%)
ERROR: Coverage for statements (86.39%) does not meet "apps/api/src/app/**"
       threshold (90%)

Five consecutive runs on one branch, inching upwards. Gates are a good technique to ensure AI agents produce better quality code, but make no guarantees on how tedious and time consuming it will be to get there.

Tests that lied. The M4 run passed locally and fell over in CI with unique constraint violations, because the tests shared a database and did not isolate their fixtures:

ERROR: duplicate key value violates unique constraint "users_email_unique"
ERROR: duplicate key value violates unique constraint "review_reports_member_unique"

Separately, npm ci refused to install at all, because the lockfile had been regenerated on a machine with a different platform matrix from the CI runner:

npm error `npm ci` can only install packages when your package.json and
package-lock.json ... are in sync
npm error Missing: [email protected] from lock file

Claude wrote bugs. Book counts on list pages ignored sublist items and were simply wrong on the live site until 50099cc. The pages failed WCAG AA contrast and had a broken heading order until I thought to ask for an audit. A failed transactional email would 500 the entire request.

Almost nothing that broke was application logic. Everything that broke lived at a boundary: between the repository and AWS, between a config template and a running process, between one test and the next, between today’s lockfile and tomorrow’s runner. It’s a useful lesson because it tracks: these are always the hardest bits to test and get right without a lot of trial and error.

Didactic prompting

You can now prompt your coding agent to act as your tutor. I call it didactic prompting - prompting an AI agent to teach you something, in an intentional and informative way, as if it were a teacher.

For example, take the HTML sub-roadmap. I can use my project to learn about any part of this, and do so in various different ways. If I wanted to learn about HTML definition lists, I could ask Claude:

Give me a use case for HTML definition lists within my website

Claude pointed out that PrivacyPage.tsx is currently using an unordered list for term-and-definition pairs, which is exactly the semantic use case for definition lists.

Can you add a HTML definition list to my website, but intentionally make 5 errors? Then pass it to me to fix the errors, and score me after I’ve finished.

Claude invented a new page, GlossaryPage.tsx, with five intentional semantic errors. I could then follow by asking Claude to mark my work.

What’s interesting to me is that by creating this test, Claude added an actual usable feature which you are now contributing to.

Can you set me some tasks that involve adding HTML definition lists to my website, in increasing order of difficulty? Then mark how well I did afterwards.

Claude listed off four changes in increasing difficulty with detailed examples:

You’re only limited by your imagination when it comes to learning opportunities here. Once you complete the entire roadmap:

Can you write an exam for me that tests my knowledge of https://roadmap.sh/html, using my website as a case study. The exam should include five sections:

  1. Multi-choice questions
  2. Free-choice questions
  3. “Correct the error” questions
  4. Tasks to fix bugs in the website (add these in if you can’t find any)
  5. Tasks to add features to the website

The benefits of this approach compound each other:

Hopefully this approach is both more fun and more informative.

Common concerns

If AI built all of it, then I don’t understand any of it

The key thing here is that we started at the end, by building a working system. But it wasn’t the end at all, it became the substrate for didactic prompting. Rather than follow dry study material, you entirely built the thing that most excites you, which is now yours to do whatever you want with. What you’ve built is an incredibly rich artefact that you can study, learn from, and make your own: see Learning patterns and Roadmaps.

This is not the AI I had in mind. I want to build AI systems, not just use AI tools to build websites

There are roadmaps for that. My point in writing this article was to empower humans to still feel useful building things in a world where AI code generation has dramatically reduced the cost of writing code, whether or not the code is for an AI system.

If I let AI write the code for me, I don’t feel like a real developer…

This is being a real developer in 2026. The truth is that scaffolding code isn’t and never was that interesting. What is interesting:

This becomes part of your project creation process, and the more complex the project, the more thought you put into it. Once your project skeleton is in place, that’s when you can practise coding the parts that really matter.

I can’t just bootstrap a large Kubernetes cluster that easily

Distributed systems are an area of intense focus in modern software engineering, and also an area of intense complexity. You may want to start with a technology used in distributed systems, such as Kubernetes or Kafka, and deliberately use it for the wrong use case - a monolithic system, single instance, straight to production, etc. Once the skeleton is in place then you can practise how it scales into a distributed system, which becomes your exercise. Again we’re bootstrapping the tech stack to get to the good part.

Summary

I wanted to write this to inspire hope in new and existing software developers in the AI era. To ground ourselves in this new reality and embrace the new rapid techniques for code generation, while still being able to learn it and understand it.

These are some approaches for doing that, to have confidence that your time is not being wasted and you can still be useful.

The tech stack I’ve used is just an example, here are some other stacks you could apply this to:

Stack Frontend Backend Data Infra Best for

Python + AI		 Reflex (Python) FastAPI (Python) PostgreSQL + pgvector Modal + Fly.io AI, ML and data-heavy products, in pure Python

.NET + Blazor		 Blazor (C#) .NET Azure SQL + EF Core Azure Container Apps + Bicep Enterprise apps in a single C# codebase

Go + Kubernetes		 Vue + Nuxt + Tailwind Go (Chi) PostgreSQL + sqlc + Redis GKE (Kubernetes) + Terraform High-throughput microservices and cloud-native distributed systems

Rust full-stack		 Leptos (Rust) Axum (Rust + Cargo) PostgreSQL + SQLx Fly.io Maximum performance and memory safety

Ruby on Rails		 Hotwire (Turbo) + Tailwind Rails (Ruby) PostgreSQL + Redis Kamal + Hetzner A solo developer shipping a complete product fast

You could try building any or all of these. See how they compare with each other and what you learn along the way If you’re not that good at using a computer, building all of these is a guaranteed way to learn how to use a computer. . However, it doesn’t have to be a full end-to-end stack. You can apply these principles to any set of technologies you’re learning. My examples just demonstrate the power of deep-diving into heavy stacks.

In the AI world human effort still has its place. For example, I wrote this article myself - AI helped with the mermaid diagrams and the code for this page, and reviewed it all afterwards. But these are my words, and writing it gives me some comfort I don’t need Claude for everything. Prompt writing is writing, after all, and knowing how to write is more valuable than ever.

Appendix A: Architecture diagram

flowchart TB
    U([Browser])
    OL[Open Library API]
    CI["<img src='/img/icons/githubactions.svg' width='20' height='20'/> <img src='/img/icons/terraform.svg' width='20' height='20'/> <img class='tech-icon--invert' src='/img/icons/ansible.svg' width='20' height='20'/><br/>GitHub Actions<br/>test · Terraform · Ansible deploy"]

    subgraph AWS["AWS - provisioned by Terraform"]
        R53[Route 53<br/>DNS]
        SES[Amazon SES<br/>transactional email]
        S3[(S3<br/>backups · release artifacts)]

        subgraph EC2["EC2 - one Ubuntu host, configured by Ansible"]
            N["<img src='/img/icons/nginx.svg' width='20' height='20'/><br/>Nginx<br/>TLS · static SPA · /api proxy"]
            W["<img src='/img/icons/react.svg' width='20' height='20'/> <img src='/img/icons/tailwindcss.svg' width='20' height='20'/> <img src='/img/icons/vitejs.svg' width='20' height='20'/><br/>React + Tailwind CSS<br/>Vite build"]
            A["<img class='tech-icon--invert' src='/img/icons/fastify.svg' width='20' height='20'/> <img src='/img/icons/nodejs.svg' width='20' height='20'/> <img src='/img/icons/typescript.svg' width='20' height='20'/><br/>Fastify<br/>Node.js + TypeScript"]
            P[("<img src='/img/icons/postgresql.svg' width='20' height='20'/><br/>PostgreSQL")]
            R[("<img src='/img/icons/redis.svg' width='20' height='20'/><br/>Redis")]
            MO[Monit]
        end
    end

    U -->|HTTPS| R53
    R53 --> N
    N --> W
    N -->|/api/v1/*| A
    A --> P
    A --> R
    A -->|email| SES
    A -->|book metadata| OL
    MO -. watches .-> A
    CI -->|deploy| EC2
    EC2 -. nightly backup .-> S3

References

  1. Elizabeth L. Bjork and Robert A. Bjork. Making Things Hard on Yourself, But in a Good Way: Creating Desirable Difficulties to Enhance Learning. Worth Publishers, in Psychology and the Real World, 2011. The source of the term "desirable difficulties": conditions that slow study down often improve retention, and the fluency you feel while rereading is a poor predictor of what you will recall later.↩ Back
  2. James Gleick. Genius: The Life and Science of Richard Feynman. Pantheon Books, 1992. The source of the "Notebook of Things I Don't Know About" episode: before his Princeton oral exam Feynman took each branch of physics apart and rebuilt it in his own words.↩ Back
  3. John Dunlosky, Katherine A. Rawson, Elizabeth J. Marsh, Mitchell J. Nathan and Daniel T. Willingham. Improving Students' Learning With Effective Learning Techniques: Promising Directions From Cognitive and Educational Psychology. Psychological Science in the Public Interest, 14(1), 2013. Ten study techniques graded on the evidence behind them. Only practice testing and distributed practice rated high utility; summarisation, highlighting and rereading all rated low.↩ Back
  4. M. Douglas McIlroy, E. N. Pinson and B. A. Tague. UNIX Time-Sharing System: Foreword. Bell System Technical Journal, 57(6), 1978. The primary source for the Unix philosophy, from the man who invented pipes: "Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."↩ Back
  5. Tsoding. Graphics API is irrelevant, 2025. Animation generated by writing PPM image frames by hand in C++, with no graphics library involved, and a compatibility layer that runs GPU shaders on the CPU to identical effect.↩ Back
  6. METR. Time Horizon 1.1, 2026. The length of task a model can finish with 50% reliability doubles every 196 days measured across all six years, but every 89 days measured from 2024 onwards. The trend is not just continuing, it is steepening.↩ Back
  7. Aleksandr Churilov. The Range Shrinks, the Threat Remains: Re-evaluating LLM Package Hallucinations on the 2026 Frontier-Model Cohort. arXiv preprint, 2026. A replication of Spracklen et al. (USENIX Security '25) on five 2026 models. The worst case has collapsed - 21.7% on 2025 open-source models down to 6.10% - while the best case has not improved on 2024, and 53 hallucinated package names remained registrable by an attacker.↩ Back
  8. GitHub. Spec-driven development with AI: Get started with a new open source toolkit, 2025. GitHub's open source toolkit for spec-driven development, supporting 30+ coding agents. The premise: "specifications don't serve code, code serves specifications".↩ Back
  9. Anthropic. Choose a permission mode, 2026. Plan mode is enforced by the harness rather than by the prompt: Claude can read, search and run tests, but cannot edit files until you approve the plan.↩ Back
  10. Dan McKinley. Choose Boring Technology, 2015. The case for spending your limited "innovation tokens" deliberately: a stack choice carries a long tail of operational cost.↩ Back
  11. Nicole Forsgren, Jez Humble and Gene Kim. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press, 2018. Four years of DORA survey data finding that delivery capability - version control, automated testing, continuous delivery, loosely coupled architecture - predicts organisational performance.↩ Back
  12. Anthropic. How Claude remembers your project, 2026. The CLAUDE.md reference. Keep it under 200 lines, prefer "Use 2-space indentation" to "format code properly", and remove contradictions.↩ Back
  13. Michael Nygard. Documenting Architecture Decisions, 2011. The post that introduced the architecture decision record: write down the decision and its context, both of which outlive the code implementing them.↩ Back
  14. Anthropic. Prompt engineering overview, 2026. The guide opens by telling you not to start there: define your success criteria and build a way to test against them first.↩ Back
  15. Anthropic. Extend Claude with skills, 2026. A SKILL.md packages a repeatable procedure and, unlike CLAUDE.md, loads only when it is used. Facts belong in CLAUDE.md, procedures in a skill.↩ Back
  16. Robert C. Martin. Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall, 2017. The source of the dependency rule: source code dependencies point inwards, so the business rules know nothing about the database, the web framework or the UI.↩ Back
  17. Martin Kleppmann and Chris Riccomini. Designing Data-Intensive Applications, 2nd Edition. O'Reilly Media, 2026. Subtitled "The Big Ideas Behind Reliable, Scalable, and Maintainable Systems". Cited here for its treatment of nonfunctional requirements: performance, reliability, scalability and maintainability.↩ Back
  18. OWASP. OWASP Top 10. The standard awareness document for web application security. Every item on it is a design or configuration decision rather than a syntax error.↩ Back

← Back to all posts