How to Create Modular Code Patterns — Build Apps That Don’t Break | Bug Free AI APP Development Day 3 of 5

Day 3 is the most productive day of the course — four modules, four exercises, SecureVault goes from foundation to functionally complete core. The AI Coding Day 3 covers how to read AI-generated code once you have it. Today we focus on how to ask for it in patterns that produce the right code the first time. Our CEH practice exam follows the same pattern philosophy — modular question banks loaded on demand, validation layer separating input from scoring, UI rendering decoupled from answer logic.

Single Responsibility — The One Rule That Prevents Everything Else

Single Responsibility Principle: each module should have one, and only one, reason to change. A validation module changes when validation rules change. A storage module changes when the storage mechanism changes. If a single file would need to change when either validation rules or storage mechanisms change, it’s doing two things — and it will produce bugs when those two concerns pull in different directions.

The prompt-level consequence: when you write a prompt for a module, you should be able to describe its responsibility in one sentence without using “and.” If your description is “this module validates input AND saves to storage,” you’re specifying two modules in one prompt. Split it. The resulting code will be cleaner, easier to test, and more reliable.

I test every module I specify against this rule before writing the prompt. I ask myself: “If the storage backend changed from localStorage to IndexedDB, which modules would need to change?” The answer should be exactly one: the Storage module. If the answer is “the Storage module and also the EntryService module and also the App module,” the storage concerns have leaked across module boundaries and the architecture needs fixing before any code gets written.

I’ve found that beginners struggle most with the service module boundary — it’s tempting to put validation logic inside the service because “it’s all part of creating an entry.” Resist that. The service calls the validator. The service doesn’t contain validation logic. That distinction means you can change your validation rules by editing exactly one file, with zero risk to the service, storage, or UI modules. That kind of surgical changeability is what makes AI-built codebases maintainable long-term, not just functional on day one.

Pattern 1: The Validation Module

The validation module is the gatekeeper. Every piece of data enters the system through validation. Nothing that isn’t validated ever reaches storage or business logic. The validation module’s only job is to accept raw input and return a typed result describing whether the input is valid and if not, exactly why.

Key properties of a good validation module: it has no side effects (it never writes to storage or the DOM), it never throws (it always returns a ValidationResult), it validates one thing per function (not “validate the whole entry” as one function — separate functions for title, content, category), and its error messages are user-facing (not “invalid input” — “Title must be between 1 and 100 characters”).

I always include one constraint in my validation prompts that beginners typically miss: the validator must accept any type as input, not just the expected type. This sounds obvious but it’s the difference between a validator that works in tests and one that works in production. In tests, you call validateTitle("My Note") with a proper string. In production, a user pastes something unusual, a browser extension modifies the form data, or a JavaScript coercion somewhere produces a number where a string was expected. My validation prompt always includes “accepts any type as input — never assumes type” as a hard constraint. That single line eliminates an entire class of runtime TypeError crashes.

The error aggregation rule is the other thing I insist on: validateEntry() must report all errors, not just the first. Nothing is more frustrating as a user than fixing one validation error only to be told about a different one that existed from the start. Aggregated errors require one round-trip to fix everything. Stopping at the first error requires N round-trips for N issues. The prompt quality gate “validateEntry reports ALL errors, not just first” costs one sentence to specify and produces dramatically better user experience.

Pattern 2: The Storage Module

The storage module is the single place in the entire application that talks to localStorage. No other module ever calls localStorage.setItem or localStorage.getItem directly. This single-access-point pattern means that if you later want to change from localStorage to IndexedDB, you change exactly one file — and nothing else in the application needs to know.

Key properties: all storage operations return OperationResult (never throw or return null), the module handles quota exceeded errors explicitly, all keys are prefixed (to avoid collisions with other code on the same domain), and the module is synchronous where possible (localStorage is synchronous — don’t wrap it in unnecessary async).

The quota exceeded case is one I’ve been bitten by in production. localStorage has a 5MB limit per origin, and it’s not difficult to hit that with a notes app where users store longer entries. An application that doesn’t handle quota exceeded will throw a DOMException that — without explicit handling — looks to the user like a blank crash. My storage prompt always includes “handle QuotaExceededError explicitly with a user-friendly error message.” This gives the user a meaningful message (“Storage is full — delete some old notes to save new ones”) rather than a silent failure.

I also always add a key prefix constant at the top of the storage module. For SecureVault I use sv_. This prevents the nightmare scenario where your app’s keys collide with another script on the same domain — a scenario that causes subtle, hard-to-reproduce data corruption bugs that only appear in specific browser environments. One constant, zero collision risk.

The two CryptoConfig functions are the piece that makes SecureVault actually work across sessions. getCryptoConfig() returning null is how app.js will know “no master password has ever been set — show the setup screen” versus “a vault already exists — show the unlock screen.” Without this, there’s no reliable way to distinguish first-run from returning-user, and no way to retrieve the salt needed to re-derive the same encryption key on every subsequent unlock.

Pattern 3: The Service Module (Business Logic)

The service module is the brain of the application. It coordinates between the other modules to execute the application’s features. The service module knows about validation, storage, and crypto — it orchestrates them. It never touches the DOM directly (that’s the UI module’s job) and never talks to localStorage directly (that’s the storage module’s job).

The service module’s functions map directly to user-visible actions: create an entry, read an entry, delete an entry, search entries. Each function runs the full workflow: validate input → encrypt → save → return result. The calling code (app.js) doesn’t need to know anything about validation rules or encryption — it just calls createEntry() and gets a typed result back.

Read the initService logic carefully — it’s the single most important piece of business logic in the entire application, and it’s the part most beginners would never think to specify. Without the verification ciphertext, there’s no way to detect a wrong password on unlock: deriveKey() never fails, it just produces some key from some password — a wrong password silently produces a wrong key, and every decrypt() call on existing entries would then fail with “wrong password or corrupted data,” which is technically true but arrives too late and in the wrong place (scattered across every entry, not as a single clear “incorrect password” message at unlock time). The verification ciphertext is a small, fixed piece of known plaintext encrypted once at setup specifically so that one decrypt attempt at unlock time can confirm or reject the password before the user ever sees their entry list.

Pattern 4: The UI Components Module

The UI components module contains pure render functions — functions that take data and return HTML strings or DOM elements. Nothing else. No event listeners. No fetch calls. No storage. Just: data in → HTML out. This purity makes UI components testable (you can call them with test data and inspect the output), reusable (the same card component works anywhere you need to render an entry), and safe (no business logic leaks into the presentation layer).

Event listeners live in app.js, not ui-components.js. This separation means you can completely redesign the UI without touching business logic, and you can change business logic without breaking the UI rendering.

The Isolation Test — Verify Before You Integrate

Before connecting any module to the application, run the isolation test. The isolation test is a minimal browser-runnable script that imports the module and calls each function with known inputs, checking that outputs match expectations. This catches bugs in individual modules before they combine with other modules and become integration bugs that are much harder to trace.

I want to be direct about why I consider this step non-negotiable. The most painful debugging sessions I’ve had with AI-built applications weren’t caused by bad code inside a single module — they were caused by two correctly-written modules that disagreed on something the architecture didn’t specify. One function returned null when it found nothing; the calling code expected an empty array. Both pieces of code were individually sensible. Together they caused a crash that took over an hour to trace because I never tested the modules in isolation first. I would have caught it in three minutes if I’d run the isolation test.

The test works because it forces a hard boundary between “this module is correct” and “this module is correctly connected.” Once you know every module passes its isolation test, any bug in the running application is definitionally an integration bug — a connection problem, not a module problem. That narrows your debugging search space from “any of eight files” to “the wiring between two specific files.” That’s the difference between a ten-minute fix and a two-hour debugging session.

My routine: I run the isolation test immediately after Claude generates each module. Not after the whole build. Not at integration time. Right after generation, while the module is still isolated in a browser console tab. If it fails, I use the Day 1 formula to get a corrected module before I’ve built anything on top of it. Building on top of a module I haven’t tested is building on sand.

One more thing I always add to my isolation tests that the basic template doesn’t include: an adversarial input section. I call every function with inputs that are technically valid types but semantically hostile — a title that’s exactly the maximum allowed length, a category that’s a valid string but not in the allowed list, a timestamp that’s zero or negative. These are the inputs real users will eventually provide, and they’re the ones that reveal validation logic gaps before they become production bugs. It takes two extra test cases per function and it has saved me far more debugging time than it costs.