DEV Community: Anika Jha

OBSERVE

Anika Jha — Fri, 09 Oct 2026 16:46:28 +0000

Your Neighborhood Is Already an Expedition

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

What I Built

The 20-20-20 rule says to look at something 20 feet away for 20 seconds every 20 minutes.

It doesn't mean you need to stare at your screen for 20 minutes, then book a trip to mountains 2,000 km away and climb 5,000 feet to finally touch grass.

You can start exploring right outside your door.

Meet OBSERVE : Look closer. Your neighbourhood is alive.

You don't need a forest, a hiking trail, or an expensive trip to discover something interesting. There are entire ecosystems hiding in the cracks of your neighbourhood.

OBSERVE turns an ordinary walk into a small expedition. It encourages you to notice things you would usually walk past: plants growing through concrete, birds on rooftops, insects near streetlights, the food being prepared at a local shop, something being repaired, or a small act of care happening around you.

Here's the catch: your phone is the notebook, not the experience.

Start an expedition, put your phone away, and observe the world. Come back to record what you noticed, save a field note, and reflect on it. You can also try Blind Walk prompts, document things that seem out of place, and revisit saved observations through Time Capsule.

OBSERVE is for anyone who wants to spend more time outside and pay closer attention to where they already live.

Demo

Live app: Observe

Code

GitHub repository: GitHub Repository

How I Built It

OBSERVE is built with React, TypeScript, Vite, and an Express backend. It uses browser storage for the field notebook, so the core experience doesn't depend on an AI service being available.

Gemma is an optional AI enhancement, not a requirement for using the app. When configured, it can help turn a completed expedition into a short reflection, identify a pattern in the user's written observations, and suggest a small observation quest for tomorrow. If AI is unavailable, the core journal experience can still work with a deterministic fallback.

I wanted the product to be useful before adding AI to it. The most important interaction isn't generating text — it's getting someone to put the phone away and pay attention to the world.

Why Does Open Innovation Matter?

An outdoor observation app shouldn't need a proprietary AI service just to help someone reflect on a walk.

Open-weight models like Gemma give developers room to experiment with how AI fits into their products, adapt prompts and outputs, and build optional AI experiences without making the entire application dependent on a closed model API.

It also makes the architecture more flexible: the field notebook and observation workflow remain useful without AI, while an open model can add another layer when it's available.

That distinction matters to me. AI should make the real-world experience richer, not give people another reason to stay glued to their screens.

And open innovation makes it easier for other developers to inspect the project, extend its ideas, and build their own versions for their neighborhoods.

My Agent Session

I used an agent-assisted development workflow to build OBSERVE, implement its core experiences, and refine the app. (Add a DevRelay agent session link here if you have one to share.)

Prize Categories

Render
Gemma (optional integration)

The goal is simple: close the app, step outside, and notice one thing you would have missed yesterday.

What is one thing in your neighborhood that you've walked past a hundred times without really noticing?

PantryPal

Anika Jha — Sun, 04 Oct 2026 13:57:01 +0000

Your kitchen, figured out.

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

"We have food at home."
❌ opens fridge
❌ opens pantry
❌ stares for 30 seconds
❌ orders food anyway

Too relateable right??

Let's change that
"We have food in the pantry."
✅ Okay. What can we make?

That tiny difference is basically why I built PantryPal for the Hacktoberfest Weekend Challenge: Build for a Friend.

What I Built

The challenge was to build something for a friend or loved one, so instead of starting with a cool technology and looking for a problem, I started by asking my friends:

And the perks of having foodie friends leads you to these:

One friend basically said:

"I want protein-rich meals, but I'm bored of eating the same things."

Another wanted:

"Can something please remind me before the food I bought becomes a science experiment?"

And another problem kept coming up:

"I have ingredients. I just don't know what to cook."

You know that feeling?
You bought curd last week because you were definitely going to eat healthier.
Now you're opening the fridge wondering whether the curd is still food or has started developing its own biodiversity.

Or maybe you're living alone with:

3 eggs
half an onion
some spinach
a questionable tomato
one pan
and absolutely no idea what to cook. And somehow, the answer is always the same five recipes you've already made a hundred times.

So I built PantryPal.

The idea is simple:

Tell PantryPal what you have → tell it what you want → get something you can actually cook.

You can add pantry items naturally:

"Bought 6 eggs and 250g spinach today."

PantryPal turns that into structured pantry information and keeps track of quantities, dates, freshness, and notes.

Then it answers the question that somehow gets harder every evening:

"What should I cook?"

Pick the ingredients you want to use, tell PantryPal what you're working with, and it generates multiple meal ideas around your real constraints.
Want:

something high-protein?
something quick?
Indian food?
Surprise?
something healthy?
one-pan only?
microwave only?
something different because you're bored of eating the same thing? PantryPal works around that.

You can also tell it:

Cuisine: Indian, International, etc.

Time: 10–60 minutes

Effort: Very easy → Challenge

Equipment: One pan, stovetop, microwave, air fryer, oven, etc.

Because if your entire kitchen is basically one pan, "use a blender and finish in the oven" isn't exactly helpful.

And then there's the food you forgot about.

This was another thing my friends wanted.

You know that ingredient you bought with a very specific plan?

And then completely forgot existed?

PantryPal keeps those dates visible and brings ingredients that need attention forward.

So instead of silently letting:

Tomatoes — Use by Oct 3

sit somewhere in your pantry...

it can say:

Check your tomatoes.
You marked them to expire yesterday.

Not:

"THIS FOOD IS DEFINITELY UNSAFE."

Just a useful nudge to check before you forget again.

Because sometimes the most useful AI isn't telling you something complicated.

It's telling you:

"Hey. The tomatoes."

What makes PantryPal different?

I didn't want to build another AI recipe generator.

There are already plenty of those.

The problem isn't:

"Can AI invent a recipe?"

The problem is:

"Can AI figure out what makes sense with the food, time, equipment and preferences I actually have?"

So PantryPal connects:

What I have
     ↓
What needs using
     ↓
What I want
     ↓
What equipment I have
     ↓
What can realistically be cooked
     ↓
Dinner

Instead of generating one random recipe, PantryPal generates multiple candidates and validates them against the user's constraints.

It also calculates a deterministic Meal Efficiency Score based on:

how much of the selected food gets used
how efficiently it fits the available cooking time
how well it covers the selected ingredients

The AI doesn't get to make up that score.

Demo

Live app: Pantry Pal

The demo shows the complete flow:

Add → Track → Decide → Cook → Remember

Add pantry ingredients in natural language
Edit quantities, dates and notes
See ingredients that need attention
Choose what you want to cook with
Select cuisine, goal, time, effort and available equipment
Generate multiple recipe ideas
Compare them
Enter Cook Mode
Save recipes and plan meals

Code

GitHub: Source Code

PantryPal is a full application rather than a static AI demo, with a frontend, backend API, structured AI generation, pantry logic, recipe validation, scoring, and recipe/planning flows.

How I Built It

The AI core of PantryPal is Gemma, specifically:

Gemma 4 26B A4B IT

I wanted the model to handle the messy, human parts of the interaction:

understanding natural-language pantry entries
generating recipes
adapting recipes to cuisines
suggesting substitutions
turning constraints into useful meal ideas

But I didn't want to ask the model to be the source of truth for everything.

The application itself handles:

pantry state
quantities
dates
freshness
equipment constraints
time constraints
recipe validation
recipe ranking
Meal Efficiency Score

So the architecture is roughly:

                 PANTRYPAL
                     │
          ┌──────────┴──────────┐
          │                     │
     Kitchen Logic           Gemma
     deterministic             AI
          │                     │
   dates / quantities     natural language
   freshness              recipe generation
   constraints             substitutions
   scoring                 cuisine adaptation
          │                     │
          └──────────┬──────────┘
                     ↓
              A meal you can make

Why Does Open Innovation Matter?

Using an open-weight model like Gemma made it possible to build the AI into the product, rather than just putting a chatbot next to it.

The interesting part isn't:

"Ask an AI for a recipe."

It's being able to take:

"I have eggs, spinach and half an onion, I want something high-protein, I have one pan, and I don't want to spend more than 20 minutes"

and turn that into a structured, validated kitchen decision.

Open innovation makes experimentation with that entire pipeline possible:

User context
     ↓
Open model
     ↓
Application logic
     ↓
Validation
     ↓
Personalized result

The model is one part of the product — not the product itself.

My Agent Session

I built PantryPal iteratively using DevRelay as an agent-assisted development workflow.

DevRelay helped me implement and refine features across the application, debug the Gemma integration, troubleshoot structured recipe generation and validation, improve the pantry and recipe flows, and test the complete application end-to-end.

I used the agent as a development partner rather than a one-shot code generator iterating through implementation, debugging, testing, and refinement until the application worked as a complete product.

Prize Categories

PantryPal uses a hybrid architecture:

Gemma for natural-language understanding and recipe generation
Node.js + Express for the application backend
MongoDB Atlas for production pantry and recipe data
HTML / CSS / JavaScript for the responsive frontend
Render for deployment

Built for a friend. Useful for anyone who has ever opened the fridge and immediately regretted it.

The funny thing about this project is that none of the original problems sounded like "AI problems."

One friend wanted more protein.

One wanted expiry reminders.

One was tired of cooking the same five meals.

Someone else just wanted to stop wasting groceries.

And underneath all of them was the same question:

"What am I supposed to do with all this food?"

So that's what PantryPal tries to answer.

We have food at home.

Now we also know what to do with it.

There's a meal in there.

🦇 The longest day of the year. The worst day to be a vampire. Race through June-inspired worlds, dodge sunlight, solve puzzles, and find your missing coffin before sunset in this whimsical browser adventure. ☀️ One day. ⚰️ One coffin. One very tired 🦇 .

Anika Jha — Fri, 19 Jun 2026 13:29:32 +0000

June Solstice Game Jam Submission

Anika Jha

Jun 18

Long Day, Tiny Vampire

#devchallenge #gamechallenge #gamedev #junesolsticegamejam

3 min read

Long Day, Tiny Vampire

Anika Jha — Thu, 18 Jun 2026 04:59:13 +0000

This is a submission for the June Solstice Game Jam

One day. One coffin. One very tired vampire.

Link for gameplay

(long-day-tiny-vampire)

What I Built

The longest day of the year.
The worst day to be a vampire.

🦇☀️⚰️

Long Day, Tiny Vampire is a browser game about a tiny vampire whose coffin gets accidentally shipped away during a series of June celebrations.

Now he's stuck outside on the June Solstice, desperately trying to get home before sunset.

Along the way, you'll:

🍣 Hide beneath giant sushi trays on International Sushi Day

🩴 Launch yourself across beaches during National Flip-Flop Day

🌈 Cross rainbow pathways created by music at a Pride Parade

🔐 Solve cryptic puzzles in an Alan Turing-inspired garden

☀️ Survive the Longest Afternoon, where shadows almost disappear

The goal? Get home. Try not to become ash.

Video Demo

Code

Built as a browser game so anyone can play instantly.
Check out the GitHub Repository

How I Built It

I wanted every level to feel like a completely different celebration rather than repeating the same platforming mechanics over and over.

Instead of designing five levels with the same gameplay, I built five different puzzle experiences connected by a single survival mechanic: sunlight.

The central system is the Dynamic Shadow System.

As the day progresses, the position of the sun changes, and shadows become smaller and smaller. Safe zones literally shrink as the player moves closer to the harshest part of the day. By the time players reach The Longest Afternoon, finding shade becomes a puzzle of its own.

Each celebration introduces a different style of interaction:

Sushi Day focuses on timing and moving shadows.
Flip-Flop Day uses physics-based traversal.
Pride Parade introduces chromesthesia-inspired puzzles where music paints the world with colour.
Turing's Garden focuses on pattern recognition and codebreaking.
The Longest Afternoon becomes a resource management challenge where every patch of shade matters.

To reinforce the feeling of a journey, I added several narrative systems:

Postcards left behind by the missing coffin.
Time-based dialogue from Nox and the Sun.
Solstice Memories hidden throughout the world.
Optional secret routes and alternate paths.

One of the biggest design goals was making the player feel the passage of time.

The game begins at sunrise.

The game ends at sunset.

Everything in between is a race against the longest day of the year.

Prize Category

Best Ode to Alan Turing

One of the game's major locations is Turing's Garden, a puzzle-filled maze inspired by Alan Turing's work in logic, cryptography, problem solving and Butterflies.

Players solve pattern-based challenges, decode encrypted notes, and uncover a hidden ending that celebrates curiosity, imagination, and the importance of being yourself.

Rather than treating Turing as a historical footnote, I wanted his influence to feel woven into the experience itself.

A hidden Alan Turing ending for players who collect every encrypted note!!

Best Google AI Usage

Google AI was used throughout the ideation and design process to explore gameplay concepts, refine puzzle ideas, shape narrative elements, and iterate on level design.

The game evolved from a simple "vampire versus sunlight" concept into a journey through June celebrations, blending storytelling, puzzle mechanics, and emotional progression into a cohesive experience.

Transfer Fees, Metadata, and Soulbound Tokens: My First Real Token Experiments on Solana

Anika Jha — Mon, 25 May 2026 08:45:14 +0000

Coming from a Web2 background, I thought tokens were basically just “crypto coins.”

After building on Solana for the past few days, I realised they’re closer to programmable economic systems.

In a single week, I created:

fungible tokens
tokens with on-chain metadata
protocol-level transfer fees
non-transferable “soulbound” tokens

And the craziest part?

Most of it required zero smart contract code.

Creating My First Token

The first time this clicked was when I ran:

spl-token create-token

That one command created a real token mint on Solana devnet.

Then I minted supply into my wallet:

spl-token mint <MINT_ADDRESS> 1000

At that moment, I had effectively created my own on-chain currency.

Not a database entry.
Not a mock project.
An actual blockchain asset.

Metadata Made Tokens Feel Real

Without metadata, tokens are just unreadable addresses.

Using Token-2022, I added:

a token name
symbol
metadata URI

spl-token initialize-metadata \
<MINT_ADDRESS> \
"ReinforceCoin" \
"RFC" \
"https://example.com/metadata.json"

That instantly made the token feel more like a real product instead of raw blockchain data.

Transfer Fees Were the Coolest Part

Then I experimented with transfer fees.

I created a token with a built-in 2% fee:

spl-token create-token \
--transfer-fee-basis-points 200

When I transferred 100 tokens, the recipient only received 98.

The remaining 2 tokens were automatically withheld by the protocol itself.

No backend.
No middleware.
No custom logic.

The blockchain enforced the economics.

That was the moment tokenomics finally made sense to me.

Soulbound Tokens Felt Like the Future

The most interesting experiment was creating a non-transferable token:

spl-token create-token \
--enable-non-transferable

I tried transferring it to another wallet.

The transaction failed instantly.

Not because my app blocked it —
because the token program itself rejected the transfer.

That immediately made me think about:

certificates
university credentials
attendance badges
KYC verification
reputation systems

All enforced directly on-chain.

What Surprised Me Most

The hardest part wasn’t the commands.

It was understanding Solana’s account model:

wallet addresses
mint accounts
token accounts
associated token accounts

I kept confusing them constantly.

But once that mental model clicked, the entire ecosystem started making sense.

Final Thoughts

Before this, blockchain development felt abstract.

Now it feels surprisingly practical.

I’m starting to see Solana less as “crypto” and more as infrastructure for programmable ownership, incentives, and identity.

And honestly?

Watching token economies work directly from the terminal was way more fun than I expected.

Why Solana’s Account Model Broke My Web2 Brain

Anika Jha — Tue, 19 May 2026 14:23:39 +0000

If you come from Web2, Solana’s account model feels weird at first.
You expect databases, backend servers, and application state living somewhere behind an API.

Instead, Solana gives you one core idea:

Everything is an account.

Wallets are accounts.
Programs are accounts.
Token balances live in accounts.
Even smart contract state is stored in accounts.

Unlike Ethereum, which separates wallets and contracts, Solana uses one flat account model for everything.

A Solana account has five main fields:

lamports → the SOL balance (1 SOL = 1 billion lamports)
data → raw bytes storing account state
owner → the program allowed to modify the account
executable → whether the account is runnable program code
rent_epoch → deprecated field related to rent collection

The biggest mental shift for me was understanding that:

Programs do not store their own state.

On Solana, programs are mostly stateless.
The executable code lives in one account, while separate data accounts store application state.

Coming from Web2, the best analogy I found is a filesystem:

Programs = executable binaries
Data accounts = files/databases
System Program = operating system kernel
Public keys = file paths

Programs simply read and write to accounts they are given access to.

Another interesting rule: only the owner program can modify an account’s data or debit lamports from it. But anyone can send lamports to an account. That ownership model is much simpler and stricter than traditional backend permission systems.

I also found Solana’s rent model surprisingly elegant. Accounts must maintain a minimum SOL balance proportional to their data size to remain on-chain. Instead of hiding storage costs behind infrastructure bills, Solana exposes them directly at the protocol level.

The coolest part is realizing how transparent the system is.
Using Solana Explorer or RPC calls, you can inspect accounts, transactions, balances, program interactions, and state changes in real time.

At some point it stopped feeling like “using a blockchain” and started feeling like debugging a distributed operating system.

Why Solana Transactions Feel More Like Database Commits Than API Calls

Anika Jha — Sat, 09 May 2026 14:35:25 +0000

The first time I sent a Solana transaction, I expected it to behave like a normal API request:

Send request → wait → success/failure.

But after debugging failed transactions on devnet, inspecting logs in Solana Explorer, and manually tracking confirmations, I realised Solana transactions behave much more like database commits than HTTP calls.

That mental model shift finally made blockchain development click for me.

A Solana Transaction Is More Than a Request

A transaction contains:

signatures (authorization)
instructions (operations)
account keys (state involved)
a recent blockhash (replay protection)

Unlike a typical API request handled by one server, every validator in the network verifies and executes the transaction independently before agreeing on the final state change.

That’s a completely different architecture from most Web2 systems.

Failed Transactions Taught Me the Most

What surprised me most was that failed transactions still exist on-chain.

Even when a transfer fails, the transaction can still:

have a signature
consume compute units
generate logs
charge fees

I intentionally triggered failed transactions on devnet and inspected them in Solana Explorer. Seeing execution traces and program logs for a failed transfer felt less like debugging an API request and more like analysing a distributed database operation.

Solana Transactions Are Atomic

This was another huge difference.

In Web2 systems, partial failures happen all the time. One service succeeds, another fails, and retries happen later.

On Solana, transactions are atomic:

Either every instruction succeeds
or the entire transaction rolls back

But validators still charge fees because the network still processes the workload.

That behaviour reminded me much more of SQL transaction commits than REST APIs.

Final Takeaway

The biggest challenge in learning Solana wasn’t the SDK or RPC calls.

It was changing how I think about state changes.

Once I stopped viewing transactions as API requests and started viewing them as signed, atomic, distributed state transitions, everything started making more sense.

And honestly, that shift is what makes blockchain development interesting in the first place.

From Skeptic to Builder: My First Two Weeks with Solana

Anika Jha — Sun, 03 May 2026 09:37:24 +0000

Coming into Solana, I expected blockchain development to feel abstract and overly complicated. I assumed everything would revolve around tokens, wallets, and buzzwords that sounded impressive but didn’t translate well into actual engineering. Week 2 changed that perspective completely.

The biggest shift happened when I started reading on-chain data directly. Querying a wallet balance through RPC and fetching recent transactions felt surprisingly familiar. It reminded me of calling APIs in traditional development, except the source of truth wasn’t a private backend server; it was a public network anyone could inspect. That was probably the first moment blockchain started to feel real to me.

Another concept that clicked was Solana’s account model. At first, hearing “everything is an account” sounded vague. But comparing it to databases helped a lot. Wallets, programs, and stored state all exist as accounts with owners, permissions, and data. Instead of rows in tables controlled by one company, the data lives on a distributed ledger. Once I looked at it through that lens, it became much easier to understand.

I was also surprised by how developer-friendly some of the tooling felt. Using JavaScript to connect to devnet, fetch balances, and build a small browser dashboard made Solana feel less intimidating. It wasn’t some unreachable ecosystem; it was something I could interact with using tools I already know.

What’s still confusing? Smart contracts/program architecture at scale, Program Derived Addresses, and how advanced apps structure state efficiently. I understand the basics now, but I know there’s another layer of depth ahead.

What I want to learn next is the write side of blockchain development: sending transactions, interacting with programs, and eventually building full dApps.

Two weeks in, my biggest takeaway is this: blockchain stopped feeling like hype and started feeling like infrastructure.

No Logins, No Passwords: How Identity Actually Works on Solana

Anika Jha — Sun, 26 Apr 2026 16:25:34 +0000

If you’re coming from Web2, identity typically refers to usernames, email addresses, and passwords stored in a database. You sign up, log in, and a platform tells the system who you are.

On Solana (and blockchains in general), that model doesn’t exist.

There are no usernames.
There are no accounts owned by platforms.
There is no central authority verifying identity.

Instead,

your identity is your keypair.

Identity = A Digital Signature

The way this clicked for me was thinking about real-world signatures.

When you sign a document:
Anyone can see your signature
But only you can create it

That’s what proves you authorised something.

Solana works the same way, just digitally.

Your private key = your ability to sign
Your public key = what others use to verify that signature

You don’t log into Solana.
You sign things, and the network verifies that signature.

No Usernames, Just Public Keys

Instead of usernames, you get something like this:

14grJpemFaf88c8tiVb77W7TYg2W3ir6pfkKz3YjhhZ5

This public key:

Is globally unique
Doesn’t require registration
Isn’t stored in someone else’s database You generate it locally, and from that moment on:

That key represents you everywhere on-chain.
No one issues it.
No one can take it away.

In Web2:

Platforms control your account
They can lock you out

On Solana:

Only your private key can authorise actions
No company sits in the middle

Ownership is cryptographic, not permission-based.

But there’s a tradeoff:
Lose your key → lose access
No recovery.

Every Action Is a Signature

When you:

Send SOL
Interact with a program

You’re doing one thing: Signing a transaction
The network verifies it and executes the action.
No sessions. No cookies. Just signatures.

How Apps Recognise You

Instead of “Sign in,” dApps use:
“Connect Wallet”
They read your public key and use that as your identity.
If needed, you sign a message to prove ownership.

Final Thought

The biggest shift is this:
In Web2, platforms give you identity.
In Solana, you own it.

Your wallet isn’t just a tool.
It’s your identity and your ability to prove it.

gh-excavate: Unearthing Code with GitHub Copilot

Anika Jha — Sat, 07 Feb 2026 17:16:59 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

Stuck with an unknown repository at 2 AM?
Accidentally deleted production code and trying to figure out what it even did?
Inherited a codebase with zero documentation?

We’ve all been there.

I built gh-excavate — an AI-powered GitHub CLI extension designed for code archaeology.

It’s a terminal-native assistant that helps you understand not just what code does, but why it exists.

Instead of manually browsing commits, scanning files, and piecing together context, you run a single command and gh-excavate digs through the repository for you.

It can:

Analyse a repository or folder to explain its purpose, architecture, and risks
Trace the life of a file from creation to deletion
Detect likely dead or forgotten code
Help investigate “why does this exist?” moments
Work on both local paths and remote GitHub repositories

The CLI handles the structure.
Git handles the history.
GitHub Copilot is the brain and soul of the operation, aka the reasoning engine.

Copilot synthesises context, interprets intent, and transforms raw code and git history into human-level explanations directly in the terminal.

gh-excavate doesn’t just read code.It interprets it.

Demo

Repository:
[gh-excavate](https://github.com/Anika-Jha/gh-excavate)

gh-excavate is a GitHub CLI extension. Once installed, it runs directly inside your terminal.

Installation

Verification

Commands

Example runs

My Experience with GitHub Copilot CLI

GitHub Copilot CLI fundamentally changed how I approached building this project.

Instead of relying on brittle heuristics and heavy parsing logic alone, I focused on designing meaningful prompts, extracting the right context from Git history, and structuring the CLI intelligently — while Copilot handled deeper reasoning.

Copilot became:

The interpretation engine
The architectural analyst
The technical historian
The context synthesiser

gh-excavate gathers the evidence — commit logs, file history, structural context. Copilot CLI connects the dots.

The most important realisation during development was this: the real problem isn’t accessing code — it’s understanding intent. Git tells you what changed. Copilot helps reason about why.

Working directly in the terminal with Copilot felt natural and developer-native. I could validate Git commands, reason about edge cases like file deletions, and refine workflows without leaving the CLI.

This project isn’t just about automation.
It’s about augmenting developer cognition.

Because when you're lost in a codebase, you don’t need autocomplete.

You need understanding.

Code ages. Context fades.
gh-excavate helps bring it back.

** When the git log gets cryptic, and production is on fire — excavate. Because “Who wrote this?” is not a strategy.**
**