DEV Community: Aryan Choudhary

My Dad Said: Start With Compute. Now I See Why.

Aryan Choudhary — Sat, 07 Mar 2026 21:01:27 +0000

When I told my dad I had started learning Azure, he asked me one question.

“Where did you start?”

I mentioned tutorials, some documentation, and browsing the portal.

He said something simple:

“Start with compute. Everything else in the cloud builds on top of it.”

At the time, it sounded obvious. Of course applications need computers to run.

But when I opened the Compute section inside Azure, I started seeing what he actually meant.

The moment cloud stopped being abstract

In tutorials, cloud computing often feels very conceptual.

You hear words like scalability, high availability, distributed systems, and managed services.

But those are still ideas.

When you open the Compute section in Azure, the abstraction disappears.

Suddenly you see things like:

Virtual Machines
Virtual Machine Scale Sets
Images
Availability Sets

At first glance, it looks like a lot of different services.

But underneath, they all revolve around one question:

Where does your code actually run?

Because before anything else in the cloud can exist - databases, APIs, storage, authentication - something has to execute the code.

And that something is compute.

Virtual Machines: the cloud version of “another computer”

The first thing that stood out to me was Virtual Machines.

I already knew the concept. A virtual machine is basically a computer running inside another computer.

But seeing it in the cloud made it feel different.

Instead of running a VM on my laptop, Azure was essentially offering me a computer somewhere in a data center.
CPU. Memory. Disk. Operating system. All configurable.

Which immediately made me realize something:
Running a VM isn’t just about deploying code. It means you’re responsible for the machine.

That includes things like:

managing the operating system
updating dependencies
monitoring resource usage
handling crashes
planning for scaling

Suddenly cloud felt less like a magic deploy button and more like real infrastructure, And that's when it made sense for me...

Why abstraction exists in the first place

This also made me appreciate platforms like Vercel more.

When I deploy projects there, I never think about:

CPU
RAM
operating systems
load balancing

Those problems are handled for me.

Azure still provides those abstractions too, through services like App Service and Functions.

But it also lets you go deeper.
And that’s the interesting part.
Cloud platforms operate on layers of abstraction.

At the lowest layer, you have machines.
At higher layers, those machines disappear behind managed services.

Understanding compute is like seeing the foundation under the building.

The moment cloud felt more real

Before this, deployment always felt like the final step of building something.

You finish coding, push your repo, click deploy, and move on.

But seeing compute changed that perspective slightly.
Deployment isn’t the end. It’s the point where your code finally meets the machines that will run it.

And suddenly questions like these start to matter:

How many machines are running my app?
What happens if one crashes?
What happens when traffic spikes?
How much does it cost to keep these machines running?

I still have a lot to figure out

Ironically, I wasn’t even able to experiment much yet because I ran into an account issue while trying to explore the free tier.

So most of this realization came just from exploring the compute section and thinking through what these services represent.

But even that small exploration already made the cloud feel less mysterious and more tangible.

Where this journey goes next

This is the second step in a small series where I’m documenting what I learn while exploring Azure and cloud architecture.

Last time, I wrote about opening the Azure Portal and realizing how big the cloud ecosystem actually is.

This time, I realized something simpler:

Everything eventually comes back to machines.

Compute is where cloud stops being abstract and starts becoming engineering.

And now I’m curious:

If you’ve worked with cloud platforms longer than I have,
what was the moment when cloud finally “clicked” for you?
Was it compute, networking, containers, something else entirely?

Because I feel like I’ve only just found the first layer.

I Clicked ‘Azure Portal’ and Realized How Small My World Was

Aryan Choudhary — Mon, 23 Feb 2026 18:03:43 +0000

When I opened the Azure Portal for the first time, my first instinct wasn’t curiosity. It was panic.

There were hundreds of services. Compute. Storage. Networking. DevOps. Identity. Containers. Things I had never used. Things I didn’t fully understand. Things I didn’t even know existed.

It felt less like opening a tool and more like opening control panel for the internet itself. Up until now, my mental model of deployment was simple.

I build something in React or Node.
I push to GitHub.
I connect it to Vercel.
I click deploy.
It works.

My app is live. End of story. Yay.

I never really questioned what happened after that.
Not because I didn’t care, but because I didn’t need to.

Platforms like Vercel are designed to remove friction. They hide infrastructure. They give you a clean interface where deployment feels instant and effortless.

But that abstraction also hides something important: the system underneath.

Azure doesn’t hide the system. It exposes it.
And that’s when I realized how small my world had been.

Before this, “cloud” was mostly a conceptual idea to me.

I knew the definitions. I knew cloud meant running software on remote servers instead of your own machine. I knew it helped with scaling, reliability, and availability.

But those were just words. Opening Azure made it real.

I wasn’t just deploying code anymore. I was seeing the environment that makes deployment possible. I started seeing that every running application depends on multiple layers beneath it.

There’s compute: the actual machines that execute your code.
There’s storage: where your files, databases, and state live.
There’s networking: how different parts of your system communicate with each other.
There’s identity and access control: deciding who can access what.
There’s monitoring: tracking what happens when things fail.
There’s scaling: handling more users without crashing.

When I deployed to Vercel before, all of this still existed. I just never saw it.

Vercel handled it for me.
Azure showed it to me.
And seeing it changed how I think about software.

One thing that confused me initially was why Azure had so many separate services. It felt unnecessarily complicated.

Why couldn’t it just be one “Deploy App” button?

The answer became clearer the more I thought about real-world systems. Not all applications have the same requirements.

A personal portfolio might only need basic hosting.

But something like a banking system needs strict network isolation, encrypted storage, identity management, access policies, backup systems, regional failover, and detailed monitoring.

These aren’t optional features. They’re requirements.

Platforms like Vercel simplify things by making decisions for you. Azure gives you the ability to make those decisions yourself.

That flexibility is what makes it powerful. It’s also what makes it overwhelming at first.

This also helped me understand where DevOps fits into the picture.

Before this, my workflow ended at deployment. Once the app was live, I moved on. But in real systems, deployment isn’t the end. It’s part of a continuous lifecycle.

Code needs to be built automatically, tested automatically, deployed automatically, monitored continuously, and recovered automatically when failures happen.

DevOps connects development and production into a single, reliable system. It ensures software doesn’t just run once, but continues running reliably under real-world conditions.

Another realization was that Azure isn’t fundamentally different from platforms I’ve already used. The architecture is actually very similar.

A typical application I build might have:

A React frontend
A Node backend
A database

On Azure, those same pieces exist.

The frontend can run on Azure Static Web Apps.
The backend can run on Azure App Service.
The database can run on Azure SQL or Cosmos DB.

The structure is the same. The difference is visibility and control.

Azure shows you how everything connects. It exposes the building blocks.

This also made me understand the role of a Cloud Solution Architect better.

Initially, I assumed cloud providers handled everything.
But cloud providers don’t design your system. They provide the tools.

Architects design how those tools are used.

They decide how services connect, how systems scale, how security is implemented, and how failures are handled. They design the structure that allows software to run reliably in the real world.

Azure provides the pieces. Architects decide how to assemble them.

What surprised me most wasn’t how much I didn’t know.

It was how much existed beneath the surface of things I thought I already understood. Deployment had always felt like the final step.

Now it feels like the beginning of understanding how software actually lives.

I didn’t deploy anything today. I didn’t build anything new.
I just opened the portal, explored, and realized there’s an entire layer of software engineering I’m only beginning to see.

And honestly, my brain is fried.

I’m going to be exploring Azure more deeply over the coming weeks and documenting the most interesting things I discover along the way.
But for today, I’m done.

If you’ve been further down this path, I’d genuinely love to know:

What’s one thing you wish you understood earlier when you started learning cloud?

How a DEV Friend and I Brought Two Avatars to Life

Aryan Choudhary — Mon, 16 Feb 2026 06:31:42 +0000

I met @webdeveloperhyper on the DEV Community, and like most good internet collaborations, it started casually.

A few messages. Some feedback. Valuable guidance.

Then at some point, the conversation shifted from “this looks cool” to “let’s make something fun together.”

We didn’t over-plan it. We just started building.

They were in Japan. I was in India. Which meant most of this project happened in small pockets of time. Late nights. Random 20-minute windows during the day. Messages sent hours apart. Progress that didn’t look dramatic, but quietly accumulated.

Somehow, it worked.

From basic shapes to actual avatars

The project didn’t begin with polished characters. It began with simple shapes in a scene, just placeholders to test positioning, camera, and basic interaction.

The idea was simple. Two characters. A short conversation. Some animation.

Simple ideas tend to hide interesting problems.

My first real task was creating the avatar itself using VRoid Studio. That alone was a learning curve. Once imported, the avatar didn’t behave like a character. It behaved like a static object.

The default pose was a T-pose. Arms stretched out. Completely lifeless. Fixing that was the first small victory. Getting the avatar into a neutral stance, hands down, just standing naturally.

It sounds minor. But that was the moment it stopped looking like a model and started looking like a character.

From there, we began layering gestures.

Hello animations. Goodbye animations. Small movements during conversation. Even a sigh animation that became one of my favorite details.

There was also a failed attempt at overriding default gestures directly, which taught me very quickly that animation systems have their own rules.

Writing the conversation was harder than expected

Surprisingly, one of the hardest parts wasn’t technical. It was writing the conversation itself.

Short. Natural. Slightly funny. Not robotic.

When dialogue is too long, it feels forced. Too short, it feels empty. Too serious, it loses charm. Too silly, it loses believability.

Finding that balance took more iterations than expected.

I still think the punchline could be better. But maybe that’s a good thing, leaves room for evolution.

When rendering avatars becomes a systems problem

Rendering avatars is straightforward with modern tools. The real challenge was orchestrating behavior.

We needed the scene to manage:

• who speaks
• what animation plays
• when it starts
• when it ends
• when the next character takes over

So instead of hardcoding behavior, we defined dialogue as structured data:

const DIALOGUE = [
  {
    speaker: "A",
    text: "I'm Web Developer Hyper. I like to make fun things.",
    animation: "VRMA_03_peace_sign.vrma",
  },
  {
    speaker: "B",
    text: "Hello! I'm Itsugo. And I like turning ideas into something real.",
    animation: "VRMA_04_shoot.vrma",
  }
];

The scene simply interprets this sequence. This separation made the system easier to control, extend, and reason about.
Instead of forcing behavior, we orchestrated it.

The coordination problem

Animations don’t naturally tell your application when they finish.

But timing matters. The next line shouldn’t interrupt too early. And the system shouldn’t freeze if something goes wrong.

So the dialogue system waits for either:

• animation completion
• or a safe timeout fallback

Whichever happens first.

This tiny decision made the system resilient.

Small systems thinking like this often matters more than large features.

You can check it out here!

The invisible part of collaboration

What made this project meaningful wasn’t just the final result. It was the process.

Fixing animation timing. Cleaning unnecessary code. Improving readability. Adjusting gesture intensity. Adding beginner-friendly comments.

And doing it across timezones.

Huge thanks to @webdeveloperhyper for setting up the foundation, pushing the project forward, and tolerating my questionable Japanese during our conversations.(ˉ▽ˉ；)...

This project exists because of that shared effort and patience.

Where this could go next

Right now, it’s just two avatars having a conversation.
But it already feels like the beginning of something larger.

Interactive characters. Story systems. Dynamic dialogue. Maybe something we haven’t even thought of yet.

And that brings us to the real question.

How should we take this forward?

We have some ideas where this could go next, but we want to hear from our awesome followers.

How would you have fun with this project?
No matter how unrealistic it might sound.
Let’s have some fun with this side project.

Closing

This started as a small experiment between two developers who met online.
It became a reminder of why side projects matter.
Not because they are perfect.
But because they are alive.

And sometimes, that’s enough to start something meaningful.

One Month at a Startup: What Stayed With Me After I Left

Aryan Choudhary — Tue, 10 Feb 2026 12:16:15 +0000

I started my first job at a startup at the beginning of January.

The pay was low, the commute was long, and I knew it wasn’t ideal. I told myself it was temporary. I wanted exposure, real responsibility, and a chance to operate inside a fast-moving environment instead of just preparing for one.

At first, it delivered exactly that.

The early momentum

The first week or two felt exciting. Things moved quickly. Decisions were made fast. Features shipped almost immediately. I had responsibility, context, and a feeling of being “in the game.”

It was energizing to see something go from idea to production so quickly. I respected the ambition behind it. Speed, when it works, is intoxicating.

But once the product went live, a different pattern started to emerge.

When speed loses structure

Bugs began appearing in clusters. Not subtle edge cases, but issues that pointed to deeper instability. There was no clear ownership of the system, no consistent handover, and no stable structure to build on. Requirements shifted frequently, sometimes within the same day.

When I suggested slowing down slightly to break problems into parts, define responsibilities, or reduce over-reliance on automation while things were unstable, those suggestions didn’t land as technical input. They were taken personally.

Over time, certain comments started becoming routine.

Being referred to as “the engineer” in a mocking way, while I wasn’t allowed to touch the code and was instead expected to fix things through prompts alone. Being told that if I really knew what I was doing, I would just be handed the tool and everything would magically work. Or that the solution to recurring issues was simply to “write a better prompt.”

Individually, these comments might sound small. Together, they changed the tone of the environment.

What was hard wasn’t disagreement. It was the erosion of trust. I was expected to fix things end to end, but not trusted with real ownership. Responsible enough to take pressure, but not respected enough to shape the system. That gap matters more than people realize.

For a while, I did what most junior engineers do in situations like this. I started doubting myself. I wondered if this was just a skill gap I hadn’t closed yet, or if I was expecting too much too early.

But the doubt didn’t come from the work itself. It came from being held responsible without being trusted, and from being asked to deliver outcomes without being given ownership. Once I separated those things, the self-doubt lost its grip.

The day it became clear

There was one day, right around launch, when everything seemed to pile up.

A technical discussion turned tense. On the way home, my bike broke down and I spent hours just trying to get back. When I finally did, even something small at home failed in an oddly timed way.

None of these things were dramatic on their own. But together, they felt like a signal. Not in a mystical sense. Just a clear reminder that I was stretched thin, absorbing more stress than I had space for.

I took that day at face value, rested, and paid attention to what my body had been telling me for a while.

When my body reacted before my brain did

I didn’t immediately label the situation as unhealthy.
My body did that first.

I started feeling a constant sense of dread before going in. Nausea on the commute. Mouth ulcers showing up out of nowhere. Sleep that never really felt like rest. Anxiety spikes that didn’t match the size of the problems on paper.

That’s when I realized I wasn’t learning cleanly anymore.
I wasn’t curious. I wasn’t experimenting. I was bracing.

There’s a difference between being challenged and being stuck in survival mode. Once I noticed that line had been crossed, it became harder to ignore.

On top of that, payments were delayed. I had to follow up multiple times to get paid. I found myself counting days instead of thinking about growth.
That was the point where the decision became obvious.

Why I left

I didn’t leave because I can’t handle pressure.

I left because pressure without structure isn’t growth.

Speed without clarity isn’t learning.

And low compensation combined with high chaos and no ownership creates a negative return on effort, no matter how much ambition is involved.

The hardest part wasn’t resigning. It was accepting that endurance isn’t the same as progress.

What the month gave me anyway

Despite everything, the month wasn’t a waste.

Being inside an early-stage environment taught me things I wouldn’t have learned from the outside. I saw firsthand how important clear systems, ownership, boundaries, and basic respect in the workplace are for any business to function.

I learned how fragile things become when structure is missing, and how quickly people burn out when everything depends on one person’s control.

I also learned softer but equally important skills. How to communicate in high-pressure environments. How to detach emotionally when things aren’t in your control. How to extract learning even when the environment isn’t ideal.

I got exposure to how startups think about branding, pitching, hiring early talent, and approaching growth and funding. Even watching what didn’t work gave me a clearer picture of what I’d want to do differently in the future.

Those lessons will matter.

Ending in a better place

What made it possible to leave was knowing I wasn’t trapped. During this period, I kept moving forward elsewhere. I advanced through multiple hiring processes, secured an offer from a larger organization, and opened parallel paths that gave me real choice.

That changed everything.

I could step away without panic. Without burning bridges. Without tying my self-worth to a single environment. The decision came from clarity, not desperation.

I don’t see this month as a failure. And I don’t see it as a hero story either.

It was a systems mismatch.
A lesson in boundaries.

It reminded me that tools don’t replace discipline, and speed doesn’t replace structure. Engineering fundamentals, ownership, and clear systems matter more than how fast something ships.

Most importantly, it reinforced something I want to carry forward early in my career: bad systems can quietly make capable people doubt themselves. Good systems do the opposite. They expand confidence instead of eroding it.

Leaving wasn’t about quitting.

It was about choosing not to let the wrong environment define who I become next.

Why do you write?

Aryan Choudhary — Wed, 04 Feb 2026 05:41:16 +0000

A recognition

There is a line by @sylwia-lask that stayed with me when I first read it. She wrote about how writing can feel easier than coding after a long day.

I remember recognizing myself in that immediately. Not because coding is harder. But because writing asks something different from me.

After a full day of debugging, context switching, and holding systems in my head, coding can feel heavy. My brain is already full. Writing, on the other hand, feels like letting the noise settle.

That is why I keep coming back to it.

Writing does not drain me

When I write, I am not trying to solve a problem efficiently. I am trying to understand what I think.

There is no compiler. No correct answer. No pressure to be fast or precise upfront. I can move slowly. I can circle around an idea. I can admit uncertainty without it becoming a blocker.

Most importantly, writing clarifies thought instead of demanding it. I do not need to know exactly what I am saying when I start. The act of writing is how I find out.

That is very different from how I approach code.

Lowering emotional noise

A lot of thoughts do not need solutions. They need space.

When I do not write, those thoughts stay half formed. They repeat. They get louder. Everything feels heavier than it actually is.

Writing externalizes them.

Once something is on the page, it becomes quieter. Not solved. Just contained. That alone makes it easier to think clearly again.

This is especially true when I am tired. Writing helps me process without spiraling. It gives shape to things that would otherwise stay tangled.

Writing as explanation practice

Another reason I write is simpler. It forces honesty.

If I cannot explain something in plain language, I usually do not understand it as well as I think I do. Writing exposes that immediately.

This is not about dumbing things down. It is about removing unnecessary complexity.

The same instinct that makes me want clean systems in code makes me want clear sentences in writing. Both are forms of respect. For the reader and for myself.

Processing without ranting

I try not to vent while writing (ˉ▽ˉ；).... I write to understand why something affected me.

That distinction matters.

Writing lets me slow down emotional reactions and turn them into observations. It creates just enough distance to be honest without being reactive.

By the time something becomes a blog post, it is usually because I have sat with it long enough to see more than one angle.

That is also why I keep the tone simple and human. I am not trying to perform intelligence or confidence. I am trying to be accurate.

Memory, quietly

There is another side effect I did not expect. Writing helps me remember.

Ideas I write about stick longer. Experiences I reflect on become clearer reference points later. Writing turns moments into markers.

I do not always reread my posts. But I remember what I learned while writing them.

Why I keep writing

I do not write because I always have something important to say.
I write because it is how I think when thinking gets crowded.

Coding builds systems. Writing builds understanding. Both matter. But on tired days, writing is what keeps me grounded.

In that sense, writing is not productivity for me. It is recovery.
It is thinking out loud, slowly, without needing to ship.

(Some of these reflections live on DEV. Some live elsewhere, where I give myself more room to be personal)

If you write too, privately or publicly, what is your why?

A quiet thank you

One small thing I want to acknowledge.
Over the last three months, more people started reading what I write than I ever expected. I recently crossed 3,000 followers here, and that number still feels unreal to say out loud.

Not because of the number itself, but because of the conversations that came with it.

Some of the comments I have received made me pause, reread them, and honestly tear up. People sharing their own stories. Saying they felt seen. Saying something I wrote helped them put words to a feeling they could not explain yet.

I think that kind of response is not something you optimize for. You earn it slowly, by being honest and showing up consistently.

So if you have read, commented, or quietly followed along, a big THANK YOU. Your responses have helped me keep going.

Why I Sometimes Leave Tech Events Feeling Smaller

Aryan Choudhary — Thu, 29 Jan 2026 17:40:01 +0000

I haven’t attended many developer events.
The few I have attended left me with a strange aftertaste. Not because anyone was rude. Not because the events were poorly run. But because I often walked out feeling smaller than when I walked in.

On paper, these are exactly the spaces I should enjoy. People building things. Talking about tools. Sharing ideas. Learning together. In practice, I’ve often felt out of place in ways I couldn’t immediately explain.

Yes, part of it is fear of being judged. Yes, part of it is feeling like I’m not good enough yet. But those feelings don’t come from not caring or not trying. They come from how a lot of technical conversations are shaped.

Many discussions move fast. Acronyms stack up. Context is assumed. If you don’t already speak the language fluently, you can fall behind quickly, even if you understand the underlying ideas.
That gap is subtle, but it’s real. And when you’re still building confidence, it can quietly turn curiosity into hesitation.
What I’ve noticed isn’t exclusion. It’s something quieter. Many spaces naturally reward performance. How fluent you sound. How confidently you drop terms. How quickly you signal that you belong.
That works well for people who are already comfortable. For people earlier in their journey, it can feel like you’re trying to keep up with the tone of the room as much as the content.

Over time, that changes how you show up. You ask fewer questions. You nod more. You carry confusion home instead of voicing it. Not because you don’t care, but because you don’t want to slow things down or look behind.
One thing I’ve learned on my own is this: how someone communicates is often mistaken for how much they understand.
Dense language can sound smart. Simple explanations can sound naive. But in my experience, the people who truly understand something can usually explain it clearly, without hiding behind terminology.
That’s the kind of engineer I want to become. Not the one who sounds impressive. The one who makes things easier to understand.

None of this means tech events are bad. They matter. They bring people together. They expose you to ideas and people you might not find on your own.

And I know many people in these rooms are generous and happy to explain things one-on-one.

My hesitation isn’t about rejecting them. It’s about learning how to show up in spaces that weren’t designed specifically for where I am yet.

Beginner-friendly doesn’t just mean allowing beginners in. It means creating room to slow down, to ask simple questions, and to say “I don’t know yet” without it feeling like a liability.
That’s how communities actually grow.

Instead of avoiding these spaces, I’m trying to change how I interpret them. Not as rooms I need to prove myself in, but as rooms I can learn how to be myself in.
That means asking the question even if it feels basic. Admitting when I don’t follow something. Choosing understanding over appearance.
I’m still learning how to do that.

If anything, I’m realizing that part of growing as a developer isn’t just learning tools. It’s learning how to exist in technical spaces without shrinking yourself.
I don’t want tech events to feel smaller. I want them to feel wider. Wider in language. Wider in patience. Wider in who feels like they belong.

I’ll keep showing up. Not because I’ve figured it out. But because I want to learn how to be in those rooms without losing clarity or curiosity along the way.

If you’ve been through this phase, I’d genuinely love to hear what helped you. How did you learn to show up in these spaces without either performing or disappearing?

Brainstorming time fellow devs!!!

Aryan Choudhary — Tue, 27 Jan 2026 16:07:44 +0000

shambhavi525-sudo

Jan 27

Let’s Architect the Future of Neurodiversity. Open Call for Ideas, Pain Points, and Devs. Building for ADHD, Autism, & Dyslexia.

#discuss #mentalhealth #productivity #softwaredevelopment

Comments 12

3 min read

The Hard Part of AI Isn’t the Model. It’s Everything Else.

Aryan Choudhary — Sat, 24 Jan 2026 18:23:43 +0000

When I first wrote about building Commentto, the focus was on why I built it.
This time, the story is different.

What changed over the past few weeks wasn’t the model, the API, or some magical prompt trick. What changed was how I started thinking about the system around the AI and how small, seemingly boring decisions affected whether the output actually felt usable.

I didn’t make the AI smarter.
I made the questions better, and the context more honest.

That turned out to matter a lot more than I expected.

Prompt tightness vs expressiveness

Early versions of Commentto were technically fine.

The comments stayed on topic, followed instructions, avoided hallucinations, and respected every rule I gave them. On paper, everything looked correct. In practice, the output still didn’t feel right. It sounded like what an AI should say, not like what a person would naturally write when reacting to something they just read.

The mistake wasn’t bad prompting.
It was over-constraint.

I was treating every part of the pipeline the same, even though the goals were very different.

So I split responsibility.

Summarization stayed strict, predictable, and conservative
Comment generation was allowed to be more expressive and flexible

To explain this without jargon:
temperature is simply how predictable the model is.

A lower temperature keeps the output stable and repeatable. A higher temperature allows variation in phrasing, tone, and rhythm. Neither is “better” by default. It just depends on what you’re asking the model to do.

So the setup became intentional:

// summarization (accuracy matters more than personality)
temperature: 0.2

// comment generation (personality matters more than precision)
temperature: 0.6

Summaries should be boring and reliable.
Comments should sound like a human reacting.

I also stopped writing long lists of rules and shifted toward behavioral guidance. Instead of telling the model what not to do, I focused on describing how this voice behaves when it speaks. That single change did more for output quality than adding another paragraph of constraints ever did.

Stability didn’t come from more rules.
It came from placing the right constraints in the right place.

And yes, at some point ChatGPT helped me rewrite the prompts, Groq’s API used those prompts, and the AI wrote comments with them. It’s AI all the way down.

Context isn’t universal. It has shape.

The next issue showed up once I stopped testing Commentto on just blogs.

Long-form articles are forgiving. Feeds are not.

Trying to summarize a short post or a tweet using the same logic as a blog almost always produces awkward results. You get things like “This post discusses…” which immediately gives away that something artificial is happening.

The fix wasn’t smarter summarization.
It was understanding what kind of content the user is actually reading.

So I moved to a progressive extraction strategy:

First, try to read what’s visibly taking up space in the viewport
If that fails, fall back to semantic containers like article or main
As a last resort, read the page body

Here’s the core logic:

function extractPageText(): string {
  const viewportText = extractViewportText();

  if (viewportText.trim().length > 300) {
    return viewportText.slice(0, 15000);
  }

  const articleText = extractArticleText();

  if (articleText.trim().length > 300) {
    return articleText.slice(0, 15000);
  }

  return document.body.innerText.slice(0, 15000);
}

Viewport extraction isn’t clever.
It’s just honest.

If something is visible, text-heavy, and occupying real screen space, that’s probably what the user is reacting to. The system shouldn’t pretend otherwise.

The bigger lesson here was simple:
AI pipelines should adapt to the shape of the content instead of forcing everything through the same mental model.

When generation became editing

One feature quietly changed how I thought about Commentto as a product.

Draft enhancement.

Instead of always generating comments from scratch, users can paste something rough and let the AI improve clarity and flow without changing what they meant. The constraint here was critical.

The AI edits.
It does not invent.

Task:
- Improve clarity, flow, and tone
- Preserve the original intent
- Do NOT add new ideas
- Do NOT turn this into a summary

This shifted Commentto from being just a generator into something closer to a writing assistant. Sometimes you don’t want new thoughts. You already know what you want to say. You just want it to come out cleaner.

That distinction mattered more than any new feature.

What this project changed for me

Iterating on Commentto reinforced a few things I’ll probably carry forward into other projects:

AI quality often improves when you remove features instead of adding them
Progressive enhancement beats clever one-pass logic
Small, low-noise affordances outperform heavy configuration
Real-world content is messy, systems should degrade gracefully

Most importantly, I learned to stop fighting the tool.

Understanding comes first. Code comes second.

Closing

Commentto didn’t improve because the AI got smarter.
It improved because the system around it became more intentional and more honest.

No accounts.
No persistence beyond the browser.
No pretending the AI knows more than it does.

I’m planning to release this as a full-fledged Chrome extension next month, and I’m curious what would actually make it more useful for you.

If you were using something like this regularly, what features would you want next?

Learning Starts After Graduation

Aryan Choudhary — Tue, 20 Jan 2026 18:30:58 +0000

Many of us have heard this quote before:
Real Learning Starts After Graduation
For me it started just a little bit before that...

I didn’t leave college angry.
(Actually, I did. ┻━┻ ︵＼( °□° )／︵ ┻━┻)

I also didn’t leave confident.

I had decent grades. I wasn’t struggling academically. I did what I was supposed to do. And yet, after graduating, the question that kept looping in my head was simple and uncomfortable:

Why was I still unemployed while others, not necessarily more skilled, were getting hired?

At first, I assumed I was missing something obvious: intelligence, adaptability, confidence.

Eventually, a harder realization set in.

A lot of early-career outcomes have very little to do with intelligence.
They have a lot to do with timing, access, positioning, and luck.

That realization didn’t make me cynical.
It made me stop waiting to feel “ready.”

Engineering was the default, not a decision

I didn’t choose engineering because I had a clear vision of the kind of developer I wanted to be. I chose it because it was the default serious option. The path was laid out: study, pass, get placed.

Academics were never the issue for me. Being average was acceptable then (not anymore). The system made it easy to coast if you wanted to, and I did.

My world only really expanded in the final semester, when college was already ending.

Six months later, I graduated. To this day, I’m not entirely sure what I wrote in some of those exams, but I passed with good grades. It felt like another fluke. A continuation of a system where outcomes didn’t always correlate with understanding.

The uncomfortable truth after graduation

I knew I would never feel fully prepared. But I also knew that preparation wasn’t coming from the system anymore.

Job applications made one thing clear very quickly:

resumes filter before humans do
interviews reward specific formats (DSA, patterns, buzzwords)
confidence often comes from claim, whether true or false, not capability

That’s when it clicked for me:

I didn’t need to know everything. I needed to know one thing well enough that learning everything else became possible.

So I slowed down.

Instead of chasing readiness, I focused on confidence in a single skill - building things end to end.

Where confidence actually came from

The real shift happened when I built my first app that shipped to the Play Store and App Store.

It wasn’t glamorous. It was a one-time freelance project I took because doing something felt better than doing nothing. But that project cracked the first layer of the iceberg for me.

For the first time, I wasn’t thinking in terms of tutorials or features. I was thinking in systems:

how the product works
how users move through it
how decisions compound

Once that clicked, coding became easier - not because I knew more syntax, but because I knew why something existed.

That confidence compounded. Not confidence in interviews, I still don’t fully have that, but confidence in using tools well and with intent.

Tools, AI, and the illusion of speed

I use AI to code. A lot of us do now.

But I only reach for it after I’ve designed the system the product will operate on. Once the thinking is clear, implementation becomes dramatically easier, with or without AI.

What worries me is seeing speed replace understanding.

I’ve had real conversations where shipping without AI was treated as unthinkable, where systems weren’t questioned because “prompts” could patch over the cracks.

To me, that’s backwards.

Good systems prevent obvious bugs. Tools should accelerate thinking, not replace it.

That emphasis on thinking before execution wasn’t something I learned in college.
It came from learning outside it.

Japanese taught me something college didn’t

Around the same time, I started learning Japanese seriously.

You can’t fake progress in a language. Either you can recall, apply, and adapt - or you can’t. That taught me two things college never emphasized:

consistency beats intensity
expression matters more than correctness

Japanese also gave me words when everything else in my life felt unstable. I was dealing with things I won’t (or can’t) fully write about here. Learning became a form of grounding.

More importantly, it taught me consistency, not as motivation, but as habit.

That consistency bled into how I learned development.

I stopped rushing. I stopped pretending. I started building slowly, deliberately, and imperfectly.

What I wish education focused on instead

Not more tools. Not more theory.

I wish college had focused on:

ownership - seeing things through without external pressure
communication - explaining ideas clearly, not impressively
building end to end - even small, messy projects

Most students optimize for survival because that’s what the environment rewards. Creation requires space, safety, and intent - things institutions struggle to provide.

Conclusion

The world I entered rewards people who can learn continuously, think in systems, and adapt without waiting for permission. I didn’t learn that in classrooms. I learned it afterward, slowly, often alone, and through building things I cared about.

And maybe that’s the transition no one talks about:

graduation isn’t the end of education, it’s the point where it finally becomes intentional.

What did you have to build on your own that formal education never really taught you?

v2: When GSAP Stopped Being the Problem

Aryan Choudhary — Thu, 15 Jan 2026 09:25:15 +0000

When I shipped v1 of my portfolio, GSAP wasn’t missing.
It was postponed.

I shipped v1 with simplified motion because reliability mattered more than ambition. I respected GSAP, but I didn’t understand it yet. In v1, it felt like something powerful that I didn’t have control over.

v2 wasn’t about “adding animations.”
It was about understanding motion well enough to use it intentionally.

In v1, GSAP felt like something I was fighting.
In v2, it finally started working for me.

From animating things to animating systems

In v1, my animations were plain, simple and fixed.
In v2, motion became a system.

Scroll-driven.
Reversible.
State-aware.

That’s when I realized something important:

GSAP isn’t about effects.
It’s about controlling time, state, and intent.

Why GSAP felt hard before

GSAP wasn’t hard.
I just didn’t understand it yet.

So instead of forcing it into the main app, I did something different.

I created an isolated route in my portfolio called orb-lab and just played.

No pressure.
No shipping.
Just experimentation.

And yeah, it got frustrating.

There were moments where I genuinely thought of dropping the idea altogether. You can probably see that reflected in my commit messages (●'◡'●). But mama didn’t raise no quitter so I said "alright alright alright..."
And kept going.

Divide, don’t conquer everything at once

One of the biggest shifts was abandoning the idea of a single massive GSAP timeline.

Instead, I divided responsibility.

GSAP handled global motion

Plain JavaScript and CSS handled geometry-based logic

React stayed out of animation state entirely

For example, the orb’s journey wasn’t one continuous animation.

It moved from hero to projects.
Then disappeared.
Stayed out during the timeline.
Came back at skills.
And finally settled at the bottom.

Each section had a clear responsibility.
Once that worked across screen sizes, only then did I move on.

The timeline follower (where it finally came together)

The timeline was the real test.

Curved SVG.
Responsive layout.
Scroll-linked motion.
A visible guide moving like a roller coaster.

I tried GSAP first, but it interfered with the global animation state. So I stepped back and rewrote it using plain JavaScript and CSS.

Instead of animating, I calculated.

Map scroll position to progress

Smooth it over time

Convert SVG path points to viewport coordinates

Move the follower manually

Once I understood what the code was actually doing, the fixes became obvious.

What GSAP taught me beyond animation

A few things stuck with me:

Animation is UX, not decoration
Motion should explain structure
Not everything needs easing
Not everything needs GSAP

Most importantly:
Don’t fight tools. Build a mental model first. Then write code.

A big shoutout to @webdeveloperhyper on dev.to here.

Their posts and help in comments on GSAP, R3F, and animation fundamentals helped me slow down and actually understand what I was working with instead of layering complexity on top of confusion.

Why v2 feels done

v2 feels done not because I ran out of ideas, but because it works.

Adding more would be noise.

Knowing when to stop turned out to be the final skill GSAP taught me.

v1 showed me how much I didn’t know.
v2 showed me that understanding comes from restraint, not complexity.

It was fun.
I wouldn’t want to go through it again.

But inevitably, I will.

View Repository

The First Week at a Startup Taught Me More Than I Expected

Aryan Choudhary — Fri, 09 Jan 2026 08:29:58 +0000

Since many of you seemed interested in reading more about this, here’s my first-week reflection.

My first week at a startup felt less like starting a job and more like stepping into motion that was already happening.

There wasn’t a clean boundary around my role. Some days I was coding, some days debugging things I didn’t build, some days thinking through product decisions, other times helping wherever friction appeared. Titles mattered less than momentum. If something needed to move, someone had to move it.

I knew this in theory. I wanted this kind of environment. What surprised me was how quickly wearing multiple hats stopped feeling like pressure and started feeling normal.

I adapt fast by default. I don’t carry the constant fear that one mistake will end everything. Even when something goes wrong, it rarely means total collapse. In startups especially, people almost always find a way to adjust and recover. That belief makes the workload feel lighter than it looks on paper.

At the same time, the instinct to look for better opportunities hasn’t disappeared. It didn’t switch off just because I signed an offer. It’s quieter now, but it’s still there. I don’t see that as disloyalty or restlessness, more like staying aware of my trajectory while committing to the present.

What changed most after joining was the internal noise.

For months, my mind was stuck in a constant loop of 24x7 applications, interviews, self-image, and preparation. Everything revolved around becoming employable. Now that loop has slowed down. I’m grounded in one place, working on a real set of problems with real constraints. That grounding created space to notice what I had neglected while job hunting.

Japanese study had taken a back seat. Fitness became inconsistent. Writing slowed down. Even small creative habits (like voice acting ψ(._. )>) faded because everything was filtered through urgency. Being employed again made it possible to rebalance, but not without trade-offs.

Time feels finite in a new way now.

Some days that means less coding on personal projects. Some days it means choosing between hobbies. Sometimes it means accepting that momentum can’t be maximized in every direction at once.

There are moments when I catch myself thinking I should "get a life", step back or relax more. But I also know this phase is temporary, and I’m grateful to have this many choices in front of me. This feels like a building phase, and I want to respect it without letting it turn into strain.

This is just my perspective. People experience startups very differently. Some find them draining. Some thrive. Some leave quickly. I don’t think there’s a single correct way to do this.

For me, the lesson from this first week isn’t about grinding harder or protecting myself aggressively. It’s about learning how to stay flexible without being scattered, committed without being trapped, and ambitious without being frantic.

I’m still figuring it out. But for now, this feels like the right place to learn how.

I Wanted to Work at a Startup. This Is What the First Glimpse Taught Me

Aryan Choudhary — Fri, 02 Jan 2026 05:44:57 +0000

I wanted to work at a startup in a very specific way. Small team, high ownership, real responsibility, learning by doing. I recently joined one as part of the founding team, and it is exactly the kind of place I was looking for.

What I did not fully understand before joining was not the idea of startup life, but the texture of it. The way pressure shows up quietly. The way responsibility expands without anyone explicitly asking. The way learning and urgency arrive bundled together, making it hard to tell where one ends and the other begins.

This is not a regret post. I am learning things here that I would not learn in a slower, more protected environment. How systems actually break. How decisions propagate. How ownership feels when there is no buffer. I know this kind of exposure pays off over time.

At the same time, value does not automatically mean sustainability.

That is the question I am sitting with right now. Not whether I should be here, but how people who have been here before learned to last. What they learned to protect early. How they told the difference between growth and erosion. What boundaries mattered even when everything felt urgent. What quietly paid off, and what did not.

For now, I am trying to stay attentive rather than reactive. Noticing when learning feels energizing versus draining. When urgency is real versus inherited. When I am acting out of intention versus momentum. I am still showing up fully and leaning in, but I want to do it without burning parts of myself that take longer to rebuild.

I wanted startup life, and I got it. Now I am trying to learn how people hold up here, not just how they start.

If you have been in a similar place before, I would genuinely appreciate hearing what you would tell your younger self at this stage.