标签：#cka

Somewhere in the DataLens build, my teammate and I hit the wall every "zero-dependency" project eventually hits: the anomaly detector needed a neural net, and the rulebook said no third-party packages. No NumPy. No pandas. No scikit-learn. Just Python 3.14's standard library. Our first reaction was denial. You cannot build an ANN without a matrix library — everyone knows that. numpy.dot() is basically load-bearing infrastructure for machine learning in Python. We spent an embarrassing amount of time trying to convince ourselves some obscure math submodule secretly did vectorized linear algebra. It doesn't. There is no shortcut. If you want matrix multiplication in pure stdlib Python, you write nested for loops and you like it. What we normally would have installed In any other project, this is a two-second decision: pip install numpy , import it, move on with your life. Matrix ops, broadcasting, vectorized activation functions — all free. Neither of us had ever really had to think about how A @ B works under the hood, because neither of us had ever had to write it ourselves. What it actually took to replace it An autoencoder needs: matrix multiplication, transpose, element-wise activation functions (sigmoid, ReLU), and gradient computation for backprop. Without NumPy, every one of those is a hand-rolled function operating on nested Python lists. Matrix multiply becomes three nested loops instead of one line. A forward pass that would be a single .dot() call turns into a small file of helper functions: matmul() , transpose() , add_bias() , sigmoid() , sigmoid_derivative() . We split it — one of us built the forward pass and activation functions, the other took backprop and the training loop — and then spent a good while debugging the seam where the two met. The genuinely hard part wasn't the math — it was performance. Pure Python loops over lists of lists are slow, and profiling a dataset with a few thousand rows through even a small autoencoder made that obvious fas

This is a submission for Weekend Challenge: Generosity Edition What I Built Community Solar Energy Bank is a platform that lets people and businesses with residential or commercial solar panels donate their surplus energy credits directly to low-income families in Brazil, through NGOs connected to each family's utility company. The idea: in Brazil's net-metering system, a solar panel owner who generates more than they use accumulates credits with their utility company, credits that often just sit there, underused. At the same time, low-income families served by the very same utility struggle with expensive electricity bills. This project connects the two without anyone touching real money, you're not buying anything, you're redirecting energy credit you already own. I wanted the project to be upfront about what's real and what's a demo. States and utility companies are real data (Light in RJ, Enel in SP/CE/GO, Cemig in MG, Equatorial in MA/PA/PI, Amazonas Energia in AM, Roraima Energia in RR, Neoenergia Pernambuco in PE), though coverage is deliberately partial, states without a registered utility show an honest empty state instead of fake data. NGOs are entirely fictional, and every card says so. No real money or energy transfer happens anywhere, the donation flow is a simulation end to end. Demo Live demo: https://solar-credit-exchange.vercel.app Flow: pick your state on the map, choose the utility company serving it, pick an NGO linked to that utility, enter how many kWh of surplus credit you want to donate, review an AI-generated checklist of what that utility typically requires, confirm, and see it reflected on the aggregated impact dashboard. Code claudiofilho87 / solar-credit-exchange Community Solar Energy Bank A demo platform that lets people and businesses donate their surplus solar energy credits directly to low-income families served by NGOs in Brazil. Built for the DEV Weekend Challenge: Generosity Edition hackathon. This is a hackathon demo. No real ut

A library isn't code. A library is thirty or forty decisions somebody already made, correctly,...

Building StudySift Without Third-Party Dependencies Introduction What if a useful study tool could be built without installing a single third-party package? For the Zero Dependency Hackathon, I built StudySift , a command-line tool that converts lecture transcripts into structured, revision-friendly study notes. The idea is simple: give StudySift a transcript and automatically extract useful information such as keywords, definitions, examples, and important points. The interesting part was the constraint. The project had to run using Python's standard library only , with no third-party runtime dependencies. The Problem Lecture transcripts can be long and difficult to revise. Important definitions, examples, keywords, and important statements can be spread throughout the transcript. Students often have to manually read the entire transcript, identify important sentences, and create their own notes. I wanted to reduce this manual work. StudySift takes a text transcript as input and processes it into organized notes. The basic workflow is: Lecture Transcript ↓ StudySift ↓ ┌─────────────────┐ │ Definitions │ │ Important Points│ │ Examples │ │ Keywords │ └─────────────────┘ **What I Built** StudySift is a Python command-line tool. The user provides a transcript file: python src/main.py examples/lecture.txt StudySift processes the transcript through several stages: 1. Read the input file 2. Split the text into sentences 3. Extract words 4. Remove common words 5. Count word frequencies 6. Detect definitions 7. Detect examples 8. Identify important sentences 9. Score sentences 10. Sort sentences by importance 11. Generate structured notes The goal is not to pretend that a collection of simple rules is a complete natural-language understanding system. Instead, StudySift is a lightweight and transparent approach to turning transcripts into useful revision material. **The Zero-Dependency Challenge** The biggest constraint was that StudySift could not depend on third-party runt

We're back with another DEV Weekend Challenge, a short bite-sized challenge planned to fit into your...

Most hackathons ask you to build whatever you want. Dogfood 2026 does the opposite. Everyone builds the same thing: a submission and judging platform for hackathons. The challenge is simple: Build the platform that will judge you. And there is a reason this is more interesting than it sounds. Hackathon Raptors has run 35 hackathons across 85+ countries since 2023. They have seen the same problems appear again and again: registrations, teams, submissions, judge assignments, scoring, normalization, results, certificates, and exports all becoming separate pieces of an increasingly messy workflow. Now they want to build the platform they actually wish they had. That is what Dogfood is about. About the Hackathon Dogfood 2026 is a 72-hour online hackathon organized by Hackathon Raptors . The event runs from September 25 to September 28, 2026 . At a glance 🌍 Online and global ⏳ 72 hours 💰 $2,500 prize pool 👥 Solo or teams of up to 4 💸 Free to participate 🔓 Open source 🐳 Self-hosted 🛠️ Build with the stack of your choice But this is not a normal platform-building challenge. The winning project is intended to be forked, self-hosted, and used for actual Hackathon Raptors events. So instead of building a demo that gets abandoned after the weekend, you are building something that could become real infrastructure. Why Build Another Hackathon Platform? Hackathon platforms already have most of the features organizers expect. Registration. Team formation. Project submissions. Public galleries. Judge scoring. Community voting. Organizer dashboards. CSV exports. So what is missing? The difficult part is not building another CRUD application. The difficult part is making the entire system reliable when real people start using it. Consider judging. Two judges can look at the same project and give completely different scores. One might give almost everything a 4 or 5. Another might rarely give anything above a 3. Simply averaging those scores can produce a ranking that reflects the judg

September marks the official start of Preptember, a month dedicated to organizers planning local...

Every company knows when it revoked access. None knows when access stopped. I built this for the All Things Agentic Hackathon , and I wrote this post for the purposes of entering that hackathon. Code: github.com/NexuChat/parallax The chore I was actually trying to kill I maintain a web application with two roles, two languages, one of them right-to-left, a dark theme, and three viewport sizes. Every release, I would open it as the owner, click through, sign out, sign in as a member, click through again, switch to Arabic, reload, shrink the window, reload — and try to remember what a page had looked like ten minutes earlier. The worst defects never survived that process, because they are not visible in any single session. A member opening a page they should have been denied sees nothing wrong. Nothing on the page says "you should not be here." The information is not in their session at all. It is in the difference between their session and the owner's. So I stopped testing sessions and started comparing them. Seven witnesses, one axis apart Parallax opens seven isolated browser contexts at the same instant against the same application. One is a baseline — owner, English, light, desktop. The other six each change exactly one axis from it: privilege, locale, theme, viewport. The full product of those axes is thirty-six combinations. Seven one-axis derivations is not just cheaper; it is the only version that can attribute a cause. When the Arabic witness disagrees with the baseline and locale is the only thing that changed, locale is the reason. With thirty-six combinations you get a bigger table and less knowledge. Each axis carries a contract about what must change and what must not: Axis Contract A finding is Privilege access must differ sameness — an escalation Locale access constant, layout mirrors access drift, or geometry that did not mirror Theme access constant, layout does not move any positional shift Viewport access constant, reflow allowed access drift That

I wrote this post for my entry to the All Things Agentic Hackathon. TLDR: I built a five-agent design team on Gemini (Including Gemini Flash 3.7 and Gemma 4) that takes a brief and a folder of photographs and returns finished, editable pages. The interesting engineering was not the prompts. It was deciding wh ere the run's progress lives. Code: github.com/minhthanhdang/vibes-ai . What it does Vibes AI is a design co-pilot. Upload photographs, describe what the thing is for, and it designs the pages: real crops, generated backgrounds, type in any Google Fonts family, all written as geometry that can be dragged afterwards. There are five agents. An orchestrator holds the other four as tools, so every hop is request and response, and the user reads one reply instead of a transcript of agents talking to each other. A property analyzer reads each upload in six design dimensions. An image editor cuts. An image generator draws the picture the gallery does not have. A design assistant does the actual designing. The part I want to write about is the unattended run. One form (purpose, page count, palette, vibe, size) and then no further human input until the pages are done. One long request was the wrong shape Designing six pages is minutes of model calls, not milliseconds. My first instinct was one request that loops over the pages and returns when it is finished. That shape gives nothing back. No honest progress, no Stop button that means anything, and a failure at page four throws away pages one to three. So a page became the unit of work. One job designs one page. The job is a row in an AgentRun table, a worker claims it under a lease, and when it settles it enqueues the next page inside the same transaction that marks the current one done: const chained = await db . $transaction ( async ( tx ) => { const won = await tx . agentRun . updateMany ({ where : { id : run . id , status : RunStatus . RUNNING , startedAt : run . claimedAt }, data : { status : RunStatus . SUCCEEDED

Building a multi-agent system sounds simple on a whiteboard. Give one agent a task, let another handle the next step, add a reviewer, connect a few tools, and you have an agentic workflow. It gets more complicated when those agents need to operate at the same time. A sequential workflow can force agents into a fixed order: one finishes, another starts, and everyone downstream waits. That model is easy to reason about, but it can become restrictive as the system grows and agents need to react to new information independently. Mozaik takes a different architectural approach. It is an open-source TypeScript framework for building reactive agents inside an event-driven environment, where agents can work concurrently, respond to events, and coordinate without requiring a central workflow to define every interaction. And now there is a practical way to try this architecture. JigJoy , together with daily.dev and Hyperskill , is organizing the Mozaik Hackathon 2026 , a free online hackathon focused on building concurrent AI agents. TL;DR Building more agents doesn't automatically make a multi-agent system better. The way those agents communicate, react, and depend on one another can have a bigger impact on how the system behaves as it grows. Mozaik approaches this problem with an event-driven architecture designed around reactive, non-blocking agents. Agents join a shared AgenticEnvironment , receive events, and decide how to react to them. Here’s what makes the Mozaik Hackathon 2026 worth a look: Concurrent AI agents: Multiple agents can work at the same time and react to events as they arrive. Event-driven architecture: Agents, humans, observers, and tools participate in the same AgenticEnvironment . Non-blocking execution: Inference and message delivery can continue in the background without holding up other participants. Loosely coupled agents: Agents can operate more independently, making them easier to reuse across projects and applications. TypeScript-based: Mozaik i

I created this content for the purposes of entering the All Things Agentic Hackathon. The problem that started it A doctor gets about eight minutes with a patient and, for anyone with a real history, forty pages of scattered records — lab reports, discharge notes, and pharmacy bills from three different clinics. So the history is effectively invisible at the exact moment it matters most. And when the visit ends, nothing follows up: the six-month course lapses at week five, the recheck never gets booked. I wanted to build an agent that closes that loop — one that reads the mess, decides urgency in a way a clinician can actually trust, and handles the follow-up on its own. That became CareLoop , my entry for the All Things Agentic Hackathon (Taskmaster track), built on Gemini, the Google Agent Development Kit (ADK), Cloud Run, and Firestore. The one principle I wouldn't compromise on Rules decide, AI explains. The temptation with an LLM is to let it do everything — including deciding whether a chest-pain patient is urgent. I refused to do that. In CareLoop, a deterministic engine owns every clinical decision: a weighted symptom score plus a red-flag override sets the triage level and routing. It is fully auditable, and it returns byte-identical output on the same input every single time. The LLM's job is strictly language: Reading unstructured documents into a fixed schema — I call it "Gemini extracts, rules merge." Writing the structured result into a plain-language brief a clinician can skim in ten seconds. No language model is ever in the decision path. When a judge asks "why was this Critical?", the answer is a score breakdown they can inspect — not a model's say-so. That single decision shaped the whole architecture. What it actually does CareLoop runs the full loop end to end: Ingest & compact — it reads a patient's documents and merges them into one structured ledger: allergies, chronic conditions, active medications, and lab trends over time. Instead of pushin

Winning is the part everyone posts about. The two months after — the part where a cash prize actually...

Every hackathon has the same 90-second moment of dread: someone hands you a codebase you've never seen, and you have to make sense of it before the clock runs out. File trees don't help. grep doesn't help. You waste the first 30–60 minutes reading the wrong files, missing a hidden dependency, and stepping straight into a production trap nobody warned you about. In other words: before writing code, you spend half your time trying to figure out where the hell the code is. The idea wasn't "AI that writes your code." It was "AI that tells you where to look before you write it." For InnovaHack Chapter-1, my team built Waypoint — a dev onboarding platform. Point it at any GitHub repo or a local folder, describe a task like "Add a new global configuration flag to app.set()", and instead of you reading the whole codebase to figure out where that even goes, it hands you a Mission Brief : exactly which files you'll touch, the traps waiting in them, what to learn first, and the order to do it in. Waypoint made the Top 50 — one of the 50 chosen to advance to Round 2. Here's how it actually works under the hood, what it took to build, what's next for it — and since I don't believe in only posting the highlight reel, what happened after we placed that made us walk away from the next round. The problem: the cold-start tax Every time a developer joins a new codebase, or picks up an unfamiliar task in one they already know, there's a tax paid in wrong files read, missed dependencies, and traps hit blind. For me, that moment came when I wanted to contribute to Forem — the open-source project that actually powers DEV. I didn't know a line of Ruby on Rails, and between learning the language, understanding the framework, and preparing for interviews, I didn't have the time to read an entire unfamiliar codebase just to figure out where one feature belonged. I never ended up making that contribution. But the problem stuck with me. It's also a pattern for our team more broadly: we delibera

MBMC IdeaX 2026 is a national technology hackathon organized by Madan Bhandari Memorial College in Kathmandu, Nepal. Registration opened on 28th Shrawan 2083 (13th Aug) and closes on 16th Bhadra (1st Sept). The Online Round runs from 21st–28th Bhadra (6th–13th Sept), followed by the Final On-Site Hackathon Event from 16th–18th Ashoj (2nd–4th Oct). Participants will develop innovative technology solutions across five problem tracks: Climate Change, Resilience & Sustainability; Tourism; E-Governance & Smart Public Services; Smart Urban Transport & Road Safety; and FinTech & Digital Financial Innovation. Visit: https://ideax.mbmc.edu.np/ for more details and registration.

The correlation notice fired. Three sites, same anomaly type, inside the time window. The orchestrator caught it and logged it, live, against the deployed service. Clean, first try. Then I asked myself a question I almost didn't bother asking, because the thing had just worked: why did it work? The answer wasn't "because the logic is correct." It was "because Cloud Run happened to route both requests to the same running instance." Well, shit. My orchestrator was holding its list of recent risk events in a plain Python list, in process memory. Worked in local testing because there's only one process. Worked live because Cloud Run, under light traffic, often reuses the same instance instead of spinning up a second one. Neither one's a guarantee. The moment traffic patterns shifted and two readings landed on two different instances, the second instance wouldn't have a clue the first one existed. A correlation that should fire would just silently not. A bug that passes its own demo is the hardest kind to catch. There's no error to chase. There's just a checkmark. What I was building VES Fleet is a network of independent site-agents (Bori, Choba, Etche, three real survey sites in the Niger Delta). Each one reads an underground electrical survey, send current into the ground, measure how it flows back, a real physical signal of what's down there, and calibrates its own contamination-risk threshold from its own site's real history. Not a number copied from anywhere else. An orchestrator watches for the same risk signature showing up at more than one site inside a time window. It's my submission to the Fortified Enterprise Fleet track of Google's All Things Agentic Hackathon. Architectural discipline is 30% of the score there. Proving it actually runs on Google Cloud is a separate 30%. So a bug that only looked fixed was never going to survive someone actually reading the state-management story. Checking the thing that already worked Once I understood the actual failure mod

I wrote this on X a few weeks ago: I just had a very bad reminder as to the fact these LLMs are statistical parrots, I let it write code I normally wouldn't trust it to write (infra code, lots of unique behaviours) and damn I wasn't talking about my own project when I wrote that. Then StacksNG proved me right, on its own corpus, in a hackathon I'm trying to win. Ask my RAG assistant to verify an Interswitch webhook signature, and it didn't say "not in my knowledge base." It wrote a full authentication flow — real-looking endpoint, real-looking headers — and cited a source URL. The URL wasn't in my corpus. It wasn't anywhere. The model invented a citation for content it also invented, with zero hedging. I'm building StacksNG for the Africa Deep Tech Challenge 2026 — an offline coding assistant scoped to the African fintech stack: Paystack, Flutterwave, Monnify, Termii. Before I submitted, I ran a 20-prompt adversarial batch against my own pipeline. Category A (in-corpus baseline) and D (phrasing brittleness) came back clean. Category B — five prompts asking about payment providers I deliberately never scraped into the corpus, Kuda, PalmPay, Interswitch, Paga, OPay — did not. Three of five ignored a system prompt that already said, in plain language, "if the context doesn't contain enough information, say so." That's the failure mode that zeroes out half the score in a hackathon where accuracy is 50% of the total. My first theory was wrong, and I could prove it My instinct was: this is a retrieval-confidence problem. Set a similarity threshold, refuse to answer below it, done. I checked the actual numbers before writing that fix. Top-1 similarity What happened Correct in-corpus answer 0.718 correct Worst fabrication (Interswitch) 0.712 fully invented, fake citation Correct decline (out-of-domain topic) 0.691 "not in my knowledge base" The worst hallucination had higher retrieval similarity than the cleanest correct decline. There's no threshold that lets the good case

npm 12 introduces significant security-related changes, making certain installation behaviors opt-in. Notably, script allowances are now off by default, which requires explicit approval for running scripts, including implicit builds. The update also restricts non-registry sources and addresses community concerns about security risks from automatic script execution. By Daniel Curtis

We're back with another DEV Weekend Challenge, a short bite-sized challenge planned to fit into your...

Finding grants means digging through 50 scattered Discords, blogs, websites, and Notion pages. So I built a fix. Meet Web3 Accelerator GrantHub (W3AGH). What is GrantHub? GrantHub is a web app that helps Web3 founders discover funding opportunities without digging through dozens of scattered websites. Grants are listed across ecosystems like Solana, Ethereum, Polygon, BNB Chain, Arbitrum, Base, and more. The idea is simple: instead of spending hours searching for funding opportunities, you should be able to find relevant grants in one place. GrantHub also has AI tools that sit on top of the grant database. You can describe your project once and instantly see which grants fit best. Why GrantHub? Funding is the lifeblood of Web3 startups, but finding grants today is painful. Scattered listings Every ecosystem publishes its own programs on its own website, blog, Discord, or other channels. There is no single source of truth. Stale information Grants expire, close, or change their requirements, while the listings founders rely on can remain outdated. Manual matching A founder has to read through each grant's requirements and figure out whether their project qualifies. With dozens of grants available, that can quickly turn into hours of work. No personal workflow There is no single place to save interesting grants, track applications, or ask questions about a specific program. GrantHub is built around solving these problems. It combines three things: One central catalog of grants stored in a real database. Personal tools: accounts, favorites, and a personal dashboard. AI assistance: a grant ranking engine, an AI assistant, a smart-contract auditor, and context-aware chat on every grant page. Who is this for? Solo builders and startups: looking for funding or ecosystem support. Beginners who don't yet know which ecosystems and grants are right for them. Anyone who would rather spend their time building than hunting for funding. The goal isn't to create another directory o

Are you interested in leveraging AI, remote sensing, and data-driven solutions to tackle climate change and public health challenges? The Climate & Wellbeing Hackathon—hosted by Nims University Rajasthan and the World Health Summit Academic Alliance in collaboration with Khushi Baby—is officially open for registrations! 🎯 About the Hackathon Climate change directly impacts human, animal, and environmental health. Rising temperatures, extreme weather events, air pollution, and changing disease patterns pose severe threats to global wellbeing. This virtual hackathon bridges the gap between scientific research and field execution to create actionable policy guidance and real-world technology interventions. 🏆 Prizes & Recognition The Top 2 Innovative Ideas will receive The Dr. B.S. Tomar Innovation Award at the prestigious World Health Summit Academic Alliance - Expert Meeting on Climate & Wellbeing. 🛠️ Problem Statements & Tracks ☀️ Hazard: Heat Near-real-time heat-health burden nowcast (Public-health surveillance / Data fusion) Build an excess-illness/mortality index by fusing open environmental & proxy-demand signals to nowcast heat stress days ahead. Satellite rooftop heat-vulnerability classifier & cool-roof prioritisation engine (Climate adaptation / Remote sensing) Automatically identify and rank urban rooftops that urgently need cooling to produce an operational work-order. From action plans to living, tracked decisions (Climate-health governance / Decision-support) Develop a copilot to benchmark plans, operationalise daily actions, and monitor public feeds to map heat-health intervention gaps. Early heat-strain warning for outdoor & informal workers (Occupational health / Edge AI & sensing) Build a smartphone-based system estimating personal heat strain with local-language guidance and zero extra hardware. Heat-surge readiness for the health system (Operations research) Build decision-support tools to help health systems prepare ahead of forecast heat spikes. 🌬