Nikhil sinha

This month is chaotic. • Resigned from my job • Started creating content on X (late, but better late than never • Moving from SDE → DevOps/SRE officially • Leaving Bangalore after 2 years Funny how life works. Sometimes many things have to go wrong before the right thing starts taking shape. People know me as an SDE. But behind the scenes, for ~1.5 years, I’ve been doing deployments, fixing VA points, handling infra-related work, and slowly moving closer to DevOps without realizing it. Looking for opportunities in DevOps / SRE. If you're in DevOps, SRE, Cloud, or Backend — let’s connect. New journey starts today.

@T3chFalcon First we wrote code. Then we reviewed code. Soon we'll mostly supervise code. Origin isn't competing with GitHub. It's competing with the assumption that humans are the primary producers of software.

2023: Cursor launches. a VS Code fork with AI autocomplete. 2025: Cursor acquires Graphite. a code review startup. 2026: Cursor launches Origin. git hosting. a direct GitHub competitor. also 2026: SpaceX acquires Cursor through xAI. three years. VS Code plugin to GitHub competitor owned by Elon Musk. the pitch for Origin is genuinely interesting: GitHub was built for humans. Origin is built for agents. the demo showed 22.6 commits per second inside one repo. hundreds of thousands of clones and pushes per hour. because the assumption is that soon it won't be one developer committing code. it'll be hundreds of AI agents committing in parallel, branching, merging, and fixing failures simultaneously. Someone online said: "Cursor needs your code to train their models." You write code in Cursor. Cursor hosts it on Origin. Cursor owns a frontier AI model trained on code. Your code is now the training data for the AI that is replacing you. Microsoft owns GitHub. Microsoft owns the code of hundreds of millions of developers. SpaceX now owns Cursor. SpaceX now wants the code of hundreds of millions of developers.

Great Read if you want to read too then TL;DR it is 4743 pages long document docs.aws.amazon.com/pdfs/IAM/lates…

started my day with a good read

June 16 - 26 Done for the day kinda good day i would say started AWS, i have already worked with AWS but i never got the chance to deep dive into concepts and “why” and behind the code what is happening and all services and all if you are also on the same journey consider follow you will not regrets this i promise good night

@ns123abc The AI problem is no longer intelligence. It's economics.

BREAKING: Microsoft exploring DeepSeek over OpenAI and Anthropic as Copilot Cowork moves to usage-based pricing “We have users who do hundreds of tasks a week… the consequence is the costs can go very high...” Jevons paradox

Many beginners who are trying to learn AWS, this page either does not make sense to them or they are way too scared to fill in their billing details. Because somewhere they heard: *"AWS charged me $100."* But that's usually not how it works. When creating an AWS account, AWS asks for a debit/credit card mainly for identity verification and to prevent abuse (people creating hundreds of accounts). A few things to keep in mind: • AWS may place a small temporary verification charge (often around $1 or local currency equivalent) and later reverse it. • AWS does not instantly start draining money from your card the moment you add it. • The card is there to verify you're a legitimate user. • If you stay within the Free Tier limits, you typically won't be charged for eligible services. • The real danger isn't adding the card — it's launching resources and forgetting to monitor them. The lesson: Don't fear the billing page. Understand the billing model. Cloud is expensive when you're careless, not when you're learning. #AWS

@devops_nk looks dope though

Commands: 1) sl 🚂 → Steam locomotive when you mistype ls 2) asciiquarium 🐠 → Aquarium inside your terminal 3) cmatrix 💊 → Matrix-style digital rain 4) cowsay "Hello World" 🐄 → Talking ASCII cow 5) telnet towel.blinkenlights.nl 🌌 → Watch Star Wars in ASCII art

Before AWS: 🏢 Buy servers ⚡ Manage power & cooling 🔧 Rack and configure hardware 💰 Pay upfront ⏳ Wait weeks or months to scale 1998 → Virtualization arrives 2006 → AWS turns infrastructure into an on-demand service Cloud didn't replace servers. It changed who manages them.

in grok now you can access cursor's composer

@ThisIsBhandari startups are fun but bit hectic tbh but learnings are great

Joining a pre-seed startup taught me more than any FAANG job. I wasn't just writing code. I was constantly talking to users. We shipped features every 2–3 days. I once spent hours perfecting drag and resize functionality for an analytics dashboard because I was convinced users would find it useful. Almost nobody touched it. That taught me a lesson I'll never forget: Customers don't care how cool a feature is. They care whether it solves their problem. Building products, getting feedback, and seeing real usage patterns taught me that product development is as much about deciding what not to build as it is about deciding what to build. That lesson alone made me a much better engineer.

Before AWS or any kind of public cloud, how did companies run applications? A brief history lesson (i promise i wont be boring) The old way was physical servers. If a company wanted to host an application, it had to buy actual hardware from vendors like IBM, HP, Dell, Cisco, etc., and place those machines inside its own data center. A data center wasn't just a room full of computers. It needed: • Servers • Network switches and routers • Cooling systems • Power backup (UPS, generators) • Fire suppression systems • Physical security • Dedicated operations teams The biggest problem? Servers were expensive and horribly underutilized. Imagine buying a server with 100 GB RAM and 100 CPU units. Your application only needs 1 GB RAM and 1 CPU unit. That means: Used: - 1% CPU - 1% Memory Idle: - 99% CPU - 99% Memory You've already paid for the entire machine, but most of it sits doing nothing. Now multiply that by: • 15 servers • 200 servers • 2,000 servers The waste becomes enormous. And it gets worse. Companies had to estimate future demand months in advance. If traffic suddenly increased: → Buy new hardware → Wait for procurement → Rack and cable servers → Configure networking → Deploy applications This could take weeks or even months. So most organizations overprovisioned infrastructure "just in case," creating even more waste. Then virtualization changed everything. Instead of one application per physical server, hypervisors allowed multiple virtual machines to share the same hardware safely. A single server could now host many workloads. Utilization improved dramatically. Public cloud providers like AWS took this idea to internet scale. Instead of buying servers: • Rent compute by the hour/second • Scale up in minutes • Pay only for what you use • Let AWS manage the hardware, power, cooling, and facilities Cloud wasn't just about renting servers. It was a solution to decades of underutilized hardware, slow provisioning, and massive capital expenditure. Understanding this history makes AWS, EC2, containers, and Kubernetes much easier to appreciate. Cloud is not magic. It's the evolution of infrastructure economics. #AWS

@benjamin_horne We're in a weird phase where AI feels less like a power tool and more like management. You spend less time writing code and more time reviewing, steering, validating, and correcting. Output goes up, but craftsmanship goes down. Productive? Usually. Satisfying? Not always.

The shittiest thing about AI as a SWE is that while it's not the 10x nitro-boost that all the AI hypebeast grifters on here claim it is, it *is* a net ~30% productivity gain (once you factor in all the review, code slop clean up, etc.), which is *just* enough of a boost where you cannot justify not using it. This is a letdown because using AI after years of learning to code without it is of course an ongoing humiliation ritual, (counterintuitively) *more* exhausting/draining than coding by hand, and way less enjoyable in general.

Interesting pattern: most AI tools are racing to improve the model, but the real unlock is reducing context-switching. Browser + files + terminal in one workflow means fewer "copy this here, paste that there" loops. The productivity gain isn't any single feature—it's keeping the agent inside the same environment from idea → inspection → edit → execution.

Desktop app has fallen a bit behind over the last few weeks as I've focused on infra and other behind the scenes stuff (more on that soon), but spent some tokens getting some new stuff in, including: - In-app browser: Including annotation tools, drawings, screenshots/screenrecordings. Your agent has full context and control over it, just tell it what you wanna do - Works seamlessly with `serve-sim` for iOS development. - Or use it to look at your HTML plans - File Explorer, Viewer and Light-weight Editor. Great for small tiny edits you don't feel like throwing tokens at (still a bit buggy, will improve it over time) - Full sized terminals w/ vertical splits Will polish these up on nightly before pushing to latest later in the week. Enjoy!

Done with CI/CD (for now) Starting my AWS journey from scratch today I'll be sharing what I learn, building projects, documenting mistakes, and growing in public. If you're learning Cloud, DevOps, or AWS, follow along. It should be an interesting journey. ☁️🚀 #AWS

@LuffyVL_56 time square is about to get librated 🤟🏻

One piece Elbaph arc takes over Time Square

@the_codewala just switch gpt with claude

Agreed guys?

@pewpiece things about to get heated, you are not ready for whats coming

First look at Harald in onepiece anime

@kristijan_kralj The irony: most startups die from lack of users, not lack of architecture. Optimizing for a scale you'll never reach is often more expensive than handling the problems you actually have.

The silent killer of web apps: Enterprise overengineering. Some devs think they're building the next Amazon. So they put CQRS, event buses, mediators, and five service layers into a simple CRUD app. The result? Every change requires going through: - 3 interfaces, - 17 files, - across 5 different projects just to return an additional field from your database. Meanwhile, productivity tanks. Features that should take hours now take weeks. And all because someone thought "more layers" meant "more professional." Here's the truth: You don't need enterprise architecture for an app that 500 people use. Complexity should solve real problems. Not create them. A better approach: 1. Start simple. 2. Scale complexity only when the app demands it. 3. Build for today. Not for some fantasy scale that may never come. Complexity isn't a badge of honor. It's a tax on everyone who comes after you.

A week ago, searching "sinhaniik" barely told my story. Today, both Google and Bing show: • My portfolio • My X profile • My GitHub • My LinkedIn • AI-generated summaries of my work The lesson: Personal branding is SEO for humans and search engines.

@devops_nk I think because if you can't write it, you can't debug it when it breaks. i might be wrong though

Everyone is using AI to write scripts and YAML files, but when it comes to interviews, suddenly it's all about "use the official documentation." What's your take on this?