Alagu Alagappan @alagu_dev

@VadimStrizheus I don't think that is an unpopular opinion B2C is way harder than B2B

@__itsmesiya Soo relatable !! Not sure why ...losing motivation midway

@Mechramc +1

Wanted a tech curator I could shape around my own taste and fully control. Had a few tokens left, so I hacked one together: Techurator alagu.dev/techurator

@Mechramc Building the platform would be worthwhile

Is Rust everywhere now because people always wanted to use it, but its steep learning curve held them back? AI can now write it for us but if we skip the learning curve, are we also skipping the understanding that makes Rust safe in the first place?

@ipranavkrishna @Mechramc Wait listed 😶

Wild how a 5 year old Coldcard firmware bug just cost people tens of millions in BTC. Seed gen fell back to MicroPython’s weak software RNG instead of the hardware one because of a `#ifndef` that only checked if the macro existed, not that it was set to 0. Untouched devices !!

@eliana_jordan 100%

@araseb_ miniclip.com

An AI summary can look like an alternative to reading. It isn’t. It can keep the conclusion while removing the reasoning. Even the best prompt leaves something out otherwise it isn’t a summary. Use summaries to decide what deserves reading, not as proof that you’ve read it.

@BeingMani97 Try gpt- sol

AI can put a developer in the reviewer’s seat for code they’re listed as the author of. They may understand every line in the pull request. What they can miss is how the code came to have that shape. We already see this difference in normal code reviews. A reviewer can follow the logic and sometimes catch problems the author missed. But the author usually remembers the abandoned approach, the assumption that failed and the bug behind an otherwise odd-looking condition. In a traditional code review, the author brings the construction history. The reviewer brings fresh questions. In an AI-assisted workflow, the developer may read the generated implementation, run the tests, change a few lines and approve it. That can still be careful engineering, but it may not recreate the thinking that normally happens while building the solution. Manually typing the code isn’t the answer. Someone can write software through copy-paste and trial and error without learning much. Someone else can understand unfamiliar code extremely well after debugging, changing and operating it. The more useful distinction is active construction versus passive inspection. When AI handles more of the construction, code review may need to recover some of the missing context: * Which assumptions does this solution depend on? * What alternatives were considered or rejected? * What evidence supports its constants and boundaries? * What is most likely to fail under production conditions? AI-assisted engineering workflows shouldn’t stop at verifying the generated answer. Someone on the team still needs to understand the questions that produced it. Where does your team rebuild that context when AI writes most of the implementation?

People keep calling AI coding the next abstraction layer. I am not fully convinced. An abstraction hides details you no longer need to reason about. AI often hides decisions you are still responsible for. With assembly, developers work close to the hardware. With C, they give up some low level control but still manage memory and resources. With higher level languages, they stop worrying about many memory and CPU level details. But they still understand the program they are building: what it does, why it exists, and broadly how the pieces work together. Each layer removes some control, but gives the developer another model to reason with. AI coding feels different. I have spoken to people who built impressive side projects in a few hours. When I ask how they built them, the answer is often some version of: “I prompted the AI and it generated everything.” The product works. They can usually explain what it does. But ask why a particular abstraction exists, why a dependency was introduced, or why the application was structured in that specific way, and the answer becomes less clear. Did the choice come from the prompt? A repository instruction file? A common pattern in the model’s training data? Or was it simply one plausible implementation among many? The source code is visible, but the reasoning behind it is not. That is different from using a library or a high level language. I may not know exactly how a sorting function is implemented, but I know its contract. I also know that its internal design is outside the part of the system I own. AI generated application code sits inside my ownership boundary. My team has to maintain it, debug it, secure it, and change it later. When I already understand the architecture and use AI to implement a bounded piece, AI can work like an accelerator. I still own the important decisions. But when AI chooses the architecture, dependencies, data flow, and implementation and I mainly review the result that looks less like abstraction and more like delegated engineering. The difference is whether the human still owns the reasoning behind it. Where do you draw the boundary between useful abstraction and giving away too much understanding?

We often look at request count or in-flight requests and assume that tells us how busy a system is. But 1,000 requests that finish almost instantly can create less work than a much smaller number of slow requests. That’s why Zalando’s approach to measuring load caught my attention. Zalando looked at occupancy instead: how much time each server actually spent processing requests. They then combined that with active requests and relative latency to get a more realistic picture of load. This heuristic worked well for Zalando’s use case. It may not apply everywhere, but the broader point holds: Traffic is not the same as work. How are you measuring load when one request can be much more expensive than the next? Worth reading for anyone interested in scaling, reliability, or distributed systems. engineering.zalando.com/posts/2026/06/…

@ipranavkrishna Does something like this exist in Claude code ?

@ipranavkrishna Wohooooo !!!

@SonOfDavid219 Pay for what you use