Archives

The expensive failure is not an agent that writes bad code. It is an agent that writes good code for the wrong design, quickly, while you nod along. The fix is an interrogation before implementation, and the questions it asks are not the ones you expect.

Your tests pass because you chose the inputs, and you chose them with the same mental model that wrote the bug. State the law instead and let a generator hunt the counterexample. Doing this to my own published reducer found a rule I had promised in print and never actually enforced.

Changing one string five levels down means rebuilding every object on the way back up, by hand, in a pyramid of spreads where the bug is never in the value you meant to change. A lens turns that path into a value you can name, compose, and reuse, and the pyramid collapses to one line.

A long design session goes bad in a specific way, and it is not that the agent forgets. It remembers everything you said, including every idea you abandoned, at full weight. The fix is the same one engineering already uses for people: write down what survived, and hand over the document instead of the conversation.

I spent months writing prompts, rejecting what came back, and rewriting it myself. The problem was never the model. It was that I was prompting a tool instead of managing a developer, and engineering already knows how to manage a fast, talented, undisciplined developer.

Your state is the residue of setter calls nobody recorded, which is why the bug won't reproduce. Name what happened as events, let one pure function fold them into state, and every screen your app has ever shown is one replay away.

Your business rules can't be tested because they're welded to fetches, toasts, and analytics calls. Split the program in two: a pure core that decides what should happen and returns it as plain data, and a thin shell that performs it. The mock count drops to zero.

Stop checking the same field in fifteen places. Parse untrusted input once at the boundary into a type that can't be invalid — validation forgets what it learned, parsing keeps the proof in the type — and every downstream check disappears.

Stop throwing, start returning. Model failure as a value with Result, compose fallible steps on a railway, make illegal states unrepresentable, and let TypeScript force you to handle every error — no try/catch required.

Three booleans give you eight states when you only meant four. Discriminated unions make the illegal ones unrepresentable — model a value as exactly one of a fixed set of shapes and let TypeScript hold you to it.

Six concrete moves that turn functional thinking into TypeScript you can ship on Monday — pipelines over loops, expressions over statements, immutable updates, higher-order functions, composition, and closures over classes — refactored on a real orders view.

The word 'function' means two different things, and the one you learned in Java is the one TypeScript keeps punishing. A pragmatic case for thinking in equations, not recipes.

Embracing functional programming principles like purity, immutability, and declarative composition is no longer optional in modern React development, as these concepts provide the predictability and stability required to manage complex application state and build scalable architectures.

I’m kicking things off with a look at my 20-year journey from backend Java to modern frontend leadership, and outlining what you can expect from my posts on engineering, architecture, and career growth.