标签：#programming

AI is not a smarter Google I am convinced most people are using AI in the worst possible way. They treat it like a slightly magical search bar. Type question. Get answer. Copy. Paste. Forget. I think that mindset is holding a lot of people back. Developers. Designers. Knowledge workers. Even my baseball kids who ask ChatGPT for homework help. AI is not a better Q&A machine. It is a delegation machine. You do not "ask" AI. You give it a job. This post is me making that shift concrete. I just shipped six AI gallery pages on my site, built entirely around that idea. Not as a gimmick. As infrastructure for how I work, learn, and build. Why I stopped asking AI questions The turning point was basically frustration. My workflow looked like this for months: Open ChatGPT Ask something like "How do I X in Astro / Svelte / Next" Skim the answer Try the snippet Debug for 30 minutes anyway The answers were fine. Sometimes even useful. But nothing stuck. I would ask the same class of questions over and over. Same concepts. Same patterns. Same gotchas. No real accumulation of knowledge. Just one-off transactions. Then I noticed something: the few times I actually got huge value from AI, I was not asking. I was delegating. "Rebuild this layout using CSS grid, but keep these class names." "Refactor this component, keep the same API, and annotate the performance tradeoffs in comments." "Act like my annoying senior engineer and poke holes in this data model." That felt different. Less like search. More like a teammate who does legwork while I keep steering. Delegation > questions So I made a decision: treat AI like a junior colleague with unlimited patience and questionable taste. That means: I do not ask "How do I do X". I say "You are responsible for X. Here is context. Here are constraints. Here is the definition of done." The shift sounds subtle. It is not. When you ask a question, the model guesses what you want. When you delegate a job, you tell it what you want and where it fit

Exposing the keys in the GitHub Issue The Phishing Site (Notice the Spotify option) There is a golden rule in cybersecurity: the weakest link is almost always human error. But what happens when that human error comes from a malicious actor trying to orchestrate a crypto phishing scam? The result is surprisingly comedic. Here is the story of how my newly built open-source secret scanner, Sentinel, accidentally neutralized a Tether (USDT) phishing operation during a routine benchmark. The Setup: Testing in the Wild I recently released Sentinel , a statically compiled, context-aware Git secret scanner and pre-commit hook written in Go. After fine-tuning its engine to achieve near-zero false positives, I decided to benchmark it "in the wild" by scanning random, recently updated repositories on GitHub. The goal was to see if Sentinel could catch edge-case credentials that traditional, regex-heavy tools often miss or drown in noise. During the scan, Sentinel instantly flagged a critical severity finding in a rather suspicious repository. The Catch: AI Copy-Paste Gone Wrong Upon inspecting the flagged file, the issue was immediately apparent: a fully exposed, hardcoded Firebase configuration object containing the API key, project ID, and messaging sender ID. It was a textbook case of a script kiddie asking an AI for a web login template and blindly copy-pasting the frontend code into a public repository. They had effectively handed over the administrative keys to their backend infrastructure before the project even launched. The Phishing Site: Logging into Crypto with Spotify? Out of professional curiosity, I checked the Vercel deployment linked to the repository. The project was attempting to impersonate Tether (USDT), the world's largest stablecoin. It featured the official logo, a catchy slogan, and a login prompt designed to harvest credentials. However, because the scammer had blindly copied a generic consumer application template, the authentication options presented

# Building an AI Sales Intelligence Platform in Just 12 Hours at Hack Aarambh 2026 Turning sales conversations into actionable business insights using AI. Yesterday, my team and I participated in Hack Aarambh 2026 at Swarnim Startup & Innovation University (SSIU) . Like every hackathon, the challenge wasn't just writing code—it was identifying a real-world problem, designing a practical solution, and delivering a working prototype within 12 hours . Instead of building another chatbot or productivity tool, we wanted to solve a problem faced by almost every sales-driven organization. The Problem Every day, sales teams spend hours talking to potential customers. These conversations contain valuable information such as: Customer pain points Buying intent Competitor mentions Product feedback Common objections Feature requests Unfortunately, most of this information remains buried inside meeting recordings or handwritten notes. Managers rarely have time to review every conversation, which means valuable business insights are often lost. That became our motivation. Introducing AI Sales Intelligence Platform Our project is an AI-powered platform that automatically analyzes sales conversations and transforms them into actionable insights for both sales representatives and business leaders. Instead of manually reviewing calls, users receive: AI-generated summaries Customer intelligence Actionable recommendations Performance analytics Business insights ...all within seconds. What We Built AI Call Transcription & Summarization The platform automatically converts conversations into readable transcripts and concise summaries. Customer Intelligence The platform identifies: Customer sentiment Buying intent Objections Competitor mentions Important discussion topics This helps sales teams focus on what actually matters. AI Generated Follow-ups Writing follow-up emails after every meeting is repetitive. Our platform automatically generates personalized follow-up emails based on each c

When learning a new technology, most of us follow a familiar path. We start with the official documentation. Then we search GitHub repositories. We read blog posts. We watch YouTube tutorials. Eventually, we ask an AI assistant when we get stuck. Each resource solves a different problem, and the best developers know when to use each one. Documentation Is the Foundation Official documentation should almost always be your first stop. It tells you how a framework or library is intended to work. The information is usually accurate, maintained, and version-specific. If you're learning React, Next.js, or Node.js, the official docs provide the most reliable starting point. But documentation has limits. It explains what something does, not always why developers use it in real projects. Community Content Fills the Gaps That's where blog posts, conference talks, and open-source repositories become valuable. Experienced developers share: Real-world architecture decisions Common mistakes Performance considerations Debugging strategies Project structure Deployment workflows These practical insights often don't belong in official documentation, but they're essential for becoming a better engineer. AI Has Changed the Workflow AI assistants have become another tool in the developer toolbox. Instead of searching through multiple pages, developers can ask targeted questions like: Why is this hook re-rendering? What's the difference between these two approaches? How can I improve this query? Can you explain this error message? AI doesn't replace documentation. It helps you understand it faster. The most effective workflow is using documentation as the source of truth while letting AI explain concepts, compare approaches, or clarify confusing examples. Build Your Own Reference Library One habit that's improved my productivity is creating a personal knowledge base. Whenever I solve a difficult problem, I write down: The issue Why it happened The solution What I learned Links to relevant

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

Publishing ten apps in four months sounds good. And it is good. It means the bottleneck is no longer building the app. With AI-assisted coding, small utilities, focused experiments, and niche apps can go from idea to App Store submission in days, sometimes hours. But there is a second part that can soon get really ugly. And messy. And time consuming. After you publish the apps, you own them – not in the inspirational sense, in the annoying sense. Every app becomes a small surface that needs attention: metadata, screenshots, reviews, ratings, keywords, conversion, cross-promotion, build status, rejections, releases, privacy answers, promo text, support links. Ok, you can catch your breath now. We good? Good, let’s move on. One app is manageable as a pastime, but ten apps are already a small portfolio. And a small portfolio needs systems. So I started building one. The repo is called app-store-release-agent , and, for now, it’s a small Python toolkit for the release workflow itself. Eventually, this could evolve into a full ASO brain. The Business Problem The business problem is simple: maintenance does not scale linearly with motivation. Building an app has a clear dopamine loop. Maintenance is fragmented: a review here, a screenshot there, a keyword set that probably needs work, a support email, a product page that now feels weak. None of these tasks are hard in and by themselves. That is a real and very subtle trap, because they can easily get postponed, and then they pile up. The benefit of an automation pipeline is not only speed. Speed is good, don’t get me wrong, but it’s secondary. The real benefit is lowering the activation energy. If the agent can pull live App Store data, compare it with local metadata, inspect git history, and apply the next release action safely, I do not have to reconstruct the context from scratch every time. A good pipeline should answer three questions quickly: What needs attention now? What can wait? What action has the highest lever

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

Offloading fan-out work to Render Workflows (docs linked above). Retries and parallel tasks live there. My problem is the web layer. First version: return 202, tasks POST back to /internal/events with a bearer token, UI subscribes over SSE. Added a reconciler that polls the Render API every 2s anyway because I didn't trust callbacks alone. Second version: skip callbacks entirely. One POST stays open, poll getTaskRun every 1.5s in an async generator, stream SSE until the digest finishes. Postgres at the end. Less wiring, but the HTTP request lives for the whole run. Both work on small traffic. I'm not sure which one I'd keep if this wasn't a demo. Restarting the API wipes in-memory viewer state in the callback version. Workflow keeps going, which is fine, but the UI looks stuck unless you reconcile. Polling version doesn't have that split because the request IS the session. Has anyone shipped callbacks + poll backup long term? Or do you pick one and accept the downsides? Callback handler: github.com/ojusave/dealhealth-playground/blob/main/services/api/src/routes/events.ts Poll loop: github.com/ojusave/read-it-for-me/blob/main/server/lib/orchestrator.ts submitted by /u/ojus_render [link] [留言]

The first year class HelloWorld { public static void main ( String args []) { // Displays "Hello World!" on the console. System . out . println ( "Hello World!" ); } } The second year /** * Hello world class * * Used to display the phrase "Hello World" in a console. * * @author Sean */ class HelloWorld { /** * The phrase to display in the console */ public static final string PHRASE = "Hello World!" ; /** * Main method * * @param args Command line arguments * @return void */ public static void main ( String args []) { // Display our phrase in the console. System . out . println ( PHRASE ); } } The third year /** * Hello world class * * Used to display the phrase "Hello World" in a console. * * @author Sean * @license LGPL * @version 1.2 * @see System.out.println * @see README * @todo Create factory methods * @link https://github.com/sean/helloworld */ class HelloWorld { /** * The default phrase to display in the console */ public static final string PHRASE = "Hello World!" ; /** * The phrase to display in the console */ private string hello_world = null ; /** * Constructor * * @param hw The phrase to display in the console */ public HelloWorld ( string hw ) { hello_world = hw ; } /** * Display the phrase "Hello World!" in a console * * @return void */ public void sayPhrase () { // Display our phrase in the console. System . out . println ( hello_world ); } /** * Main method * * @param args Command line arguments * @return void */ public static void main ( String args []) { HelloWorld hw = new HelloWorld ( PHRASE ); try { hw . sayPhrase (); } catch ( Exception e ) { // Do nothing! } } } The fifth year /** * Enterprise Hello World class v2.2 * * Provides an enterprise ready, scalable buisness solution * for display the phrase "Hello World!" in a console. * * IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED * TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER * PARTY WHO MAY MODIFY AND/OR REDISTRIVUTE THE LIBRARY AS * PERMITTED ABOVE, BE LIABLE TO YOU FOR DAM

The café was crowded that evening, but to me, the world had fallen completely silent. An open...

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

When building an AI agent, you need LLM calls. It can be done via a remote API or a local API, but either way you need to do it. Whether the agent is a simple conversational agent or a ReAct agent with a bunch of tools, whether it's using a complex graph or a simple RAG, it must be based on the concept of sending prompts to the language model. But, what if we replace the language model with... another agent? Let's say we already have a smart agent with a bunch of tools that can handle complex problems. Why not use it to build a new agent on top of it? This way we can focus on the specific custom functionality we want to achieve, while already having the common functionalities covered by the underlying agent. You might think this must be expensive. You get a better performance, so you have to pay for it, right? Well, not necessarily. The catch is that the coding assistants are actually surprisingly cheap when compared to API prices. They offer much more than raw LLM calls, they offer amazing agent functionality, but the cost is actually lower, and it's not a small difference. The cost of LLM calls per 1M tokens is usually between $2 and $7. For coding assistant subscriptions, it's a bit more tricky to calculate because you pay for monthly subscription, but it can be still converted to per 1M tokens cost, and from what LLM just told me it is around $0.08 to $2. That's a huge difference! And the complex agents are cheaper than raw LLM's! according to ChatGPT: Service Cost per 1M tokens Codex / ChatGPT coding plan ~$0.08 Cursor Pro ~$0.08–0.25 GitHub Copilot Pro ~$0.10–0.30 Claude Pro / Claude Code ~$0.74 GPT-5 API ~$2.1 Claude Sonnet API ~$4.2 Claude Opus API ~$7.0 according to Claude: Service Cost per 1M tokens Haiku 4.5 (API) $1.80 Sonnet 5 (API, intro thru Aug 31 '26) $3.60 Sonnet 5 (API, standard) $5.40 Opus 4.8 (API) $9.00 Fable 5 (API) $18.00 Claude Code — Pro ~$1.10–$2.15 (est.) Claude Code — Max 5x ~$2.10–$4.15 (est.) Claude Code — Max 20x ~$2–$4 (est.) So, why

Rewriting a Database Giant: Meet pgrust PostgreSQL is the bedrock of modern application development. It is incredibly stable and feature-rich, but it is built on a C codebase that started in the 1980s. In systems programming, legacy C architectures carry memory-safety risks and make core changes difficult. pgrust is an experimental open-source project that aims to rewrite the entire PostgreSQL database engine from scratch in Rust. The project recently hit a historic milestone: it now passes 100% of the official PostgreSQL 18.3 regression test suite (over 46,000 test queries). What is pgrust? pgrust is a native reimplementation of the Postgres query execution and storage layers. Unlike other projects that wrap Postgres or write extensions, pgrust is a complete rewrite of the database core itself. Crucially, it is disk-compatible with PostgreSQL 18.3, meaning it can boot up and read from an existing Postgres database directory on your machine. Key Technical Improvements By shifting from C to Rust, pgrust introduces several modern engineering improvements: 1. Memory Safety Rust’s strict compiler guarantees eliminate major classes of security vulnerabilities (like buffer overflows and dangling pointers) that frequently patch legacy C databases. 2. Thread-Per-Connection Model Standard PostgreSQL uses a "process-per-connection" architecture, which consumes a lot of system memory. pgrust changes this to a "thread-per-connection" model, drastically reducing the overhead of open connections. 3. Massively Improved Performance Because of its optimized query engine and thread-based architecture, early benchmarks show: 50% faster execution on standard transaction workloads. Up to 300x faster execution on analytical workloads. Built with an "AI Agent Factory" Rewriting a database with millions of lines of code is a monumental task. The authors of pgrust accomplished this by setting up an automated pipeline of concurrent AI coding agents. The agents were tasked with explaining leg

How I Supervise Three Engineering Workflows at Once Three Workflows, One Operator Right now, I have three engineering workflows open. One is under council review. Four AI roles are challenging an architectural proposal, and I will need to decide which objections actually change the plan. The second is already in implementation. That one does not need me at the moment. The specification is approved, the boundaries are clear, and the executor can keep moving. The third has come back from audit. The findings are valid, but corrective work is paused. A remediation plan exists, and someone other than the executor needs to review it before any more code changes. This is the part that still feels new: I can move between all three without reopening old chats and rebuilding the story in my head. A few months ago, even one workflow could take most of my attention. I carried context between every stage: rewriting role prompts, moving decisions between conversations, tracking the current document, and turning audit findings into the next round of work. The AI council itself was already useful. It produced strong reasoning and exposed assumptions I would probably have missed. But I was still the glue around it. The council improved the decisions. The system around it made those decisions easier to carry into implementation, audit, and correction without losing control. Conversations Were No Longer the Workflow The main change was simple to describe: I stopped treating the workflow as a series of conversations. Chats are good for thinking. They are not a good place to keep authority. Before this change, a decision might exist somewhere in a long discussion. The next agent had to interpret it, and I had to remember whether it was final, provisional, or already replaced. Now the state of the work lives in a small set of artifacts. Evidence becomes a source-grounded brief. Decisions become an approved specification. The specification becomes bounded implementation. The implementatio

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback. You've been using the terminal for months/ years. Maybe you cd into a folder, ls around, run your script, and call it a day. That's fine. That's like knowing how to boil water and calling yourself a chef. But the terminal has layers . It's basically an onion that occasionally makes you cry, usually around 12 AM when a script fails silently and you have no idea why. So grab your coffee and let's talk about the command line tricks that actually make your life better. Not the "did you know ls -la shows hidden files" tier tips. Your Terminal Has A Memory. Use It. Most devs mash the up arrow like it's 2007 and they're trying to beat a Flash game. Stop that. Press ctrl-r instead. It searches your command history live. Type a few letters, it finds the last matching command. Press ctrl-r again to cycle back further. Found it? Hit Enter to run it, or the right arrow to drop it into your prompt so you can edit it first. ctrl-r ( reverse-i-search ) ` docker run ` : docker run -it --rm -v $( pwd ) :/app node:20 bash Pair this with ctrl-w (delete last word) and ctrl-u (nuke the line back to the cursor) and you'll start editing commands like you're speedrunning a text adventure. And if you're the type who types a whole essay of a command and then realizes you forgot something at the start, ctrl-a jumps to the beginning of the line and ctrl-e jumps to the end. No more holding the left arrow key like it owes you money. Pro tip: if you're a TUI fan and ctrl-r's default search feels a bit flat, check out McFly xargs Is The Friend Who Actually Shows Up Pipes ( | ) are great. They pass output from one command into another. But sometimes you don't want to pass output as input , you want to pass it as arguments . That's where xargs comes in, and once you get it,

Better to sacrifice a part to preserve the whole. — The 36 Stratagems, Sacrifice the Plum Tree to...

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

Everyone talks about AI writing code. Nobody talks about AI debugging code. Bad error messages are the worst, we've all seen them. You open the logs or run your program and see something like this... Error: something went wrong It leaves you asking: What happened? Where did it happen? Why did it happen? How do I fix it? You might have written some of these pretty silly error messages, I know I have. They don't help us fix software quickly because we first have to figure out why the error happened. Rust has been shipping fantastic error messages for years. Take this example where I accidentally call println instead of println! . $ cargo run 101 ↵ Compiling ducksay v0.2.0 (~/oss/ducksay) error[E0423]: expected function, found macro `print` --> src/main.rs:51:3 | 51 | print("{}", render_with_style(&message, cli.width.get(), style)); | ^^^^^ not a function | help: use `!` to invoke the macro | 51 | print!("{}", render_with_style(&message, cli.width.get(), style)); | It's fantastic! It tells you what went wrong, where it occurred, and how to fix it. When you're building software, you should make your error messages exceptional (punny 😂). Here's another example from Vite+ where I had a syntax error in the config file. $ vp dev failed to load config from ~/oss/test-ssr-on-aws/vite.config.ts error when starting dev server: Error: Build failed with 1 error: [PARSE_ERROR] Error: Unexpected token ╭─[ vite.config.ts:5:3 ] │ 5 │ , │ ┬ │ ╰── ───╯ Now imagine debugging code with generic error messages that tell you absolutely nothing helpful. You'll have to manually trace through the code to figure out what the heck is going on. AI agents run into the same problem. If the error tells them almost nothing, they have to spend extra time reading files, tracing execution paths, and making additional tool calls just to understand what failed. So what can we do to help humans and AI? Here are some of my top recommendations for writing good error messages. 1. Be descriptive and specific W

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

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