标签：#disc

I asked AI to help me write this article. Then I sat there for a second, thinking about how ironic...

With increased adoption of AI, there is often an argument that code-reviews are now the new bottleneck. And I agree with this completely. Code-Reviews, especially the review you do yourself after AI has written your code, take time. But I would object to the notion that this is a bad thing. What is a bottleneck? A bottleneck is something that slows down the process. It becomes a point where work must get in a line, to pass through a narrow space. With the speed of AI producing code, code reviews become a bottleneck. But is having a bottleneck in the process always a bad thing? The value of slowing down I can only speak from my personal experience of developing software for roughly 7 years now. But in my experience, slowing down is not always bad. On the contrary, it can be very healthy. When you slow down, and take the time to really think about things, you often come up with insights that you would not have if you always rush through things. And these insights can be golden opportunities to change something for the better. Be that a subtle bug discovered, be that a design flaw addressed or something else - the list is long. But as British computer scientist Tony Hoare famously said: "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." But simplicity is hard "I would have written a shorter letter, but did not have the time." If it was Mark Twain or Blaise Pascal who said it is beside the point. The point is, there is a lot of truth in this quote. A writer of prose I know also confirmed what many senior software engineers know - to make something complex simple and easily comprehensible takes way more time and effort in the form of careful thought than it takes to leave it being complicated and hard to understand. AI is good at writing code quickly, yes. But is it also good at writing code which has high q

For a long time, education and work rewarded one thing above all else: the ability to produce correct answers. School exams were built around it. Technical interviews were built around it. Even many engineering jobs were built around it. The person who could respond faster, explain better, and deliver the right output was often seen as the most valuable person in the room. But AI is changing that. Today, answers are becoming cheap. With modern AI tools, anyone can generate code, summaries, documentation, architecture drafts, and even product ideas in seconds. The scarcity is no longer in producing answers. The scarcity is in defining the right problem. That is why, in the AI era, learning how to ask better questions matters more than learning how to write better answers. The Bottleneck Has Moved The biggest shift is not that AI can answer questions. The bigger shift is that answering is no longer the hardest part. When answers can be generated instantly, the real bottleneck becomes: What exactly should be asked? What is the real problem behind the surface request? What constraints actually matter? What outcome is considered good enough? AI can generate many possible answers. But it still depends heavily on the quality of the question. A vague prompt creates vague output. A precise question creates leverage. In that sense, the person who defines the problem is now more important than the person who simply responds to it. The Problem Setter Is More Valuable Than the Problem Solver This idea may sound exaggerated at first, but it becomes obvious in practice. Suppose someone says: Optimize this system. That sounds like a reasonable task, but it is actually too weak to produce a strong result. Optimize for what? Cost? Latency? Reliability? Simplicity? Team productivity? Now compare it with this: We have a Node.js API running on AWS ECS. Under burst traffic, CPU throttling causes latency spikes. How can we reduce p95 latency without increasing infrastructure cost by more

Some of you may have noticed I disappeared a bit from the community over the last couple of weeks....

Eleven exhibits, last time. A career that kept refusing to fit inside a single box — trainer,...

I have been building software for sixteen years. I have four ambassador titles I earned honestly. And last week I sat at my desk at eleven at night, certain that everyone else my age was further ahead than me. You know that feeling. The one where you scroll past someone's launch, someone's promotion, someone's clean little success, and a cold voice says you should be there by now. It does not care what you have done. It only points at what you have not. For most of my career I treated that voice as a problem to solve. If I could learn one more tool, ship one more thing, earn one more title, it would finally go quiet. So I did. I learned the tools. I shipped the things. I earned the titles. The voice did not go quiet. It moved the finish line and waited for me there. Here is the opinion I wish someone had handed me a decade ago. Feeling behind is not a bug in you. It is the tax you pay for caring about the work. The people who feel the most behind are almost never the ones who are actually behind. They are the ones paying attention. They see the gap between what they made and what they meant to make, and that gap never closes, because the moment you get better, your taste gets better too. The gap is not evidence that you are failing. The gap is proof that you still have standards. I know engineers with twenty years and a wall of real accomplishments who quietly feel like frauds. I know brilliant people five years in, staring at a job market that feels brutal, convinced everyone else got a memo they missed. None of them are behind. All of them are exhausted from running a race that has no finish line, on a track only they can see. The comparison is rigged, and it is worth saying why. You compare your inside to everyone else's outside. You know your own doubt, your own half-finished drafts, your own two in the morning. You see their launch, their title, their highlight. You are matching your bloopers against their trailer, and then calling yourself slow. So what change

Everyone talks about the build. Nobody talks about what happens the week after, when you go to actually tell people it exists and discover every distribution channel has its own quiet gatekeeping you didn't know about until you hit it. Hacker News flagged my Show HN before it ever reached the front page. Not rejected — flagged, silently, likely because the account posting it was brand new with a self-promotional link and zero history. No warning, no explanation, just gone from /newest for anyone not specifically looking. Reddit was worse in a different way. r/webdev's AutoMod rejects any submission from an account under three months old with low karma — a hard gate, not a soft one, and it doesn't care which day you post or how you phrase it. r/SideProject let the post through technically, but Reddit's own spam filter quietly removed it minutes later, invisible to everyone except me looking at my own profile. X was just silence. Zero followers means the algorithm has no graph to push the post into. Four views, three of which were probably me refreshing. The one channel that actually worked was the one with the lowest bar to entry: writing. dev.to doesn't gate you behind account age or karma. You write something, it's live, and if it's genuinely useful, people find it — slowly, but for real. That's where actual engagement happened. The pattern underneath all of this: almost every high-leverage distribution channel is, by design, hostile to accounts with no history. That's not a bug — it's the exact mechanism that keeps those platforms usable, and it exists specifically to stop people doing exactly what I was trying to do: show up once with a link and leave. The system is working as intended. It just doesn't feel that way when you're the one hitting the wall. What's actually working, three weeks in, isn't a growth hack — it's writing things people search for, verbatim, and being patient about everything else building account history the boring way: showing up, commenti

Yo! what's up guys 👋🏻 Every developer👩🏻‍💻 has a different environment where ideas turn into...

We’ve all been there. You click "Export Health Data" on your iPhone, wait ten minutes, and receive a massive, bloated export.xml file. If you've tracked your fitness for years, this file can easily exceed 5GB. Try opening that in Python’s ElementTree or even pandas , and your RAM will cry for mercy. This is a classic Data Engineering challenge: transforming high-volume, semi-structured XML into actionable insights without waiting an eternity. In this tutorial, we are going to build a high-performance parser using Rust performance techniques, Rayon for parallelism, and ClickHouse for lightning-fast OLAP queries. By leveraging Rust's zero-cost abstractions, we'll turn a 20-minute Python slog into a sub-30-second sprint. 🚀 The High-Level Architecture Handling 5GB of XML requires a streaming approach. We cannot load the whole file into memory. We will stream the XML, parse segments in parallel, and ship them to ClickHouse using Protocol Buffers for maximum serialization efficiency. graph TD A[Apple Health export.xml] --> B[Streaming XML Reader] B --> C{Chunking Logic} C -->|Batch 1| D[Rayon Worker 1] C -->|Batch 2| E[Rayon Worker 2] C -->|Batch N| F[Rayon Worker N] D & E & F --> G[Protobuf Serialization] G --> H[(ClickHouse DB)] H --> I[Grafana / SQL Insights] Prerequisites To follow along, you'll need: Rust (Stable) Tech Stack : quick-xml (for streaming), serde (serialization), rayon (data parallelism), and clickhouse-rs . A running ClickHouse instance. 1. Defining the Data Schema Apple Health data (specifically Record types) consists of types, dates, and values. Since we want high performance, we'll use Protocol Buffers to define our intermediate format, ensuring minimal overhead when moving data through the pipeline. // Simplified representation of a Health Record use serde ::{ Deserialize , Serialize }; #[derive(Debug, Serialize, Deserialize, Clone)] pub struct HealthRecord { #[serde(rename = "@type" )] pub record_type : String , #[serde(rename = "@startDate" )] pub

A post on X last week: "The fact that people can't even reply to posts without AI anymore says a...

It is been while I am learning and build around FastAPI. So there is a project where I was thinking how to add this new feature over exiting one. Like what changes I need to make in database which need to be reflected in my backend and frontend. I already lunched the web locally. Problem started When I when back to the web and reload it it shows this error: ERROR: ConnectTimeout: Unauthorized 401. I was like what? Why? I thougth there is some issue with login endpoint or refresh token function. When i did some debugging and found some new information which is: "Either Supabase's edge/pooler (or OS, or an intermediate proxy/NAT) silently kills those idle connections server-side after some timeout but client-side pool doesn't know that." As I was doing nothing in become idle state so to save the resources server side silently close that particular connection. So I came back and try to connect it give this error. First thought come it my mind after this was there should be a way to automatically check this idle state and if user was in ideal state then create a new connection. Proposed Solutions After a while I come up with these solution: Calculate the Idle time: if it is more then server connection timeout then establish new connection. Retry logic: retry once on the specific connection errors. I thought this will work but This again give me error then this new issue I faced. Cold-start connection problem There is something call dual-stack (IPv4 and IPv6) networks and Happy Eyeballs is a network mechanism which automatically move to IPv4 connection if IPv6 fails. But supabase-py uses httpx and it doesn't support Happy Eyeballs. So in first try after the connection time out it try to establish IPv6 connection which is not routeable in most Pakistani ISPs and ultimately it fails and wait for timeout. There is no way to try it again for IPv4. So we have to do it manually. So this error help me to learn many thing in process. Share your thoughts.

Watch the fires burning on the far shore. Don't cross until they've burned themselves out. — The 36...

Have you ever wondered how AI engineers fine-tune and align large language models? Under the hood, they run Supervised Fine-Tuning (SFT), optimize parameters using direct preference gradients (DPO), filter out low-quality pre-training corpuses (Pruning), and mitigate catastrophic drifts. To help you visualize how LLM alignment and parameter optimization work in a highly strategic way, I built a cyberpunk card battler inspired by Gwent: 🤖 Epoch Duel: Cyberpunk LLM Alignment Battle Play in Fullscreen Mode (if the embed sizing is tight) 🛠️ Tune Your Model Parameters Your mission as an alignment engineer is to play optimizer cards to outscore the adversarial baseline AI across 3 training Epochs: ⚙️ Logic & Coding: Run SFT code snippets, compile theorem provers, and deploy Python scripts to build your coding benchmark scores. 📖 Language & Speech: Train on multilingual datasets and summarization corpuses to maximize reading comprehension. 🛡️ Safety & Alignment: Implement red-team safeguards, configure RLHF preference pairs, and run DPO tuning to protect your model's outputs. ⚡ regularizers & Drifts: Deploy Regularization cards like Gradient Clipping (Scorch) and Model Pruning to destroy anomalies, or exploit Anomalous Drifts to collapse the AI's rows. 🧬 Playable ML Concepts Explained Here is how the card battle mechanics map to production machine learning pipelines: 1. ✂️ Model Pruning (Weight Compression) In-Game: Playing the Model Pruning card triggers a glitchy dissolution animation that purges the lowest-value card from the targeted board row, cleaning up noise. 💾 The Real-World Counterpart Model Pruning removes unimportant weights (often those closest to zero) from a trained neural network. It shrinks the memory footprint of the model, allowing it to run faster on edge devices. ⚠️ How it affects LLMs By stripping out low-impact weights, pruning compresses models by 30-50% with minimal loss in benchmark accuracy, making deployment significantly cheaper. 2. 🔀 DPO vs RL

Quantum mechanics gave us the transistor before we understood it. The same pattern is happening with AI right now — and the builders who recognize this will define what comes next. The argument that never ended — and the lab that didn't care In 1927, the greatest minds in physics gathered in Brussels for the Solvay Conference. Albert Einstein, Niels Bohr, Werner Heisenberg, Erwin Schrödinger, Max Planck, Marie Curie — twenty-nine of the most brilliant humans who ever lived, in one room. They were arguing about quantum mechanics. Specifically: what does it mean for a particle to exist in multiple states simultaneously until observed? Does reality require an observer? Is the universe fundamentally probabilistic? Is God playing dice? Einstein said no. Bohr said yes. Neither convinced the other. That argument never fully resolved. Nearly a century later, physicists still debate the interpretation of quantum mechanics — the Copenhagen Interpretation, Many Worlds, Pilot Wave theory. We have not settled it. Meanwhile, in 1947 — twenty years after the Solvay Conference — three engineers at Bell Labs in New Jersey quietly invented the transistor. William Shockley, John Bardeen, and Walter Brattain did not wait for the philosophical debate to conclude. They did not need to understand why quantum tunneling worked at a fundamental level. They understood it well enough to build something with it. That transistor became the foundation of every computer, every smartphone, every server, every piece of digital infrastructure that exists today. We built the entire digital civilization on something we still don't fully understand. Not despite the uncertainty. With it. The pattern repeating right now Across the internet in 2025 and 2026, a remarkably similar argument is happening. Will AI take all the jobs? Is it conscious? Does it hallucinate too much to be trusted? Are we building something we cannot control? Should we slow down? Should we stop? These are not trivial questions. The r

Intro AI Avatar is a completely free app that lets your VRoid (VRM) 3D avatar animate in...

Is it just me, or has anyone noticed that articles on dev.to don't get as many reads/views as they...

Last week I sat in my parked car for fifteen minutes before going inside. Not because of...

Here is an uncomfortable one: you do not own your reading list. You rent it. Every "follow" button you have pressed in the last decade put your reading relationship inside a company's database, where it can be ranked, throttled, or ended the day the business model changes. You did not sign anything. You just stopped owning it. It was not always like this. Feeds were the quiet machinery that kept the web interoperable. RSS and Atom meant a site, a reader, and a robot could all agree on the same stream without asking anyone's permission. You published once, and anything could read it: whatever app, whatever order, no algorithm in the middle. Then it eroded. Plenty of sites ship no feed at all now, and "follow us" quietly became "create an account on someone else's platform." The reason is not mysterious. Platforms had every incentive to close the loop, because a feed lets you leave, and an account does not. So the industry swapped "here is my stream, read it however you like" for "log in to see updates," and a generation of sites simply stopped publishing feeds, because the platform was where the audience was. That is the trade you made without noticing. The open format that asked nothing of you got replaced by a login that asks for everything. Your reading list used to live in your reader and survive a company changing its mind, its ranking, or its whole business. Now it lives in their database and survives exactly as long as they allow. Getting it back is not nostalgia. It is infrastructure for independence: tooling that treats feeds as a first-class citizen, aggregates the sources you actually choose, and keeps that stream under your control instead of a platform's. The full case for why this is worth fixing, and what feed-first tooling looks like, is here: https://mederic.me/blog/open-web-feeds So, honestly: how many of the people and sites you follow could you still read tomorrow if the platform in the middle disappeared tonight?

Two weeks ago one of my outdoor cats bit me. She's fine — healthy, pregnant, and deeply offended that I picked her up, but she needed flea medicine and I needed to confirm the pregnancy. (If anyone wants a kitten, I know a grumpy lady who has some.) My pinky swelled up, and typing went from "mildly error-prone" to "not happening." So I dictated this post. If you've ever looked at raw voice transcription, you know what that produces: one giant unpunctuated block with half the words wrong. My transcript literally claims "AI needed to put flea medicine on her." It was me. That's the kind of thing the AI is cleaning up. The ideas are mine. The argument is mine. The punctuation and clarification belongs to the machine, because the machine is better at punctuation than a transcript is. By the rules of the current discourse, you're now supposed to stop reading. That's the game, right? "Not reading this if it's AI-generated." "It has em dashes — slop." Let's deal with the em dash first, since it's apparently forensic evidence now. You can type one. Shift-Option-hyphen on a Mac. Windows-Shift-hypen on Windows. Writers were littering pages with them for a century before the first transformer shipped. Its little brother the en dash is everywhere too, and nobody has ever accused an en dash of being a robot. The em dash gets singled out for exactly one reason: it's a fast, cheap way to judge a piece of writing without engaging with a single idea in it. Zero effort, instant superiority. Remember that phrase — zero effort. It's coming back. Because real AI slop absolutely exists. Someone fires off one prompt, ships whatever falls out, never reads it, then farms for stars and upvotes. That's slop — not because a model was involved, but because no human was. Effort is the variable. The tool never was. Here's what the other end of the spectrum looks like. Hundreds of hours on a single project. I decide the architecture, the language, how it compiles, how it deploys. I fork the output

Have you ever wondered how vector databases like Pinecone, Milvus, Qdrant, or pgvector search through billions of high-dimensional documents in milliseconds? Under the hood, they map semantic concepts into dense numerical vectors, calculate multidimensional cosine similarity angles, and traverse proximity graphs to locate nearest neighbors without scanning the entire database. To help you visualize how vector databases and embeddings actually operate, I built a retro-vector arcade game: 🛰️ Vector Strike: Database Defender Play in Fullscreen Mode (if the embed sizing is tight) 🛠️ Choose Your Database Optimizations Your mission as a Vector Database (VDB) administrator is to configure your query settings and index structures to defend your index nodes: 📏 Similarity Threshold (τ): Tweak the match threshold slider. High thresholds require near-identical semantic matches but protect your index, whereas lower thresholds act like a splash-damage laser but risk matching incorrect clusters. 🪐 Embedding Dimensions (2D $\rightarrow$ 8D $\rightarrow$ 32D): Higher dimensions isolate categories and guarantee precise hits. Lowering dimensions collapses the projection space, causing spatial overlap that results in false deflections and friendly-fire query failures. ⚡ Proximity Indexing (Flat Scan $\rightarrow$ HNSW Graph): Flat Scan: Runs a brute-force linear search over all targets. It causes computation latency spikes as more query objects arrive. HNSW (Hierarchical Navigable Small World): Dynamically builds proximity links between adjacent node targets. The turret traverses vectors along the nearest-neighbor graph, snap-locking onto targets with zero lookup latency. 🧬 Playable ML Concepts Explained Here is how the arcade mechanics map to production vector databases: 1. 🔀 Multidimensional Projections (Dimension collapse) In-Game: You can toggle between 2D, 8D, and 32D space. In 32D space, the categories are cleanly separated. In 2D space, the database collapses, and you'll find sp