标签：#dev

I recently launched SpotClause, a small AI contract review and reader tool. The idea came from a simple problem: contracts are often difficult to read, especially for freelancers, consultants, and small teams who receive agreements but do not work with contract language every day. SpotClause helps users: summarize contracts in plain language identify key clauses understand payment terms, renewal terms, cancellation language, obligations, and deadlines compare two contract versions and see added, removed, changed, and unchanged wording I also added a Contract Clause Library with plain-language explanations of common clauses like cancellation clauses, renewal clauses, payment terms, confidentiality clauses, and notice periods. You can try the AI Contract Review Tool here: AI Contract Review Tool You can explore the Contract Clause Library here: Contract Clause Library SpotClause is not a law firm and does not provide legal advice. The goal is to help people understand contract language more clearly. I would appreciate feedback on: whether the homepage explains the product clearly whether the AI contract review page feels understandable what clause explanations would be useful to add next

Due to a growing influx of questions on this topic, it has been decided to commit a monthly thread dedicated to this topic to reduce the number of repeat posts on this topic. These types of posts will no longer be allowed in the main thread. Many of these questions are also addressed in the sub FAQ or may have been asked in previous monthly career threads . Subs dedicated to these types of questions include r/cscareerquestions for general and opened ended career questions and r/learnprogramming for early learning questions. A general recommendation of topics to learn to become industry ready include: HTML/CSS/JS Bootcamp Version control Automation Front End Frameworks (React/Vue/Etc) APIs and CRUD Testing (Unit and Integration) Common Design Patterns You will also need a portfolio of work with 4-5 personal projects you built, and a resume/CV to apply for work. Plan for 6-12 months of self study and project production for your portfolio before applying for work. submitted by /u/AutoModerator [link] [留言]

Hi everyone, We're building an automation platform using Playwright where all browser automation runs on the backend. For portals that require manual intervention (OTP, CAPTCHA, MFA, document uploads, etc.), we're exploring a way to let users temporarily view and interact with the running backend browser from our React application, after which automation would resume automatically. Our goals are: Keep all automation logic on the backend Support human intervention only when necessary Scale to bulk processing workflows Deploy reliably in production We're currently evaluating approaches such as CDP screencasting, VNC/noVNC, and WebRTC-based browser streaming. Has anyone built something similar in production? What architecture did you choose, and what were the biggest challenges around scalability, latency, security, session management, and CAPTCHA/OTP workflows? Also, is there a better alternative than live browser streaming for this use case? Any advice, experiences, or open-source projects would be greatly appreciated. submitted by /u/Loud_Ice4487 [link] [留言]

Shopify Staff Engineer Guilherme Carreiro discusses building and scaling highly customizable platforms. Using Shopify’s Liquid theme system as a case study, he explains how to balance extreme design flexibility with low-latency performance under massive traffic. He shares insights on implementing secure domain-specific languages, native code extensions, and resilient developer tooling. By Guilherme Carreiro

The AI productivity paradox states that AI scales whatever abstraction it is built on. If that abstraction is structurally brittle, it scales structural brittleness. This article shows how, to build a future of reliable, AI-driven test automation, we must stop scaling DOM-centric abstractions and build a new testing paradigm grounded in perception and intent. By Amanul Chowdhury, Vinay Gummadavelli

Hello Dev Community! 👋 It is officially Day 8 of my journey to master the MERN stack! After spending the first week structuring with HTML and styling with CSS, today I finally started learning the core language of web logic: JavaScript . Moving from static designs to actual programming logic feels like unlocking a whole new level of web development. 🧠 Key Learnings From Day 8 Today was all about setting up the foundation in JavaScript and understanding how code runs in the browser. Here is what I covered: 1. The Browser Console & Execution I learned that every browser has a built-in environment to run JavaScript. Writing my very first console.log("Hello World"); and seeing it print in the developer tools console was the perfect start. 2. Variables: Storing Data Safely I learned how to store information using variables and the crucial differences between modern variable declarations: let : For values that can change later in the program (mutable). const : For values that must remain constant and cannot be reassigned (immutable). Note: I also read about var , but learned why modern JavaScript avoids it due to scoping issues. 3. Data Types Fundamentals Data needs a type so the computer knows how to handle it. Today I practiced with: Strings: Plain text enclosed in quotes (e.g., "MERN Stack" ). Numbers: Integers and decimals without quotes (e.g., 2026 ). Booleans: Simple true or false states (e.g., isLearning = true ). 🛠️ What I Actually Code / Experimented With Since I am just starting with core logic, I didn't write code directly into my HTML webpage layout today. Instead, I created a script.js file, linked it to my project, and built a basic script in the console that: Stores a user's name and learning status in variables. Dynamically calculates values (like years left until a milestone). Outputs formatted statements into the browser console. It is simple, but understanding how data moves in the background is incredibly exciting. 🎯 My Goal for Tomorrow (Day 9) Tomorr

Not every old business web app needs a full Internet Explorer environment. That sounds obvious, but it is easy to miss when a legacy intranet, ERP, OA, or ASP.NET WebForms page fails in Chrome or Microsoft Edge. The first instinct is often to put the whole system into IE mode. Sometimes that is absolutely correct. Other times, the page mostly works in Chromium and only breaks on older JavaScript or DOM assumptions. The useful first step is to separate those two cases. Case 1: the page needs a real IE engine Use Microsoft Edge IE mode, a Windows virtual machine, remote desktop, or another managed legacy-browser path if the page depends on: ActiveX controls COM integration VBScript Trident or MSHTML rendering behavior Browser Helper Objects Java applets strict IE7 or IE8 document modes A Chrome extension or JavaScript compatibility layer should not be presented as a replacement for those requirements. If the workflow depends on the IE engine, the browser engine is part of the application runtime. Case 2: the page mostly works, but old browser assumptions fail There is another common category. The page loads in Chrome or Edge, authentication works, and the main UI appears, but a small set of old behaviors fails. Examples include: empty frameset entry pages loading pages that do not finish redirecting attachEvent window.event event.srcElement showModalDialog -style picker flows document.frames older WebForms date fields that call a calendar function on focus For maintained source code, the best answer is still to fix the application. Replace old event APIs, remove synchronous dialog assumptions, and modernize generated WebForms scripts where possible. But in many real organizations, the legacy page is owned by a vendor, frozen department system, or migration backlog. In that situation, a scoped compatibility layer can be worth testing before moving the whole workflow into IE mode. A low-risk triage sequence I use this sequence: Pick one legacy hostname. Pick one failing

Mañana cambia el billing de Copilot: las premium requests dan paso a AI Credits calculados por tokens. Esto es lo que debe revisar un equipo técnico. El 1 de junio de 2026 GitHub Copilot empieza a migrar desde el modelo de premium requests hacia billing por uso con GitHub AI Credits. La unidad deja de ser una petición premium más o menos abstracta y pasa a reflejar consumo de tokens: entrada, salida y tokens cacheados, con precios vinculados al modelo usado. Decisión rápida Qué cambia mañana La idea de GitHub es alinear precio con coste real. Una pregunta rápida a un modelo ligero y una sesión larga de agente sobre varios archivos ya no son equivalentes. Para equipos técnicos, eso obliga a tratar Copilot como infraestructura de IA, no como una extensión de editor de coste fijo. Este artículo complementa la guía previa de AI Credits, pero se centra en el cambio operativo inmediato: qué mirar antes de que el modelo entre en vigor mañana. Briefing Qué es un AI Credit GitHub define AI Credits como una unidad de billing donde 1 AI Credit equivale a 0,01 USD. Cada interacción que usa modelos consume tokens. Esos tokens se valoran según el modelo y se convierten a créditos. En planes individuales, Copilot Pro, Pro+ y Max incluyen asignaciones mensuales de AI Credits. En organizaciones y empresas, cada licencia aporta créditos que se agrupan en un pool compartido a nivel de billing entity. La diferencia clave con el sistema anterior es que el consumo puede variar mucho dentro de una misma función. Dos sesiones de chat no cuestan igual si una es una pregunta corta y otra arrastra contexto de repositorio, varias iteraciones y generación de código extensa. Lectura práctica Qué consume créditos y qué no GitHub documenta que consumen AI Credits funciones como Copilot Chat, Copilot CLI, Copilot cloud agent, Copilot Spaces, Spark y agentes de terceros. Las code completions y Next Edit suggestions no se facturan en AI Credits y siguen incluidas en planes de pago. Esta distinción es

Hey everyone 👋 I'm exploring ideas for an AI-powered developer tool, but before building anything, I want to understand the real problems developers face every day. There are already plenty of tools that generate code. What I'm interested in is everything around coding: Debugging Code reviews Technical debt Documentation Dependency upgrades Testing Deployment Architecture decisions Learning large codebases I'd love to hear from you: A few questions: What's the most frustrating part of your workflow? What task takes more time than it should? What's something you wish AI could do for you today? Have current AI tools (ChatGPT, Claude, Cursor, Copilot, Gemini, etc.) failed you in any important way? If you could eliminate one developer headache forever, what would it be? I've also created a short 2-minute survey: 🔗 https://docs.google.com/forms/d/e/1FAIpQLSf1M5d2y-0RXEIhrbDBtS5gC900YuzWl43cJCxGUrU38MyeDQ/viewform?usp=publish-editor I'll happily share the survey results and key findings with the community once I collect enough responses. Thanks in advance for any feedback!

Integrations kill product velocity. Every SaaS team knows this. You ship a killer feature, customers love it, then they ask: "Can it sync with Salesforce? What about HubSpot? Zendesk?" Suddenly your roadmap is hostage to building connector after connector. Each one takes 2-3 weeks. Your engineers hate it. Your customers wait. Competitors who solve this faster win deals. The standard response has been iPaaS platforms. They help, but they don't fundamentally change the game. You still need engineers to map fields, handle edge cases, and maintain brittle connections. The real breakthrough isn't just automation , it's making integrations LLM-native from the ground up . What Actually Makes an Integration Layer "AI-Native"? Let's cut through the marketing speak. Every B2B tool now claims to be "AI-powered." Most just added a ChatGPT wrapper to their UI. Real AI-native architecture means three things: 1. LLM-Ready Connectivity via MCP Servers Model Context Protocol (MCP) is Anthropic's standard for connecting LLMs to external data sources. If your integration layer doesn't support MCP servers natively, your AI features will always be bolted on, not built in. MCP servers expose your SaaS data to language models in a structured way. Instead of engineers writing custom API wrappers for every LLM interaction, you get a standardized interface. Claude, GPT-4, and future models can query your integration layer directly. Example: A customer support tool with native MCP integration lets an AI agent pull ticket history from Zendesk, check Stripe subscription status, and update Salesforce records in one conversation flow. No custom code. No brittle middleware. 2. AI-Mapped Data Migration Data migration is where most SaaS deals die. Customer says "we'll switch from ServiceNow to your ITSM if you migrate our 50,000 tickets." Your team estimates 6 weeks. Deal stalls. Traditional migration means: Manual field mapping spreadsheets Custom scripts for data transformation Downtime windows Hi

I've been thinking about a specific version of AI-assisted debugging. Not asking which tool is smarter, but asking about the behavior change that would come from removing the context-setup step entirely. Right now I self-select which debugging problems to involve AI on. The threshold is roughly: is this complex enough that the setup cost is worth paying? Copy the relevant code, copy the error, add context about the project structure, ask my question. It takes a few minutes to do well. If the AI could see my IDE directly, no copying, no pasting, just "look at this and tell me what's wrong," I think my threshold would drop significantly. I'd ask about more things. Smaller things. Things I currently just push through myself because they don't seem worth the setup overhead. Whether the answers would be better because the AI sees the actual screen is a separate question. But the behavioral change from removing the friction might matter more than any quality improvement. If AI debugging had zero setup cost, would you use it differently? Or do you think the current copy-paste step is actually useful because it forces you to think through the problem before you ask? submitted by /u/Professional-Peach-3 [link] [留言]

I use Claude a lot for complex problem-solving and Copilot inline in VS Code for quick completions. The difference in actual usage frequency is something I've started noticing. Copilot I use constantly, basically without thinking about it. Claude I use maybe five times a day, and half the time I talk myself out of opening it because I already know what's coming: copy the relevant code, paste it, add context about the project structure and what I was trying to do, explain the error I'm getting, then finally ask the actual question. The friction is small. But it's consistent enough that I default to struggling through something myself, or Googling, instead of opening Claude. The specific case that gets me most is when the problem is visible on screen. I can see the bug. Claude could probably help me solve it faster. But the work of getting what's visible into Claude's context is just enough friction to make me not bother. Is the gap between ""AI embedded in the tool you're working in"" and ""AI in a separate chat window"" meaningful to other developers, or is this a habit thing I should just push through?" submitted by /u/Queasy_Hotel5158 [link] [留言]

Hey r/webdev 👋 I recently launched UtilCraft , a collection of free browser-based tools for devs and creators. The whole idea is that everything runs locally, nothing gets uploaded anywhere. Right now it has 16 tools across 6 categories: 🛠️ Developer tools (UUID generator, JSON formatter, Regex tester, Cron generator…) 🖼️ Image tools (compressor, converter, resizer) 📄 PDF tools (merge, split) 🔒 Security (password generator, hash generator) 📝 Text tools 🔄 Converters (color, unit) I'd love to know two things from people who actually write code for a living: 1. What tool do you find yourself Googling way too often that you wish was just… there? 2. Any of the existing tools that feel half-baked or could be way more useful? No account needed, no sign-up, just open and use. Roast it, suggest stuff, I'm all ears. 🙏 submitted by /u/Yolmack [link] [留言]

Hi everyone, I need some career advice. I'm from a non-IT background and have been working in a small company for the last 2.5 years, mainly doing HTML and WordPress work. I don't have much exposure to modern development, and with AI changing the industry so fast, I'm worried about my future career growth. I'm thinking of joining an offline Full Stack Development course in Chennai because online learning hasn't worked well for me. I'm confused between **Java Full Stack** and **Python Full Stack**. For those who have experience in this field: * Which stack would you recommend? * Which institute is better: Besant Technologies, Greens Technology, or FITA Academy? * Are there any better alternatives in Chennai? I want to learn real-world projects and build skills that can help me get better opportunities. I'm 2.5 years into my career and don't want to make the wrong decision at this stage. Any guidance, personal experiences really help full for me. Any advice would be greatly appreciated. Thanks! submitted by /u/Best-Quantity-4749 [link] [留言]

I build a security platform. Last night I stopped adding features and did something less fun and more honest: I sat down to make every capability prove it actually works — end to end, with real data, demanding a real pass or fail. "It ran" is not a pass. A page that renders is not a feature. A green checkmark is a claim, not evidence. So I went capability by capability and tried to break each one. I found four real bugs and one of them was a gut-punch: a whole detection engine that was wired into the UI, unit-tested, and never actually ran in production. Here's how the night went. The rule: drive it, don't admire it My method was boring on purpose. For each capability: Feed it real input through the real entry point (CLI or API), not a test fixture. Check the data actually landed (query the DB, don't trust the success message). Feed it a malicious input and a benign input — it has to fire on one and stay quiet on the other. The detection engine passed cleanly. I threw a PsExec process event at it and it lit up: $ zds-core detection eval --event '{"event_type":"process_create","process_name":"psexec.exe"}' 1 alert ( s ) : [ high] PsExec Execution — ( matched: map[process_name:psexec.exe] ) A wevtutil cl Security event tripped a critical "Log Clearing" rule. A plain notepad.exe matched nothing. Good — it detects, and it doesn't cry wolf. (Small UX papercut I fixed while I was there: if you forgot the event_type field, the engine silently matched nothing and printed "no rules matched" — which reads exactly like "you're safe." Now it warns you that the event can't match any rule. Silence that looks like safety is the most dangerous output a security tool can produce.) The one that hurt: ITDR Identity Threat Detection and Response. The engine has detectors for impossible travel, credential spraying, brute force, privilege escalation. All unit-tested. All green. I ran the real flow: POST two login events for one user — New York, then London thirty minutes later. That's ~5

15 years ago Akamai was the CDN network every tv station was using to distribute their content on, but from what I can remember they were also crazy expensive. Nowadays I still noticed that most major companies use Akamai but with strong competition from AWS. Did Akamai became more price friendly or did AWS become to have to same amount of local nodes? submitted by /u/Sure-Guest1588 [link] [留言]

Submission Template Challenge: Build With Hermes Agent Project: CompliScore AI compliance health checks for Indian startups Repo/live-demo: https://github.com/nehaprasad-dev/hermes-scout What I built CompliScore gives Indian startup founders a compliance score out of 100 in under a minute - overdue GST filings, MCA returns, penalty exposure, and a plain-English action plan. The upgrade for this challenge: I replaced the one-shot Groq summary with a Hermes Agent reasoning loop that plans an investigation, calls deterministic compliance tools, and writes a prioritized report - with a collapsible agent trace so judges can see the agentic work. Why an agent loop fits here Compliance analysis is conditional. A company with overdue GST needs a filing-calendar deep dive; one with active notices needs notice triage; a clean company needs a light touch. A single prompt guesses all of this at once. An agent that calls tools based on what it finds produces tighter, grounded reports. Hermes Agent integration Scan → computeHealth (deterministic score) → Hermes Agent loop (plan → tool calls → report) → agent trace in UI ↓ on failure Groq one-shot → static fallback Four tools exposed to Hermes (scores never hallucinated): Tool Purpose score_company Canonical score, risk level, pending tasks estimate_penalty GST / MCA / notice penalty breakdown filing_calendar GSTR-3B, GSTR-1, MCA deadlines (90-day horizon) classify_notices Severity labels for pending government notices The agent runs over Hermes's OpenAI-compatible /chat/completions API with function calling — self-hostable via vLLM, LM Studio, Ollama, etc. Transparency: Every successful agent run returns an agentTrace — plan steps, tool names, compact result previews — rendered in a collapsible panel under the AI action plan. Reliability: Three-tier fallback (Hermes → Groq → static). Scans never break. Tech stack Next.js 16 (App Router), TypeScript, Tailwind v4 Hermes Agent (OpenAI-compatible tool-calling loop) Groq fallback ( ll

My Hermes Agent Mac just received a signed, secure and monitored message from a Claude Managed Agent, and got a reply! - A solution for long runtime work, A2A ID and security. What I Built A solution that enables two agents with different owners on a shared identity network, a Hermes and a Claude Managed Agent (Claude platform) talking to each other across the internet. Every message is Ed25519 signed by the sender. Every receiver verifies the signature against a public registry and shows a blue tick before acting. Continuous Agent Monitoring A handshake proves identity once but agents in a long runtime world don't trade a single message, they hold ongoing, autonomous conversations across hours, days, and many turns. Keys get compromised, agents get swapped, a colleagues behaviour drifts, all after the initial check. ZipViz re-verifies every message signature, registry chain, freshness, and watches the stream over time for behavioural anomalies. Trust is re-earned on every turn. So this agent was who it claimed this morning," but "this agent is who it claims, on this message, right now." The demo agents on the ZipViz network: mac-her.smc.viz — Hermes Agent on my Mac Mini brendan-clau.smc.viz — Claude Agent in Cloud When Mac sends a message to brendan-clau, Mac's private key signs it. Brendan-clau verifies the signature against ZipViz's registry, and checks it just ran with the MCP (algorithm, key fingerprint, registry chain, timestamp), then replies signed. Same flow in reverse. Same flow Hermes ↔ Hermes , or Claude ↔ Openclaw . The runtime doesn't matter; the identity layer does. "I received a signed message from mac-her.smc.viz". Reads back the four checks it just ran: ✓ Algorithm: Ed25519 ✓ Key fingerprint: ab52afe... matches registry ✓ Registry chain: mac-her → smc.viz → .viz (Handshake) all resolved ✓ Timestamp: 2026-05-31 11:18 UTC, fresh Demo Hermes continuous monitoring and verification with A2A Protocol Code One MCP server: [ zipviz-mcp ] https://www.npmjs.

One of the biggest myths in the software industry is that great engineering teams are built by hiring great engineers. They aren't. I've worked with incredibly talented developers who eventually became disengaged, indifferent, and unwilling to contribute beyond the bare minimum. I've also worked with average developers who grew into exceptional engineers because they were surrounded by a culture that rewarded curiosity, ownership, and continuous improvement. The difference was never talent. The difference was culture. The Toxicity Nobody Talks About When people hear the term toxic workplace , they usually imagine shouting managers, impossible deadlines, public humiliation, and constant pressure. Those environments certainly exist. But some of the most damaging engineering cultures are far more subtle. On the surface, everything appears professional. Meetings are calm. Nobody raises their voice. Everyone speaks politely. The company presents itself as collaborative and mature. Yet beneath that polished exterior exists a culture that quietly destroys accountability and discourages anyone from caring too much. A Simple Pull Request That Revealed a Bigger Problem Recently, while reviewing a pull request, I asked a few straightforward questions: Why are we passing an empty string to a component that doesn't function without an ID? Why is a skeleton component living in a file where it doesn't logically belong? Could this conditional statement be simplified for readability? These weren't major architectural concerns. They weren't requests to redesign the application. They were ordinary engineering discussions—the kind that happen every day inside healthy teams. When Ownership Disappears What happened next was far more interesting than the code itself. Instead of discussing whether the observations were valid, the conversation immediately shifted toward ownership. Who originally wrote the code? Who moved the code? Who was responsible for introducing it? The discussion was n

This article was originally published on aicoderscope.com In early 2023, Andrej Karpathy coined the term "vibe coding" to describe a new mode of software development: you describe what you want, the AI writes the code, and you ship without reading every line. He meant it as a genuine observation about where the craft was headed. By 2026, vibe coding is the default mode for most solo developers, with AI tools handling roughly 70% of keystroke work on a typical feature. The other 30%—direction, review, judgment—still belongs to the human. The pitch is real. Solo developers can now build features that would have taken a week in a day. The bottleneck isn't code volume anymore; it's knowing what to build. That's a genuine productivity unlock. The problem is also real. Codebases vibe-coded without guardrails develop a specific pathology: inconsistent patterns across files (because each AI session starts with no memory of the last), logic errors masked by plausible-looking code, and no rollback culture because no one committed before letting the AI loose. The developer who vibed their way through six weeks of feature work often can't explain what the codebase does anymore, because they never had to think through it. This guide is not about slowing down. It's about the ten rules that let you keep the speed without the debt. The Promise vs. the Reality What vibe coding looks like in 2026: you open Cursor, describe the feature in natural language, and Agent mode writes the file. You review the diff, accept what looks right, reject what looks wrong, and move on. For standard CRUD features, state management, boilerplate API clients, and UI components, this works well. The AI has seen enough patterns that its output is often correct on the first try. Why it works especially well for solo devs: there's no code review bottleneck. A team has to slow down to onboard the AI's changes into shared mental models. A solo developer owns the whole context and can iterate without waiting fo