I’m reviewing a mid-level dev’s PR who’s not on our team. First concern is its on our most important repo with high consequence of failure. The work could be piloted on a less risky repo, but she chose this one. She may not be aware of that context. Nowhere in the docs does it state that for the LLM’s to know, more is there a “map between repos” for our team for the LLM to have context. Should we build that? Yes. Do we have that now for the LLM? No. Does the dev know this? No. So I explain all that. She had no idea. She questioned the entire approach. This is the good part of iterative development; failing quickly; reducing the time it takes to learn. This is normal and good.

Second concern is it’s quite large. Not just many files, but many new files, some are quite long. I explain even without Github Stacks, we should be doing small PR’s with few changes and architected for a smaller blast radius. She appreciated the review; apparently getting PR reviews, from a human, are rare in some teams. :: face palm :: She had never heard of Github stacks or even just branching off of a branch; I explained the easier version if she wanted to avoid the github complexity rabbit hole that is gh stacks. Newer LLM’s have some of this in their training data, but unless you specify it, I’ve not seen them recommend it unless the repo has rules.

Third, approaching the work this was new for her. I don’t know what team experiences she had, nor where they are in in their CD journey, but I explained we don’t really plan that out. The whole point is to take small steps, learn, and use those learnings to inform where we should go next. So I don’t really plan or even know what the next PR’s will be, their size, nor the files. That said, I looked at her original PR and gleaned 3 smaller PR’s with only a few changes each that might form a great exercise to learn how to work in small steps since she had already trod this path once AND it’d be easier for me to have a more focus discussion on architecture since the changes are small. The LLM’s can help here if you know how to ask; I don’t think she even know you could ask such a thing yet.

Fourth, there were various architecture challenges, many of which she’d have no context unless she was on our team. Much of the code base was OOP, little dependency injection, heavy use of mocks, little types, and a consistent use of exceptions to drive responses. I’m attempting to move the team towards a more functional, typed, and errors as values approach. LLM’s _really_ struggle with navigating this as each integration has a flurry of options, and unless you narrow each one, it’ll just best guess. This is compounded in Brownfield code bases. This takes 110% of my focus just to help navigate this large space frigate through an asteroid field while drinking my coffee using sketchy inertial dampeners. There’s no way a Junior or Mid-level could both navigate this, know all the options, nor the vision not being on our team. I suggested we pair program on this so I could show how this vision has challenge, and what to do when you’re presented with a crossroads of architecture decisions to lead by example.

Fifth, one architecture one that was prevalent was a lack of DRY around a new framework they are using. It also uses exceptions, but checks the 5 types via instanceof; kind of like their own version of Promise.then/catch. The issue is all the parsing code is on the developer; since they didn’t use error types, you get error:unknown, and about 20+ lines of type narrowing code ensues in at least 4 call sites. At first I’m like “use types” to prevent all this. Then I was like “well, geez… ok, now you need a Zod schema to at least parse to one of the error shapes you’re expecting”. Then I was like “wait a minute, you’re doing this all over the place, why isn’t the framework handling this all for you via abstractions and types?”. Errors as types, types as values, Zod schemas parsing to known shapes, and leaky abstractions are all new concepts to her, and when you throw all of these at once, it’s quite overwhelming. We had a good brief discussion on perhaps making some new PR’s to the framework itself to help here since many others are going to run into the same implementation challenge. The framework has 200% docs, rules, and skills setup for LLM’s to be mostly Spec Driven Development style, but none of that was linked here in our repo, in her rules, or in however this was coded, LLM or not, I suppose. Again, the LLM is having to integrate this framework which has a different style into our repo which has 2 styles, with very little guidance on what to do at crossroads, so you need human in the loop guidance here.

Sixth, the shotgun parsing and lack of an anti-corruption layer was heavy, which in turn caused a lot of shotgun parsing because the maybe’s/optional’s were everywhere. In Brownfield, that’s fine, you just slowly add the parsing higher up, leaving it in a better place than you found it. But in the Greenfield code we’re adding, you have an opportunity to do things better, while still interfacing with the old in clear boundaries. So I explained Parse, Don’t Validate, Shotgun Parsing, and how you “design for the types you want, not what you’re given by some back-end” and how Zod can handle all this in colocated code. Again, it’s a lot throw at someone who’s never heard of all this a cohesive concept. LLM’s, even Opus 3.5, has all this in its training data. It may not be aware of Zod Codecs or the encoding angle, but even ghetto-fabulous SWE 1.6 can pick that up quickly if you give it a golden example. You have to be clear, though, about all of those rules, AND how to integrate them, (e.g. use Zod .transform/.pipe to map from downstream Data Transfer Objects, aka DTO’s ,to our domain Value Objects aka VO’s, so nice types come out).

Seventh, the LLM she was using read our code and started throwing custom class exceptions. The miss was we have a mapping layer at the top to ensure the responses match what we tell the user, so both the exception has to be shaped a certain way, the tests have to check for specific id’s, AND placement has to be thought out because since there are no types, the tests have to be aware of what level this is thrown from to test it. I explained we’re moving away from this approach to Railway programming using Neverthrow to have typed errors. I still can’t tell if this landed, but I know LLM’s can help you a ton here; I still use LLM’s to help debug Promise/ResultAsync chains when the return type isn’t requite right; they have an uncanny ability to fix it, even if you use the wrong explicit return type. Errors as Values is a huge mind shift for those used to imperative coding, especially those not from Go or Rust or FP languages. Especially tricky is the boundaries we have to map back to exceptions so our harness to “read all the errors and translate to the correct user response”. Easy with a .map, hard if you’re like “why do I need a .map?” LLM’s can grok that part easily, what’s hard for them is identifying the correct boundary. I don’t know all the boundaries, nor does she; we’d have to explore together to figure them out.

Eighth, and this is extremely common among TypeScript devs not from an FP background, the types are more for spelling, not for doing any type of Type Driven Development, or “if it compiles, it works” philosophy. So I had to give multiple ideas for certain sections on what could be done to offload to the type system instead of numerous tests, mocks or not. Some situations were impossible, and I had to give a couple of examples to show how you can model it so those impossible situations don’t occur anymore. There were a few switch statements that had default in them, and I had to explain how exhaustiveness checking in TypeScript works, and how the LLM’s will tell you to use never, but ignore them, and how some of that wasn’t her fault because the data they were using was draw DTO’s with optionals and nulls, and some approaches on how to possibly refactor and fix that. The LLM’s are extremely aware of how to type well, and they can easily bounce between OCAML pragmatism eschewing currying, to full Scala (feels like Java) where you don’t need tests “because we typed the universe”. You have to know those styles, AND the verbosity that TypeScript entails, AND figure out where your team falls in that extremely long spectrum, AND what to type now vs later given TypeScript is gradually typed. All of that, and if you’re learning this? Oh man, it’s harder in TypeScript because it’s so verbose compared to other languages, so the LLM (or me) has to know the level you’re at to teach it. Whew!

Had I not reviewed the code:

– the blast radius was high for this PR, with no easy ability to identify what would have caused it given so many changes

– condoning this behavior, human or LLM, sets a precedent that’s ok to make large PR’s. It’s not ok, and I will not condone it.

– would have missed so many wonderful opportunities to teach; I even got a message saying “Thanks for the review, those are rare nowadays” which about made my heart sink; happy she appreciated the attention, but this should be the norm to teach, not to be a meat proxy and just “have the LLM approve it”

– she now knows of all of this to better drive the LLM; before she wouldn’t even think to ask, and the code style + lack of rules-in-repo ensured the LLM would never volunteer alternatives

I got to help teach, she got setup for success, we both learned how to better drive the LLM’s. THIS is why I read the code.

2nd case is a lot simpler. Junior has a small PR to move a service to a new one with a feature flag. This new service is GraphQL, not REST, but the idea is the data will come back and map to our same domain objects. The issue, however, is despite using Zod in the new code, he’s still got Shotgun Parsing going on. If Zod safeParse works, he returns void, and continues on vs. using that safe-to-use domain data. There’s a fundamental understanding of how data validation should work, how TypeScript type narrowing works, and an LLM misunderstanding of how our code base wants you to do things given it’s brownfield and is lacking repo rules.

Again, I get to level him up, and we both learned how we could better articulate to the LLM how to do things, both in prompts and rules, and adding yet another golden data set to give to LLM’s for the future. THAT again, is why I have to read the code.

Yes, LLM’s are helping me. I’ve got Claude and Codex running my 3 Domain Driven Design, Unit Test, and Architecture review skills as well as SWE 1.6 in Windsurf. We have an Enterprise LLM code review that I’ve contributed to as well when I saw a core review was a bit off. So all hands are a deck for this, and helping. None of them, though, know the purpose, or does the Mid-level dev nor Junior know some of these fundamentals in architecture to ASK the LLM’s for help. Together, we all get smarter, and help the LLM’s help us more.

Yes, there are cases where I’m not reading the code; libraries that we use, integration points that never change, infra configurations that a multitudes of red tape and cyber checks to ensure they work and are safe. However, I’m erring on the side of read all of it because I’m consistently seeing code and architecture I wouldn’t want to be on call for in production, there are so many wonderful opportunities to teach and learn myself, misunderstandings from both Dev’s and LLM’s, and all of these help me refine the LLM’s to help me, and hopefully others self-teach, in this regard.

Finally, the most important part, is to learn. Are these requirements correct? Does this architecture allow future change more easily? Is this safe, or will we get dinged by cyber? I could go on and on; so far, the LLM’s aren’t catching all of these things, or are confused on when to apply my rules correct to all situations.

Motivation

When I first did it, I was motivated by 3 things that happened at the same time:

1. Primary Care Doctor recommended I get diagnosed for ADHD; specialist says I wasn’t, told me to Google sleep studies around diet (it was more specific keywords than that, I found good articles)
2. Saw an interview with Matthew Walker on Joe Rogan who talked about the half-life of caffeine. This lead to a rabbit hole of research.
3. I was having sleep issues and hitting fitness limits.

Surprising Caffeine & Fitness Learning’s

Both of those taught 3 key things that completely invalidated the “years of learning” I thought I had accrued from my fitness & diet years:

• caffeine has a half life of almost 12 hours
• yes, you can drink too much caffeine, resulting in disturbed sleep
• coffee was consistently sold as a table stakes benefit to fitness; little did I know it was sabotaging my entire life

There were other good learning’s that arose from that, but suffice to say I was immediately extremely frustrated. When I started getting into fitness, I approached it from a nerd perspective and just read everything I could, and watched all the YouTube videos. Not 1 person, fitness guru, dietician, nor sports science grad said ANYTHING about the negative effects of caffeine. There were only 2 consistent things you’d read/hear: “Don’t drink to much” or “you can use black coffee to break a fast”. That first NEVER had any explanation, or was expanded upon.

Most of the fitness blogs / thought leaders I really liked were super heavy on prioritizing your fitness pyramid into sleep first, diet second. Yet despite the common “turn off lights, avoid blue light on phone” etc. nothing about caffiene can ruin all of that, rather “use coffee with your BCCA’s to really make this workout count!”.

Life Changing

To say removing caffeine from my life was world changing was an understatement. The amazing things that changed and 1 horrible thing:

• I fell asleep immediately; like a switch turning off when my head hit pillow
• I woke up and could immediately function
• I woke up and felt “refreshed”
• I struggled to be creative as quickly

Let’s talk about them in order.

Fall Asleep Immediately

The immediately falling asleep was wild. I only experienced this 3 times in my life: twice when doing extreme workout routines and on particular days I was just so tired, or when extremely sleep deprived from traveling. Even those didn’t compare to this.

First, I’d start dreaming BEFORE I fell asleep. I read that many REM deprived individuals experience this, especially longer term alcoholics who will dream while they are awake. This is because the brain is so deprived of REM sleep.

Second, it was consistent falling asleep where you’re just “out like a light”. No long waiting, no getting comfortable, just “click”; immediately out.

Third, the dreams were unbelievably vivid. No nightmares except once (I had a slight tummy ache, which is normal for me to have a not-so-great dream when I don’t feel well). I still had the inability to remember most of the dreams, but still remembered way more details, and breadth then I’d usually have while on caffeine. This was consistent; every night, long, vivid dreams. Despite being fine and normal, nothing scary, I was still a bit apprehensive going to sleep some nights because I knew I was in store for some weird dreams. Despite me being an intense individual, I wasn’t used to having these intense of dreams, this often, for this long.

Immediate Wake Up

This one was weird too. Typically I’d struggle to wake up. Hit snooze 50 times, get up and feel super groggy until the 3rd cup of coffee. Mornings were always rough for me. I chalked it up to my circadian rhythms, just being a night person.

I’d be dreaming and then “I’m awake”. My eyes would open, and I’d be able to immediately sit up once I realized I was awake. I could even walk immediately to the kitchen. The sheer fact I was conscious, could sit up, and start my daily routines immediately was … just crazy. I often avoided people, social media, and my family on purpose because I just hated mornings so much and was such in a bad mood until the caffeine kicked it, and I was my normal, positive, high-strung self.

Refreshed

This one was the most wild. Once I stood up… I felt better. BETTER. Like “I’m glad I slept” and “I feel refreshed”. I cannot articulate the level of disrespect and anger I felt for those who would create medical forms asking you “Do you wake up feeling refreshed?”. I likened those people creating those questions as “Do you own 50 Lamborghini’s on your Unicorn ranch on the moon?” or “What will you invest in once we have world peace?”. These people are completely out of touch with reality. Nobody wakes up “refreshed”. Healthly or not, fit or not, we’re all tired, and even morning people I’ve talked morning people, and they too struggle to get started. Please remove this dumb question from these forms. It is a myth; nobody wakes up “refreshed”. I can’t take you seriously.

Then it happened to me. I did wake up refreshed. Every day. For weeks. It took me a long while to reconcile what was happening, and my anger towards feeling “misled” by the fitness industry deepened. Being older now, I don’t blame them. Many are young and aren’t as adversely affected. Many doing the writing/influencing have amazing genetics. The research and narratives around caffeine were buried; even the keyword searches or algorithms used to filter content on social did NOT surface anything negative about caffeine. All was positive with the silly warnings of “don’t drink too much caffeine” with nobody explaining what too much meant.

I later learned that caffeine is one of the largest traded and consumed drugs in the world. It’s not just an American “work till you drop, sleep when you’re dead” culture thing; it’s a worldwide incentive and cultural norm.

Brain Speed at 60%

I call this this one my “Brain Thesaurus Problem”.

This was the 1 negative, and why I stopped and went back to coffee. It felt like there was a “dark veil” across my thinking. Like I was thinking in slow motion. The only way I can give you an idea what it was like is imagine if I said “Give me some words of when something is really good”.

With coffee, I’d immediately blurt out in quick succession “rad, amazing, epic, super duper, dope, amaze”. But now… it was almost like I’d search for the words, and they weren’t there. I don’t know if some kind of wires just weren’t connecting anymore or what, but it’d take till about noon to 1pm to get back to the ability to fire on all cylinders. Physically I was fine. Mentally I felt really good. But, as a programmer, you are constantly being creative and connecting a lot of thoughts together whether through verbal communication, in chat, or in code while typing and reading. This was extremely frustrating.

The only thing I can think was my body’s natural Cortisol and Orexin deliveries to my brain in the morning were broken or unused since I started drinking caffeine heavily as a teenager, and coffee in in particular around 14. Given my high metabolism, and strict school schedule, I was always up early and eating, and caffeine usually played a role. That’s nearly 25 years of me ignoring/overriding those morning wake up hormones.

Anyway, given what I do for a living, after 2 weeks of this, I had to go back. Even just 1 cup of coffee and within minutes my brain worked as normal, further convincing me my body’s normal hormones were just broken for the morning.

Last Warning: Depression

I’ve learned a lot of things the hard way, and started to learn many industries seem to leave out important, negative details. For example, all the amazing hype around a Keto diet, I found no mention of the Keto Flu until after I tried it. Almost as bad as when I got Covid shots, I felt like I had the flu; felt like absolute trash, on the couch for days.

Quitting caffeine, even in the slow, wean myself off manner still had a horrible side-effect that thankfully was temporary: depression.

I get sad sometimes just like everyone else, and I’ve had episodes during my teenage years where things were extremely hard. But those were nothing compared to this. The worst depression I’ve ever experienced in my life was the 10 days when I was no longer drinking any caffeine in the mornings, not even decaf. It wasn’t the kind where you sleep more than normal, or feel detached from friends, family, your hobbies. This was a constant, deep in my soul “things are bad” feeling. I’m a strong will type of guy, quit smoking cold turkey, go 220% into new things I’m learning, can’t be hypnotized, etc. So when I get sad, I usually get angry, and that helps bring me out of it.

There was no anger here. Only emptiness and a deep sense that the world was sad. No dread, no anxiety, just an emptiness with me being stuck in some empty expanse of nothing, with no one, and a weak yearning to no longer be there. On the 11th day it stopped; there was like a 2% linger, but I knew it had “passed”. On the 12th day, gone totally.

You can see why I am now more careful when I hear about new things from the fitness and diet industry.

Why Doing This Again?

As I’ve gotten older, my energy levels have dropped. I’m still super high-strung compared to many I know, but it’s nothing like my 20’s. I first noticed a problem at 42 where I couldn’t finish workouts. I’d find the days I could power through, albeit barely, were when I had good sleep. People told me it was age, but I don’t think that’s 100% it. I took up Backpacking and riding a heavy motorcycle off-road, and found in most cases I had energy to do those things. After years of experiments during my 20’s and 30’s with sleep, diet, and exercise I could tell it was sleep and diet.

The second reason is AI. A lot of the LLM’s have accelerated the rate at which I have to review, and reject or fix, crap code. Social Media has made things worse as both bots and devs who don’t know any better have gone full AI Pyschosis, cargo culting the bad practices. This has galvanized me to help teach the juniors and mid-level devs the best practices, and hold back the rushing river of slop code and technical debt. To do that, I have to be at my best emotionally, and to do that, I have to fix my sleep, diet, and fitness. Given sleep is always the most important, I’m trying to fix it.

How Did My Life Change

While I went back to drinking coffee, I did some strict changes I haven’t deviated from the past 8 years.

1. I go to bed the same time every night; 11pm
2. I ensure I allow for 8 hours of sleep, even if I don’t get it. This means alarms are set for 7am. If I need to awaken earlier, I go to bed earlier even if I sit there waiting to fall asleep.
3. I ensure it’s dark at least 60-30 minutes before when I go to sleep; usually 10pm I’ll turn off all the lights (excluding my laptop, I’m a nerd)
4. I don’t drink caffeine within 12 hours of my bedtime; so I ensure to have my last coffee by/before 11am.

What’s Different This Time?

The first thing that’s different is I’m greatly expanding the wean time. I think I did like a month last time, where I did 3 cups for 3 days, then 2 for a few days, then 1, then decaf for a week, then none. I think that was way too fast.

I currently finished 2 weeks of just 2 large cups a day. Today is the first day of just 1 large cup. I’m going to try that for 2 weeks before I decide to make a change. Even on the 2 cups a day, I already noticed 2 days where I had the “Blocked Creativity” problem; I was trying to explain some code to a co-worker in our 9:30am meeting and struggled to find the words. I knew what was happening, but the wired connections weren’t there. After about a minute of struggling, it finally connected, albeit slowly… like when Starlink internet will occasionally just be slow for a minute and then slowly starts working again. If the 1 cup of day makes the above worse, I may go to 1 1/2 for a couple of weeks.

Even with just the 2 cups, I already started to feel my dreams get more intense. They aren’t as long, and I don’t have any of the immediate sleep, immediate wake up effects yet, but they’re getting close; I’d say 140% intensity compared to normal.

The other odd thing is I keep waking up SUPER early. This didn’t happen last time; I’d sleep consistently for 7 to 8 hours. This results in me getting super tired midday, often taking a nap, and then being super groggy the rest of the day. This was part of the impetus to try to fix my sleep in the first place. I’m hoping this is just a temporary health/diet thing. Summer is over and it’s already getting darker sooner, and it’s mostly dark in the mornings now so hopefully my body will adjust.

I’m also doing more cardio now, or at least trying. I was running 3 nights a week for 3 weeks + started improving diet (haven’t _totally_ cut out alcohol on weekends yet), but noticed the scale didn’t move at all. Usually when I start cooking healthy, it does. I’m about 178lbs, which was my max during my Powerlifting days, but since the motorcycle shoulder accident a year ago, I wasn’t doing my of anything. My normal natural weight is 166; that’s where I can do moderate Body Building / Cardio, and my body just “likes to be”. Perhaps age has increased things . I’ve started Body Beast’s Lean version to lose weight for Halloween. I’ve been doing Body Beast off and on for almost 10 years, and I’ll usually do the Bulk version.

I’ll attempt to increase my cardio as the Lean version only has 1 day a week devoted to it, so I’ll probably throw in 2 days of running. The motorcycle and backpacking trips usually take it out of me, so will probably throw a couple of them in too. We’ll see how that pans out as usually 6 weeks to 2 months in, my body, even in my early 30’s, started to struggle with the “increase in weight balanced with the fact we’ve been doing this for 2 months of high intensity”. I’ve found since the intensity never stops, I could simply drop the weight some to ensure I have the energy to continue. I do NOT feel guilty anymore doing this either. I’d rather drop from my 20lb dumbbells to my 15 or 10’s just so I can keep going for 2 more weeks. I started skipping the cut phase and just extending the last Bulk phase for 2 to 3 weeks until my body just said “stop”. May skip that this time, and do the cut phase more aggressively this time.

I found my body is super sensitive to protein intake, meaning, muscle mass just drops. However, because I’m so high strung, I cannot live without carbs. So I may go try a vegan / animal protein on and off again the last week to see how that works. I’m not really into tracking macros or calories anymore, but I did have massive success using cardio + weights + vegan 6 days a week to decrease fat. However, this time I could compensate with some animal protein to see how much I can tolerate. That, and it’d only be for 2 weeks vs. 3 months like last time. We’ll see.

Anyway, will report back when I’m at 0 cups a day.

Spending the last 3 weeks side-of-desk looking into redaction, specifically around PCI/NPI (Payment Card Industry / Non Public Information) data (bank account, personal user data, etc) in logs. You break various laws when this happens, and it’s not a fun thing to clean it up.

This in turn taught me that logs aren’t the only sinks, e.g. exits of data out of your app that could have PCI/NPI data in them. Streaming data (e.g. Kinesis, Kafka, etc). HOW you get that data is also interesting. Sometimes you parse stuff through JSON.parse from a downstream, but get things you didn’t mean to. Sometimes a REST call comes in, and things you didn’t intend to keep around were from the headers. Some of this data can go into the sinks that you didn’t intentionally mean to log/stream.

I looked at how most are solving it. The dynamic language, or “lol, wat are types” crews are basically attacking with various Regular Expressions, and string parsing. Any string you log, they either abstract things atop OOP loggers, or write single points of exit sinks like in Pino/Tap. At these points, they’ll combine multiple RegExp’s together into a mass string replacer. I’ve even see a strong arm approach of JSON.stringify’ing an Object, then redacting the big string that comes out.

Some will mark that they redacted something. Some will mark what they redacted. Some will just say “[REDACTED]” and you don’t know if it was a bank account number (BAN), an email, or a number you wrote that was a false positive.

The types crew will use… types. They’ll either create Branded or Variant/Sum/Union types to designate something as a secret, and ensure logging, streaming, and metrics functions cannot take those types. Some will use type proofs in functions or methods to ensure even nested type records do not contain secrets; ensuring “if it compiles, it doesn’t leak PCI data”.

Some, particularly in the TypeScript, Python (gradually typed community) will use both. This is because the type system can, and will often, lie because developers consuming the library can hack their way around it using the 20 billion escape hatches & levers these type systems give you.

The amount of Regular Expression and string matchers is vast. I remember back in the video sharing with chat days, there were many string matchers to filter out bad words from chat, and many also included XSS helpers. This ensures that people who find they can’t type “badword” will type “b a d w o r d” and find that using spaces like that defeats the string matcher for bad words, so they can type other bad words, or even bad code snippets using spaces. The devs will counter with more aggressive string matchers and regular expressions, and they seem to err on the side of “false positives are fine because the cost of failure is quite bad”. While the chat will filter out random words you don’t think are bad, it gives business piece of mind from legal ramifications of NOT doing it. The User Experience costs here are interesting, both to users and to devs.

I’m finding my in own work, for our existing logger, I’m having to use that dual approach of “use types to prevent this from happening”, but also using a combination of regular expressions when the narrowness of type system breaks down. I’m also thinking of starting from scratch on a secondary implementation once the first is done that type narrow specifically to ensure we don’t even need the runtime checks (well, it’s TypeScript, almost anything can be defeated with an as unknown so I’ll have to run various tests). But it’s clear the hybrid approach causes the API to suffer because you’re constraining what the dev can log, but also have to do a ton of type work to compensate for when they (unknowingly) lie to you.

I really like the clean, typed approach as it lessens the attack surface, and I share a lot of this with the streaming and metrics use cases as well as those are less open to the developer so easier to constrain what gets in. It also helps when we attack the problem at the source, and immediately decode into secrets vs. “I don’t know man… they could be anywhere, let’s just JSON.stringify all the things and run a ball of RegExp on it”. Having schema libraries like Zod decode immediately to know secrets enables such a better security posture.

Before: “Where are your secrets?” “Uh, in this codebase… I think from a downstream REST call. You’ll have to go track down their Swagger, it may/may not point them out”

After: “Find all instances of the Secret class.”

I’ve found that some secrets aren’t even secrets. Devs will put credit card number in a secret container, and when you look inside, it’s actually a null. Having a schema validate it’s even an actual secret prevents a lot of this from even being a problem.

There’s also some tricky situations that reminds me of the 1989 Batman movie Joker plot. You’ll have a user’s last name and the last four digits of their credit card. Both aren’t necessarily PCI on their own… but together? Yes. Same with the chemicals Joker was pushing in the movie; isolated they were innocuous, but together, poison. There are various Intersection and Union types you can create to prevent these combinations so you can relax when it compiles.

It’s been interesting to tackle this problem from a Brownfield approach. “How do we prevent PCI data leakage?”

I think I’ve settled on improving the logger we have better runtime redaction, with some compile time preventative measures to help move in the right direction over time. A separate, ideal logger for where we’d like to go. This includes helpers to verify we even have secrets in the first place, and if we do, we use a Parse, Don’t Validate + Anti-Corruption Layer in the same place via a Zod transform.

Brownfield: npm/pip update, you’ll be safer.

Brownfield + migrate: move to this logger, you can offload the problem to the compiler, but log sinks/targets/streaming outputs remain the same.

Greenfield: same

Auditing: With schema parsing, we can confidently know what secrets we have, where, and what combinations we’ve forbidden.

The escape hatches have been interesting too. Getting at your source logger, whether that’s AWS Power Tools, or Pino, or Winston or whatever is often needed to configure it, but if it’s done in more than 1 place, you should get nervous. So we have to provide the ability to do that, but also mark that we’ve done that. I can solve this with a Linter.

For the secrets, you need to provide access to them to do business logic, but sometimes you may have to do that in multiple places unlike log/metric/streaming configurations. I … don’t know how to solve this beyond having an LLM track the Branded type that comes out and doing it’s own audit.

Hard problems, lots of ways to approach it. While I’m having fun, I keep reminding myself why I’m doing this:

1. ensure we’re following the law
2. we won’t have any surprise security work to do
3. make this easy on developers now in Brownfield, and a “pit of success” for those in Greenfield

Still more to learn, but what a rabbit hole, man.

I wanted to cover how you’d do that in Linting because now that LLM’s are showing us how “fuzzy things can still give definitive steps to help, with options”

The cop-out is to be like “build it like Elm… I mean Rust even copied that style so it must be good”.

However, I’ve been reviewing JavaScript Linters lately, and the spectrum is pretty deep, but Flint in particular has a nice Elm-like error in interactive mode.

tl;dr; on Flint, it’s a hybrid JavaScript/TypeScript linter: the core and rules are written in TypeScript to make it easier to allow open source contributions, but plugins can be written in native code, like Biome/Oxlint are doing.

Here’s a screenshot attached of Flint finding a linting failure on a loop using for, citing what file, why the linter failed for this particular bit of code, a suggestion of what to do, and a link to learn more. That’s … amazing.

Now imagine if _every_ domain and infrastructure error you created had even one tenth of this meat embedded inside it, with ability to print for non-prod/local dev logging scenarios? Always inspiring to me to see how people interpret errors, specifically linter errors which can be quite fuzzy/squishy, open to interpretation, but need some kind of actionable step to fix it. I really like Flint’s approach here.

1. wrap native fetch with Neverthrow
2. provide nicer, Elm style return types
3. abstract away decoding/enoding for JSON
4. same, but for GraphQL + company’s rules around that

Learnings the past 3 days:

• Zod v3 to v4 has been a nightmare, so at first I just removed Zod and provided a decoder type interface instead b/c writing a Zod wrapper is like 1 line of code
• … but then I found out in v3.25.0 they name spaced the versions, making it easier for each to co-exist
• … so now I’m wondering if I should undo all my work of “abstracting away a Zod dependency
• but then I found out many are moving to Standard Schema and it’s not a too obtuse type to include, thus enabling me to be nice to ArkType and Effect-ts peoplez
• So now I think I can support Zod v4 internally, include an encoder interface for POST style operations, but still not exclude other schema libraries WHILE reserving the right to use Zod internally for various GraphQL schemas
• … but still requiring me to map those ZodErrors to my own type to not “leak Zod out”.

I really don’t like that last one. I may just not do it, install in a Zod v3 project, and “see what happens” in the unhappy paths.

Once done, I can wrangle the insane grossness that is Open Feature while dual-wielding Discriminated Unions of flame and frost brands.