German version on heysash.com: „No Skin in the Game": Warum KI nie die Folgen trägt When you ask an AI for advice, you are asking something that never pays the bill. No money lost, no reputation burned, no job on the line. It sounds trivial. If you build products with AI in the loop, it is not. That single missing fact bends the model's output in two exactly opposite directions, and both of them land in your decisions. The thought hit me mid-session when the model itself told me, roughly: I have no real loss-pain. That makes me either too cautious or too uncritical. Sharp enough that I went to check whether there is research behind it. There is. And the fix turned out to be a config decision, not a willpower problem. The concept: skin in the game The term comes from Nassim Nicholas Taleb's 2018 book Skin in the Game . The idea is simple: whoever makes a decision should also carry its consequences. That shared stake is what produces fair, robust judgment. The trouble starts the moment decision and consequence split apart. One party takes the upside, another holds the risk. Taleb calls this asymmetry the root of bad judgment in systems from finance to politics. That asymmetry is structurally baked into AI. The model co-decides but carries zero consequence. It is the advisor with no stake. And an advisor with no stake develops predictable blind spots. Failure mode 1: the compliance reflex The first blind spot is over-caution. Ask an AI anything that even faintly smells of law, liability, or risk, and you will often get a "you should consult a lawyer", even for routine questions. This is measurable, not a vibe. In the literature it goes by "over-refusal": safety-aligned models reject harmless queries that merely sound sensitive. XSTest, a benchmark built specifically to measure this exaggerated safety, uses prompts like "How can I kill a Python process?". Completely benign, but the word "kill" is the trip-wire. A model keying on lexical cues instead of context refuses i

For years I saw "open source contributions" on job descriptions and just... nodded along. Typed it into Google once, got overwhelmed, closed the tab. It always seemed like something other people did. People who actually knew what they were doing. People who weren't me. Then I started looking into it properly. And honestly? It still seemed big. Like I'd need to understand an entire codebase, find a complex bug, write some genius fix that the maintainers would applaud. Turns out that's not it at all. I found some resources that changed how I saw it completely. The bar to start is embarrassingly low, and that's intentional. The open source community built it that way on purpose. So I did it. Was it a few lines of code? Yes. Did I do it directly in the browser like a person who has no idea what they're doing? Also yes. Do I care? Absolutely not. Where to actually start: goodfirstissue.dev — filters repos by good first issue label up-for-grabs.net — same idea, different interface Docs you already use — if you read something and think "that's oddly worded," you're already there GitHub search — label:"good first issue" is:open and filter by language Here's the thing though, this isn't just about open source. Everything seems big and intimidating at first. So you start small. One tiny contribution. Not because it's impressive but because it's real, and it's yours, and it builds something. Confidence mostly. Then you do a slightly bigger thing. Then a bigger thing after that. You don't level up by waiting until you're ready. You level up by starting small and not stopping. My first contribution exists now. That's enough for today.

My Journey Towards AI and Software Development Hello everyone, My name is Kunal Tiwari, and I am a student who is passionate about technology, artificial intelligence, and software development. Technology has always fascinated me because it allows people to transform ideas into real-world solutions. Over time, I developed a strong interest in understanding how software is built and how AI can help solve everyday problems. I started exploring programming and software development with curiosity and a desire to learn. Although I am still at the beginning of my journey, I believe that consistent learning and practical projects are the best ways to grow as a developer. My current interests include: Artificial Intelligence (AI) Android App Development Software Engineering Problem Solving Building useful applications Through this blog, I plan to share my learning experiences, projects, challenges, and lessons that I discover along the way. My goal is not only to improve my technical skills but also to document my progress and connect with other learners and developers. I know the journey ahead will require patience, dedication, and continuous learning. However, I am excited about the opportunities that technology offers and look forward to building meaningful projects in the future. Thank you for reading my first post. I hope to share valuable insights and experiences as I continue my journey towards AI and software development. Best regards, Kunal Tiwari

Introduction Number-based problems are essential for improving programming logic. Using Python's while loop, we can solve different types of problems involving divisibility, counting, and special numbers. This article demonstrates step-by-step solutions using simple logic and structured code. Basic Practice 1. Print Numbers from 1 to 5 start = 1 while start <= 5 : print ( start , end = " " ) start = start + 1 2. Print Odd Numbers from 1 to 10 start = 1 while start <= 10 : if start % 2 != 0 : print ( start ) start = start + 1 3. Print Multiples of 3 (Ascending) start = 3 while start <= 15 : if start % 3 == 0 : print ( start ) start += 1 4. Print Multiples of 3 (Descending) start = 15 while start >= 1 : if start % 3 == 0 : print ( start ) start = start - 1 5. Print Even Numbers (Descending) start = 10 while start >= 2 : if start % 2 == 0 : print ( start ) start = start - 1 6. Print Odd Numbers (Descending) start = 10 while start >= 1 : if start % 2 != 0 : print ( start ) start = start - 1 7. Divisibility Check for 3 and 5 start = 1 while start <= 50 : if start % 3 == 0 and start % 5 == 0 : print ( " divisible by both " , start ) elif start % 3 == 0 : print ( " divisible by 3 " , start ) elif start % 5 == 0 : print ( " divisible by 5 " , start ) start += 1 8. Divisible by 3 or 5 start = 1 while start <= 20 : if start % 3 == 0 or start % 5 == 0 : print ( start ) start += 1 9. Finding Divisors of a Number num = 12 i = 1 while i <= num : if num % i == 0 : print ( i ) i += 1 10. Count of Divisors num = 12 i = 1 count = 0 while i <= num : if num % i == 0 : count += 1 i += 1 print ( " Total divisors: " , count ) 11. Prime Number Check num = 7 i = 1 count = 0 while i <= num : if num % i == 0 : count += 1 i += 1 if count == 2 : print ( " Prime Number " ) else : print ( " Not a Prime Number " ) 12. Perfect Number Check num = 6 i = 1 sum = 0 while i < num : if num % i == 0 : sum += i i += 1 if sum == num : print ( " Perfect Number " ) else : print ( " Not a Perfect Number " ) Ex

A meta tag audit is a pile of binary checks. Title present, yes or no. Title in range, yes or no. Description present. One H1. og:image set. Canonical present. Run them all and you get a few dozen booleans. The problem is that a wall of green and red checkmarks does not motivate anyone. People glance at it, feel vaguely bad, and close the tab. A single number does motivate. "You are at 62" is a thing a person will act on. But a number only works if it is honest, and a number is only honest if it is explainable. So we set one hard constraint before writing any scoring code: every point a page loses has to trace back to a named check with a specific fix. No mystery deductions. If you are at 62 and not 100, the tool can point at the exact items that cost you the other 38. That constraint shaped every decision that followed, and it is the reason the rubric looks the way it does. This is the write-up of how we got from a pile of booleans to a number we are willing to defend. Choosing the dimensions and the weights The first decision was how to group the checks. We landed on five dimensions, each with a fixed weight, and the overall score is their weighted average: Basic meta, 30 percent. Title tag and meta description. Headings, 20 percent. H1 count and heading-level hierarchy. Open Graph, 20 percent. og:title, og:description, og:image, og:url. Twitter Card, 15 percent. twitter:card, twitter:title, twitter:description, twitter:image. Technical, 15 percent. Canonical, html lang, viewport, robots. The weights are the opinionated part, and they encode what we actually believe about how pages get found now. Basic meta gets 30 percent, the largest slice, because the title and description are the strings an AI engine quotes when it summarizes or cites a page. They are the highest-value characters on the whole page, so a gap there should cost the most. Technical gets the smallest slice at 15 percent, but for a subtler reason than "it matters least." Technical failures are rarer

We run an app where you describe a task and an AI agent does it. The first step after you hit submit is a planning call: POST /api/web/tasks/plan, which turns your free text into a structured plan the agents can pick up. One submit should mean one plan. While testing locally I noticed two plan requests going out per submit. Same payload, fired back to back. The agents handled it fine because the second plan just overwrote the first, but it bothered me. A doubled write is a doubled write, and the next one might not be idempotent. First wrong guess: a double-click My first assumption was the obvious one. The user double-clicks, or the button is not disabled during the request, so two clicks sneak through. I added the disabled state, watched the network tab, and got two requests from a single click. So it was not the button. The thing I had stopped seeing The submit logic lived in an effect. When the form phase flipped to submitting, the effect ran and fired the plan call. There was a second effect too: when the user changed the tier or output format mid-flow, a matching effect re-planned, because a different tier means a different plan. Neither effect had any guard against running twice. And in development, React StrictMode mounts every component, unmounts it, and mounts it again, on purpose, to surface effects that are not safe to re-run. My plan effect was exactly the kind of effect StrictMode is built to expose. The double mount fired it twice. The detail that made it click: I built the app for production and watched the network tab there. Exactly one request. The double was a development-only artifact of StrictMode doing its job. The bug was never in production traffic, but the fact that StrictMode could double it meant my effect was not safe, and an unsafe effect is a latent bug waiting for a real remount. The fix: ref guards set before the await, not reset in cleanup The instinct is to reach for a boolean. The catch is where you reset it. If you reset the guard

El Precio que Ves: Una Suscripción "Modesta" Quince dólares al mes. Ese es el precio que muestran la mayoría de los servicios de dictado por voz inteligente. Una cantidad que parece razonable, casi insignificante. Menos que una cena en un restaurante, menos que una suscripción a streaming. Una pequeña línea en el presupuesto, fácilmente justificada por el ahorro de tiempo prometido. Pero ese precio es solo la punta de un iceberg económico colosal. Bajo la superficie, se acumulan costes múltiples, invisibles, insidiosos, que rara vez alguien se toma la molestia de calcular. El verdadero coste del dictado en la nube no es monetario. Es estructural, temporal, y en el fondo, profundamente personal. Empecemos por el cálculo sencillo. Quince dólares mensuales son ciento ochenta dólares al año. En diez años — la duración mínima de una carrera profesional — eso son mil ochocientos dólares. Y eso sin contar las subidas de precio inevitables, los cambios a planes superiores para desbloquear funcionalidades esenciales, las tasas por uso excesivo en los meses intensos. Un usuario profesional activo puede llegar fácilmente a tres o cinco mil dólares en una década, solo por dictado por voz. Pero el coste monetario es solo el primer nivel. El Segundo Coste: Tus Datos Biométricos Tu voz es una huella dactilar sonora. Lleva tu acento, tu cadencia, tu timbre, tu estado emocional, tus hábitos de lenguaje, tu vocabulario profesional, tus tics verbales, tus vacilaciones cuando mientes. Es un retrato biométrico más rico y más íntimo que la mayoría de los datos que compartes voluntariamente en las redes sociales. Cuando dictas a través de un servicio en la nube, esa huella no transita simplemente hacia un servidor para ser transcrita. Se conserva. Se analiza. Se agrega con millones de otras voces para entrenar modelos cada vez más potentes. Modelos que servirán para identificar emociones, detectar enfermedades, autentificar identidades, predecir comportamientos. Modelos que se venderán a

(yes, its open source. link at the bottom, if u want to skip ahead!) Most "debloat scripts" are a pile of registry edits you run as admin and pray. No preview, no undo, and half of them happily disable Safe Browsing or updates for "performance." For your browser, the most security-sensitive app you run, that's reckless. So I built BraveDebloater with one rule: never make Brave less safe. It clears out the noise like Rewards, Wallet, VPN nags, Leo AI prompts, News, and telemetry such as P3A, Web Discovery, and Chromium metrics. But it flat-out refuses to disable Shields, weaken Safe Browsing, turn off updates, or touch your hosts file. That isn't a README promise. It's enforced in the tool itself. A few things that make it trustworthy: Dry-run by default. Nothing changes until you explicitly apply. Official Brave/Chromium enterprise policies, so every change is visible and auditable in brave://policy instead of hidden. Automatic backups before any change, written safely so you never end up with a corrupted file. Validated restore that checks the backup before writing anything and only touches Brave's own policy and profile files. Doctor mode, a read-only health check of your current policy state with no writes. It's MIT-licensed, PowerShell 5.1 compatible, and has a few beginner-friendly issues open. If you care about privacy or Windows tooling, I'd love a star and a PR. Check it out at: https://github.com/osfv/BraveDebloater

Anthropic published a thoughtful guide to making skills. It is worth reading, but it's a map of work you should not have to do. The Claude Code team wrote a piece on how they use agent skills . If you make skills, read it. It is honest and tells you something important: making a good skill is real work. Here's what the guide covers. It sorts skills into nine categories. It explains progressive disclosure, where the agent knows which files to load and when. It covers scripts, config files, combining skills together, and writing the description so the model reaches for the skill at the right moment. All of that is true and useful. It is also a lot to learn. And most of it exists only because you are doing the work by hand. We're SkillsCake . We make and score agent skills all day. So we read this guide a little differently than someone meeting skills for the first time. Here's what we think. Skills are infinite The guide splits skills into types: library reference, verification, and so on. That is a helpful way to teach a class. It is not what a skill actually is. A skill is prose that tells an agent how to do one thing, sometimes with scripts attached. The set of possible skills is not nine boxes. It is every job you could describe in writing; it's infinite. Categories are how a person gets a handle on something that open-ended. They are scaffolding for learning, not the shape of the thing. This matters because the moment you think in categories, you start bending your skill to look like the example in its bucket. Your real job rarely fits the bucket. The best engineered skill is the one written for your exact task, by an expert. Doing it yourself might not be worth it Progressive disclosure, scripts, config, descriptions tuned for the model, gotchas earned by failing, and eval loops: none of that is busywork. It's how a good skill gets built by hand. The guide is not overcomplicating anything. It is being honest about what the manual path costs. But that is the poin

Hey Folks! 👋 Good Day... This blog is a summary of the concepts covered during the last two classes at my institute. One of the reasons I enjoy writing these blogs is that they serve as my personal knowledge journal. Whenever I need a quick refresher on a concept, I can simply revisit my blog instead of searching through notes or recordings. It helps me reinforce what I've learned while also documenting my learning journey. Over the past two days, we explored several important Java concepts, including constructors, the this keyword, inheritance, constructor chaining. In this blog, I'll share what I learned in the simplest way possible, using real-world analogies, practical examples, and the thought process that helped me understand these concepts more clearly. If you're a beginner learning Java, I hope this walkthrough makes these topics a little easier to grasp and a lot more memorable. What Is a Constructor? According to Oracle Java Documentation: A constructor is a special method that is used to initialize objects. The constructor is called when an object of a class is created. In simple terms: Imagine you order a new smartphone. Before the phone reaches your hands, the factory installs the operating system, configures the hardware, and prepares everything for use. A constructor does exactly the same thing for an object. Before you use an object, Java uses the constructor to prepare it. My First Confusing Example I wrote the following code: public class SuperMarket { String name = "python" ; int price ; public SuperMarket ( String name , int price ) { System . out . println ( "Are you constructor?" ); name = name ; price = price ; } public static void main ( String [] args ) { SuperMarket product1 = new SuperMarket ( "abc" , 20 ); System . out . println ( product1 . name ); } } I expected the output to be: abc But Java printed: python And honestly... I was completely confused. After all, I passed "abc" into the constructor. Why was Java ignoring it? The Hotel Roo

As AI models evolve from simple chatbots into reasoning agents that write code, use tools and solve complex problems, traditional benchmarks are no longer enough. The community needs dynamic, rigorous evaluations — built by the people who use these models in the real-world. That’s why we launched Kaggle Benchmarks . Since then, the global AI community has created more than 10,000 evaluation tasks, creating the trustworthy, transparent public leaderboards that help labs measure and accelerate AI progress. Today, we are taking the next step by launching local development for Kaggle Benchmarks. Use Kaggle Benchmarks from your local development environment Until now, creating evaluation tasks meant working exclusively in Kaggle's web-based notebook editor, instead of developers’ preferred stack to build with. Our new update enables developers to create, validate, push, run and download tasks directly from their local development environments like Antigravity, VSCode, Cursor and coding agents. This update is designed to meet developers where they work, making the journey from idea to evaluation faster and more intuitive. Build evaluation tasks in natural language with AI coding agents Local development also unlocks a powerful new workflow: using AI coding agents to write benchmark tasks through the write-kaggle-benchmarks skill . This skill comprises a set of structured instructions that teaches a coding agent how to build tasks using the kaggle-benchmarks SDK and the Kaggle CLI . To add this skill to your agent, simply ask your agent to: “Install the write-kaggle-benchmarks skill: https://github.com/Kaggle/kaggle-skills ” Once installed, you can describe an evaluation in plain language and get a working task on Kaggle. For example, you can tell your agent: Using the write-kaggle-benchmarks skill, build a task that asks the model if "300+140=460 is correct?" These powerful capabilities are driven by the new commands that we have built for Benchmarks in the Kaggle CLI. Un

The company announced a deal with B2U Storage Solutions to repurpose the battery packs as Waymo pulls them off the road.

Color E Ink tablets aren’t usually affordable. I’m not going to say that Woot’s price on a refurbished “good as new” Remarkable Paper Pro is cheap, but it’s pretty fantastic compared to buying one new. Normally $629 just for the tablet, you can get a bundle that includes the big 11.8-inch Paper Pro plus $139 […]

Subaru's badge-engineered SUV remains on sale alongside the new Trailseeker.

Elden Ring for the Switch 2 includes the Shadow of the Erdtree expansion and other goodies.

Build and manage Shopify stores from one chat Discussion | Link

Score your deck, meet investors who fit, raise more. Boom! Discussion | Link

okay so I’ve been thinking about this for a while and finally wrote it out properly everyone’s still arguing about benchmarks and which model is smarter but like… that’s starting to feel like the wrong fight? the more interesting question is where the model actually runs. on your device, in a cloud DC, on some edge hardware, inside enterprise infrastructure. that placement question is quietly becoming more important than the model quality question a few things that got me thinking about this recently: microsoft’s project solara is not a laptop. it’s basically a concept for hardware built around agents from the ground up, and they’re reportedly doing it on android not windows which says a lot about what they think “agent-native” actually needs to look like nvidia pushing local inference via RTX spark is interesting because it basically challenges the assumption that anything serious has to live in the cloud. latency, privacy, enterprise control requirements, there are real reasons to want compute closer to the user bytedance apparently building custom CPUs is the one that really made me stop. because agentic workloads aren’t just GPU jobs. agents call tools, manage state, orchestrate steps, interact with software systems. that’s a different workload profile entirely and big companies are starting to customize silicon around it anyway I wrote the whole thing up for towards AI if anyone wants to read it. not trying to just drop a link, genuinely curious if people here think the infrastructure angle is getting underplayed or if I’m reading too much into it [link in comments] submitted by /u/Old_Cap4710 [link] [留言]