标签：#programming

The promise of agentic AI coding was a tireless partner, an assistant that could take a feature request and run with it while we focused on the hard problems. The reality, for most professional engineering teams, has been different. The reality is a brilliant but distractible intern you have to constantly supervise. The reality is spending 20 minutes writing the "perfect prompt," only for the AI to ignore a critical constraint, use a deprecated pattern from your codebase, and confidently break three other features. The reality is the "babysitting tax." It's the cognitive overhead of constantly reviewing, reverting, and re-explaining. And it's negating the incredible potential of these tools. At BrainGrid, we believe the problem isn't the agent—it's the plan. Or the lack thereof. In our rush to generate code, we've skipped the most critical step: creating a shared, deep, and unambiguous understanding of what we're actually building. "Vibe coding" doesn't work in a multi-tenant system where permissions are non-negotiable, or at least not with peace of mind. It doesn't work in a complex fintech application where money is on the line. And it certainly doesn't work in a four-year-old codebase with layers of tech debt and unwritten rules. The bottleneck in software development is no longer just the speed of writing code. The bottleneck has shifted to the speed of creating a reliable plan. BrainGrid is the AI-powered planning platform built to solve this new bottleneck. It's designed to provide the structure and guidance—the "babysitting plan"—that turns powerful but unreliable coding agents into predictable and effective teammates. Here's how: We Give the Agent a Map BrainGrid starts by deeply analyzing your entire codebase—its architecture, data models, and dependencies. It provides the persistent context that agents desperately need but currently lack. We Help You Define the Destination Our requirements agent acts like a seasoned tech lead, asking you and your team clar

submitted by /u/AdvertisingFancy7011 [link] [留言]

submitted by /u/West-Chard-1474 [link] [留言]

I spent a long time dissecting OOP and I had a really interesting realization that I detailed in the attached blog post. If you're as interested in software design as I am, I hope you get new inspiration for how to structure your programs from it. I'm obviously leaving out a lot, but if you're intuitively familiar with the concepts behind OOP, you should understand the parts I left implied. PS for after you read it: Now obviously, I'm not saying they're "the same thing". There are different styles of programming that make something "more functional" or "more object-oriented". In fact, the "pure" versions of both OOP and FP are extremely easy to identify: pure OOP being the endpoint of leaning into the naming, and pure FP being the endpoint of leaning into the functors, and neither really being fun to work with. But my point is that the fundamentals of both are the same, just like how derivatives and integrals form two sides of Calculus. If you try to defend one and chastise the other, you can't use either effectively, and just dig yourself deeper into a hole of design patterns to make up for how inflexible you've left yourself. In truth, once we dissect how OOP really works, we can deconstruct it to replace most design patterns with something that borrows from each of them - Factories with constructor references, listeners with function references, list mapping with transducers - all without violating any OOP principles. It's only once we intuitively understand their foundations that we can use OOP less rigidly and FP more structured, creating something that's far greater than the sum of its parts. submitted by /u/bythepowerofscience [link] [留言]

submitted by /u/AmrDeveloper [link] [留言]

Quick Tip: How to Choose the Right Model for Slack AI Workflows in 2026 I've been running Slack-integrated AI workflows in production for about three years now, and the question I get asked most often is deceptively simple: "Which model should I actually use?" Back in 2024, the answer was easy — you picked GPT-4o and moved on. But in 2026, with 184 models accessible through Global API and price points ranging from $0.01 to $3.50 per million tokens, that decision has become a genuine engineering problem. Pick wrong and you're either burning budget or shipping a sluggish experience. Pick right and your CFO actually smiles at you. Let me walk you through how I think about this, what the numbers actually look like, and where I've landed after months of benchmarking across multi-region deployments. Why Slack Workloads Are Weird Most people underestimate what a Slack AI assistant needs to do well. It's not a chatbot. It's a latency-sensitive, always-on, context-heavy workload that has to feel native inside a chat client where users expect responses faster than they can refresh the channel. In my experience, the three constraints that matter most are: p99 latency under 1.5 seconds for the first token — anything slower and users start double-messaging 99.9% uptime across at least two regions — Slack itself is up, so your AI better be too Cost per active user per month under $0.40 — this is the line where finance stops asking questions If a model can't hit those numbers consistently, it's not viable, no matter how clever the benchmark scores look. The Pricing Landscape I Actually Use Here's the table I keep pinned in my team's documentation. These are the models we rotate between depending on the workload. I haven't changed a single number — these are the exact rates as of writing this: Model Input ($/M) Output ($/M) Context DeepSeek V4 Flash 0.27 1.10 128K DeepSeek V4 Pro 0.55 2.20 200K Qwen3-32B 0.30 1.20 32K GLM-4 Plus 0.20 0.80 128K GPT-4o 2.50 10.00 128K The spread is w

submitted by /u/Infamous_Sorbet4021 [link] [留言]

I wrote this technical deep-dive to explore the paradigm mismatch between declarative, set-based processing and sequential, depth-first search algorithms. The write-up walks through the mechanics of forcing a relational database engine (DuckDB) to handle chess logic, specifically: Data Representation: Mapping 64-bit bitboards into a relational model using UBIGINT types. The Pruning Blocker: Why the stateless nature of relational sets prevents sibling nodes from communicating, making true Alpha-Beta pruning impossible inside a single query. The Workaround: Offloading the stateful control flow to an external orchestrator to implement Batched Principal Variation Search (PVS) across query boundaries without violating the declarative nature of the core chess math. The resulting chess engine is obviously not competitive, but the goal was to document the architectural trade-offs, the performance walls encountered with recursive CTEs, and how relational algebra behaves when pushed entirely out of its comfort zone. submitted by /u/swing_bit [link] [留言]

British Columbia has recently made some time zone changes —- but you have a few months until you feel the impact. That gives an opportunity to deep dive into time zones, timestamp storage, and more. submitted by /u/winsletts [link] [留言]

I spent the last 2 months building a storage engine from scratch understand how storage engines actually work. To respect the rules of this subreddit, we will not discuss the features ør benchmarks, for that you should read the repo yourself. To understand how I came up with the bits and pieces to put together this project, follow along. So here's my entire journey. Two things: - I built this project because of a recent interest in low-level and systems programming, that combined with my general affinity towards stateful systems made this project an obvious choice. - I see a lot of cool projects (on various social platforms) and when I attempt to read their code, it's obvious that it's written by AI. I intend to share my thought process here because I want to spread awareness that it's very much possible to build something like a storage engine using your first principles intuition. ---------------- Let's begin: 1 . Given all the knowledge I had and using first principles thinking, I setup an in-memory KV store but then it's obvious I had to make it persistent. I added persistence by writing a single line to the file every time someone made a PUT request. The file now had a bunch of {key: "hello", value: "world"}\n. So during startup, I would read all these lines and recover everything into in-memory. 2 . For me, at this point that's all the upfront knowledge I had. So I asked some very basic questions: > How would I recover the entire file into memory on startup? At some point it just wouldn't be possible because the file is growing unbounded. This means that I must not load everything in-memory and instead access the file directly > But then if I read every line top to bottom on every GET then my latency would be literally obliterated? This means I must somehow efficiently query the file. I came up with a solution, I created files based on alphabets, all keys with prefix A will end up in file A, all keys with prefix B will end up in file B and so on. By first prin

This one is bit math heavy. I started of building a small timeseries compression library, and ended up digging through some numerical algorithms, linear algebra. I learnt through a hose during last week and found something genuinely beautiful. If you stick through it I suppose you can see what I saw. submitted by /u/ennamo_po_madhava [link] [留言]

How I replaced all the ugly S3 URLs on my Laravel blog with clean /storage/media/... and /storage/og-images/... paths. The setup: Laravel + Octane + Traefik + Cloudflare. Two buckets -- a private one for uploaded media and a public one for auto-generated OG images. What's in the post: - MediaUrlBusiness helper class that centralizes URL generation (replaced 6+ blade templates of raw Storage::url() calls) - ObjectProxyController that streams files directly from S3 using readStream() + response()->stream() -- no memory buffering - Cache-Control: public, max-age=86400, immutable so Cloudflare caches aggressively - Route setup in routes/static.php with a middleware tweak that doesn't overwrite the proxy's own cache headers One gotcha: Storage::download() and streamDownload() buffer the whole file into memory. Switching to readStream() sends it directly from S3 to the client. submitted by /u/HolyPad [link] [留言]

Originally published on the Prufa blog . Five days ago we audited 49 Show HN launches and found that 78% had a critical bug on day one. This week we pointed the same free audit at a different cohort: 14 products freshly posted to r/SideProject. We expected more of the same. We got the opposite — and it turned out to be more interesting. Not one of the 14 had a critical finding. No broken signup flow, no canonical pointing at the wrong domain, no analytics tag silently swallowing every event. By the measure that matters most on launch day — does the core thing work — these builders shipped clean. And yet every single site had findings. They just all live one tier down, in a layer so consistent it reads like a shared checklist nobody handed out: 11 of 14 sent no analytics events at all. 11 of 14 shipped with no Content-Security-Policy and could be framed by any site (no X-Frame-Options ). 11 of 14 had serious accessibility violations . 12 of 14 had tap targets smaller than 24px on mobile. 9 of 14 took over four seconds to paint their largest element on mobile. 8 of 14 had no canonical link on the entry page. No site is named in this post. The point isn't to embarrass anyone — these are good builders who got a real product live. The point is that the same common side-project launch mistakes show up again and again, and if 11 of 14 strangers have them, you probably have a few too. Methodology, briefly We pulled 20 URLs from recent r/SideProject posts and ran each through the same audit a free Prufa run does: a real browser loads the public pages and captures network traffic, console output, response codes, headers, and the rendered DOM, then a fixed suite of deterministic checks grades the evidence. Same input, same verdict. Of the 20: 14 completed cleanly , 4 were blocked by bot protection before our runner could load them, and 2 didn't finish inside our polling window. The numbers below are from the 14 that completed. Two honest caveats. First, 14 is a small sample —

I use a form validation problem as a technical interview question. It's deceptively simple — and the solutions people reach for reveal a lot about how they think. Then I tried it on Claude, ChatGPT, and Gemini. The results were illuminating, but not for the reasons I expected. The Problem Many form libraries share a common convention: form data is represented as a plain nested object, and the validation function returns an object of the same shape containing the errors. You'll find this pattern in Formik and React Final Form in React, and — full disclosure — in Inglorious Web , my own framework, which ships form handling built in without any extra dependencies. const values = { productName : ' VR Visor ' , quantity : 1 , homeAddress : { street : ' Long St ' , zip : ' 00666 ' }, shippingAddress : { street : ' Short St ' , zip : ' 00777 ' , co : ' Inglorious Coderz ' }, billingAddress : { street : ' Wide Plaza ' , zip : ' 00888 ' , vat : ' 1142042 ' }, } The validation function should return an object containing all errors found. A starting example: function validate ( values ) { const errors = {} if ( ! values . productName ) { errors . productName = ' required ' } return errors } The ask: extend this to validate every field . Notice that the three address types aren't identical. shippingAddress requires a co field. billingAddress requires a vat . These differences matter — and how you handle them reveals a lot. Four Solutions, Four Instincts 1. The Flag — the average human The most common approach I see in interviews is a single validateAddress function with a type parameter: function validateAddress ( values = {}, type ) { const errors = {} if ( ! values . street ) errors . street = ' required ' if ( ! values . zip ) errors . zip = ' required ' if ( type === ' shipping ' && ! values . co ) errors . co = ' required ' if ( type === ' billing ' && ! values . vat ) errors . vat = ' required ' return errors } It works. But every new address type, every new special rule,

submitted by /u/chkas [link] [留言]

submitted by /u/BlondieCoder [link] [留言]

We Built Korexbase: A Lead Generation Platform for Finding Business Leads by City and Niche Building software is exciting. Building software that solves a real problem is even better. Over the past few months, we've been working on Korexbase , a lead generation platform designed to help businesses discover targeted leads faster. The Problem Many agencies, sales teams, freelancers, and startups spend hours manually searching for potential customers. The process usually looks something like this: Search for businesses online Collect contact information Copy everything into spreadsheets Repeat the process every day It's slow, repetitive, and difficult to scale. We wanted to simplify that workflow. The Idea Korexbase allows users to search for business leads by: City Industry Business category Instead of manually collecting data, users can generate leads and manage them through a clean dashboard. The goal isn't to replace sales. The goal is to help businesses spend less time searching and more time closing deals. Building the Platform A major focus during development was creating a dashboard that feels simple and easy to navigate. Some areas we focused heavily on included: Responsive layouts User-friendly navigation Clear data presentation Fast loading interfaces Consistent design patterns Challenges Like most projects, we faced a number of challenges: Designing for Simplicity One of the biggest lessons was that adding more features doesn't automatically create a better product. We spent a lot of time simplifying interfaces and removing unnecessary complexity. Creating a Better Dashboard Experience Presenting lead generation data in a way that is useful without overwhelming users required multiple design iterations. We focused on: Better spacing Better visual hierarchy Cleaner cards and tables Improved responsiveness Product Positioning An interesting challenge was refining the product's positioning. As development progressed, we learned more about what users actually w

This module built one thing, from many angles: the container — the part of Spring that creates your objects, wires them together, and hands them out. Eight articles each zoomed in on a different corner of it. This recap zooms back out. The goal here is not to re-explain each topic, but to show how they are all the same idea seen from different sides, so the whole module collapses into a picture you can hold in your head at once. So before the details, here is the single sentence the entire module hangs on: the container is a factory that runs at startup, and almost every feature you met is just that factory doing a little extra work while it builds a bean. Keep that sentence close. Everything below is a way of filling it in. The factory, in one picture Picture an assembly line that runs exactly once, when your application boots. You hand it a list of what to build and how the pieces fit. It builds every object your app is made of, connects them, sets them on a shelf, and hands them out on request for the rest of the program's life. That assembly line is the container. The objects it builds and manages are beans . An object you create yourself with new is not a bean — Spring never touched it — and that distinction is the thread running through every trap in this module. The factory does four things at startup, and the order matters: it reads recipes, works out who needs whom, builds from the bottom up, and caches each result. ApplicationContext ctx = SpringApplication . run ( App . class , args ); OrderService svc = ctx . getBean ( OrderService . class ); // already built and wired By the time run returns, the work is done. Asking for a bean is instant because the building already happened. Every other topic in the module is a detail about how that one startup pass works. Why we hand the work over at all The module opened with a question of control. Left alone, a class builds its own collaborators with new — and in doing so it welds together two unrelated decisions:

I'm not here to trash Sololearn. Sololearn taught millions of people how to code. It was one of the first apps to make programming education feel mobile-native. That's a real achievement. I respect it. But I'm building Codino — a Python learning app — and I'd be lying if I said I didn't study Sololearn carefully before writing a single line of code. I looked at what they got right. I looked at where users complained. And I made decisions based on both. This is that honest breakdown. What Sololearn Got Right 1. The Community Feel Sololearn built a genuine community. The code playground where users share their projects, comment on each other's code, and get likes — that was smart. Learning feels less lonely when other people are doing it alongside you. It created a social loop that kept people coming back even when they weren't actively doing lessons. I haven't built this yet in Codino. The leaderboard is a start, but a full community layer is something I'm thinking about for a future update. 2. Multi-Language Support Sololearn didn't bet on just one language. Python, JavaScript, C++, SQL, HTML — they covered everything. That gave them a massive addressable audience. Codino is Python-only right now. That's intentional — going deep on one language is better than going shallow on ten. But I understand why multi-language eventually matters for scale. 3. The Code Playground The ability to write and run real code inside the app — without going to a browser — was ahead of its time when Sololearn launched it. That feature alone brought back users who had finished all the lessons. Codino has a full offline IDE powered by Sora Editor. I'd argue ours is actually more capable — real syntax highlighting, autocompletion, offline Python execution — but Sololearn deserves credit for proving this feature matters. 4. Bite-Sized Lessons That Actually Work Sololearn understood that people learn on the bus, in bed, waiting in line. Their lessons are short, digestible, and don't demand 45

AI coding assistants have fundamentally changed the way we write software. Today it's perfectly normal to ask ChatGPT, Claude, Cursor, or Copilot to explain an API, generate a React component, review a pull request, or help debug a problem. For many developers, these tools have become part of the daily workflow. Yet there's one area where they still struggle more than we'd like to admit: understanding the current state of the web platform. Mozilla recently demonstrated this problem in a surprisingly direct way. While evaluating Claude Code on recently released Firefox features, the team discovered that the model confidently claimed Firefox didn't support the Web Serial API and that Mozilla had no plans to implement it. The answer sounded plausible, detailed, and authoritative. There was just one issue. Firefox had already shipped support for the API. That experiment became one of the motivations behind Mozilla's new MDN MCP Server , a tool designed to give AI assistants direct access to MDN documentation and browser compatibility data. More importantly, Mozilla didn't just launch the service—they tested whether it actually improves the quality of AI-generated answers. The results are worth paying attention to. The Real Problem Isn't Hallucination When discussions about AI reliability come up, the conversation usually focuses on hallucinations. But browser compatibility is a slightly different problem. The web platform evolves continuously. Browsers ship new APIs, CSS features, HTML capabilities, and compatibility updates every few weeks. Specifications change, Baseline statuses evolve, and features that were experimental yesterday can become production-ready tomorrow. Large language models, on the other hand, are trained on snapshots of information. Even highly capable models can only know what was available when they were trained. When they're asked about something that appeared later—or something that wasn't widely represented in their training data—they often hav