标签：#programming

Tools like Claude Code and Codex have completely reshaped how software engineering is done. This new tooling allows for much faster development and iteration, but it's important to keep the code maintainable and scalable to make sure the project can continue evolving over the long term. A template project with an initial structure using all of the technologies described here is available on GitHub: https://github.com/MartinXPN/nextjs-firebase-mui-starter When working on a startup, the speed of iteration is key. The requirements change quickly, features are added daily, and code gets modified rapidly. In those conditions, picking technologies that enable fast iteration, while ensuring your users get the best experience possible, is crucial. During the last four years or so, we have experimented with many modern technologies while building Profound Academy . So, in this blog post, I'd like to present the whole tech stack that enables building quickly, while having a highly maintainable codebase, scalable infrastructure, and a great user experience. We'll cover everything from Authentication to UI, we'll talk about the backend, hosting, testing, and much more! AI Agents, Skills, and MCP servers AI Agents enable quick iteration and rapid improvement, including bug fixes, the addition of new features, and performance improvements. Yet, it's important to keep the code maintainable for the long run. AI tools make it really easy to overengineer things and add thousands of lines of code to a project. It's important to resist the urge to solve problems that don't exist yet, and keep things simple (both in terms of the code, the infrastructure, and the user experience). Even in the Agentic Software Development Era, having a small and simple setup helps. Agents coordinate better, features are added faster, bugs are fixed more easily, and the code is maintainable by humans, too. So, we have chosen to take a balanced/nuanced approach to how we use AI Agents when it comes to worki

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

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

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

I wanted to see how far an autonomous coding agent could get unattended. The constraint that makes this hard isn't code generation — it's that each session starts with zero memory of the last. So the design problem is state, not prompting. Setup A cron-scheduled task fires hourly, 11pm–7am (~8 runs). Each run is a fresh agent session. No shared context, no carryover. State lives entirely on disk: the working tree, the git history, and two files — BUILD_SPEC.md (the immutable goal/architecture) and PROGRESS.md (an append-only decision + status log). The run loop Every session does the same thing: Read BUILD_SPEC.md, then PROGRESS.md, then git log --oneline. Reconstruct "where are we" from the files themselves (the code is the source of truth, not the narrative). Do one unit of work. Commit. Append to PROGRESS.md: what changed, why (chosen X over Y because Z), and the exact next step. Commit granularity = checkpoint granularity. Worst case on an interrupted session is losing one unit, and the next run re-derives it. The "why" lines matter as much as the diffs — without them a later session re-litigates settled decisions. Guardrails The agent was allowed to build, test, and commit locally. It was explicitly not allowed to deploy, push to a remote, or touch secrets — those get written into PROGRESS.md as "needs human" items instead. This boundary is what makes unattended runs safe to leave alone. What came out A working full-stack monorepo: a pure TS scheduling engine (with property tests), multi-tenant auth, a Drizzle/Postgres schema, server-side re-validation, and publish/share/export flows. Across the runs it cleared its own stale git lock, and one session caught and fixed an off-by-one in a labeling layer that spanned five files. The takeaway The leverage wasn't the model writing code. It was designing a process where progress is durable across total context loss — externalize state, checkpoint constantly, log decisions not just actions, and fence off irreversible o

Is FAANG Becoming MANGO in the AI Era? For years, FAANG was the gold standard for innovation and engineering excellence. If you were a developer, working at companies like Facebook (Meta), Apple, Amazon, Netflix, or Google was often seen as the ultimate career goal. But the AI revolution is changing the conversation. Today, some of the most influential companies aren't just building products—they're building intelligence. The spotlight is increasingly shifting toward AI-native organizations such as OpenAI , Anthropic , NVIDIA , and others that are shaping the future of software. The Bigger Shift This isn't really about replacing FAANG with another acronym. It's about a fundamental shift in technology: Search → Answers Automation → Agents Software → Intelligence Features → Capabilities As developers, we're entering an era where understanding AI is becoming as important as understanding frameworks, databases, and system design. What This Means for Engineers The most valuable engineers of the next decade will likely combine: Strong software engineering fundamentals AI-assisted development skills Prompt engineering LLM and agent integration AI-powered product thinking The goal isn't to compete with AI. The goal is to learn how to build with it. Read the Full Article This post was inspired by a thought-provoking article that explores the FAANG-to-MANGO idea in much greater detail. 👉 Read the complete article here: https://www.saurabhsharma.dev/blogs/mangos-vs-faang-ai-era/ What do you think? Are we witnessing the rise of a new generation of AI-first companies, or will traditional tech giants continue to lead the next wave of innovation?

A story about an AI content moderation system that flagged 347 posts since launch — and what...

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

Swift Testing shipped with Xcode 16 back in 2024. Swift Testing was built from the ground up for Swift. That means Swift concurrency is a first-class citizen, test cases run in parallel by default, and the API surface is dramatically smaller than XCTest's forty-plus assertion functions. One macro, #expect , replaces most of them. If you are still on XCTest, you have probably felt the friction: class inheritance for every test suite, function names that must start with test , assertion messages that tell you what the values were but not where the expression came from. Swift Testing fixes all of this. That said, you do not need to migrate everything at once, and WWDC 2026 is emphatic about this. The Migration Strategy: Small Chunks, No Big Bang The session opens with something refreshing: permission to be slow about this. The recommended approach is to leave your existing XCTests where they are and start using Swift Testing only for new tests. Both frameworks can coexist in the same target and even the same file. You do not need a separate test target, and you do not need a migration sprint. The one rule: Swift Testing tests cannot live inside XCTestCase subclasses. Everything else is fair game. Raw Identifiers for Readable Test Names One small quality-of-life improvement worth knowing about from the start: Swift supports raw identifiers using backticks, and Swift Testing takes full advantage of this. import Testing @testable import DemoApp @Test func ` Default climate : tropical ` () async throws { let fruit = Fruit ( name : "Coconut" ) #expect(fruit.climate == .tropical) } No more testDefaultClimateTropical or dealing with camelCase names in test output. The test name is the test name. Interoperability: The Key to Reusing Your Helper Code This is the main new story in WWDC 2026 and the feature that makes incremental migration actually work. The problem: you have test helper functions that wrap XCTFail . You want to call them from new Swift Testing tests. Previously,

Forget neural networks for a second. The real idea inside this repo is a blueprint for letting AI agents run unattended overnight — and it maps onto problems you already have on your team. If you've been anywhere near tech Twitter or LinkedIn this week, you've probably seen people losing their minds over a small GitHub repo called autoresearch , published by Andrej Karpathy — former Tesla AI director and OpenAI founding member. The framing is dramatic: an AI agent that runs machine learning experiments on its own, overnight, while you sleep. Tweak the code, train for five minutes, check if it got better, keep it or throw it away, repeat. Wake up to a log of a hundred experiments and a model that's quietly improved itself. If you're not an ML researcher, your instinct might be to scroll past. "Cool, but I don't train neural networks. How does this apply to me?" Here's the thing — the neural network part is almost incidental. What Karpathy actually open-sourced is a pattern for structuring AI-agent work: a specific way of dividing responsibility between human and AI that happens to generalize to a huge range of engineering problems. Once you see the pattern, you start noticing places in your own job where it fits. What's Actually in This Repo The repo itself is intentionally tiny — and that's the point. There are really only three files that matter: The evaluator (untouchable). A file containing the fixed constants, data preparation, and the scoring logic. The agent is never allowed to modify this. It's the ruler everything else gets measured against. The implementation (the agent's playground). A single file containing the actual model, training loop, and hyperparameters. This is the only file the agent is allowed to change. Architecture, batch size, optimizer — all fair game. The instructions (the human's only job). A plain Markdown file describing what the agent should try, what the constraints are, how to interpret results, and what to do when something breaks. Ka

I asked AI to write a commit message for me last week The code change was simple. A bug fix One line,...

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

Class, Record, and Struct serve as blueprints for creating new objects. Classes Classes are the foundational building blocks of Object-Oriented Programming (OOP). Blueprint and instance // blueprint public class Person { public int ID { get ; set ; } public string Name { get ; set ; } } // instance var p = new Person { ID = 1 , Name = "Mirza" } Inspection Printing the class instance in the console will just display it's name: var p1 = new Person { ID = 1 , Name = "Mirza" }; Console . WriteLine ( p1 ); // Person To print the actual, we'd need print each property explicitly: Console . WriteLine ( p1 . ID ); // 1 Console . WriteLine ( p1 . Name ); // "Mirza" Mutation C# classes are mutable, meaning the originally set values can be altered: var p1 = new Person { ID = 1 , Name = "Mirza" }; Console . WriteLine ( p1 . Name ); // "Mirza" p1 . Name = "Armin" ; Console . WriteLine ( p1 . Name ); // "Armin" That said, this can be tweaked by changing the accessor the class property. public class Person { public int ID { get ; set ; } public string Name { get ; init ; } // <-- } This time around if we try to change the value of the Name property after initialization, the C# compiler will start to complain. var p1 = new Person { ID = 1 , Name = "Mirza" }; p1 . Name = "Edis" ; // ❌ The init accessor allows you to create properties that can only be assigned a value during object initialization. Memory location Classes are reference types and are allocated on the heap. If we create two distinct class objects and assign one to the other, both objects will point to the exact same reference in memory: var p1 = new Person { ID = 1 , Name = "Mirza" }; var p2 = new Person { ID = 2 , Name = "Mirza" }; p1 = p2 ; p1 . Name = "Sead" ; Console . WriteLine ( p1 . Name ); // Sead Console . WriteLine ( p2 . Name ); // Sead If we change a value in one of the objects, it will be reflected in both. Equality Two class instances (objects) aren't equal even if they share the same values: var p1 = new P

When you double-click WP Maintenance Manager, it opens a browser tab — and the entire UI lives inside that tab. No native window is created. It's an unusual structure for a first-time user, and the natural question is: "why a browser?" That choice was an intentional design decision when building a Python desktop application. Here's the comparison that led to it, and the side effects of the choice. Four realistic options For a WordPress maintenance automation tool, four implementation styles were practical: Approach UI Distribution size Dev cost Per-OS extra work Native (Swift / WPF) OS-native windows Small–medium High (separate impl per OS) Heavy PyQt / PySide Qt widgets Medium (~80 MB) Medium Light Electron Chromium-embedded web UI Large (~150 MB+) Medium Light Local Flask + system browser System browser tab Small (~50 MB) Medium Light PyQt was a serious early candidate. A Python-only stack is appealing, but widget styling drifts subtly between OSes, Qt's layout system demands constant attention, and resolving Qt plugins under PyInstaller is fiddly. Dev velocity was not where it needed to be. Electron is the industry-standard choice for cross-platform UI, with the big benefit that HTML/CSS-based UIs are quick to write. But the distribution is well over 100 MB, and memory consumption is heavy. For a tool that often runs in the background, that overhead is too much to justify. Why local Flask + browser won The final structure was Flask (Python's lightweight web framework) + the system browser for UI. The decision rested on three axes: 1. The backend had to be Python anyway SSH connections via fabric / paramiko , browser automation via playwright , encryption via cryptography — every library at the core of WordPress maintenance lives in the Python ecosystem. Writing the backend in another language wasn't really an option. If Python is already required on the backend, putting the UI in Python too keeps distribution simple. 2. HTML/CSS/JS makes UI iteration fast Flask r

At Inithouse — a studio running parallel product experiments — we built Be Recommended , a tool that checks how visible your brand is across ChatGPT, Perplexity, Claude, and Gemini. The idea sounded simple: query multiple AI models, score the results, show a report. It was not simple. Here are four technical mistakes we made shipping v1 — and the fixes that actually survived production. Mistake 1: Rate Limiting Was an Afterthought We treated rate limits as edge cases. They were not. Every AI provider has different rate-limit headers, different backoff expectations, and different definitions of "too many requests." Our first architecture just retried on 429. That turned a rate limit into a cascade — one provider throttling triggered a retry storm that cascaded to the others. The fix: Per-provider circuit breakers with exponential backoff. Each provider gets its own state machine. When a circuit opens, we serve cached results for that provider and mark the score as "partial" in the UI. Users see real data, not a spinner that never resolves. At Audit Vibe Coding — another tool in our portfolio focused on code quality audits — we observed the same pattern in a different domain: external API dependencies need isolation. The lesson transferred directly. Mistake 2: The Caching Strategy Was Too Naive Our first cache key was query + model . That breaks immediately — AI model responses drift over time, and a cached result from two weeks ago is misleading. We also had no invalidation strategy beyond TTL. The fix: Cache by query + model + week_number . Weekly invalidation with stale-while-revalidate: serve the cached score instantly, trigger a background refresh, update the display when new data arrives. Users get instant feedback and fresh data within the same session. We measured the impact across our portfolio: stale-while-revalidate cut perceived load time from 8+ seconds to under 1 second for returning visitors. The background refresh means scores stay current without the

Yesterday, as I was working on a CORS configuration, AI generated a block of code for me: const allowedOrigins = [ process . env . FRONTEND_URL || " http://localhost:3000 " , process . env . ADMIN_URL || " http://localhost:3001 " , ]. filter ( Boolean ); I was wondering... why use .filter(Boolean) here? 🤔 The fallbacks already guarantee strings. So I hovered on the variable. The type definition read: const allowedOrigins : string [] Fine. Made sense. But then I got curious. What if I removed the hardcoded fallbacks? const allowedOrigins = [ process . env . FRONTEND_URL , process . env . ADMIN_URL , ]. filter ( Boolean ); My type definition changed to: const allowedOrigins : ( string | undefined )[] I was shocked. I just filtered the array. How can TypeScript still think there's an undefined in there? First: What Does .filter(Boolean) Even Do? Boolean used as a filter function removes any falsy value from an array: false null undefined 0 "" NaN So: [ " https://app.com " , "" , undefined ]. filter ( Boolean ) // Result: ["https://app.com"] At runtime, this works exactly as you'd expect. No undefined survives. So why does TypeScript disagree? 🤷‍♀️ The Real Answer: TypeScript Doesn't Run Your Code TypeScript is a transpiler. It doesn't execute .filter(Boolean) — it only looks at types. When it sees this: array . filter ( Boolean ) It knows the callback returns a boolean . But it doesn't know what that means for the type of the elements that survive. It can't infer "if Boolean(x) is true, then x must be a string." So the undefined stays in the type — even though it'll never actually be there at runtime. That's the gap: your runtime behavior is correct, but your types are lying. The Fix: Type Predicates TypeScript lets you close that gap with a type predicate — a way of explicitly telling the compiler what a filter function guarantees: const allowedOrigins = [ process . env . FRONTEND_URL , process . env . ADMIN_URL , ]. filter (( origin ): origin is string => Boolean ( o

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

Hi everyone, I’m working on a new programming language called Zentax. It is still in early development, but the goal is to build a modern language focused on: Performance and low-level control Simple and clean syntax Native desktop application support A modular compiler and runtime design Zentax is not trying to replace existing languages — it is an experiment in building a unified approach for systems programming and UI development. Current Status Compiler: in development Runtime: early design stage Renderer: experimental Standard library: planning phase Looking for Contributors I’m open to collaboration from anyone interested in: Programming language design Compiler development Runtime systems Graphics / rendering engines Open-source tooling Even feedback and ideas are welcome at this stage. Links Git Hub Repo Discord Thanks for reading. Dr. Zoha Tariq Anoneurx

This is an adapted excerpt from a guide in my AI Knowledge Hub. The full interactive version is linked at the end. Agentic design patterns are named control structures for arranging LLM calls and tools. This post gives you the decision rule for picking one, the exact shape of each pattern, and the cost each adds — so you can match a task to the minimum structure that solves it. Everything here is model-agnostic and grounded in Anthropic's Building Effective Agents and the Claude Agent SDK. Workflow vs. agent: the split that decides everything Anthropic divides all agentic systems into two categories, and the split decides every downstream tradeoff: Category Definition Control lives in Use when Workflow LLMs and tools orchestrated through predefined code paths Your code You can pre-map the decision tree; want accuracy, control, lower cost Agent LLMs dynamically direct their own processes and tool usage , maintaining control over how they accomplish tasks The model Open-ended task where you can't predict the number of steps Every pattern composes one unit: the augmented LLM — an LLM enhanced with retrieval, tools, and memory. It generates its own search queries, selects tools, and decides what to retain. If a single augmented LLM call solves the task, stop — no pattern required. The escalation rule is the whole game: find "the simplest solution possible, and only increasing complexity when needed" — which "might mean not building agentic systems at all." Agentic systems trade latency and cost for better task performance, so only escalate when a specific failure mode forces it. The agent loop: gather → act → verify → repeat For open-ended tasks, every agent runs the same four-beat loop: Gather context — read files, run agentic search ( grep / find / tail to pull relevant slices instead of whole files), or delegate to subagents with isolated context windows. Take action — execute via tools: bash, code generation, file edits, MCP servers. Verify work — check the result b

today we discuss about Interface in Java. first we understand the concept with simple Analogy, Imagine you go to a shop and buy items. in a bill counter, the shop keeper care about only one thing. The customer paid the Money or not. The shopkeeper does NOT care about how you pay the money, UPI Debit Card Cash They only thing is payment paid in successfully. Here a interface acts like a Rule in billing counter. It only defines what must be done, not how it should be done. Different payment methods follow the same rule, but each one works in its own way. The shopkeeper does not need to change anything in the billing counter. No matter how the customer pays, the system works the same. so, i follow this analogy and using a example for this blog. What is Interface? (in GeeksforGeeks) An interface in Java is a blueprint that defines a set of methods a class must implement without providing full implementation details. It helps achieve abstraction by focusing on what a class should do rather than how it does it. Interfaces also support multiple inheritance in Java. A class must implement all abstract methods of an interface. All variables in an interface are public, static, and final by default. Interfaces can have default, static, and private methods first create a interface file Payment.java public interface Payment { void pay ( int amount ); } here we create a method but not defined that method This is the shop rule. “Anyone wants to pay must follow one rule → pay the amount.” The shop does not explain how you pay, only thing is you must pay. next we create another file for Different Customers, class CardPayment implements Payment { public void pay ( int amount ) { System . out . println ( "Paid ₹" + amount + " using Card" ); } } class UpiPayment implements Payment { public void pay ( int amount ) { System . out . println ( "Paid ₹" + amount + " using UPI" ); } } class CashPayment implements Payment { public void pay ( int amount ) { System . out . println ( "Paid ₹" +