To add basic logging at each major step of the pipeline — scrape started, change detected, extraction done, alert sent — instead of only adding print statements when something broke. Debugging reactively — only adding console logs after something failed, then removing them once it was fixed. Because when something goes wrong days later, I need to know exactly which step failed without having to reproduce the bug first — logs written in advance turn "something broke somewhere" into "step 3 failed for this specific reason." I assumed things will fail quietly at some point without me watching — a scheduled job especially, since nobody's staring at the terminal when it runs at 2am. A bit of extra code and slightly noisier output — but knowing exactly where and why something failed saves far more time than it costs to log it in the first place.

To write a short README explaining what the project does and how to run it, instead of assuming the code would explain itself . Skipping documentation since the code is readable and I'm the only one working on it right now. Because "the code explains itself" only works if you're looking at it while it's fresh in your head — a week later, even I won't remember why a decision was made unless it's written down somewhere outside the code . I assumed someone else — a reviewer, a future me, or a founder checking the repo — will judge the project faster from a clear README than from reading through every file to piece together what's going on. A bit of time that could've gone into more features — but a project nobody can quickly understand doesn't get evaluated fairly, no matter how good the code actually is.

To go back through my own code a day after finishing a feature, instead of considering it done the moment it worked. Moving straight to the next feature as soon as the current one worked, without revisiting it. Because code that works right after writing it often has shortcuts or clever tricks that only make sense to me in that moment — coming back a day later shows me what's actually confusing or overcomplicated, before someone else has to deal with it. I assumed that "it works" and "it's actually finished" aren't the same thing — and that the gap between them only shows up once I'm not staring at the code I just wrote . Some time that could've gone straight into building the next feature — but simplifying three overcomplicated spots today probably saves more time later than moving on would have.

To profile the app first and only optimize the specific parts that were actually slow, instead of adding memoization and other optimizations everywhere just to be safe. Adding performance optimizations broadly across the codebase from the start, without checking whether they were actually needed. Because optimizing code that wasn't actually slow just adds complexity without any real benefit — profiling first meant I only touched the parts that genuinely needed it, and left the rest simple and easy to read. I assumed most of the app would run fine without special optimization, and that guessing which parts are "probably slow" is usually wrong until you actually measure it. The feeling of having "optimized everything" upfront — it's slower to add performance improvements only when needed, but it keeps the codebase simpler until there's real proof something needs fixing.

To write a few tests for the core pipeline logic — the hashing and change-detection functions — instead of skipping tests entirely since this is a solo MVP project. Skipping tests altogether since it's a small project built solo, and just checking manually whenever something looked off. Because the core logic — deciding whether something actually changed — is exactly the part that breaks silently if I refactor it later, and a test catches that immediately instead of me finding out days later when a real update gets missed. I assumed not every part of the app needs tests equally — the parts other things depend on (like change detection) matter more than UI code that's obvious when it's broken just by looking at it. Speed early on — writing tests took extra time upfront instead of just moving straight to the next feature, but it means I can change this logic later without wondering if I silently broke it.

To keep all secrets — API keys, bot tokens, database URIs — in environment variables loaded from a .env file, instead of writing them directly into the code. Hardcoding the actual tokens and keys directly into the source files, since it's faster to just paste them in and get things running. Because a hardcoded key gets committed to version control and exposed the moment the code is shared or pushed anywhere — keeping them in .env means the secrets stay local and the code itself is safe to share. I assumed I'll want to share this project, deploy it, or show the code to someone at some point — so treating every credential as sensitive from day one is safer than fixing it after something leaks. A tiny bit of convenience — now I have to set up a .env file and remember to fill it in wherever the project runs, instead of the code just working the moment it's copied anywhere.

to wrap every external call in the pipeline — scraping, Claude API, Telegram, database — in its own try/catch, so one failing source never stops the others from being checked.riting one big try/catch around the whole pipeline run, so any single failure would stop the entire job for all sources.Because if SSC's site is down or Claude's API rate-limits for a moment, I still want RRB and every other source to get checked that cycle — one broken piece shouldn't take down the whole system.I assumed government sites and external APIs will fail sometimes just from normal instability, so the pipeline needs to expect and survive that, not just handle the happy path.A simpler, shorter error-handling setup — wrapping each step individually means more code and more places to log errors, but it means a partial failure stays partial instead of becoming a total one.

to build and test every piece of the pipeline logic — hashing, module loading, Claude response parsing — using mocked data before connecting any real API keys or database

to add inline validation as the user types for the fields that matter most, instead of only validating on submit Only validating when the form is submitted, and showing all errors at once at the end. Because catching mistakes early prevents a wall of errors appearing all at once at the end, and it's less frustrating for whoever's filling out the form.

today i haven't done anything

I picked connecting the repo to auto-deploy on every push over deploying manually whenever I remembered to because manual deploys mean it's easy to forget to ship the fix that actually mattered

I picked committing in small, specific chunks with clear messages over committing everything at the end of the day in one big commit because small commits make it possible to actually find and undo the exact change that broke something, instead of guessing

I picked tracing the bug back to where the data first went wrong over patching the symptom where it showed up on screen because fixing where it appears usually just hides the real problem, and it comes back in a different form later

I picked building one central function to handle all API calls over writing separate fetch calls inside each component that needed data because if the API changes later, I only have to update it in one place instead of hunting through every component that calls it

I picked setting up the folder structure and planning how components would connect before writing any UI over starting with a component and figuring out structure as I went because building screens before deciding the structure means rebuilding them later once the real structure becomes clear

I flagged The job search is exhausting right now. Rejections come fast. Roles disappear after you've put in the work. You send emails and wait. You show up every day and the silence on the other side doesn't match the effort on yours. I'm flagging this not to complain — but because pretending it's fine when it isn't is exactly what this log is supposed to avoid. because The job search is exhausting right now. Rejections come fast. Roles disappear after you've put in the work. You send emails and wait. You show up every day and the silence on the other side doesn't match the effort on yours. I'm flagging this not to complain — but because pretending it's fine when it isn't is exactly what this log is supposed to avoid.

I learned that high agency means acting on gaps, not just naming them from seeing my own entries in the What High Agency Looks Like feed todayOpened Proof today and saw both my entries featured under "What High Agency Looks Like." That's not something I expected. But reading RK's notes again, I realised the pattern he's picking up on isn't the technical content — it's that I named what I skipped and said what I'd do next. I actually did those things. Docker to Render, JWT gateway, refresh tokens, ReAct pattern. Each day I said tomorrow I'll do X — and I did. That's what high agency means. Not knowing everything. Acting on the gap you just named.

how I look at code I've already written because writing forces you to name decisions you made by reflex — and named decisions are ones you can improveTen days ago I thought knowing how to build something was enough. I had three projects, a working MERN stack, a Gen-AI platform with LSTM — and I couldn't explain a single decision I made while building them. I just built. Docker was there because tutorials used it. JWT was there because auth needed it. The LLM was there because the project needed AI. No reasoning. Just pattern copying. These 10 days changed that. I now know why Docker and Render coexist in my repo. I know why JWT verification belongs at the gateway not inside each service. I know the difference between an LLM that generates and an agent that reasons. I know why latency matters more than accuracy in production. None of this came from studying harder. It came from writing it down and asking why — every single day

Read about evals today but didn't go deep — skimmed more than studied. What I did pick up: evals are how you know if your agent is actually working or just appearing to work. Without evals you're guessing. You run the agent on test cases, check the outputs, and score them — either against expected answers or using another LLM as a judge. I decided to understand this over skipping it entirely because yesterday I realised I don't know how Omnisavant would know if their onboarding agent is doing the right thing. Evals are the answer. I just don't fully understand them ye over skipping evals entirely and assuming the agent works because you can't trust a system in production if you have no way to measure if it's right

Read about low latency LLMs today — specifically why Omnisavant's job description mentions R&D on them. The core insight: smaller models are faster because they have fewer parameters to compute per token. A 7B model responds in milliseconds where a 70B model takes seconds. For a customer onboarding agent that needs to scrape docs, generate demos, and respond in real time, latency isn't a nice-to-have — it's the product. A slow agent feels broken even if the answer is correct. I decided to understand this over skipping it because I kept thinking LLM quality = bigger model. That's wrong for production. The right model is the smallest one that's good enough for the task over always using the biggest most capable model because production agents need speed, not just accuracy — a slow agent feels broken

Studied the ReAct pattern in LangChain today. ReAct = Reason + Act. The LLM doesn't just generate an answer — it first reasons about what it needs, decides which tool to call, calls it, reads the result, then reasons again. It loops until it has enough to answer. I decided to understand this over just using LangChain as a black box because my GenAI platform calls an LLM once and stops — I needed to know what I was missing. What I was missing is the loop. My platform generates. An agent equipped with ReAct thinks, acts, checks, and repeats. That's the gap between what I built and what Omnisavant actually needs over using LangChain without understanding how it works because I needed to know what my GenAI platform is missing before I can improve it

the difference between an LLM generator and an LLM agent from my GenAI platform code and LangChain docsWent back into my GenAI assessment platform today. I expected to find a simple LLM call — send prompt, get answer. It's more layered than that. There's prompt construction logic, LSTM predictions feeding into the prompt, and response parsing after. But it's still not an agent — it calls the LLM once and stops. No tools, no looping, no decision about what to do next. I also read about LangChain agents today. The difference is clear now: my platform uses the LLM as a generator. An agent uses the LLM as a reasoner — it decides what action to take, calls a tool, checks the result, and loops until the task is done. I built something smart but not something that acts

Wrote the refresh token logic today — when the access token expires, the client now automatically sends the refresh token, gets a new access token, and retries the request. The user never sees a 401. I also spent time understanding what an LLM agent actually is. A normal LLM just responds to input. An agent has tools it can call, loops until the task is done, and acts instead of just answering. The gap between "I can use an AI API" and "I can build an agent" is the difference between giving someone a brain and giving them hands. That clicked today from

Traced how my API Gateway handles JWT today. The gateway receives the request, pulls the token from the Authorization header, verifies the signature using the secret key, and only then forwards the request to the right microservice. If the token is invalid it never reaches the service at all. I wrote this code months ago but I was thinking of it as "authentication middleware" — today I understood it's actually a bouncer at the door, not a check inside the room. The decision to verify at the gateway level instead of each service was the right one — because if each service verified tokens independently, a bug in one service's auth logic could expose all the others. One gate is easier to secure than six. I just didn't know why until now over each service checking its own token because one gate is easier to secure than six

from Opened my docker-compose.yml properly today instead of just running it. Each service is its own container — they share a network so they can talk to each other by service name, not localhost. The depends_on field is what I was copying blindly — it just controls startup order, not whether a service is actually ready. That's why I had race condition bugs early on. I fixed them by adding retries but never knew why they were needed. Now I d

over because I had both docker-compose.yml and render.yaml in my e-commerce repo. I thought they were alternatives — pick one. Today I realised they solve different problems. Docker because I needed all 6 services to run identically on my machine without "works on my laptop" issues. Render because I didn't want to manage servers in production. The decision was always there — I just never named it while buildin

I've been building projects — MERN microservices, ML pipelines, a GenAI assessment platform — but I realised today I've been listing what I built more than understanding why I made each call. Like, I used Docker Compose for the e-commerce platform. But if you asked me right now why Docker over just deploying directly on Render — I'd stumble. That's the gap I'm starting to close.