Forem: Supriya

Product Mindset Is the Skill Vibe Coding Can't Replace

Supriya — Tue, 31 Mar 2026 05:05:00 +0000

Everyone Can Ship Now. That's the Problem.

A few weeks ago, I built a full quiz app in three hours. Peaky Blinders on one window, Claude on the other. I described what I wanted, and it appeared. I didn't write a single component. I didn't set up a build tool. I didn't think about routing.

I just thought.

That's what vibe coding does. It collapses the distance between idea and implementation so dramatically that the bottleneck is no longer "can you build it" but "do you know what to build."

And most engineers, myself included, are quietly underprepared for that shift.

The Cost of Building Used to Do the Thinking For You

For a long time, the cost of building was a forcing function for clarity. If you were going to spend two weeks on something, you'd better understand it well enough to defend your decisions. The effort of implementation forced you to ask the uncomfortable questions early, because asking them late was painful and expensive.

Vibe coding removes that friction. Which is mostly great. Genuinely. You can go from idea to working thing in an afternoon, and that's kind of wild.

But it also means you can now ship something confidently without ever asking the questions that used to be forced on you by circumstance.

What problem does this actually solve? For whom? What does success look like? What are the tradeoffs? What happens when it scales? What's the failure mode?

These aren't engineering questions. They're product questions. And they've always mattered. They just used to have a built-in enforcer. That enforcer is gone now.

I Felt This Firsthand Building Go Mastery

When I sat down to build Go Mastery, my first instinct was the engineering instinct: what components do I need, how does state flow, what's the data model.

Then I caught myself. This was supposed to be about learning Go, not building a React app to learn Go. Those are very different projects. If I'd gone down that path I'd have spent three hours on architecture and zero hours thinking about whether the quiz would actually teach anything. I'd have shipped a beautiful, thoroughly useless piece of software.

So I forced myself to stay in the product questions first.

Why do most quizzes fail to produce real learning? Because they're built to be completed, not understood. One obviously right answer surrounded by obvious decoys. You don't need to understand anything. You just need to not be distracted. It's less of a test and more of a vibe check.

What would a quiz look like if it made that strategy impossible? One wrong answer surrounded by options that all sound plausible. Suddenly you can't pattern-match your way through. You have to actually think.

What would make it even harder to shortcut? A pushback mechanic. 60% of the time, after you answer, the quiz asks "are you sure about that?" You never know if you're wrong or just being challenged. So you pause, reread, and, if you're like me, briefly question every choice you've made.

None of that thinking required code. It required understanding the problem deeply enough to have opinions about the solution. The implementation took three hours because the thinking happened first.

That's the product mindset. And vibe coding doesn't give it to you. It just makes it more visible when you don't have it.

Hallucinations Are the Same Problem, Wearing Different Clothes

Here's where it gets interesting.

AI hallucinations and learning misconceptions are structurally the same problem. In both cases, something that sounds correct isn't. In both cases, the danger isn't obvious wrongness. It's plausible wrongness. The output that's 90% right and 10% subtly broken is far more dangerous than the output that's just clearly wrong, because at least the clearly wrong answer is easy to catch.

Spotting the obviously wrong answer is table stakes. Spotting the wrong answer when everything around it sounds reasonable, that's the actual skill.

This is why I think misconception-spotting is becoming one of the most underrated skills in engineering. Not skepticism for its own sake, not compulsive fact-checking on every sentence. The specific ability to read something that sounds authoritative and plausible, hold it up against what you actually know, and find exactly where it goes sideways.

That skill is directly trained by building with AI. Every time you prompt Claude or GPT and get back something that's almost right, you're exercising it. Every time you catch a hallucination before it ships, you're getting sharper. It's like going to the gym, except the gym occasionally tries to convince you that goroutines work like JavaScript promises.

The engineers who will thrive in the vibe coding era aren't the ones who can prompt best. They're the ones who can evaluate output best. And evaluating output requires the same thing that evaluating quiz answers requires: understanding the concept deeply enough to know why something is wrong, not just that it is.

What This Means Practically

A few things I've changed about how I work since building Go Mastery:

Before writing a prompt, write the brief. What problem am I solving? Who has this problem? What does good look like? What are the constraints? Five minutes of this saves thirty minutes of iteration and one very confusing diff.

Treat AI output like a quiz answer. Not "is this right?" but "where is this wrong?" The assumption of correctness is the trap. The default should be "this is probably mostly right and I need to find the part that isn't." It usually isn't hard to find.

Study the concepts, not just the syntax. Vibe coding makes it easy to ship Go without understanding Go. But when the hallucination shows up (and it will), you need the mental model to catch it. Surface-level familiarity doesn't give you that. Understanding does.

Think in problems, not features. The question "what should I build?" is less useful than "what problem am I solving and is this the right solution?" Features are easy to generate now. Problems worth solving are still hard to find, and no amount of prompting helps with that part.

The Skill Stack Is Shifting

We're not heading toward a world where engineering skills don't matter. We're heading toward a world where the engineering skills that matter most are shifting up the stack.

Implementation is getting cheaper. Understanding is getting more valuable. Product thinking, knowing what to build, for whom, and why, is becoming the differentiator.

That's not a threat to engineers. It's honestly a pretty good development if you're willing to lean into it. The engineers who've always wanted to think at the product level but got stuck in implementation details now have the tools to do both. The ones who only ever thought about implementation are going to find that better tools make the work harder, not easier, because the tools expose what was always true: code was never the hard part.

Vibe coding doesn't replace thinking. It just makes thinking the job.

I write about Go, full-stack development, and shipping projects without overthinking them. Follow along on LinkedIn if this resonated.

Building Go Mastery: Socratic Learning, Claude Artifacts, and the Art of Productive Struggle

Supriya — Wed, 11 Mar 2026 10:43:47 +0000

I came to Go from the React world. Frontend was comfortable. I knew the mental model: components, props, state, async with promises, then().catch(), async/await. It felt like home.

Go felt like moving into a new city where everything is slightly off. The streets look familiar but the traffic flows the wrong way.

The typed, compiled mindset was an adjustment. JavaScript lets you be loose; Go does not. But the thing that genuinely baffled me was concurrency. In JS, async is a pattern layered on top of the language. Promises chain. await suspends. The mental model, once you have it, is linear.

Goroutines don't work like that. There's no await. No .then(). You launch a goroutine and it runs alongside everything else, communicating through channels. I kept reaching for the async mental model I already had and kept grabbing at air.

That's when I realized the problem wasn't Go. It was that I was trying to learn it the same way I'd learned everything else: skim, pattern-match, move on. For React, that worked. For Go's concurrency model, it absolutely did not.

One Tuesday Afternoon and a Claude Subscription Going to Waste

Around that time, I kept thinking my Claude subscription wasn't pulling its weight. Then one Tuesday after spring break, I finally had a breather. I opened up their Cowork app and started poking around. One thing led to another and I found a remixable hallucination detection game sitting there. It clicked immediately.

We're living in a world flooded with AI-generated content. Finding the wrong pattern, the thing that sounds right but isn't, is becoming a genuine skill. That framing mapped perfectly onto what I was struggling with in Go. I decided to remix it.

I spent three hours that afternoon prompting and thinking through the product on breaks, with Peaky Blinders running on the other window. What surprised me was how easy it felt to describe what the app should do without worrying about the how. That's usually not how I work. As a frontend engineer, I think in components, in implementation. But this was supposed to be about learning Go, not building a React app to learn Go. If I'd done it the other way, I'd have missed the whole point.

So I stayed in the prompt. I brainstormed streaks to keep users coming back. I worried about the wait time between questions. Every question was a fresh API call and the pause felt wrong. The frontend engineer brain kicked in immediately: just add a loader. So I did. But a loader alone felt lazy, so I asked Claude to show random quotes from Go talks and well-known Go engineers while users waited. That helped.

Then came the caching question. I'd recently learned what caching was, in that early curious way where you start seeing it everywhere. My new backend instincts whispered: this is a perfect place to cache something. But I wasn't sure if a cache could be shared across different users. Turns out, with Claude artifact storage, it can.

The design fell into place naturally: shared storage for generated questions, personal storage for each user's streak and progress. The first user to load the app takes the hit of generating questions. Everyone after that gets them instantly. And the more users play, the richer the question pool gets, and the faster it gets for the next person.

That was the first working version. But building it forced me to confront something I'd been doing wrong for years.

The Problem with Most Quizzes (and How I Broke the Format)

I've been cheating myself for years.

Not on exams. On learning. There's a difference, and building this app made me finally see it.

The pattern showed up first in grad school, then again as I started learning Go. I'd sit down for a quiz, skim the options, and pick the answer that felt right. Not because I understood the concept. Because I'd gotten good at finding the odd one out, the option that didn't match the vibe of the others.

I was pattern-matching, not thinking. And it worked often enough that I never questioned it.

That's the problem with most multiple-choice quizzes: they're built to be completed, not understood. One obviously right answer, three obvious decoys. You don't need to understand anything. You just need to not be distracted.

So I flipped it. Instead of one right answer surrounded by wrong ones, Go Mastery has one wrong answer surrounded by options that all sound plausible. Suddenly you can't skim for vibes. You have to read. You have to think. You have to know the why, not just spot the outlier.

And I made it harder still. 60% of the time, after you pick an answer, the app pushes back: "Are you sure about that?" You never know if it's because you're wrong or just unlucky. So you pause, reread, rethink. If you do fail, you get three more tries and a mini lesson that explains what you missed. Failure stops being "you lost" and starts being "here's what you didn't understand."

The Deployment Question: Knowing When to Stop

With the quiz working and the format redesigned, one question remained: does this actually need to be deployed?

That's not laziness. It's a real design decision. I'm in grad school. I don't have weekends. And "deploy it properly" means ongoing maintenance, billing alerts, and infrastructure decisions that compound over time. Before committing to any of that, I wanted to understand what I was actually signing up for.

So I did the math.

A typical question generation on Sonnet runs about 1,200 input tokens + 600 output tokens, roughly $0.012 per question. Add a doubt challenge, a hint, and a lesson for a user who struggles, and a full 10-question session costs around $0.24.

That sounds fine until you think about scale:

100 users/day → $540/month
500 users/day (one Reddit post) → $2,700/month
1,000 users/day (viral) → $5,400/month

(These estimates use Anthropic's Sonnet 4.5 pricing as of early 2026. Always verify current rates before building on this math.)

That's the deployed version. The artifact version costs me nothing to run.

Option 1: Deploy with my API key. Polished, standalone, mine. Also, a billing liability I can't monitor from an assignment deadline.

Option 2: Stay in Claude artifacts. Less control over uptime and updates. Every change means republishing. But users can fork it, remix it, make it their own. And the marginal cost to me is zero.

I chose artifacts. Not because it was easier, but because it was the right tradeoff for this stage. A freely remixable tool that reaches more learners beats a locked-down app I'd eventually neglect.

The Caching Layer: How It Actually Works

If you want to build something similar on top of Claude artifacts, here's the technical reality of the caching layer.

Claude artifact storage gives you two modes: personal and shared. Personal storage is scoped to each user — that's where I store streaks and session progress. Shared storage is visible to everyone who loads the artifact — that's where the generated questions live.

The virtuous cycle this creates:

The first user loads the app and triggers question generation, which seeds one question per topic into shared storage
Any user who clicks "Generate" adds more questions, also cached to shared storage
Every user after that skips generation entirely and pulls from cache
The pool grows organically over time, and API calls drop toward zero

The cache caps at 5 questions per topic. Once full, new generations push out the oldest so the pool stays fresh without growing unbounded.

A few constraints worth knowing if you build on this:

20 MB limit per artifact — more than enough for text-based question data
Text only — no images or binary data
Only works when published — storage operations fail in development, so you have to publish to test the caching layer

The one real tradeoff: updating the question set requires republishing the artifact. That's fine for my use case. But if you need live updates, you'd want a different architecture.

What This Is Really About

Go Mastery started as a Tuesday afternoon side project. It ended up teaching me more about learning than Go did.

The throughline across every decision: make the right things harder, not easier.

Hard to pattern-match answers. Hard to mindlessly click through. Hard to walk away without understanding why you got something wrong. That friction isn't a bug in the design. It's the whole point.

The same principle applied to how I built it. The easy path was spinning up a React app. The better path was staying in the prompt, describing what I wanted, and letting the tool handle the how. That's a different kind of thinking, and it's one I needed to practice.

If you're learning Go, or building learning tools, or just trying to ship something without overthinking it: Go Mastery is here. Fork it, change the topic, make it yours. Try it. Struggle a little. That's the point.

I write about Go, full-stack development, and shipping projects without overthinking them. Follow along on LinkedIn if that sounds useful.

How to set up SSH keys for signed commits

Supriya — Mon, 16 Jun 2025 18:54:46 +0000

SSH keys are used to access and write data into your GitHub repository. Whenever you connect via SSH, you authenticate using the private key file on your local machine.

Before creating a new key, check if you already have one:

# on linux
ls ~/.ssh

# on Windows
ls c:/Users/<your name>/.ssh

Look for files like:

id_rsa  id_rsa.pub  or  id_ed25519  id_ed25519.pub

1. Create your SSH key

You can generate your SSH key pair using ssh-keygen. Many algorithms generate an SSH key pair. Here, we specify the Ed25519 algorithm using the -t flag. The -C flag allows us to add a comment to identify the key and is optional.

ssh-keygen -t ed25519 -C "your_email@example.com"

This generates an SSH key pair (public and private keys) in the c:/Users/<yourName>/.ssh folder on Windows.

Your key pair is saved as:

c:/Users/<yourName>/.ssh/id_ed25519 (private)

c:/Users/<yourName>/.ssh/id_ed25519.pub (public)

On Linux, this is usually: ~/.ssh/. Listing the files in the folder shows two files.

ls


id_ed25519  id_ed25519.pub

2. Add the SSH Key to the SSH Agent

eval $(ssh-agent -s)

# on Linux
ssh-add ~/.ssh/id_ed25519

# on Windows
ssh-add /c/Users/<yourName>/.ssh/id_ed25519

3. Copy the public key

cat shows the file's content. The pipe (|) operator feeds this content as input to the clip command. This copies the file content to your clipboard.

cat ~/.ssh/id_ed25519.pub | clip

4. Add the public key to your GitHub account

Go to GitHub → Profile Icon → Settings.

Navigate to SSH and GPG keys

Click New SSH key

Give it a title (e.g., “Laptop - June 2025”) and paste the key

Since we are using this key to sign our commits, make sure you change the "Key type" to Signing key.

5. Testing your SSH connection

ssh -T git@github.com

You should see something like this after you enter your passphrase (if you configured it while generating the SSH key pair).

If you also want to authenticate repositories with this SSH key, add the same public key again as an Authentication key under SSH and GPG keys → New SSH Key → Change "Key Type" to Authentication key.

6. Use SSH for Your Repo Remote (optional)

If your repo was cloned using HTTPS, you'll need to switch to SSH to use this key to push changes.

git remote set-url origin git@github.com:yourusername/yourrepo.git

7. Signing commits

Enable commit signing and specify SSH key format

git config commit.gpgsign true

# or enable it globally

git config --global commit.gpgsign true

Configure Git to use SSH to sign commits and tags:

git config --global gpg.format ssh

To set your SSH signing key in Git, paste the text below, substituting /PATH/TO/.SSH/KEY.PUB with the path to the public key you'd like to use.

git config --global user.signingkey /PATH/TO/.SSH/KEY.PUB

8. Check for verification on your new commit

When committing changes in your local branch, add the -S flag to the git commit command.

git commit -S -m "YOUR_COMMIT_MESSAGE"
# Creates a signed commit

If you configured a passphrase while setting up the SSH key, provide it. Otherwise, leave it blank.

Now, visit the commits in your repository to check the verified status.

Resources:

A brief overview of HTTP protocol

Supriya — Fri, 18 Aug 2023 10:53:42 +0000

Introduction

Let's start with the basics. The web works on client and server model. Where the Client initiates the request. It passes through the internet and reaches the server. The server then processes it and sends it a response the same way it arrived.

Client - usually the browser. But can also be a web crawler bot indexing the search results.
Internet - many networks of connected computers
Server - THE computer that responds to that particular request

HTTP

HTTP stands for Hypertext Transfer Protocol. But what is Hypertext? Hypertext is a way of linking text to other text or resources. It is the underlying concept of the World Wide Web, where web pages are interconnected by hyperlinks. It is a text which you see on a computer, and on clicking on it redirects to the resource. Furthermore, this resource is a document (usually HTML files) present on a computer (it can be any computer. Be it yours or someone else's on cloud). And now, what is a Protocol? To send this request to the server, we need to follow some standard rules/protocols.

In short, HTTP is the standard set of rules, which describe the way we can make a request, that allows us to transfer a text/file/media (hypertext/hypermedia) over the internet.

Between the client and the server, there are many entities (routers, switches, load balancers) through with the requests get passed. But discussing them would be out of scope for this article. You can read more about this here.

It's Simple and Stateless

All the HTTP messages are human-readable, which makes it easier for the developers to debug and reduces complexity. Whenever a request is made from the client, the server doesn't store any information; which makes it stateless.

You might question, if the server doesn't have the data from previous requests, how will it be able to keep track of what response to send for an authenticated user or a user with different permissions?
Well, though it is stateless; it can keep track of this data using cookies, whenever a new session is created. This is where we store the JWT tokens of an authenticated user in HTTP Header, to let your server know that the user is logged in.

Building Blocks

HTTP is built on top of TCP/IP protocols and consisted of 4 blocks

textual format to represent Hypertext files (HTML)
protocol to exchange these files (HTTP)
client to display these files (browser)
server to give access to these files

Evolution on HTTP

HTTP/0.9

The initial implementation of HTTP was remarkably straightforward. It's also called one-line protocol, which contained only GET method followed by the path to the resource.

REQUEST

GET /fancyWebPage/index.html

RESPONSE

<html>
  HTML page with only text. 
  No images or other resources are included in this file.
</html>

only GET method was provided to access the resources
no HTTP Headers. The response was always a (HTML) file.
no status or error codes. If there was an error, an HTML file with the generated error description was sent.

HTTP/1.0

versioning was added at the end of the resource path.
status code was also sent at the beginning of the response.
HTTP Headers were introduced for both request and responses, which allowed us to send metadata.
This allowed us to transfer documents other than plain HTML if its respective HTTP header value was included in Content-Type
The connection is closed after the response is received. We need to create a new connection for every request.

REQUEST

GET /fancyWebPage/index.html HTTP/1.0
User-Agent: BrowserName/3.0 (OS-Name 2.0)

RESPONSE

200 ok                               # status code
Date: Fri, 11 Aug 2023 12:23:22 IST  # metadata
Server: company/2.0 project/2.8      # metadata
Content-Type: text/html              # metadata
<html>                               # html content
  HTML page with images and other file content. 
  <img src="/cat.png" />
</html>

If the response contained, other resources; subsequent calls are made to the server to fetch them. Here, in the next call, the browser makes a call to the server to fetch the cat.png file.

HTTP/1.1

it introduced 'keep-alive' mechanism. Connections can be reused. There's no longer a need to open multiple connections for each request.
Pipelining was introduced, which allowed the client to make a new request without waiting for the response from the previous one. The responses were sent in the order they were requested.
- But this couldn't be handled well by the proxy servers(entities) between the client and server.
Cache control mechanisms and support for chunked responses was added.
It was easier to create new Headers and methods. It was stable for more than 15yrs.

Here's an image from MDN showing the request/response structure.

HTTPS
Netsape came up with additional layer SSL on top of HTTP to encrypt the transmission of messages between client and server.

Authoring before REST
When the World Wide Web(browser) was created by Tim Berners-Lee, he wanted to create a medium, where everyone can share, edit, create and share the documents over the internet. But eventually, the webpages became read-only for most users. The write access was limited to few folks, who can change these documents on the servers.

In 1996, people of World Wide Web consortium addressed the problem of authoring on the web and HTTP was extended to allow authoring, creating WebDAV - Web Distributed Authoring and Versioning. It is an extension to HTTP that lets clients edit remote content on the web. Any server that supports WebDAV can act as a file server. There are other extentions like CalDAV which allows the client to schedule events on the server and CardDAV, which allows you to share the contact informatiom on the remote server which work similarly.

Popular clients of WebDAV are Microsoft Office, OpenOffice, DropBox, etc. Any fie sharing system you can think of uses WebDAV behind the scenes to create/ share/ modify/ delete your files or folders over the internet.

✨REST✨

In 2000, Representational State Transfer (REST) was designed to use the HTTP protocol. It uses the basic methods defined in HTTP/1.1 and allowed any web application to modify the data, without the need to update its servers. One drawback of it was each website defined its own RESTful APIs and had complete control over them.

Think of this as using an open API(MovieDB) on your website, to display the content, but also allowing your clients to modify the data(marking a movie as favourite). But any modification of the data wouldn't effect the data in server where the Open API's being hosted. But instead, these changes are persisted on your website server where you handle these changes on top of Open API data.

HTTP/2

As webpages became complex, more scripts being added for interactivity of the webpage... more and more data was being transfered through the HTTP requests. This created more overhead for the HTTP/1.1 connections. In early 2010, Google created an experimental protocol SPDY, which laid foundation for HTTP/2.

Officially standardised in 2015 and 35.7% of websites use HTTP/2

Binary protocol, unlike HTTP/1.1 which is text based
multiplexed protocol. Enables the client to make parallel requests.
It compresses headers, which are common for similar set of requests. This removes duplication and overhead of data transmitted.
Server push. This allows the server to populate the client cache

HTTP/3

It uses QUIC instead of TCP in the transportation layer. 26.5% of websites use HTTP/3. QUIC is a connection-oriented protocol that creates a stateful interaction between a client and server. QUIC authenticates the entirety of each packet and encrypts as much of each packet as is practical. QUIC packets are carried in UDP datagrams [UDP] to better facilitate deployment in existing systems and networks.

Initially an acronym QUICK was described as Quick UDP Internet Connections, but RFC 9000 mentions it as name, not an acronym.

multiplexed protocol, unlike HTTP/2 which runs on single TCP connection. QUIC runs on multiple UDP streams.
Endpoints communicate in QUIC by exchanging QUIC packets. Most packets contain frames, which carry information and application data between endpoints.
Application protocols exchange information over a QUIC connection via streams, which are ordered sequences of bytes.
- bidirectional streams, which allow both endpoints to send data;
- unidirectional streams, which allow a single endpoint to send data.
A credit-based scheme is used to limit stream creation and to bound the amount of data that can be sent.
QUIC depends on congestion control to avoid network congestion using QUICK-RECOVERY algorithm for detecting and recovering losses.

How to create a server with HTTP/2/3 protocol?

Many programming lanaguages have in-built libraries, for us to create servers. Node.js has http, http2 libraries to build implement servers with HTTP protocols.

Golang has similar libraries http, and http2, http3✨

But the support for creating servers which use HTTP/3 is still a work in progress in Node.js community. As of today, 18 Aug 2023, there's no library available for us to get on HTTP3.

Keep track of HTTP/3 and QUIC

Node.js - status : currenly blocked on QUIC implementation #38478

Reference
HTTP - MDN Docs
What is WebDAV
RFC 9000

Icon by Freepik