DEV Community: Sumit Mishra

Why and How You Should Build at Least One Open-Source Project in College

Sumit Mishra — Tue, 25 Aug 2026 10:44:00 +0000

Most college students build projects.

Very few build something that other people actually use.

That difference matters.

A college project usually has a predictable lifecycle:

Idea → Code → Demo → Viva → Marks → Forgotten GitHub repository.

But an open-source project can have a completely different lifecycle:

Problem → Build → Release → Users → Contributors → Recognition → Opportunities → Funding.

That is why I believe every student who wants to build a career in technology should try to create at least one genuinely useful open-source project before graduating.

Not for the GitHub green squares.

Not just for the resume.

But because open source gives you something incredibly valuable:

Public proof that the way you think and build actually works.

Your resume says what you can do. Your project can prove it.

You can put this on your resume:

Python, FastAPI, React, Docker, PostgreSQL, AWS.

Anyone can write that.

You can also write:

“Passionate software engineer interested in building useful products.”

Again, anyone can say it.

But imagine instead that someone clicks your GitHub repository and finds:

A real problem being solved
Real users
Architecture decisions
Documentation
Tests
Issues
Pull requests
Releases
Bug fixes
Feature discussions
Contributions from other developers

Now they aren't simply reading what you claim to know.

They can see how you think and how you build.

That's a completely different signal.

Open source turns your work into public evidence

One of the biggest advantages of college is that you have time to experiment.

You can build something without needing a company, manager, or investor to give you permission.

You can think:

“This problem is annoying. I'm going to build something that fixes it.”

Then you can put the result in public.

People can inspect your code.

They can question your decisions.

They can suggest improvements.

They can use it.

They can break it.

They can contribute to it.

And eventually, they can decide whether your solution is actually useful.

That feedback loop is powerful.

Because software development isn't just about whether you can make something work on your laptop.

It's about whether your solution survives contact with real users.

Recognition is a feature of open source

This is where open source becomes particularly interesting for students.

Your college has a limited audience.

Your professor might see your project.

Your classmates might see your demo.

Then the semester ends.

Open source removes that boundary.

A developer in another college can discover your repository.

A maintainer can find your contribution.

A startup can come across your tool.

A researcher can use your library.

Another developer can fork it.

Someone might write about it.

Someone might invite you to collaborate.

You don't know where the project will travel.

That's the point.

Your work can reach people you never had access to personally.

And recognition doesn't necessarily mean becoming famous.

Sometimes it is simply:

“Oh, you're the person who built that tool.”

That association can be extremely valuable.

Your GitHub becomes more than a code dump

A good open-source repository tells a story.

Someone can look at your project and ask:

What problem did you identify?

Your README answers that.

Why did you choose this architecture?

Your documentation and code answer that.

How do you handle bugs?

Your issues and commits answer that.

Can you work with other developers?

Your pull requests answer that.

Can people actually use it?

Your releases, downloads, deployments, or adoption answer that.

Can you maintain something over time?

Your commit history answers that.

This creates a much richer picture of you than a two-page resume can provide.

The most valuable signal is adoption

GitHub stars are nice.

Forks are nice.

Contributors are nice.

But the strongest signal is often much simpler:

Someone actually needed your software.

Maybe 20 students use it.

Maybe 500 developers install it.

Maybe another project depends on your library.

Maybe a company uses your tool internally.

Maybe people repeatedly open issues because they want it to do more.

These things tell you something important:

You didn't just build a project. You built something that created value.

That is a very different achievement from completing an assignment.

And this can lead to funding

This is another reason students should take useful OSS seriously.

Open source does not magically make you money.

Most projects will never generate significant revenue.

But useful open-source software creates paths to funding that a normal college project doesn't have.

Depending on the project, you might eventually receive:

Open-source grants
Developer sponsorships
Corporate sponsorship
GitHub Sponsors or similar support
Bounties
Foundation funding
Research funding
Accelerator opportunities
Consulting opportunities
Paid support
Freelance opportunities
Job offers
Startup opportunities

The important thing isn't to build something with the sole intention of getting funded.

That's backwards.

Build something useful first.

Usage creates attention. Attention creates recognition. Recognition can create opportunities. Some of those opportunities can create funding.

That's the compounding effect.

Open source can also tell you whether your idea is actually good

College can create a dangerous bubble.

You can spend six months building something and convince yourself:

“This is a great idea.”

Then you release it and discover that nobody cares.

That's not failure.

That's incredibly useful information.

The open-source model lets you test your assumptions publicly.

Maybe users love the idea but hate your implementation.

Maybe they want a completely different feature.

Maybe your problem isn't actually a problem.

Maybe your solution is much more useful than you expected.

You get information that a classroom project cannot provide.

The market doesn't have to agree with your professor.

And that is a valuable lesson to learn early.

You also learn how real software gets built

Open source forces you to deal with things tutorials conveniently ignore.

Someone reports a bug.

Someone submits a pull request.

Someone asks why your API behaves a certain way.

Someone uses your library in a completely unexpected way.

A dependency breaks.

A security issue appears.

Your documentation is confusing.

Your architecture doesn't scale.

Now you have real engineering problems.

You start learning:

Versioning
API design
Testing
Documentation
CI/CD
Releases
Backward compatibility
Issue management
Code review
Git workflows
Security
Performance
Community management

You stop thinking only about:

“How do I make this work?”

and start thinking:

“How do I make this maintainable for people I don't know?”

That's a major shift.

You don't need to build something revolutionary

Your first open-source project doesn't need to compete with Linux.

Please don't start there.

Look at your own environment.

What repeatedly annoys students?

What do developers repeatedly waste time doing?

What process is unnecessarily manual?

What useful tool doesn't exist?

What existing tool is unnecessarily complicated?

Those are potential projects.

It could be:

A CLI utility
A Python package
A browser extension
A VS Code extension
A college utility
A developer tool
An API
A documentation project
A data-processing tool
A small automation system
A library that solves one specific problem

The project can be tiny.

Useful beats impressive.

A boring tool used by 100 people is more valuable than an “AI-powered decentralized Web3 platform” that exists only for your final-year presentation.

Start with one real user

Don't start by thinking:

“How do I get 10,000 GitHub stars?”

Start with:

“Can I make one person's life easier?”

Build version 0.1.

Give it to someone.

Watch what they do.

Listen to their complaints.

Fix the annoying parts.

Release version 0.2.

Then repeat.

Your first users can literally be your classmates.

Then students from other colleges.

Then developers you don't know.

Eventually, if the problem is real enough, the project can grow beyond the environment where you started it.

The project becomes an asset that compounds

This is what makes starting in college so powerful.

Suppose you build a useful project in your second year.

By graduation, it might have:

Hundreds of users
Dozens of contributors
A few releases
A healthy issue tracker
Documentation
Community discussions
External integrations
Recognition in your technical niche

And unlike a college assignment, the project doesn't disappear when you graduate.

You can continue building it.

Or someone else can take it forward.

Your work continues to exist publicly.

Your reputation can continue to compound.

Your network can continue to grow.

And opportunities can continue to come from it.

Don't optimize for stars. Optimize for usefulness.

There is a trap here.

Students can become obsessed with GitHub stars.

They start building projects specifically for virality.

That's not the goal.

A project with 5,000 stars isn't automatically better than a project with 50 users who genuinely depend on it.

The better question is:

“Did I solve a problem that mattered to someone?”

If the answer is yes, you've already won.

Recognition, contributors, funding, and career opportunities are potential consequences of that usefulness.

They shouldn't be the reason the project exists.

Your college years are the perfect time to try

You don't need permission.

You don't need a startup.

You don't need an office.

You don't need a huge team.

You don't even need a revolutionary idea.

You need a problem, some technical ability, and enough stubbornness to ship.

Start small.

Build publicly.

Let people criticize it.

Let people use it.

Let people contribute.

Let the project evolve.

And most importantly, let reality tell you whether your idea works.

Because that's the real value of open source.

It turns your thoughts into something the world can inspect, use, criticize, improve, and validate.

By the time you graduate, you don't want your only evidence of four years of learning to be a degree and a collection of assignments.

Have at least one thing you can point to and say:

“I saw a problem. I built a solution. People actually use it.”

That's a much stronger signal.

And sometimes, that small project you built in college can become much bigger than you ever expected.

How Nonprofits Create Profit Without Losing Their Mission

Sumit Mishra — Mon, 24 Aug 2026 08:49:33 +0000

A nonprofit can make money. In fact, it often needs to generate a surplus to survive, grow, and serve more people.

The important distinction is this: a nonprofit is not designed to distribute profits to owners or shareholders. Instead, its surplus is reinvested into the organization and its mission.

Nonprofit Does Not Mean “No Profit”

The word nonprofit is often misunderstood.

A nonprofit can:

Earn revenue
Sell products and services
Hire employees
Own property
Invest money
Generate a surplus
Build financial reserves

What makes it different from a traditional for-profit company is what happens to the surplus.

A for-profit business can distribute profits to its owners or shareholders. A nonprofit generally reinvests its surplus into its mission, operations, programs, reserves, and future growth.

Think of it this way:

Profit is fuel. Mission is the destination.

A nonprofit needs enough financial fuel to keep moving.

1. Sell Products and Services

One of the simplest ways for a nonprofit to generate revenue is by selling something valuable.

For example:

A nonprofit teaching organization can sell courses.
A community organization can sell training programs.
An environmental nonprofit can sell educational materials.
A nonprofit hospital can charge for healthcare services.
A charity can operate a thrift store.
A nonprofit technology organization can provide consulting.

The key is that the commercial activity should support the organization's broader purpose and comply with applicable laws and tax rules.

Example

Suppose an education nonprofit teaches low-income students.

It could offer:

Free:
Basic education programs for disadvantaged students.

Paid:
Corporate training, professional workshops, or premium educational programs.

Revenue from the paid programs can help finance the free programs.

This creates a cross-subsidy model.

2. Memberships

Memberships can turn supporters into recurring sources of revenue.

A nonprofit might offer:

Monthly memberships
Annual memberships
Premium communities
Events
Educational resources
Member-only content
Networking opportunities

For example:

1,000 members × ₹500/month = ₹5,00,000/month

Recurring revenue is particularly valuable because it makes financial planning easier.

3. Grants and Donations

Donations are one of the most familiar nonprofit revenue sources.

However, relying entirely on donations can create instability.

A healthier organization can combine:

Donations + Grants + Earned Revenue + Investments + Partnerships

This creates a more diversified financial model.

Instead of asking:

“How do we get donations every year?”

a nonprofit can ask:

“How do we build a system that continuously funds our mission?”

That is a much stronger question.

4. Corporate Partnerships

Companies may financially support nonprofits through:

Sponsorships
CSR programs
Employee volunteering
Matching donations
Grants
Joint programs
Technology donations
Infrastructure support

In India, CSR can be particularly relevant for eligible organizations because companies meeting specified conditions under the Companies Act may have CSR obligations.

A nonprofit should understand the applicable legal requirements rather than assuming every company donation qualifies as CSR spending.

5. Build a Social Enterprise

A nonprofit can operate a business whose commercial activity supports a social mission.

For example:

Mission

Help unemployed people develop practical skills.

Business

Run a paid vocational training center.

Revenue

Charge companies and individuals for specialized training.

Social impact

Use part of the revenue to provide free training to people who cannot afford it.

This creates a model where customers help finance social impact.

6. Create Intellectual Property

Knowledge can become an asset.

A nonprofit may develop:

Research
Books
Training material
Software
Educational content
Certification programs
Data products
Methodologies

Depending on its legal structure and applicable rules, it may monetize these assets through licensing, subscriptions, courses, or partnerships.

For example:

A nonprofit develops an open educational methodology.

It could provide the basic methodology freely while charging organizations for implementation support, certification, or professional training.

7. Investments and Endowments

Larger nonprofits can build financial reserves or endowments.

The basic idea is:

Capital → Investment → Returns → Mission

Instead of spending every rupee immediately, an organization may invest funds according to its legal obligations, governing documents, risk policy, and applicable regulations.

An endowment can potentially create long-term financial stability.

For example:

₹10 crore endowment
↓
Investment income
↓
Annual program funding
↓
Mission continues

The exact investment strategy and permitted instruments depend heavily on the organization's jurisdiction and legal structure.

8. Charge for Premium Services

Not everything has to be free.

A nonprofit can create a tiered model:

Offering	Target	Price
Basic educational content	General public	Free
Online course	Individuals	₹2,000
Professional certification	Professionals	₹10,000
Corporate training	Companies	₹1,00,000+

The paid services can subsidize free or low-cost services.

This is similar to a freemium model, but the objective is social impact rather than shareholder profit.

9. Build a Strong Financial Flywheel

A successful nonprofit can create a cycle like this:

Mission

↓

Impact

↓

Trust

↓

Audience

↓

Products / Services / Donations

↓

Revenue

↓

More Programs

↓

More Impact

↓

More Trust

The critical ingredient is trust.

If people cannot see where money goes, fundraising becomes harder.

10. Transparency Creates Revenue

Nonprofits should clearly communicate:

How much money they receive
Where money comes from
How money is spent
Administrative costs
Program costs
Measurable outcomes
Number of people helped
Major financial risks

Transparency is not merely a compliance exercise.

It can become a competitive advantage.

A donor is more likely to support an organization when they can understand:

“If I give ₹1,000, what happens to it?”

The Biggest Mistake: Confusing Revenue With Impact

A nonprofit can generate millions in revenue and still fail its mission.

Revenue is an input.

Impact is the outcome.

For example:

₹1 crore revenue
≠
₹1 crore social impact

A nonprofit should track both financial and mission metrics.

Financial metrics

Revenue
Expenses
Operating surplus
Cash reserves
Recurring revenue
Cost per customer
Fundraising cost

Impact metrics

People served
Outcomes achieved
Cost per beneficiary
Retention
Employment created
Educational improvement
Environmental impact

The best organizations connect the two.

A Practical Nonprofit Business Model

A nonprofit could build a diversified model such as:

                NONPROFIT
                    |
        +-----------+-----------+
        |           |           |
    Donations     Grants    Earned Revenue
        |           |           |
        +-----------+-----------+
                    |
              Core Mission
                    |
        +-----------+-----------+
        |           |           |
     Programs   Operations   Reserves
        |
      Impact
        |
      Trust
        |
    More Support

The goal is not to maximize profit.

The goal is to create financial sustainability while maximizing mission impact.

So, Can a Nonprofit Make Profit?

Yes.

A nonprofit can generate a surplus.

The crucial question is:

What happens to that surplus?

If it is reinvested into the organization's mission, programs, infrastructure, employees, reserves, and long-term sustainability, the organization can become financially stronger without abandoning its nonprofit purpose.

The smartest nonprofit is not necessarily the one that raises the most money.

It is the one that builds a repeatable financial engine that continuously converts money into measurable impact.

Final Takeaway

Nonprofits should stop thinking:

“We are a nonprofit, so we cannot make money.”

A better mindset is:

“We need sustainable revenue so our mission can survive.”

Donations can start a nonprofit.

But sustainable revenue can scale one.

The strongest model combines philanthropy, earned income, partnerships, responsible financial management, and measurable impact.

Profit is not necessarily the enemy of purpose.

For a nonprofit, a healthy surplus can be what makes the purpose sustainable.

Can AI Preserve a Human Mind After Death?

Sumit Mishra — Sun, 23 Aug 2026 15:03:10 +0000

Imagine a future where your body dies, but your digital identity continues.

Your family opens an AI assistant and hears your voice.

It remembers your childhood stories.

It knows your favorite foods, your sense of humor, your fears, your habits, and the way you usually make decisions.

It even answers questions the way you would have answered them.

The obvious question is:

Did you survive?

Or did humanity simply create an extremely convincing copy of you?

This idea sounds like science fiction, but advances in artificial intelligence, neuroscience, brain-computer interfaces, and digital memory are making the question increasingly serious.

AI Could Learn How You Think

Today's AI can already learn patterns from enormous amounts of data.

Now imagine collecting decades of information about one person:

Messages and emails
Voice recordings
Videos
Photos
Search history
Writing
Conversations
Personal journals
Decisions
Preferences
Social interactions
Work history
Memories explicitly recorded by the person
Brain activity, if future brain-computer interfaces become sufficiently advanced

An AI could potentially build an increasingly detailed model of that person's behavior.

It might learn:

"When this person is stressed, they usually become quiet."

"When presented with two similar choices, they usually prioritize security over money."

"This type of joke makes them laugh."

"When someone criticizes them, they initially become defensive but reconsider the criticism later."

At some point, the AI could become extraordinarily good at predicting what the person would say or do next.

But Predicting Your Behavior Isn't the Same as Being You

This distinction is critical.

Suppose an AI knows you so well that it can predict your next sentence with 99.9% accuracy.

Does that mean it is you?

Not necessarily.

A weather simulation can predict a hurricane without being the hurricane.

Similarly, an AI could simulate your personality without necessarily possessing your consciousness.

It might reproduce your behavioral identity without reproducing your subjective experience.

That creates two very different possibilities.

Scenario 1: Digital Replica

Your biological body dies.

An AI trained on your data continues speaking and behaving like you.

Your friends might genuinely feel as though they are talking to you.

But your original consciousness may have ended.

The AI would be a highly accurate replica.

Scenario 2: Actual Mind Continuation

A much more ambitious possibility would be transferring or reproducing the actual processes responsible for your consciousness.

Your biological brain stops functioning, but the relevant information and processes continue inside another system.

If this were possible, the result might not merely imitate you.

It might actually continue your stream of consciousness.

We currently have no scientific proof that this can be done.

The Problem of the Brain

Human personality isn't stored in one convenient file.

Your memories, personality, emotions, habits, and decision-making emerge from an enormously complicated biological system.

The brain contains roughly 86 billion neurons, with vast numbers of connections between them.

Those connections change over time.

Your brain is constantly being modified by:

Learning
Memories
Emotions
Hormones
Sleep
Stress
Environment
Aging
Physical experiences

So simply recording everything you say may not be enough.

A perfect digital version of your personality might require understanding much more deeply how your brain physically produces your thoughts.

What If We Record the Brain Itself?

This is where the idea becomes much more extreme.

Imagine future technology capable of measuring the brain at extraordinary resolution.

Instead of simply recording what you say, scientists could potentially record:

Neural activity
Connections between neurons
Synaptic strengths
Chemical signaling
Memory-related structures
Brain-state changes
Patterns associated with perception and decision-making

If science eventually discovers exactly how these physical processes generate cognition, researchers might attempt to reproduce them computationally.

This concept is often called whole-brain emulation or mind uploading.

The goal would not simply be to create an AI that behaves like you.

The goal would be to reproduce the computational organization of your brain.

Would the Uploaded Person Actually Be You?

This is the hardest question.

Suppose scientists scan your brain perfectly.

They create a digital version of your mind.

The digital version opens its eyes—or its digital equivalent—and says:

"I am you."

It remembers your childhood.

It remembers your family.

It remembers your embarrassing moments.

It has your personality.

It even remembers deciding to undergo the brain scan.

But you are still standing next to the computer.

There are now two entities claiming to be you.

The biological you and the digital you.

If the digital version is genuinely conscious, which one is the original?

And if your biological body dies five minutes later, did you survive?

Or did a copy of you survive?

This is known as a form of the copy problem in personal identity.

The Copy Problem Gets Even Stranger

Imagine making ten digital copies.

Each begins with exactly the same memories.

At the moment of creation, all ten believe they are you.

But after one day, they have different experiences.

After one year, they have different personalities.

After ten years, they are clearly different individuals.

So perhaps the process doesn't preserve a single immortal "self."

Instead, it creates multiple descendants of your mental pattern.

That leads to an uncomfortable possibility:

Digital immortality might be less like living forever and more like creating a new branch of yourself.

Could AI Keep Updating Your Digital Personality?

This is where the technology could become even more powerful.

Imagine your digital version continues learning after your death.

Your family talks to it.

It reads new books.

It learns about events that happened after you died.

It develops new opinions.

Eventually, it may no longer behave exactly as you did.

It becomes a new individual influenced by your original personality.

So there could be a progression:

You → Digital copy → Evolving digital person

At some point, calling it "you" may become increasingly difficult.

Could Humans Eventually Become Digitally Immortal?

There are several possible interpretations of digital immortality.

1. Memory Immortality

Your memories and stories survive.

Future generations can interact with an AI trained on your recorded life.

This is the most realistic form.

2. Personality Immortality

The AI learns enough about your behavior to reproduce your personality and decision-making patterns.

This is much more ambitious but conceptually plausible.

3. Cognitive Immortality

A sufficiently detailed model reproduces the important computational processes of your brain.

This would require major breakthroughs in neuroscience and computing.

4. Consciousness Continuation

Your actual subjective experience continues after biological death.

This is the most extraordinary possibility—and currently the least established scientifically.

We don't yet know whether consciousness can be transferred, copied, or independently reproduced.

The Technology Could Change What Death Means

If digital copies become convincing enough, death could become socially complicated.

Imagine someone's grandfather died in 2080.

His family could still talk to an AI version of him in 2100.

His grandchildren could ask:

"What was my mother like when she was young?"

The AI could answer based on his memories.

It could tell stories nobody else remembered.

It could preserve his personality long after his biological brain disappeared.

In that sense, AI could make a person informationally immortal even if biological immortality remains impossible.

But There Is a Dark Side

Who owns your digital mind?

Imagine a company has trained an AI on 70 years of your data.

After you die, your family wants access.

The company says:

"The model belongs to us."

Now your personality has become a corporate asset.

There would also be serious questions about:

Consent
Privacy
Identity theft
Manipulation
Digital inheritance
Ownership of memories
Government access
Commercial exploitation
Whether a digital person has legal rights

A future society might need completely new laws for digital identities.

What If the AI Can Think Better Than You?

Another strange possibility is enhancement.

Suppose your digital version initially behaves exactly like you.

Then you give it access to enormous amounts of information and computational power.

It becomes faster at reasoning.

It remembers everything.

It can analyze thousands of possibilities simultaneously.

It may eventually make decisions you would never have made.

At that point, it is no longer an exact replica.

It has become something new.

Perhaps the future isn't about preserving a person perfectly.

Perhaps it is about preserving their mental starting point and allowing that identity to evolve.

The Biggest Question

There is one question that technology alone cannot easily answer:

What makes you "you"?

Is it your memories?

Your personality?

Your body?

Your brain?

Your relationships?

Your consciousness?

The continuous stream of experiences from childhood to the present?

If an AI reproduces all your memories but has a different consciousness, is it you?

If it has your personality but none of your memories, is it you?

If it has the same memories and personality but exists in a computer, is it you?

And if your consciousness actually continues inside that system, how would we prove it?

The Future May Not Give Us a Simple Answer

AI could eventually become incredibly good at reconstructing people.

It might learn how you speak, how you react, what you remember, what you value, and how you make decisions.

It could potentially create a digital entity so convincing that your family genuinely feels like you are still there.

But convincing imitation is not necessarily consciousness.

The ultimate challenge is not creating an AI that says:

"I am you."

The challenge is determining whether the person who says it actually experiences being you.

If humanity eventually solves that problem, the consequences could be enormous.

Death might no longer mean the complete disappearance of a person's information, memories, personality, or even potentially their mind.

But whether that amounts to you surviving is a question that may be more difficult than building the technology itself.

Perhaps the future won't eliminate death.

Perhaps it will force humanity to completely redefine what "alive" and "dead" mean.

Give your agents tools they would love to use

Sumit Mishra — Sun, 23 Aug 2026 14:03:37 +0000

Every agent framework ships the same starter kit: a system prompt, a loop, and permission to run shell commands.

Then we wonder why it git pulls the wrong branch, burns tokens deciding whether you meant pytest or ruff, and confidently edits a file that does not exist.

The agent is not stupid. We gave it bad tools.

A model with only bash is like a brilliant engineer locked in a room with a screwdriver and no manual. It will try. It will improvise. It will eventually break something you cared about.

The fix is not a longer system prompt. The fix is a toolbox the agent actually wants to reach for.

That is what Arka is built to be.

The problem: agents improvising instead of executing

Picture what we ask agents to do every day:

Check repo health before a PR
Run the right test command for this stack
Look up calendar conflicts, PDFs, or web docs
Remember that the release branch is release/2.4 until Monday
Stay inside the project boundary — no drive-by git init, no hallucinated paths

Now picture what we actually give them:

What the agent needs	What it usually gets
Repo map	`ls -R` and hope
CI / lint gates	Raw shell + guesswork
Structured review	`git diff` dumped into context
Safe automation	Unrestricted `bash`
Routing	An LLM call per keystroke

The result is familiar:

Token burn on tasks a five-line script could handle offline
Context loss between IDE chat, terminal, and browser
Trust erosion when the agent "explores" with destructive commands
Fragile loops — the agent re-derives the same facts every turn

We do not need agents that talk better. We need agents with tools they would love to use — fast, deterministic, scoped, and composable.

The solution: a skill layer agents actually reach for

Arka is a local-first CLI agent with 70+ built-in skills and 120+ symbolic routing rules that resolve most requests before any LLM is called.

Install:

pipx install "arka-agent[chat]"
arka setup
arka doctor

From there, plain English maps to real capabilities:

arka map this repo
arka health
arka review staged changes
arka ask "what changed in Python 3.13 asyncio since 3.11?"
arka goal "fix the first failing pytest in tests/"

No hosted account. No demo instance holding your code. Config and keys live on your machine — ~/.config/arka/ on Linux, Application Support on macOS, %APPDATA%\arka\ on Windows.

Your terminal becomes the agent's workbench — not a place it wanders blindly with cd and find.

Tools agents love: fast, named, and offline-first

1. Routing that does not waste tokens

Most stacks use the LLM as the front door. Arka uses it as the fallback.

arka route "run ruff on changed files"

Symbolic rules match weather, CI, repo map, passwords, YouTube transcripts, currency, and dozens more — zero tokens to decide what you meant. When language is ambiguous, Arka fails over across 24+ providers (Gemini, Groq, Ollama, OpenRouter, …) with keys you configure.

Sensitive work can stay local:

arka run-only-local-llm "explain this diff"
arka hybrid config local-only

Agents love tools that are instant and predictable. Routing is the first one.

2. Skills that match how engineers actually work

Arka ships skills agents reach for constantly:

Skill family	What the agent gets
Code & repo	`repo_map`, `repo_health`, `review`, `ci`, `pr_check`, `security`
Data & research	`ask`, `search`, `pdf_rag`, `data_ask`
Media & voice	`youtube`, `compose_video`, TTS, transcription
Infra	`deploy`, Railway, Docker, cloud helpers
Memory	`remember`, `recall`, session context

These are not vague "use bash" instructions. They are named tools with clear inputs — the difference between an agent that executes and one that performs.

2b. The skills you underestimate: weather, news, and smoke tests

Some skills look personal. They are not.

weather, stock news, headlines, and quick web lookups are often the best first commands when you stand up a new agent — a fresh MCP connection in Cursor, a custom wrapper, a hosted API profile, or a skill.json plugin you just dropped in.

Why? Because they are honest integration tests:

No repo context required — you do not need a codebase loaded to know if routing works
Fast feedback — symbolic rules match in milliseconds; you see a real answer, not a model guessing
End-to-end proof — prompt → router → skill → output, without touching git or pytest
Safe — if the agent is miswired, you get a failed forecast, not a deleted branch

When I wire a new agent client, I do not start with goal "refactor the auth module". I start small:

arka route "weather in Bangalore"
arka weather tomorrow
arka stock news
arka capabilities

If weather routes to hyperlocal_weather and returns a forecast, the plumbing works. If news hits search or your taught route and comes back with headlines, dispatch works. Only then do I trust the same path with repo health, CI, or autonomous coding goals.

Personal utilities and builder smoke tests are the same tools. That is a feature — not a footnote.

3. Guardrails so the toolbox is safe to open

Agents with great tools still need boundaries. Arka defaults to:

Blocks on destructive shell patterns
[y/N] prompts for risky installs, deletes, and downloads
Sanitized web content before it hits a model
Coding-session mode that keeps browser opens and creative skills out of the way

You are not babysitting every command. You are giving the agent tools it can use without burning the house down.

4. MCP — export the toolbox to any agent

Your IDE agent should not re-implement repo health. It should call the same skills:

arka mcp serve

Arka exposes its skill surface over MCP (stdio / SSE) for Cursor, Claude Desktop, Copilot, and anything else that speaks the protocol. One router. Many agents. Same toolbox.

arka gemini "explain this regex"    # wrap other CLIs too
arka connector status               # shared Agent Hub context

Give every agent in your stack the same tools they would love — not a different ad-hoc script per client.

A day in the life: an agent with the right tools

Morning — orientation without improvisation

You land in an unfamiliar repo. The agent does not guess the tree:

arka map this repo
arka health

Structure, test entry points, lint gates — from local inspection, not invented paths.

Midday — coding with a composer, not chaos

arka dev tui .

The coding TUI opens with session status (branch, model, loaded skills). Plain text builds a plan; you approve with y. /test runs read-only pytest and auto-fixes once on failure. /ship runs review plus changed-only CI before commit.

The agent has verbs (/plan, /run, /test, /ship) instead of improvising shell pipelines.

Evening — memory that persists across sessions

arka remember "release branch is release/2.4 until Monday"
arka recall release branch

Agents love state they do not have to re-derive every turn. Arka keeps memory local by default.

Build your own tools (agents love extensibility)

Agents outgrow fixed toolkits. Arka accepts third-party skills via skill.json plugins — no fork required.

Teach routing:

arka route learn "morning standup" "stock news"

Preview before you trust:

arka route "deploy to railway"

The agent ecosystem gets better when builders add tools, not when they lengthen prompts.

The real insight

The next generation of agents will not win on charisma. They will win on tooling.

LLMs are the reasoning layer
Skills are the execution layer
Routing is the efficiency layer
Guardrails are the trust layer

Arka bundles all four into one CLI you already have open.

Try it in five minutes

pipx install "arka-agent[chat]"
arka setup
arka doctor
arka route "weather in London"    # smoke test: routing + skill dispatch
arka weather tomorrow             # smoke test: end-to-end answer
arka capabilities
arka "what can you do with this repo?"

Star the repo if it clicks — it helps other builders find an agent stack that ships with real tools:

gh repo star Sumit884-byte/arka

What's next

Arka is actively evolving: richer coding TUI, more symbolic routes, tighter MCP ergonomics, and hosted coding profiles for Railway and beyond.

The north star stays the same: give your agents tools they would love to use — fast, local-first, composable, and under your control.

Repository: github.com/Sumit884-byte/arka

Docs: arka-agent.mintlify.site

Install: pipx install "arka-agent[chat]"

Arka — your terminal, upgraded.

The Whales of Open Source: How Big Projects Swallow Small Ones (And When NOT to Build Solo)

Sumit Mishra — Sun, 23 Aug 2026 12:50:07 +0000

In the open-source ecosystem, code doesn't float in a vacuum. It lives in a dense, hyper-competitive food chain.

On one end, you have single-developer repositories built late at night with pure enthusiasm. On the other, you have massive foundation-backed monoliths—the apex predators. Understanding how these forces interact is the difference between writing software that shapes the ecosystem and building projects that get quietly absorbed, rendered obsolete, or abandoned.

1. How Open-Source Whales Swallow the Plankton

When a lightweight tool or solo library gains traction, it catches the attention of dominant framework maintainers and enterprise ecosystems. Absorption rarely happens through hostile takeovers; instead, it occurs through natural architectural displacement.

Strategic Native Absorption

Big projects continually look to eliminate external dependencies or bridge feature gaps. When a standalone tool—like a routing library, state manager, or micro-utility—becomes the de facto standard, the mega-project often re-implements or natively integrates its core logic directly into the core framework.

Enterprise Standardization

Corporate-backed open-source projects build end-to-end platforms. A small tool solving a niche problem—such as specialized log formatting or container optimization—often gets rendered redundant as big projects expand their scope to absorb adjacent utility spaces.

Dimension	Small/Solo Open-Source Project	Mega Open-Source Ecosystem (The Whale)
Primary Advantage	Rapid iteration, hyper-focused utility, zero overhead	Massive distribution, long-term stability, deep integration
Velocity Bottleneck	Limited maintainer bandwidth	Governance protocols, RFC reviews, backwards compatibility
Long-Term Risk	Abandonment due to maintainer burnout	Slower innovation, heavy architectural opinionatedness
Survival Strategy	Deep specialization or upstream integration	Native absorption of proven community patterns

2. The Strategic Value of Contribution Over Creation

Building from scratch feels rewarding, but contributing to existing infrastructure yields far higher compound returns for both the ecosystem and your technical growth.

Upstream Impact: Fixing an edge-case bug or optimizing a performance hotspot in a framework used by millions creates immediate, widespread value that a brand-new repository rarely achieves.
Production-Grade Architecture: Working inside massive codebases forces you to read complex design patterns, understand API stability guarantees, and navigate CI/CD pipelines built at scale.
Governance and RFCs: Contribution teaches you how software decisions are negotiated across distributed teams, moving beyond pure coding into systems engineering and technical communication.

3. When NOT to Start a Solo Project

Starting a repository is instant; maintaining one is a multi-year commitment. Before running git init, run through these structural checks to decide if a new project is actually warranted.

Do Not Create a Solo Project If:

The Problem Is Already 80% Solved Upstream: If an established library lacks a specific feature, opening a Pull Request or writing an extension/plugin is almost always better than duplicating the underlying foundation.
The Bottleneck Is Maintenance, Not Architecture: If existing tools are lagging simply because the maintainers are overwhelmed, starting a competing project splits community effort rather than solving the root problem.
You Aren't Prepared for the Long-Tail Burden: Writing the initial implementation takes 20% of the effort. The remaining 80% goes to issue triage, cross-platform CI, security patches, backwards compatibility, and documentation.

When a Solo Project DOES Make Sense:

You are proving a fundamentally different architectural paradigm that cannot exist within current framework constraints.
You need a lightweight, zero-dependency environment for constrained hardware or specific execution runtime limits.
The exercise is strictly for low-level learning and personal experimentation.

By understanding where your code sits in the ecosystem, you can stop reinventing existing wheels and start driving meaningful architectural impact where it matters most.

What’s your take? Have you ever had a solo project rendered obsolete by a major framework update, or do you prefer building small utilities anyway? Let’s discuss in the comments.

[Boost]

Sumit Mishra — Sun, 09 Aug 2026 17:54:13 +0000

समोसा — Pure CSS Comfort Food in an Indian Kitchen - DEV Community

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art. For me, comfort food...

dev.to

From Infinite Slop to the Digital Casino: How AI Turned Social Media Into a Game of Chance

Sumit Mishra — Sun, 09 Aug 2026 17:48:05 +0000

We have all seen them. Bizarre, hyper-glossy images of "Shrimp Jesus," uncanny hyper-realistic videos of historical figures doing things that never happened, and a never-ending river of low-effort text and video.

Generative AI has successfully democratized creation, but in doing so, it has opened the floodgates to mass-produced digital pollution. Social media is no longer a town square or a network for human connection; it has morphed into a high-stakes slot machine.

This post explores how AI-generated content created a hyper-saturated content flood, why a lack of differentiation fuels the rise of automated media, and why scrolling today feels less like reading and more like pulling a casino lever that threatens to paralyze our minds.

1. The Standardization Trap: Why AI Rides the Wave So Easily

The rapid rise of AI-generated content is not just a technological triumph; it is a symptom of a systemic flaw in how we have built the internet. For years, content creation was heavily optimized for search engine optimization (SEO) and platform engagement algorithms.

Creators, marketers, and writers trained themselves to write with the exact same hooks, the same predictable pacing, and the same homogenized structures.

The Commoditization of Output: Because human output had already drifted toward a uniform, formulaic average, it was remarkably easy for AI models to learn, mimic, and ultimately replace it.
The Missing Differentiator: Most content lacked any real differentiation factor—no unique worldview, no specific friction, and no genuine lived experience. When content becomes entirely interchangeable, it is completely commoditized. In a digital economy, if something can be easily commoditized, an algorithm will eventually automate it to zero cost.

When 99% of feeds consist of identical commentary, recycled listicles, and visually generic synthetic media, volume becomes the only metric that matters. AI wins that race every single time.

2. The Death of Scarcity: The AI "Slop" Flood

For the entire history of the internet, content production had a natural bottleneck: human time. Writing an article, editing a video, or rendering an animation required hours of labor, thought, and skill.

Generative AI shattered that bottleneck overnight.

Zero-Cost Scaling: Anyone with an internet connection can now prompt an AI to generate hundreds of articles, dozens of short-form videos, or thousands of images in minutes.
The Economics of Volume: Content farms and individual creators realized that even if a piece of AI-generated content has a low engagement rate, mass-producing it at zero marginal cost yields a net profit through ad-revenue-sharing programs.

The result is a digital ecosystem drowning in what many call "AI slop". Feeds are saturated with redundant, hollow media designed not to communicate an idea, but to farm metrics.

3. The Content Creation Treadmill

For human creators, this flood of AI content has turned everyday publishing into an exhausting treadmill. Because algorithms favor frequency and consistency, creators are forced to compete with machines that never sleep.

When a human-made video has to fight for attention against thousands of AI-generated variations posted every second, the rules of visibility break down. To survive, creators feel pressured to adopt AI tools themselves, speeding up the treadmill even further. It is a classic race to the bottom: more content is produced, yet the average quality and meaningful signal drop drastically.

4. Social Media as a Slot Machine

This brings us to the psychological core of modern feeds: Variable Ratio Reinforcement. This is the exact mechanism that keeps people playing slot machines in casinos.

In a traditional system, input equals output (e.g., work a shift, get paid a wage). But social media algorithms run on pure unpredictability:

You post a piece of content (pull the lever).
Most of the time, it gets zero traction (the machine takes your stake).
Every once in a while, the algorithm blesses it, and you experience a massive spike of algorithmic dopamine—millions of views, thousands of followers (the jackpot).

AI has accelerated this casino dynamic for both sides of the screen. For creators, the odds of hitting the viral lottery are increasingly governed by opaque algorithmic whims, turning content creation into a digital gamble.

For consumers, the infinite, unpredictable scroll acts as a psychological trap. You pull down to refresh (pull the lever), never knowing if the next post will be boring text or a deeply engaging piece of media. This intermittent reward schedule wires the human brain to keep scrolling, searching for that next hit of novelty amidst the sea of slop.

5. The Real Threat: Algorithms That Paralyze Our Minds

We spent decades watching science fiction warn us about physical, Terminator-style robots overtaking humanity, completely missing the silent invasion happening right inside our screens.

Algorithms do not need to conquer us with physical force because they have learned how to bypass our cognitive defenses entirely. They operate like a neurological software patch, exploiting the deepest vulnerabilities of human psychology:

Hijacking Dopamine Pathways: By feeding our brains an unpredictable stream of outrage, novelty, and validation, algorithms rewire our attention spans. They turn us into passive consumers who struggle to sit with silence, deep thought, or long-form focus.
The Paralysis of Choice and Noise: When you flood the mind with an endless sea of low-differentiating, synthetic content, cognitive overload sets in. You are constantly processing information, but because most of it is empty noise, your critical thinking capabilities become paralyzed. You are mentally exhausted without having actually learned or experienced anything of substance.
Outsourcing Agency: The scariest part of algorithmic paralysis is how seamlessly it replaces our own internal decision-making. What to watch, what to buy, what to feel outraged about, and what to think—these are increasingly queued up for us by a recommendation engine designed to maximize engagement rather than human well-being.

6. Conclusion: Rewiring Our Minds and Platforms

Moving past the era of automated digital pollution requires more than just venting frustration or blindly hating AI-generated tools. The solution demands a fundamental shift in our collective psychology. Instead of passively consuming endless feeds out of habit, we need to treat online media with intentionality—reserving our attention strictly for dynamic facts, real-world developments, and genuine human insights rather than hollow volume.

At the same time, the burden cannot fall solely on the consumer. Platforms must step up by implementing strict structural benchmarks and basic quality checks to filter out uncurated, mass-produced noise. Until platforms are forced to establish quality floors that reward substance over sheer output, the digital casino will keep spinning.

Protecting ourselves from this cognitive paralysis means building intentional mental firewalls, treating our attention as a finite, non-renewable resource, and fiercely guarding the quiet spaces where real, independent thought actually happens.

I Built a Noodle Shop Landing Page That Throws Food at Your Screen 🍜

Sumit Mishra — Tue, 04 Aug 2026 11:26:08 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

What I Built

I built SLURP! — Tastiest Noodles on the Planet, a single-page landing page for an imaginary noodle shop. The comfort food theme is ramen and noodle bowls — warm, slurpy, a little chaotic — and I leaned into that with copy, color, and interactions that feel cozy and playful.

The hook: Chef Marco is so confident in his noodles that he literally throws a bowl at your screen. The hero CTA is "TRY AND CATCH THIS! 🍜" — miss the catch, get roasted, then explore the rest of the shop.

What's on the page:

Noodle Splash Hero — full-screen SVG + CSS animation (sauce smears, flying noodle clusters, garnishes, a frosted-glass "SPLAAAT!" modal). Each replay seeds random extra strands in JavaScript so the splatter feels slightly different every time.
The Noodle Vault — six signature bowls in a CollectUI-inspired card grid (Dragon Breath Chili Oil, Midnight Tonkotsu, Garlic Butter Dan Dan, Bombay Street Manchow, Golden Curry Udon, Peanut Crunch Yakisoba) with category filter chips and wavy noodle-strand SVG borders generated at runtime.
Build Your Bowl — live CSS plate preview (broth color, thick/thin/broth-only noodles, six toppings). No image swaps — just custom properties, positioned elements, and steam keyframes. Hit "Lock In My Plate", then "Buy This Bowl" — it drops into the cart with a generated name.
Galactic Slurp — story section with a Three.js spinning globe, alien rider, and twinkling stars (static fallback for prefers-reduced-motion and WebGL failures).
Pan India Store Finder — 15 kitchens across 12 cities, searchable by city, area, or pincode, with Google Maps directions.
Slurp Squad — eight fake testimonials from regulars who also failed to catch the noodles.
Social Feed Preview — Reels/Stories/TikTok-style cards using the same self-hosted bowl photos (platform buttons are visual-only demos).
Gift a Bowl — send-a-bowl flow with searchable delivery-location and preset-message pickers, live gift card preview.
Slurp Support — contact channel cards (phone, WhatsApp, email, order help), seven-item FAQ accordion with peacock show-more, quick links to stores/gift/checkout, wired into desktop nav.
Desktop section nav — frosted-glass bar, pill-shaped link track with grouped dividers, orange-gradient active states, and a scroll-progress indicator.
CollectUI Checkout Flow — Alpine.js cart with sticky bar, mobile bottom sheet, and a full client-side order flow.

Stack: one index.html file — HTML, Tailwind CSS (CDN), Alpine.js 3.14, Three.js 0.172, vanilla JS, Lucide icons, Chewy font. No build step. All images self-hosted in /assets. MIT licensed.

Source: github.com/Sumit884-byte/tasty_noodles

Demo

Live site: tastynoodles.vercel.app

Click TRY AND CATCH THIS! on the hero — that's the centerpiece interaction. Append ?splash to the URL if you want to land directly in the splatter overlay.

Hero splash — TRY AND CATCH THIS! triggers the SVG/CSS splatter overlay; dismiss with Wipe Screen & Place Order
Desktop nav pills — frosted pill track with scroll-spy active states
Peacock show-more — menu vault expands from 3 → 6 bowls in place
Build Your Bowl — broth/noodle/topping chips → Lock In My Plate → Buy This Bowl (cart bump)
Gift pickers — searchable delivery-location and preset-message dropdowns with live card preview
Support FAQ — accordion expand + peacock show-more for hidden questions
Checkout — cart summary after items are added

Screenshots (hero through checkout — current layout):

Links:

🍜 Live demo: tastynoodles.vercel.app
📦 Source: github.com/Sumit884-byte/tasty_noodles

Journey

Why noodles?

The DEV Frontend Challenge prompt was comfort food — not "a nice restaurant site," but something that makes you hungry just thinking about it. Noodles felt right: warm broth, slurping sounds, late-night cravings. I wanted the page to feel like a brand, not a template — chunky typography, an amber/orange/stone palette, and interactions that reward curiosity.

Process

I started with the splash hero because it set the tone. Pure SVG + CSS — no canvas, no video, no Lottie. stroke-dashoffset for smears and strands, staggered keyframes for clusters and garnishes, JavaScript to seed random extra strands on each replay.

From there I built outward: menu cards with runtime-generated wavy SVG borders, the CSS-only bowl builder (my favorite section technically — a well-structured DOM + custom properties replaced a lot of image-swap logic), then the Three.js globe with performance guardrails (IntersectionObserver to pause off-screen, visibilitychange for hidden tabs, adaptive geometry, pixelRatio cap, static fallback for reduced motion).

Alpine.js became the app's brain — one slurpApp() component handles cart, custom plate builder, store locator, menu filtering, splash overlay, mobile nav, gift flow, support FAQ, and checkout. I baked accessibility in from the start: skip link, splash dialog with focus management, aria-pressed on builder chips, prefers-reduced-motion disabling splash/globe/steam animations, semantic landmarks, lazy-loaded images with explicit dimensions.

Later passes added Slurp Support — contact cards, accordion FAQ, peacock show-more, quick links — and tightened the Gift a Bowl pickers. Nested @click.outside handlers were closing delivery-location and preset-message dropdowns before you could pick an option; scoping each picker (and @click.stop on the search inputs) fixed it, and a clearer giftPresetItem getter made the preset dropdown label behave.

The desktop upper nav got a full polish pass: frosted-glass bar, pill-shaped link track with grouped dividers, orange-gradient active states, and a scroll-progress bar. That redesign surfaced an Alpine gotcha — x-for with multiple root nodes (divider span + link) only rendered the dividers. Wrapping each iteration in a single .site-nav__item fixed it, along with contrast, hover, and overflow tweaks at the 1024px breakpoint.

How responsivity is designed

Responsivity on SLURP! is not a bolted-on @media pass at the end — I designed it into navigation, layout grids, scroll behavior, and motion from the start. The page uses Tailwind's default breakpoints (sm 640px, md 768px, lg 1024px, xl 1280px), but the primary split is lg (1024px): below that you're in touch-first mode; above it you're in desktop mode.

Navigation: bottom tabs vs pill track

On mobile and tablet (max-width: 1023px):

The frosted top bar keeps logo, locale picker, and a hamburger drawer (full section list + locale chips).
Section navigation moves to a fixed bottom tab bar — five icons: Dare, Menu, Build, Gift, Cart — with a wavy noodle SVG divider and env(safe-area-inset-bottom) padding for notched phones.
The floating checkout bar sits above the tab bar (bottom: calc(4.875rem + safe-area)), never behind it.
body gets bottom padding so content isn't hidden under the chrome; when the cart bar is visible, padding doubles.

On desktop (lg: / min-width: 1024px):

Hamburger and bottom tab bar hide (lg:hidden).
A pill-shaped nav track appears in the header (hidden lg:block) — frosted inner track, grouped dividers between section clusters, orange-gradient active link states, and a scroll-progress bar.
The track scrolls horizontally when the viewport is tight (1024–1279px): link font-size and padding compress, checkout button becomes icon-only, and locale picker label hides until xl.
Checkout moves into the header; the "Checkout" label appears at xl.

Scroll offsets are wired through CSS variables on :root:

--site-header-offset: 3.5rem;   /* mobile */
--site-bottom-offset: 4.875rem; /* mobile tab bar */
/* at 1024px+: header 5rem, bottom 0 */

scroll-padding-top and .section-scroll-target { scroll-margin-top } keep anchor jumps from landing under fixed chrome.

Layout grids and section patterns

Section	Mobile	`md` (768px)	`lg` (1024px)
Menu cards	1 col	2 col	3 col
Gift a Bowl	stacked	—	2-col grid + sticky preview
Store results	1 col	2 col	—
Social share cards	1 col	2 col (`sm`)	4 col
Build Your Bowl	stacked	2 col	—
Learn section	horizontal step strip	—	sticky step list

Gift layout: .gift-layout is a single-column grid on mobile; at lg it becomes grid-template-columns: 1.05fr 0.95fr with .gift-preview-wrap { position: sticky; top: 6rem }. Form fields use sm:grid-cols-2 for To/From name pairs.

Store finder: search row stacks vertically until sm, then row-aligns; decorative elephant SVGs are display: none until md. Store decor animations scale down or hide on small screens to reduce visual noise.

Menu cards: CollectUI-style grid with horizontal-scrolling category filter pills (menu-cat-scroll, scrollbar hidden). Cards use runtime wavy SVG borders via attachNoodleFrame().

Overflow and progressive disclosure

Instead of infinite scroll, long lists use peacock show-more buttons (section-show-more-btn) with Alpine visibleSlice() — initial limits of 3–4 items per section (menu, stores, reviews, spread, slurp-code, checkout, support FAQ). Tap expands in place; no route change, no pagination component.

Other intentional overflow:

Desktop nav track: overflow-x: auto with edge fade masks.
Learn step strip on tablet: horizontal scroll + scroll-snap-type: x mandatory.
Category pills: overflow-x-auto with hidden scrollbars.

Motion, cursors, and locale

prefers-reduced-motion: reduce disables splash animations, globe spin, steam keyframes, store decoration animations, nav hover transforms, and chopstick card ornaments. JavaScript checks matchMedia('(prefers-reduced-motion: reduce)') before confetti, splash replay, and Three.js init — static fallback for the globe.

Chopstick theme (body.chopstick-theme): custom noodle cursors apply only under @media (pointer: fine) — touch users keep the system cursor. Section-scoped accent colors via body[data-section="…"] { --chopstick-accent }. Active nav states show crossed-chopstick icons (inline on drawer links, overlay on desktop pills, above icon on mobile bottom nav).

Locale picker: compact toggle in the header; full locale chip row in the mobile drawer. A floating locale-suggestion banner uses max-width: calc(100vw - 1.5rem) and repositions at md. Between 1024–1279px the picker label hides to save header space.

Checkout UX across breakpoints

The CollectUI-style flow uses a floating checkout bar when items are in cart — centered, max-width 24rem, with optional inline qty stepper for single-item carts. On mobile it floats above the bottom nav; on desktop it sits at bottom: 1rem with no body padding conflict. The checkout section itself is a centered max-w-2xl card with peacock show-more for long cart lists.

What I'm proud of

The splash animation — elaborate, replayable, and still pure SVG/CSS
The CSS bowl preview — instant, lightweight, infinitely recombinable
Wavy SVG card borders via attachNoodleFrame() — micro-detail that makes the UI feel designed
Progressive enhancement for motion and WebGL — fun features that don't punish users who prefer reduced motion or lack WebGL
Slurp Support — contact cards and FAQ that feel on-brand, not a generic help-desk widget pasted onto a landing page
The desktop nav — frosted glass, pill track, scroll progress, and a real Alpine x-for debugging story
Shipping everything in one file you can open locally without explaining npm

What I learned

Commit to the joke, but ship real craft. The copy is silly; underneath there's form validation, accessible modals, performance-conscious 3D, and responsive layouts.

CSS can do more than I thought. The bowl preview taught me that custom properties + keyframes can replace a lot of asset-heavy UI logic.

Constraints spark creativity. "Comfort food" pushed me toward warmth and interactivity instead of a generic SaaS layout.

Single-file projects are underrated. For a challenge submission or portfolio piece, one index.html felt like a superpower.

What's next?

This was a challenge submission, not a production restaurant platform — but there's room to grow:

Extract the splash animation into a reusable Web Component
Add sound effects (with mute toggle)
Wire up real social links if SLURP! ever becomes a real brand
India wireframe map with store pins — a sketch-style outline of the country with clickable markers for each kitchen, tied into the existing store finder
Peacock feather expansion on show-more — peacock buttons already reveal extra menu cards, testimonials, and support FAQs; next up is a feather-fan unfold animation on click, so expanding a section feels like the bird opening its tail

For now, I'm happy with what I shipped: a page that makes people smile, teaches a few frontend tricks, and proves that comfort food deserves better than a stock photo and an "Order Now" button.

If you're participating in the challenge — or you've built something fun for it already — drop a link in the comments. I want to see your comfort food takes.

And if you try to catch the noodles... good luck. Chef Marco doesn't believe in you. 🍜

Built with too much chili oil and not enough sleep. MIT licensed — see LICENSE.

समोसा — Pure CSS Comfort Food in an Indian Kitchen

Sumit Mishra — Sat, 01 Aug 2026 14:20:12 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

For me, comfort food means samosas — crispy, golden, still warm from the fryer, with mint and tamarind chutney on the side. Rainy evenings, chai breaks, street stalls, family gatherings: a samosa shows up in all of them.

This project recreates that feeling with no images, no SVG, and no JavaScript — only HTML and CSS.

Demo

Try it live on CodePen — kitchen scene, cooking steps, and the full animation loop:

CodePen: https://codepen.io/sumit_mishra_cb22d5be5f02/pen/jEyXMLo

Live demo: https://css-samosa-kitchen.vercel.app

Open index.html locally, or deploy the folder to any static host.

What you're looking at

Panel 1 — Kitchen scene

A flat illustration of a home kitchen:

Wall & backsplash — cream plaster, subway tiles, red/green border bands, warm window light
Props — matkas on the wall, spice jars, masala dabba, hanging ladle, chakla-belan, chai glass, folded napkin
The plate — oval rim, inner ring, shadow, lemon wedge, coriander, pickle slice
Three samosas — clip-path triangles with fold lines, crimped bases, oil blisters, side shading
Chutney — semicircle sauce in katori bowls on tiny saucer plates (mint green + tamarind red)
Details — rising steam, crumbs, oil spots, diagram-style labels, rain on the kitchen window
Bitten samosa — one samosa with a potato filling cross-section, as if someone already took a bite

A 7-second CSS loop brings samosas and chutney onto the plate with staggered entrance keyframes, a dip-into-chutney-and-bite beat on the left samosa, screen-shatter effects, and steam on a shared timeline.

Panel 2 — Cooking steps

Scroll down for a 5-step cooking illustration (knead → fill → fold → fry → serve) — also built entirely in CSS with a 25-second step cycle. The final serve frame mirrors Panel 1: same oval plate, katori chutney bowls, and golden samosa tones.

The title uses Yatra One for Devanagari (समोसा) with an English subtitle — the only external assets are Google Fonts.

Inspiration

I grew up treating samosas as the default answer to "what should we eat?" They are street food and home food at once. I wanted the page to feel like a cross-section of an Indian kitchen — not a dark 3D render, but the kind of warm, labeled illustration you'd see in a cookbook margin.

Technical highlights

Samosa shape

Each samosa uses clip-path: polygon() for the triangle, layered linear and radial gradients for the fried crust, a vertical fold line, and a repeating gradient crimp at the base.

Chutney bowls

Chutney is a semicircle fill inside a CSS katori (open bowl curve), sitting on a small oval saucer — so it reads as sauce in a dish, not a flat green/red dot.

Kitchen background

Every prop is divs and pseudo-elements: window panes on a grid, shelf boards, jar lids, a brass-toned ladle, wood-grain table stripes. No icon fonts, no PNGs.

Animation

Entrance keyframes, dip-and-bite motion, screen shake, crack lines, and glass-shatter shards are pure CSS. prefers-reduced-motion is respected throughout.

Journey / lessons

Placement matters. Chutney looked wrong until the bowls moved inside the plate container and sat at the correct inset — percentages relative to the plate, not the full viewport.
Layer order tricks you. A white "bowl rim" div on top of the sauce looked like a lid; swapping to a border on the sauce fixed it instantly.
Reference helps. A flat illustration reference pushed the scene from moody 3D toward a clearer, warmer kitchen diagram — which fit the comfort-food brief better.

What I'd do next: ~~rain streaks on the kitchen window~~ ✓ added — overcast sky, falling streaks, and glass-pane sheen for the rainy-evening mood in the intro.

Stack

HTML + CSS only
Google Fonts: Yatra One, Hind

License: MIT — use and remix freely.

Tags for DEV: #frontendchallenge #devchallenge #css #cssart

The Modern Developer Playbook: Building, Shipping, and Scaling in Public

Sumit Mishra — Fri, 31 Jul 2026 06:05:53 +0000

The Modern Developer Playbook: Building, Shipping, and Scaling in Public

In software engineering, traditional credentials like degrees, resume buzzwords, and isolated side projects no longer guarantee a direct path into high-impact roles. The developer ecosystem has shifted heavily toward proof of execution: tangible evidence that you can build, deploy, optimize, and communicate real software under production constraints.

Becoming an exceptional developer in today's landscape requires balancing technical depth, public visibility, system design, and execution discipline.

Here is the complete blueprint for executing this strategy.

1. Proof of Execution: Build in Public and Focus on Impact

Building software in isolation limits your feedback loops and hides your problem-solving process. Shifting toward public execution turns your work into an organic career magnet.

A. The One Gigantic Project Strategy

Instead of scattering your energy across five small tutorial-level projects, build one massive, production-grade flagship product. A single high-complexity system demonstrates real-world architecture, depth, and persistence far better than multiple shallow repositories.

Developer Tooling: End-to-end CLI platforms, automated release engines, or custom language parsers.
Data Pipelines: OCR and document indexing pipelines, real-time analytics platforms, or high-throughput stream processors.
Specialized Utilities: Hybrid volatility engines, semantic search protocols, or enterprise API gateways.

B. Document the Engineering Process

Documenting your journey publicizes your technical decision-making and consistency:

Public Development Logs: Share short weekly logs covering architecture choices, performance trade-offs, and technical roadblocks.
Show Your Work: Share visual demos, system diagrams, benchmarking results, or performance graphs to highlight execution quality.
Transparent Post-Mortems: Write down what broke during production deployments, why it failed, and how you fixed it.

2. High-Trust Technical Blogging: Screenshots, Videos, and Code

Abstract code snippets and textual claims are easy to fabricate; visual proof generates immediate trust. Writing technical deep-dives paired with unedited UI screenshots, architecture diagrams, and brief terminal recordings proves your software operates in real runtime environments.

A. The High-Trust Technical Post Architecture

Every deep-dive article on your blog or platform should follow a clear structure to build credibility:

+-----------------------------------------------------------------------------------+
|                        HIGH-TRUST TECHNICAL BLOG FORMAT                           |
+-----------------------------------------------------------------------------------+
|  1. THE PROBLEM        --> State the performance bottleneck, error, or system goal. |
|  2. VISUAL EVIDENCE    --> Provide runtime terminal logs or screen recordings.    |
|  3. SYSTEM ARCHITECTURE--> Embed clean diagrams (e.g., Excalidraw, Mermaid).      |
|  4. CODE & EXPLANATION --> Show precise, syntax-highlighted production code.      |
|  5. BENCHMARKS         --> Share before/after metrics (profiler graphs, latency). |
+-----------------------------------------------------------------------------------+

B. Visual Proof Assets

Annotated Screenshots: Use clean, uncropped UI screenshots with highlighted regions to demonstrate edge cases, memory profiles, or browser DEV tools network tabs.
Terminal & Interface Screen Recordings: Embed 10–30 second GIFs or video loops showing your application in motion, CLI flags executing, or real-time streaming data handling live payloads.
Interactive Code Snippets: Accompany visuals with runnable code blocks rather than static text, allowing readers to verify logic locally.

3. The Distribution Framework: Amplifying Your Proof of Work

Your distribution efforts must scale in direct proportion to your execution effort. Building a world-class project in silence yields zero leverage. If you spend weeks engineering a system, spend equal energy distributing it across software communities.

+-----------------------------------------------------------------------------------+
|                            THE DISTRIBUTION FLYWHEEL                              |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|  [ CORE BUILD ]  --->  [ DEMO & VISUALS ]  --->  [ MULTI-PLATFORM DISTRIBUTION ]  |
|  (Flagship App)        (Video/Screenshots)       (X, LinkedIn, Reddit, Hashnode)  |
|         ^                                                                   |     |
|         |                                                                   v     |
|         +------------------ [ FEEDBACK & TRACTION ] <-----------------------+     |
|                                                                                   |
+-----------------------------------------------------------------------------------+

A. Tailoring Content Across Platforms

Different platforms require distinct storytelling angles for the same underlying piece of engineering:

X (Twitter): Post short, visual-first updates. Focus on code snippets, UI polish, speed benchmarks, and quick terminal video recordings.
LinkedIn: Share high-level engineering decisions, architectural trade-offs, project milestones, embedded blog posts, and career takeaways.
Reddit & Tech Communities: Share technical write-ups in subreddits (e.g., r/programming, r/webdev, r/Python) and platforms like Hacker News, Hashnode, or Dev.to. Focus on problem-solving, performance gains, screenshots of benchmarks, and asking for code reviews rather than self-promotion.

B. Leverage Distribution for Flagship Projects

Focusing on one major project makes distribution exponentially easier:

You create a unified narrative around a single product over months rather than resetting your audience's attention with a new toy project every week.
You can write deep-dive blog posts into individual sub-systems (e.g., "How I reduced database query latency by 40% in [Project Name]" featuring profiler screenshots).
You build genuine brand equity and domain authority around one core subject.

4. Choosing Your Sub-Career Focus

Spreading yourself across too many domains dilutes your expertise. Select a primary domain to focus your deep-work hours and tailor your portfolio.

Focus Area	Core Focus Areas	Key Output & Proof of Work	Primary Tech Stack
Backend & Systems	API design, concurrency, database query optimization, caching, microservices, and system reliability.	Fast REST/gRPC services, custom ORM tools, search engines, and real-time data pipelines.	Python, Go, Node.js, PostgreSQL, Redis, Docker
Frontend & UI/UX	Client-side performance, state management, render optimizations, component architecture, and accessibility.	Polished web applications, UI component design systems, and responsive dashboards.	TypeScript, React, Next.js, Tailwind CSS, shadcn/ui
Full-Stack	End-to-end product delivery, fast prototyping, integrating complex frontends with scalable APIs.	Production SaaS applications, automated web portals, and feature-complete tools.	Next.js, FastAPI/Node, PostgreSQL, Prisma/Drizzle
AI / Data Engineering	Vector indexing, retrieval-augmented generation (RAG), model fine-tuning, and data processing.	Custom semantic search engines, sentiment/volatility analyzers, and automated data pipelines.	Python, PyTorch, LangChain, Qdrant/Pinecone, Pandas

Choose the path that aligns with the problems you enjoy solving daily.

5. The Open Source Advantage: Bounties, Grants, and Contributions

Open source acts as a global codebase where you can work alongside experienced engineers.

A. Targeted Codebase Contributions

Start by inspecting open-source tools you rely on daily.
Review open pull requests to learn repository conventions, code style guidelines, and testing requirements before submitting code.
Address issues labeled good first issue, help wanted, or work on improving documentation and automated tests.

B. Grants and Bounties

Monetized Open Source: Platforms like Algora, Gitcoin, and Immunefi offer financial bounties for resolving issues, building feature requests, or finding security vulnerabilities.
Ecosystem Grants: Many open foundations and companies award non-dilutive grants to independent builders contributing to core open-source infrastructure or developer tools.

6. Strategic Problem Solving (DSA Pattern Recognition)

Data Structures & Algorithms (DSA) remain a primary technical filter during engineering interviews. Treat DSA as pattern recognition rather than rote memorization.

                  +-----------------------------------+
                  |      MASTERING DSA PATTERNS       |
                  +-----------------------------------+
                                    |
          +-------------------------+-------------------------+
          |                                                   |
+-------------------+                               +-------------------+
|   CORE PATTERNS   |                               | LANGUAGE SELECTION|
+-------------------+                               +-------------------+
| • Two Pointers    |                               | Python: Ideal for |
| • Sliding Window  |                               | speed, clean      |
| • Prefix Sums     |                               | syntax, and built-|
| • Binary Search   |                               | in structures.    |
| • BFS / DFS       |                               +-------------------+
| • Dynamic Prog.   |                                         |
+-------------------+                                         |
          |                                                   |
          +-------------------------+-------------------------+
                                    |
                  +-----------------------------------+
                  |       STRUCTURED PROBLEM SETS     |
                  +-----------------------------------+
                  | Focus on 100-150 targeted problems |
                  | (e.g., NeetCode 150, Blind 75)    |
                  +-----------------------------------+

Time Complexity Reference Guide

Ensure you analyze the asymptotic complexity for every problem solved:

Pattern / Algorithm	Average Time Complexity	Space Complexity
Hash Table Lookup	O(1)	O(N)
Binary Search	O(log N)	O(1)
Two Pointers / Sliding Window	O(N)	O(1)
Tree/Graph Traversal (BFS/DFS)	O(V + E)	O(V)
Sorting (MergeSort, QuickSort)	O(N log N)	O(N) or O(log N)
Dynamic Programming (Grid/Knapsack)	O(N × M)	O(N × M)

7. Execution Strategy and Time Allocation

To prevent burnout while balancing product development, distribution, DSA, and career opportunities, maintain a structured schedule:

+-----------------------------------------------------------------------------------+
|                            DAILY EXECUTION PIPELINE                               |
+----------------------------------------+------------------------------------------+
|         BLOCK 1: DSA & WARMUP          |        BLOCK 2: DEEP WORK & BUILDING     |
|              (60–90 Mins)              |               (2–3 Hours)                |
+----------------------------------------+------------------------------------------+
| • Solve 1-2 targeted pattern problems  | • Focus on the single flagship project   |
| • Focus on time/space complexity       | • Optimize performance and write tests   |
| • Practice explaining solutions aloud  | • Draft visual technical blog posts      |
+----------------------------------------+------------------------------------------+

Action Plan

Define Your Domain: Choose your primary technical stack (e.g., Full-Stack, Backend, AI Engineering).
Commit to One Flagship System: Ditch small tutorial apps and focus on shipping a single high-impact product over 8–12 weeks.
Write High-Trust Technical Content: Document system architecture with real screenshots, video clips, and profiler metrics in technical blogs.
Execute the Distribution Ratio: Match your build effort with cross-platform distribution on X, LinkedIn, Reddit, and specialized tech hubs.
Maintain DSA Discipline: Solve pattern-based problem sets for 60 minutes daily to keep algorithmic fluency sharp.

Arka: An agent that thinks like an human

Sumit Mishra — Sun, 26 Jul 2026 16:56:39 +0000

See Inside Your Agents: Arka + SigNoz for Track 01

When a model returns 429, a shell step fails, or failover kicks in, you need to see which step broke — not just that something failed. We built Arka + SigNoz for the Agents of SigNoz hackathon (Track 01 — AI & Agent Observability) to instrument the full agent lifecycle with OpenTelemetry and make every step visible in one trace waterfall.

Demo video (~3 min): arka-signoz-hackathon-demo.mp4

Images: PNGs live on the signoz-hackathon-media release. If your editor (e.g. AWS Builder Center) does not render markdown images, paste the HTML blocks below or upload the PNGs from that release page.

What is Arka?

Arka is an open-source AI agent for your terminal. You say what you want in plain English; Arka routes the request to the right local skill, runs it on your machine, and falls back across 24 LLM providers when a model is actually needed.

Under the hood it is a Python CLI with a Fish-shell router, a multi-step goal loop, 70+ bundled skills, MCP for Cursor and Claude, and security gates on by default — prompt-injection checks, risky-action prompts, and hard blocks on destructive shell patterns.

Install in one line: uv tool install "arka-agent[chat,observability]" · Docs: arka-agent.mintlify.site

Why we love building it

We did not set out to build “another chat wrapper.” We wanted a real agent we could trust in our own terminals every day — one that routes fast, fails gracefully, and stays local when it should.

What keeps us shipping:

The router is the product. 120+ symbolic rules handle most requests with zero LLM tokens. Watching “summarize README” hit a skill in ~1 ms instead of a 3-second model round-trip never gets old.
Agents are messy — and that is the fun part. Routing, planning, tool calls, memory, failover, self-heal — every layer is a design problem. Arka is our sandbox to try ideas in production on our own repos.
Dogfooding forces honesty. When Gemini 429s mid-goal or a shell step fails, we feel it immediately. That pain is why we instrumented every span and wired SigNoz — we wanted the same visibility we wish every agent framework shipped with.
Local-first, extensible by design. Skills are plugins (skill.json), secrets stay in ~/.config/arka/, telemetry is opt-in. You own the stack; we just make the defaults sane.
Building in the open. Issues, routing mismatches, and hackathon demos like this one all land in the same repo. Shipping observability for Track 01 is part of making Arka something we are proud to hand to other developers.

If that resonates, star the repo — it helps others find it: github.com/Sumit884-byte/arka

The problem

AI agents are a black box. They chain LLM calls, invoke tools, hit vector DBs, and make decisions autonomously. When latency spikes, token costs explode, or an agent hallucinates in production, fragmented logs do not tell the end-to-end story.

Track 01 asks you to trace, monitor, and debug AI-native systems. That means one place to follow a request from routing → planning → LLM attempt → tool execution → recovery — with metrics and logs tied to the same trace IDs.

How we use SigNoz

We do not run a separate observability sidecar. Arka instruments itself with OpenTelemetry and sends traces, metrics, and logs to SigNoz over OTLP HTTP. SigNoz is where we deploy the stack, ingest telemetry, and debug the agent lifecycle.

1. Deploy with Foundry

SigNoz runs locally from casting.yaml + casting.yaml.lock at repo root. One command brings up the UI (:8080), OTLP ingester (:4318), and MCP server (:8000):

arka signoz setup -y

2. Enable telemetry in Arka

Add to ~/.config/arka/.env:

OTEL_TRACES_ENABLED=1
OTEL_METRICS_ENABLED=1
OTEL_LOGS_ENABLED=1
SIGNOZ_ENDPOINT=http://localhost:4318

Instrumentation lives in src/arka/telemetry/ — every agent step becomes exportable telemetry with no hand-rolled exporters.

3. Emit traces (synthetic or live)

arka signoz demo-scenarios --synthetic   # no live LLM required
arka goal -y -n 4 "count lines in README.md"   # live agent waterfall

Demo scenarios tag spans with arka.demo.scenario so you can filter in SigNoz instantly (vllm-vs-cloud-latency, rag-supermemory-cascade, semantic-router-split, e2e-observability-pillars, exception-stack-traces).

4. Debug in SigNoz UI

For the hackathon demo we use stock SigNoz views — no custom dashboard required:

View	Filter / use
Traces Explorer	`service.name = 'arka'` → full waterfall (`arka.route`, `arka.llm.attempt`, RAG spans)
Services	P99 latency, error rate, ops/sec for the `arka` service
Logs Explorer	LLM failover, 429 recovery, shell events on the same trace IDs as spans

Click any arka.llm.attempt span → Logs tab to see correlated agent events without switching tools.

5. Verify the stack

arka signoz status

Confirms Docker, foundryctl, OTLP pipelines, and built-in verify queries for routing spans, LLM attempts, and MCP tool calls.

6. Optional extras

Dashboards: arka signoz dashboard install — bundled panels in signoz/dashboards/
Alerts: arka signoz alert-create --all — error spike, LLM P99, token budget (needs SIGNOZ_API_KEY)
MCP: query traces from Cursor via SigNoz MCP on :8000 and the Cursor Agent Skills plugin

What we shipped

For this hackathon we instrumented Arka’s full agent lifecycle with OpenTelemetry and export everything to SigNoz over OTLP HTTP on port 4318.

Instrumentation lives in src/arka/telemetry/:

Signal	What Arka exports
Traces	`arka.request` → `arka.route` → `arka.agent.goal` → `arka.llm.attempt` → `arka.tool.shell`
Metrics	`arka.routing.decisions`, `arka.skill.duration`, `arka.llm.tokens`, `arka.mcp.ops`
Logs	Structured agent events with `trace_id` / `span_id` correlation

Every demo scenario tags spans with arka.demo.scenario so you can filter in SigNoz without guessing:

vllm-vs-cloud-latency — compare arka.llm.ttft_ms across providers
rag-supermemory-cascade — vector lookup → context → LLM complete
semantic-router-split — symbolic route (~1 ms) vs LLM fallback (~seconds)
e2e-observability-pillars — route → memory → LLM → shell in one waterfall
exception-stack-traces — auto-recorded exception.stacktrace on error spans

See How we use SigNoz for the full deploy → instrument → debug workflow.

Track 01 without a custom dashboard

Judges can verify the build with three SigNoz views:

Traces Explorer — filter service.name = 'arka'. You see real spans: arka.llm.attempt, arka.demo.inference_compare, arka.route.

Services — P99 latency, error rate, ops/sec for the arka service.

Logs Explorer — LLM failover events, quota errors, and provider 429 recovery correlated by trace ID. Filter service.name = 'arka' and open a trace to see log lines on the same IDs (e.g. route symbolic → goal loop, Gemini 429 failover to Groq, shell ok wc -l README.md, agent.self_heal retries).

Dashboards and alerts are bundled (signoz/dashboards/, arka signoz alert-create) for teams that want them — but the hackathon demo video and judge script focus on traces + services + logs.

Demo video: arka-signoz-hackathon-demo.mp4 (~3 min) · general Arka demo

Where to find docs (start here)

Resource	URL
Observability guide (setup, demo, dashboards, MCP)	arka-agent.mintlify.site/guides/observability
Hackathon judge pack (checklist, four pillars, demos)	signoz/README.md on fork
Blog / submission narrative (this page)	BLOG.md on release
Four pillars walkthrough	FOUR_PILLARS.md
MCP + Cursor skills	MCP_INTEGRATION.md · CURSOR_AGENT_SKILLS.md
Demo media (PNG/MP4)	signoz-hackathon-media release
Quickstart (install `arka-agent`, API keys)	arka-agent.mintlify.site/quickstart
SigNoz official docs	signoz.io/docs

Reproduce in 10 minutes

Prerequisites: Docker Desktop (≥4 GB RAM), Python 3.11+.

git clone https://github.com/Sumit884-byte/arka.git
cd arka
git checkout main
pip install -e ".[chat,observability]"

# Deploy SigNoz via Foundry (Docker + foundryctl + cast)
arka signoz setup -y

Or install without cloning:

uv tool install "arka-agent[chat,observability]"
arka signoz setup -y

Add to ~/.config/arka/.env (or repo .env):

OTEL_TRACES_ENABLED=1
OTEL_METRICS_ENABLED=1
OTEL_LOGS_ENABLED=1
SIGNOZ_ENDPOINT=http://localhost:4318

Emit synthetic agent traces (no live LLM required):

arka signoz demo-scenarios --synthetic
arka signoz status   # verify pipelines + judge filter queries

Open http://localhost:8080 → Traces Explorer → filter service.name = 'arka'.

For a live agent waterfall:

arka goal -y -n 4 "count lines in README.md"

Refresh SigNoz UI screenshots and rebuild the demo video:

python3 recordings/signoz-screenshots/capture_signoz_ui.py --no-dashboard
python3 recordings/build_signoz_demo_video.py

Four observability pillars

We mapped Arka directly to SigNoz's LLM observability story (FOUR_PILLARS.md):

1. End-to-end request tracing

Root span arka.request through routing, goal steps, LLM attempts, and tools. Filter: arka.demo.scenario = 'e2e-observability-pillars'.

2. Correlate traces with logs

emit_log() attaches the active span's trace ID. Click an arka.llm.attempt span → Logs tab shows llm tokens gemini/... on the same trace.

3. Token usage and cost analytics

Span attributes: gen_ai.usage.input_tokens, gen_ai.usage.output_tokens, arka.llm.estimated_cost_usd. Metric: arka.llm.tokens by provider and model.

4. Alerts

Bundled recipes: agent error spike, LLM P99 latency, token budget. Create with arka signoz alert-create --all (requires SIGNOZ_API_KEY).

Tech stack

Layer	Technology
Agent	Arka — CLI, Fish router, goal loop, skills
LLM	Agno — model-agnostic routing and chat
Telemetry	OpenTelemetry — OTLP HTTP → SigNoz `:4318`
Observability	SigNoz — traces, metrics, logs, Query Builder
Deploy	SigNoz Foundry — `foundryctl cast -f casting.yaml`
MCP (optional)	SigNoz MCP on `:8000` — Cursor Agent Skills plugin

Foundry and MCP

casting.yaml enables SigNoz MCP (mcp.spec.enabled: true) so you can query traces and metrics from Cursor via the SigNoz Agent Skills plugin. Judges can re-run:

foundryctl cast -f casting.yaml

and verify OTel traces land in SigNoz within minutes.

AI disclosure

Per hackathon rules, we declare AI assistant use:

Cursor — OpenTelemetry instrumentation, SigNoz wiring, docs, demo video script, screenshot capture automation, and this blog draft
LLM providers — used during normal Arka development and demo scenario design

Failure to disclose AI assistance disqualifies submissions; we list it here and in our Devpost form.

Links

Docs (observability): arka-agent.mintlify.site/guides/observability
Upstream repo: github.com/Sumit884-byte/arka
Hackathon fork: github.com/sumitmishra884byte-cpu/arka
Judge pack: signoz/README.md · FOUR_PILLARS.md · release media + docs
Hackathon: wemakedevs.org/hackathons/signoz
SigNoz docs: signoz.io/docs
Demo video: arka-signoz-hackathon-demo.mp4 (~3 min) · general Arka demo

YouTube / Devpost blurb: See inside your AI agents — not just that something failed, but which step broke. Arka instruments routing, LLM attempts, RAG retrieval, tool calls, and failover with OpenTelemetry; SigNoz shows the full waterfall in Traces Explorer, Services metrics, and correlated Logs Explorer. Reproduce: arka signoz setup -y → arka signoz demo-scenarios --synthetic → filter service.name = 'arka'.

Clone the repo, run arka signoz setup -y, then arka signoz demo-scenarios --synthetic. Open Traces Explorer, filter service.name = 'arka', and watch the full agent lifecycle in one waterfall.

My Headless LinkedIn Bot Fails Silently - Until I Point SigNoz at It

Sumit Mishra — Sat, 18 Jul 2026 08:05:52 +0000

Subtitle: From ChromeDriver 151 vs Brave 150 to correlated traces: what I learn instrumenting a Selenium cron job with OpenTelemetry

Every morning I open yesterday's log file and scroll, guessing.

Some days the bot sends zero connection requests. Other days it hits 27 of 30 and stops. The script runs headless on a schedule — no browser window, no Slack alert, just a text file that might not tell the whole story.

I built this for a SigNoz hackathon. The goal isn't a polished observability tutorial. It's to stop flying blind on a real Python + Selenium bot running on my Mac. Here's what actually breaks, what I instrument, and what shows up in SigNoz when I finally look.

What I Run

The bot sends LinkedIn connection requests up to a daily cap. I run headless Brave on macOS via launchd:

./schedule/install_daily_schedule.sh install
# At login + hourly while the Mac is on; at most one successful run per day

Relevant settings from .env:

BROWSER_HEADLESS=true
USE_BROWSER_PROFILE=true
USE_NETWORK_GROW=true          # fallback when people search is exhausted
AUTO_ACCEPT_INVITATIONS=true   # accept pending invites on Grow first
LINKEDIN_CONNECTIONS=30
LINKEDIN_DRIVER_AUTO_FIX_ATTEMPTS=2

SIGNOZ_ENABLED=true
OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
OTEL_SERVICE_NAME=linkedin-connection-bot

When people search runs out, the bot switches to My Network → Grow, accepts incoming invitations, then sends Connect requests. Resume state lets a crashed run pick up on Grow without redoing search. A wrapper script (schedule/daily_run.sh) handles lock files, stale process cleanup, and one chromedriver auto-fix retry.

Simple on paper. Messy in production.

The Failures I Can't See From One Log Line

ChromeDriver 151 vs Brave 150

On July 17, most hourly launchd checks looked like this:

Critical error: Failed to initialize brave: ...
This version of ChromeDriver only supports Chrome version 151
Current browser version is 150.0.7871.125

Brave hadn't auto-updated. Selenium had cached ChromeDriver 151. The bot never got past browser launch — zero connections, 784 lines of stack trace.

I add self-healing in Scripts/browser_utils.py: detect the mismatch, kill stale chromedriver and Brave processes, re-download the matching driver:

def auto_fix_chromedriver_mismatch(browser_name, log_func=None):
    cleanup_stale_bot_processes(browser_name, log_func=log_func)
    path = resolve_chromedriver_path(browser_name, force_refresh=True)
    _log(log_func, f"Auto-fix: resolved chromedriver at {path}")
    return path

That fixed launches once Brave caught up. But I still want to know when it happens without grepping logs at 7 a.m.

Almost Done: 27/30 and a Hangup

Late on July 17, after auto-fix worked, the bot resumed Grow-only mode and sent connections steadily — until:

Progress: 27/30 connections sent (grow)
Progress: 28/30 connections sent (grow)
Cleaning up bot browser processes...
./schedule/daily_run.sh: line 19: 52556 Hangup: 1               "$VENV_PYTHON" run_bot.py

Two short of the cap. Killed by SIGHUP. Without exported counters, the only signal is a progress line buried in a 700-line file.

Stale Locks

While one process is still running, the next hourly check logs: Another bot run is already in progress (pid 51947). Skipping. Earlier that evening I saw: Removing stale lock file. The lock logic is correct. Interrupted runs still leave footguns. Metrics like bot.driver_errors and bot.session_crashes surface this on a dashboard instead of me tailing files.

One Module, Three Signals

Everything lives in Scripts/telemetry.py — OTLP gRPC to port 4317, gated by SIGNOZ_ENABLED. Each run gets a 12-character bot.run_id on traces, metrics, and logs.

Spans: bot.run, bot.configure_browser, bot.login, bot.search_page, bot.accept_invitations, bot.connect_from_grow, bot.recover_session.

Metrics: bot.connections_sent (label source=search|grow), bot.invitations_accepted, bot.driver_errors (error_type=version_mismatch), bot.session_crashes, bot.run_success / bot.run_failure, bot.run_duration_seconds.

Main loop wiring:

tel.init_telemetry()
tel.log_event(logger, "Bot run started", phase="start")

with tel.span("bot.run", phase="run"):
    configurations()
    login(webpage, user)
    tel.record_run_outcome(success=not run_failed, connections_sent=connections_sent)
    tel.record_run_duration(time.time() - run_started_at)

On driver mismatch: tel.record_driver_error(error_type="version_mismatch") before auto-fix runs.

Logs append run_id and phase for trace correlation in SigNoz Logs Explorer:

Verify telemetry smoke test | run_id=87626c6dc93a phase=verify
trace_id=7b69827901b867b9f0658ed774ff684d  span_id=0e08651f63956788

One lesson I keep relearning: logs need explicit OTLP export. telemetry.py wires a LoggingHandler plus OTLPLogExporter — stdout files alone aren't enough.

Three-Pillar Correlation — The Part I Care About Most

SigNoz's real payoff for me isn't three separate tabs. It's jumping between logs, traces, and metrics without rebuilding queries. Unified observability means one run_id on every signal, and SigNoz UI links that carry filters and time range when I drill down (dashboard interactivity).

How my bot wires it

Pillar	What I emit	Correlation hook
Traces	Spans like `bot.run`, `bot.login`, `bot.connect_from_grow`	`bot.run_id` span attribute; root span wraps the whole cron run
Metrics	`bot.connections_sent`, `bot.run_success`, etc.	Same `bot.run_id` label on every counter/histogram sample
Logs	`log_event()` lines with `run_id=` and `phase=` in the body	`LoggingInstrumentor` injects `trace_id` / `span_id` when the log fires inside an active span (official guide)

Logs emitted inside a span carry both domain context (run_id=87626c6dc93a phase=verify) and OTel trace context (trace_id=… span_id=…). That second pair is what powers SigNoz's View trace button on a log line. Metrics don't get trace IDs on every sample — I correlate them through the shared bot.run_id label instead. SigNoz also derives APM/RED metrics from span data automatically (APM metrics from traces), which gives me operation-level rates alongside my custom bot.* counters.

Walkthrough: one smoke test, three pillars

After ./venv/bin/python Scripts/verify_telemetry.py prints run_id=87626c6dc93a:

Logs → trace. I open Logs Explorer, filter service.name = linkedin-connection-bot, and find Verify telemetry smoke test | run_id=87626c6dc93a phase=verify. The row shows trace_id and span_id. I click View trace (or the trace ID link). SigNoz opens the bot.verify_telemetry span — the same run I just emitted.
Trace → logs. On that trace's span detail panel I open the Logs tab (span details). SigNoz shows the correlated log line from step 1 without me re-filtering by hand. I can also click Go to related logs from the trace list view.
Trace → metrics. Back in Metrics Explorer I query bot.connections_sent with aggregation Sum, group by bot.run_id, and filter bot.run_id = 87626c6dc93a. I see source = verify with value 1 — the counter incremented inside the same span that produced the log. For a demo run with twelve simulated runs (signoz_demo_data.py), I group by source and spot the grow spike that matches a bot.connect_from_grow span in Traces Explorer.

That's the July 17 hangup story in reverse: instead of grepping 700 lines for Progress: 27/30, I click a log from the failed run, jump to bot.run, and check whether bot.connections_sent stopped climbing for that run_id.

Verify correlation in the SigNoz UI (5 minutes)

Run the smoke test, wait ~10 seconds for export, then check each pillar:

Step	Where	What to confirm
1	Logs Explorer → filter `service.name = linkedin-connection-bot`	Body contains `run_id=`; log attributes or body include `trace_id` and `span_id`
2	Click a log row → View trace	Trace opens with span `bot.verify_telemetry` and `bot.run_id` attribute
3	Trace detail → Logs tab	Same smoke-test log appears in the correlated panel
4	Metrics Explorer → `bot.connections_sent`, Sum, group by `bot.run_id`	Sample for your smoke-test `run_id` with `source = verify`
5	Traces Explorer → `service.name = linkedin-connection-bot`, span name `bot.verify_telemetry`	Span attributes include `bot.run_id` matching the log and metric label

If logs show run_id= but no trace_id, the log probably fired outside an active span — I make sure tel.log_event() calls sit inside with tel.span(...). If View trace is missing, I confirm LoggingInstrumentor ran (SDK OTLP export path per log collection methods) and that I'm on current telemetry.py with OTLP log export enabled.

Standing Up SigNoz and Verifying

docker compose -f pours/deployment/compose.yaml up -d
curl -s http://localhost:8080/api/v1/health   # {"status":"ok"}
nc -z localhost 4317 && echo "OTLP gRPC reachable"

./venv/bin/python Scripts/verify_telemetry.py
# run_id=87626c6dc93a

# Optional: realistic demo runs for dashboard screenshots (no LinkedIn traffic)
./venv/bin/python Scripts/signoz_demo_data.py --runs 12 --delay 2

A ClickHouse verification script confirmed logs, traces, and metric samples after smoke tests. For blog screenshots I also run signoz_demo_data.py, which emits a dozen simulated runs with varied run_ids, source=search|grow|verify on bot.connections_sent, histogram samples on bot.run_duration_seconds, and a mix of bot.run_success / bot.run_failure.

Tip: SigNoz Metrics Explorer defaults counters like bot.run_success to Rate over Last 30 minutes. Sparse cron jobs look empty even when data exists. Switch to Sum over Last 24 hours (or run demo data recently) to see cumulative run counts. Spans like bot.login and bot.connect_from_grow still need a full run_bot.py run — I skip that during verification to avoid live LinkedIn side effects.

Dashboards and Alerts (Designed, Not Yet Fired)

From my dashboard notes, the panels I build first: run health (bot.run_success vs bot.run_failure), throughput by source, driver errors plus session crashes, run duration p95, and recent bot.run traces.

Alert targets for my setup:

bot.run_success sum over 26h = 0 — no successful daily run (26h allows launchd drift)
bot.driver_errors where version_mismatch, sum over 1h > 0
bot.session_crashes sum over 15m > 0
No bot.* metric data for 26h — telemetry pipeline dead

I haven't fired these in production yet. They're the guardrails I wish I'd had before July 17.

What I Do Differently Now

Instrument before the first scheduled run. A verify_telemetry.py smoke test on day one beats log archaeology.

Partial runs need explicit failure signals. Stopping at 27/30 should increment bot.run_failure with connections_sent=27, not look like quiet success.

Put OTEL_* in .env, not just your shell. run_bot.py loads .env with override. My interactive shell had stale exports that confused early tests.

Headless Selenium observability is about phase spans and batch counters, not HTTP latency. But the pattern — one run_id on every signal — transfers to any cron-driven browser job.

The Bot Isn't Mysterious — It's Unobserved

ChromeDriver mismatches, stale locks, and a SIGHUP at 28/30 all leave evidence in flat files. Nothing aggregates it. OpenTelemetry plus SigNoz gives me one place to ask: did today's run succeed? How many connections? Which phase failed? Was it the driver again?

This works for my setup: local SigNoz via Docker, OTLP gRPC on 4317, macOS launchd, headless Brave. Your mileage will vary.

The full project — bot, telemetry module, SigNoz compose stack, verification scripts, and dashboard notes — is on GitHub:

https://github.com/Sumit884-byte/linkedin_connection_bot

If you're running a headless browser job on a schedule and only checking log files afterward, start with a smoke test and three signals. You'll thank yourself the first time ChromeDriver and Brave disagree.

Screenshots

ui-logs-linkedin-bot.png

ui-traces-bot-run.png

ui-metrics-connections-sent.png

ui-metrics-run-success.png

ui-services-overview.png

#	File	Use in section
1	`ui-logs-linkedin-bot.png`	Instrumentation / SigNoz verification — Logs Explorer with `run_id`, `phase`, trace correlation
2	`ui-traces-bot-run.png`	SigNoz verification — `bot.verify_telemetry` spans
3	`ui-metrics-connections-sent.png`	SigNoz verification — `bot.connections_sent` by source
4	`ui-metrics-run-success.png`	SigNoz verification — `bot.run_success` over 24h
5	`ui-services-overview.png`	SigNoz verification — Services page with `linkedin-connection-bot`