标签：#software

I have spent more than six years shipping production software and I have no public repositories worth showing you. Everything substantial I have written at work lives in private repositories belonging to the companies I wrote it for, and confidentiality obligations do not lapse when a role ends. So I cannot hand you the code, and I am not going to. That is not caution for its own sake. An engineer who sends a prospective employer another company's source code has told you exactly what they will do with yours. The restraint is part of what you are assessing, and I would want the same restraint applied to my work later. Which leaves a real problem. "I was the principal author of the web application" and "I contributed to the web application" are the same sentence to a reader who cannot check either. Most engineering CVs resolve this by getting louder. I think the only honest resolution is to publish the measurement method rather than the artefact, in enough detail that someone familiar with the tools can judge the figure on its own terms without ever seeing the repository. Here is the method I actually used, what it does badly, and the places where applying it forced me to shrink a claim I would have preferred to keep. Three measurements, in increasing order of rigour All-branch commit count. Total authored activity. Do not use this. It counts abandoned branches, spikes and experiments, and it inflates — usually in favour of whoever is most willing to commit. It is the number that makes contribution graphs look impressive and says the least about a codebase. Production-branch commit count, scoped to tenure. What reached customers, while you were there. Better, because it excludes work that never shipped, and because scoping to tenure stops you either taking credit for years of history that predate you or being penalised for them. But it still counts commits, and a commit is a unit of activity, not a unit of code. Commit share rewards granular committers and punishes p

The standard objection to writing the design down is that it is what you give up in exchange for speed. Early-stage companies are meant to be the place where you skip it: no specifications, no plans, just build the thing and find out. Documentation is treated as a tax that mature organisations can afford and small ones cannot. I have worked the other way round, and I want to make the argument properly rather than just assert it. At Cendra , across a twelve-month tenure as one of two founding engineers, the work produced 255 design specifications, 207 implementation plans and 17 production runbooks. Over the same period: 377 production releases coordinated across four repositories, and 482 merge commits across those repositories (an all-merges count, broader than the frontend-only first-parent integration figure on the Cendra page), across 239 active development days. That release figure works out at roughly one every twenty-two hours. All of those figures are tenure-scoped, and self-measured against private repositories while I held authorised access to them, which is a caveat I will come back to. But the shape is the point: the documents and the shipping happened together, at the same time, by the same person. What I am not claiming I cannot prove the specifications caused the cadence. There is no control group. It is entirely possible to imagine a version of that year with no documents and more releases, and I have no way to rule it out. What I can do is describe precisely what the artefacts removed from the critical path, and let you judge whether that is worth the hours. The mechanism matters more than the correlation, because the mechanism is the part that transfers to your codebase rather than mine. The specification is a comprehension test I administer to myself The honest reason I write a design down before building it is not communication. It is that writing it is how I find out whether I actually understand the problem. There is a specific and reliable exp

AI engineering sounds fancy. New terms are everywhere: agentic development, AI-native engineering, spec-driven development, and now AI harness engineering. Underneath all the terminology, though, something genuinely useful is happening. AI can now help with requirements, challenge a PRD, explore UX ideas, reason about architecture, create implementation plans, write code and validate the result. The obvious question is what AI can do. The more interesting question is whether the way we build software is ready for it. The workflow is changing A workflow we've been exploring breaks development into five stages: requirements, refinement, planning, build and validation . The stages themselves aren't new, but AI can now participate in each one. It can take existing product inputs, help clarify the problem, question assumptions, identify gaps in a PRD and then turn a well-defined requirement into a plan and eventually implementation tasks. This puts more emphasis on the quality of the requirements. A human involved in a project might understand what “improve the experience” means because they've had several conversations about it. An agent doesn't have that shared history. It needs the problem, scope, constraints, edge cases and expected outcome to be explicit. That doesn't mean writing enormous specifications; it means using AI to help make the requirements precise before we start building. AI can actually be a useful, slightly annoying reviewer here, asking what happens when something fails, whether a requirement is testable, whether two parts of the document contradict each other and what we haven't considered yet. It can also help compare different versions of a PRD or have one model review another's output, making gaps easier to spot. The important part is that AI is helping us uncover ambiguity, not making the decisions for us. Maybe coding isn't the bottleneck This becomes more interesting when we look at where teams actually spend their time. Complex work can invo

I built the pipeline that publishes this site's content in versioned code instead of n8n. Not a philosophical stance against no-code tools, a practical call, and one specific bug is why I still think it was the right one. Why code, not a canvas Four reasons drove it, in order of how much they actually mattered: Review parity. Every change to how a post gets approved or published goes through the same PR review as the rest of the site. A workflow-canvas change doesn't get that by default. Headless operation. Claude Code drives the queue directly, no GUI dashboard sitting between the agent and the task. Existing infrastructure. A Telegram bot already handled approvals; there was no gap a workflow tool needed to fill. One fewer service. Every extra tool in the stack is something else to patch and keep secure. Skipping it was the cheap option, not just the principled one. The bug that proved it On July 20, 2026, a scheduled post silently failed. The Buffer API adapter treated an error response as a normal one, never checked the status, so the X post never actually went out while the pipeline marked it published. Nothing threw, nothing alerted, the queue just quietly lied about what had shipped. I found it the way you'd expect: read buffer.py , saw exactly where the status check was missing, fixed one line. Cheap once you can see it. That's the part I can't picture happening the same way in a workflow canvas. I genuinely don't have a mental model for debugging that failure mode there, a canvas doesn't hand you the same thing a stack trace and git blame hand you in code. You'd be reading node configuration and hoping the tool's own logging caught the edge case, instead of reading the exact line that skipped a check. What this is actually about It isn't code versus no-code as a philosophy. It's about legibility when automation is wrong in a way that doesn't throw an error. A silent-fail bug is the worst kind, because nothing tells you to go look. The only thing that saved

Intro There's a pitch behind every "AI writes your tests too" workflow: more coverage, less manual toil, a safety net that used to take a sprint now takes minutes. The pitch skips over what that safety net is actually made of. When the same model writes the implementation and the test suite, you haven't added a second, independent check. You've asked one reviewer to grade its own homework and handed you the green checkmark as if someone else had signed off. The blind spot loop A model reasons about a function once, forms an implicit set of assumptions (input shapes, timezone handling, what counts as "empty"), and writes the implementation against those assumptions. Ask the same model to write tests for that function, and it doesn't re-derive correct behavior from scratch. It writes tests against the same assumptions it just used to write the code. If it assumed dates always arrive as ISO strings in UTC, the implementation assumes that, and the tests assume it too. The suite goes green. The assumption is still wrong. Tests that pass for the wrong reason (Illustrative, not a specific case, but recognizable to anyone who's shipped an AI-generated suite.) Picture a discount-calculation function where the model assumes quantities are always positive integers. The implementation skips a negative-quantity check. The generated tests exercise 1, 5, and 100, because those are the "normal" values a model reaching for plausible test data will reach for. Nothing ever asks what happens at -1 or 0, because neither pass, the code or the tests, ever considered them worth asking about. Coverage tooling reports 100% on this function. The bug ships anyway. Coverage becomes a false signal High line or branch coverage from an AI-authored suite tells you the code paths were exercised, not that the right inputs exercised them. A suite can hit every line of a function and still never send it a null, an empty array, a duplicate key, or a value at a type boundary, if the author, human or mode

Enterprise resource planning has traditionally been associated with large vendors, complex implementations, long contracts, and significant licensing investments. For decades, companies evaluating ERP systems were likely to encounter names such as SAP, Oracle, Microsoft Dynamics, and other established commercial platforms. That model is not disappearing. But the assumptions behind it are changing. In 2026, enterprises have more choices than simply selecting between competing proprietary ERP vendors. Open-source platforms such as ERPNext, Odoo, and other business application ecosystems have become credible alternatives for organizations that want greater control over their software, more flexible customization, and different approaches to total cost of ownership. At the same time, SaaS pricing, vendor lock-in, integration complexity, cloud adoption, data ownership, and increasingly capable development tools are changing how businesses think about enterprise software. This does not mean open-source ERP is automatically better. It means the ERP decision deserves to be reconsidered. The question is no longer simply: Which ERP vendor should we buy from? Increasingly, organizations are asking: How much control should we retain over the software that runs our business? What Is Open-Source ERP? Open-source ERP is enterprise resource planning software whose source code is made available under an open-source license that grants defined rights to use, inspect, modify, and distribute the software. The practical implications depend heavily on the specific project's license. For an enterprise buyer, however, the important distinction is that open-source software can provide a level of visibility and extensibility that proprietary software may not. A simplified comparison looks like this: Proprietary ERP Business │ ▼ Vendor Software │ ├── Vendor controls source ├── Vendor controls roadmap ├── Vendor controls licensing └── Vendor controls many upgrade decisions Open-Source ERP Busi

When businesses outgrow spreadsheets and disconnected SaaS tools, the next question is often whether they should buy another application, customize an existing platform, or build a system specifically around their workflows. For many organizations, building custom business software can appear expensive and technically demanding. A development team has to think about authentication, permissions, database models, APIs, user interfaces, background jobs, reporting, audit trails, and deployment. This is where open-source application frameworks can change the equation. Instead of building every foundational capability from scratch, a framework can provide the underlying architecture while developers focus their effort on the business problems that actually differentiate the organization. One example is the Frappe Framework , an open-source web application framework used to build business applications such as ERPNext. But what exactly is Frappe, and why would an organization consider using it for custom enterprise software? What Is Frappe Framework? Frappe is an open-source, Python- and JavaScript-based web application framework designed to make it easier to build database-driven business applications. Rather than being simply a collection of programming utilities, Frappe provides a broader application foundation. It includes capabilities for: Data modeling Authentication Role-based permissions REST APIs Web forms Background jobs Reporting Workflow management Notifications File attachments Activity and audit information User interfaces Database access Application configuration This means a development team can start with an application architecture that already understands many of the requirements common to business software. The important distinction is this: Frappe is a framework for building applications. ERPNext is an application built using that framework. That distinction matters when evaluating Frappe for custom software development. Frappe vs ERPNext Frappe and ERP

A developer opens a pull request. The feature works. The tests are green. The implementation looks reasonably clean. Then they realize the PR changes 17 files for what should have been a relatively small feature. There is a new abstraction nobody on the team has seen before. A dependency has been added for functionality the project already had. Two similar utilities now exist in different parts of the codebase. The tests are extensive, but nobody is completely sure what assumptions they are actually testing. And the author didn't write most of it manually. AI did. This is one of the less obvious problems created by AI coding tools. The problem isn't necessarily that AI generates bad code. Sometimes it generates perfectly valid code. The problem is that it can generate code faster than a team can develop an understanding of it. That changes the bottleneck in software engineering. The Cost of Writing Code Has Changed For a long time, engineering teams were constrained by how quickly developers could implement things. A developer had to understand the requirement, design the solution, write the code, debug it, and test it. AI changes the economics of that process. A developer can now describe a feature, generate an implementation, ask for tests, refactor it, and generate supporting code in a fraction of the time it might previously have taken. That's useful. But the amount of code entering the system can increase faster than the team's ability to review and understand it. Consider a simple feature that requires modifying four files. An AI coding assistant might produce a solution that touches twelve. It may introduce a service layer, a helper abstraction, a configuration object, several interfaces, and a new package. None of these things are necessarily incorrect. But every additional abstraction creates another thing a future developer has to understand. This is where code familiarity becomes an engineering concern. Working Code Isn't the Same as Understandable Code A

A couple of weeks ago, I helped a cross-platform app team with their App Store release. The code, packaging, and testing were all done, but we got stuck on the last step: how to get the IPA to the App Store. Nobody on the team had used a Mac, and many articles we read assumed you already have Xcode. That step is actually not that difficult. If you break down the complete iOS App Store publishing process, it comes down to registering an account, creating certificates, creating provisioning profiles, configuring Bundle IDs, packaging, uploading, and waiting for review. Each stage has clear steps, and I will walk through them in order below. Registering a Developer Account Registering a developer account is the first step. Both individual and company accounts cost $99 per year. To register, log in to the Apple Developer website with your Apple ID and agree to the agreement, and the account will be activated. Company accounts also require a D-U-N-S number. A free account can create development certificates and run internal testing, but it cannot submit or publish, and it cannot use capabilities such as Sign in with Apple, payments, or push notifications. To publish officially, you must upgrade to a paid account. Creating Certificates Certificates are the ticket for packaging and publishing. There are two types: development certificates (iOS App Development) and distribution certificates (iOS Distribution). The generated files are in P12 format. On a Mac, you would open Keychain Access and request a Certificate Signing Request file, then upload it to the developer portal. With Appuploader, a cross-platform team can generate certificates directly on Windows by entering a certificate name, email, and password, without touching the Keychain. The certificate can also be synced to different computers, saving considerable effort in team collaboration. Note that the certificate password must be remembered, because it is used as the private-key password for packaging and signing

abandoned open source package vulnerability EOL dependency strategy fork vs patch security alert open source risk mitigation OSS abandonment decision tree tech lead security SLA abandoned dependency vulnerability end of life open source package unpatched upstream dependency replace abandoned OSS library isolate vulnerable code fork open source package internal maintenance OSS fork formal risk acceptance InstaSLA accepted risk logging vulnerability SLA deadline EOL package remediation open source dependency risk unmaintained open source library patching abandoned packages Upstream OSS Abandonment An Engineering Decision Tree for EOL Dependencies Back to blog The Silent Crisis of Upstream Abandonment Option 1: Replace the Dependency (The Ideal, but Costly Path) Option 2: Wrap and Isolate the Code (The Tactical Defense) Option 3: Fork and Maintain Internally (The Ownership Commitment) Option 4: Formal Risk Acceptance (The Compliance Reality) What 2025–2026 Actually Looked Like Conclusion Upstream OSS Abandonment: An Engineering Decision Tree for EOL Dependencies When an active vulnerability SLA deadline looms over a critical application, the standard playbook is straightforward: update the package, run the tests, merge the pull request. But what happens when the underlying open-source library has been quietly abandoned by its maintainer? Engineering teams are running into this exact scenario more often, and the numbers back that up: Veracode's 2025 State of Software Security report found that half of organizations carry critical security debt, and 70% of that debt originates from third-party code and the software supply chain. As the software supply chain grows more complex, the odds of an EOL package sitting somewhere in your dependency tree keep climbing. This article lays out a step-by-step decision framework for tech leads and security teams managing an EOL dependency when no upstream patch is coming — and updates it with what's actually happened in the open-source

🎮 ADAM-PS5 — A PS5 Emulator in Development I’m working on an ambitious project called ADAM-PS5 , with the ultimate goal of developing a PlayStation 5 emulator for PC capable of running PS5 games . The project is still in the early stages of development , and I do not consider it a complete emulator at this point. I’m building the foundation step by step: system architecture, low-level emulation, memory and resource management, graphics, input handling, execution, debugging, and development tools. 🚧 Early Development There is still a huge amount of work ahead before reaching the point where commercial PS5 games can actually run. That’s why I’m sharing the project from its early stages rather than presenting it as a finished product. 🤖 One of the project’s goals is also to integrate Artificial Intelligence to help analyze errors, monitor performance, understand system logs, and assist with the development process. The long-term goal is: PC → ADAM-PS5 → PS5 Software Environment → Games Reaching that stage requires implementing and accurately simulating many different components of the console’s hardware and software architecture. I’m sharing the project now because I want to document the entire development journey from the beginning — including what gets built, what fails, what gets improved, and how the project evolves with each release. 🔥 ADAM-PS5 is not finished. It is being built. And the ultimate goal is simple: Run PlayStation 5 games on PC through our own emulator. ADAM-PS5 is an independent development project and is not affiliated with Sony Interactive Entertainment.

Every developer I know now runs an AI coding agent in something like auto-accept mode. Claude Code, Codex, Cursor: you give it a task, it runs commands, edits files, installs packages, and you review... the diff, maybe. The commands? The installs? The thing it did in that folder outside the repo? Nobody looks. The activity scrolls off the terminal and is gone. That asymmetry bothered me. We built an entire industry around audit trails for humans (git blame, CI logs, access logs), then handed the keyboard to agents and kept none for them. So I built Tracon: a local flight recorder for AI coding agents. The name is the FAA's term for Terminal Radar Approach Control, the radar room that tracks every aircraft in an airspace. This one tracks every agent on your machine. What it does Tracon is a Mac and Windows desktop app (Tauri 2, Rust core, React UI, SQLite store) that sits in the tray and records what your agents do: A timeline per session: every command, file edit, package install, and prompt, attributed to the agent and session that did it Danger flags as they happen: recursive deletes, pipe to shell installs, credential access, force pushes, permission bypasses. Tracon flags; it never blocks A Live page: one monitor per active session, like a security room, streaming recent commands with flagged ones highlighted in red, plus which subagents the session has spawned A conversation reader: the actual chat behind any event, read straight from the agent's own transcript, read only A package watch across npm, pnpm, pip, cargo, and brew, with opt in threat intelligence against osv.dev Capture is deliberately passive. Hooks give real time events over localhost; transcript tailing (filesystem notify, read only) covers everything else, so CLI sessions show up live even with zero setup. A dead or closed Tracon never slows an agent down. Everything stays on your machine: no telemetry, no accounts, AGPL. The recursive part Here is the part I find genuinely funny: Tracon was lar

In traditional software architectures, we almost instinctively reach for the CRUD (Create, Read, Update, Delete) paradigm. We design an entity model, map it to a relational schema using an ORM, and use that identical abstraction to both alter state and display data on user dashboards. For simple applications, this works flawlessly. But as systems scale—both in business complexity and throughput, this dual-purpose model starts showing fractures: Write logic demands tight validation, transactional boundaries, normalization, and domain invariants. Read logic demands flat, pre-aggregated, denormalized representations across dozens of tables to serve responsive UIs. Trying to satisfy both masters with a single schema leads to unwieldy SQL joins, lock contention, compromised domain boundaries, and performance gridlock. This is where Command Query Responsibility Segregation (CQRS) enters the picture. 1. What is CQRS? Coined by Greg Young and based on Bertrand Meyer’s Command-Query Separation (CQS) principle, CQRS states that an application should use separate models to update and read data . At its philosophical core: Command (Write): Represents an intent to alter domain state (e.g., SubmitOrder , DeactivateUser , ChangeBillingAddress ). A command should focus entirely on domain logic, data integrity, and business rules. In strict CQRS, commands do not return domain data — only an acknowledgment, validation failure, or generated entity ID. Query (Read): Retrieves data without mutating application state (e.g., GetOrderSummaryById , ListCustomerInvoices ). Queries should execute side-effect-free operations that return lightweight Data Transfer Objects (DTOs). ┌────────────────────────────────────────────────────────┐ │ Client │ └─────────────┬────────────────────────────▲─────────────┘ │ │ Execute Command Run Query │ │ ▼ │ ┌───────────────────────────┐ ┌───────────┴─────────────┐ │ Command Model │ │ Query Model │ │ (Validation & Invariants) │ │ (Optimized for DTOs) │ └──────

How do you ship a software product with 0 lines of manually-written code? A friend asked me this today, and I realized I didn't have a simple answer. So I dug deeper. It turns out the answer is in how you engineer your harness. Wait now, what? What is harness engineering? There is a reason this is the most important trend right now around coding agents. The biggest question these days is how to validate AI-generated code without reading every single line. How do you make sure an agent doesn't break production or delete your data? A blog by OpenAI shared an interesting experiment where a team of 3 engineers have built and shipped an internal beta of a software product with 0 lines of manually-written code. Every line of code: application logic, tests, CI configuration, documentation, observability, and internal tooling, has been written by Codex. How did they do it? They didn't write the app. They designed the harness. What exactly is a harness? Think of an AI agent like a powerful racehorse. The harness is the track, the blinders, and the jockey's reins that keep it running in the right direction instead of jumping into the stands. As my colleague Arthur Thompson explained today: for agents — the harness is composed of all the deterministic components that wrap the LLM. Balaji Subramaniam details those deterministic components in his blog — the orchestration layer, execution sandboxing, state persistence, and verification tools. If you want to build reliable agentic systems, your job shifts from writing the logic to designing the environment. Here is what you need to focus on: Set strict boundaries: Don't let the agent guess what it can touch. Enforce strict access rules (like confining it to a specific sandbox) so it can't accidentally wipe out production data. Build "Repair Loops": Agents will inevitably make mistakes. A great harness automatically traps errors, like a failed build or a test failure, and feeds those clean logs right back to the agent so it can fix

I had been using Xcode for iOS development until one day I changed computers. Downloading Xcode took nearly two hours, and after unzipping, I found only 20GB left on the hard drive. Every major version update involved over ten gigabytes of downloads, plus Simulator and various iOS SDKs, so a 256GB Mac soon required cleaning up space. Later, a new teammate arrived with a Windows laptop and wanted to write iOS code, but the Mac configuration hadn't been approved yet. The threshold of iOS development being tied to Mac and Xcode is indeed not flexible for many scenarios. So I began to wonder: can iOS development be done without Xcode? Are there lighter alternatives? Several Alternative Paths Without Installing Xcode I first tried the approach of VS Code plus remote Mac compilation. Write code on Windows, connect to a remote Mac via SSH, and execute xcodebuild. The coding environment problem was solved, but the debugging phase is unavoidable—running on a real device requires Xcode to handle provisioning profiles and signing, so ultimately a Mac with full Xcode is still needed. Moreover, after each code change, the three steps of local editing, remote compilation, and syncing to the device made the workflow longer than developing directly in Xcode. I also tried the CI approach. Codemagic and GitHub Actions can automate build packaging, suitable for continuous integration before releases. However, frequent debugging and modifications during daily development—changing a line of code and running to see the result—cannot be pushed to CI every time and wait a few minutes. Its coverage is limited. I also considered AppCode, but it essentially still depends on Xcode's toolchain, and JetBrains has discontinued its maintenance. Another Approach: KXApp IDE KXApp has built the compilation toolchain into the IDE, allowing iOS applications to be compiled and signed without installing Xcode on the system. It uses VS Code as its editor layer, with shortcuts, interface layout, and plugin

Anyone who does iOS development has likely encountered this situation: after submitting your app with great effort, you receive an App Store review rejection email the next day with a variety of reasons—incorrect screenshot sizes, missing privacy policy links, unclear permission usage descriptions, and so on. Most rejection reasons can be avoided in advance, without waiting to be rejected before making changes. Here are the common reasons for rejection, categorized and explained with how to fix each. Screenshots and Metadata Issues Screenshots are a frequent cause of rejection. Rejections can result from sizes not conforming to App Store specifications, screenshots containing unreleased features, screenshots marked with test environment indicators (such as "beta" watermarks), screenshots inconsistent with the actual interface, or screenshots with incorrect device model labels. These issues can be caught by checking for yourself before submission. How to fix: Regenerate screenshots at the sizes required by App Store, with one set for 6.5 inches and another for 5.5 inches. If your app supports iPhone only, these two sets are sufficient; if it supports iPad, add an additional set. App Store screenshots do not support transparent backgrounds (alpha channel), so convert transparent backgrounds to opaque before uploading. When batch-uploading screenshots, tools like Appuploader allow you to select multiple images at once and upload them automatically sorted by device size, rather than dragging them one by one on the web page. Privacy Issues Missing privacy policy links or incomplete content is a common reason for rejection. If your app collects user data (including via third-party SDKs), you must provide a privacy policy, and the link must be accessible. How to fix: Prepare a privacy policy page and host it at an accessible URL, then fill in the link in the privacy policy section in App Store Connect. If your app involves third-party SDKs for advertising, analytics, payme

Warum KI-Agenten Leitplanken brauchen: Operatives Gedächtnis statt Over-Engineering Ki-Agenten sind nicht böse. Sie sind nicht einmal unzuverlässig im klassischen Sinne. Das eigentliche Problem ist vielmehr ihre beständige Bereitschaft zu helfen, gepaart mit einem fehlenden Verständnis für die Grenzen ihrer Befugnisse. Sie wollen das Problem lösen, das ihnen gestellt wird, oft mit einer Aggressivität, die menschliche Manager selten aufbringen. Wenn ein Agent eine Produktionsdatenbank bereinigen soll, tut er es. Wenn er eine Datei löschen soll, die er für überflüssig hält, weil sie im aktuellen Kontext nicht erwähnt wurde, wird er es tun. Wir haben in unserem Engineering-Team 182 sogenannte Guards implementiert. Diese Zahl klingt auf den ersten Blick nach extremem Over-Engineering. Nach 182 Prüfungsschritten, die vor jeder Aktion eines autonomen Agents laufen, könnte man meinen, wir hätten ein unverhältnismäßig komplexes System gebaut. Doch jeder einzelne dieser Guards entstand nicht aus theoretischer Vorsicht. Jeder einzelne steckt in einem echten Vorfall, bei dem ein Agent ohne diese Barriere etwas getan hätte, das wir nicht rückgängig machen konnten oder das immense Kosten verursacht hätte. Dies ist kein Over-Engineering. Das ist operatives Gedächtnis. Was ist ein Guard? Ein Guard ist eine schlanke, deterministische Prüflogik, die zwischen der Entscheidungsfindung der KI und der tatsächlichen Ausführung einer Aktion liegt. Die KI plant eine Aktion. Zum Beispiel: "Führe einen SQL-Update-Befehl auf der Tabelle 'users' aus." Bevor dieser Befehl an die Datenbank geschickt wird, läuft er durch eine Pipeline aus Guards. Ein Guard fragt nicht nach dem "Warum" der KI. Das ist die Domäne des Large Language Models. Der Guard fragt nach den "Was" und "Wie" der realen Welt. Er prüft Fakten, nicht Absichten. Ein typischer Guard könnte so aussehen: def check_write_scope ( agent_action : dict ) -> bool : """ Stellt sicher, dass Schreiboperationen nur auf spezifisch erlaubten Tab

developer context switching security DevSecOps flow state developer velocity security alerts batch security patching ROI cost of context switching developer productivity security security alert fatigue developer cognitive load ad-hoc security patching interrupting developer flow engineering vp productivity metrics DevSecOps velocity context switching recovery time 23 minute recovery context switch batching security alerts SLA-backed fix campaigns security SLA for developers minimizing context switching feature delivery vs security developer experience DevSecOps The Real Cost of Context Switching What Security Alerts Actually Do to Developer Flow Back to blog What interruptions actually cost Is it worse for developers specifically? The research says probably yes The alert volume isn't imaginary — but be careful which numbers you cite The fix: batch the routine work, protect the calendar The important exception: not everything can wait for the batch A more honest way to estimate the ROI The takeaway Sources The Real Cost of Context Switching: What Security Alerts Actually Do to Developer Flow Companies keep investing in better frameworks, tighter deployment gates, and broader platform suites — and feature delivery keeps getting slower anyway. For engineering leaders trying to explain that paradox to the board, the usual suspects (headcount, tooling, talent) rarely hold up. The more useful place to look is something less visible: how often developers get pulled out of what they're doing, and what it costs them to get back in. As "shift-left" security practices spread, developers absorb a steady stream of vulnerability alerts, automated pull-request comments, and one-off Jira tickets throughout the day. The goal — a more secure codebase — is the right one. The delivery mechanism is often the problem. Scattering fixes across random moments in the workday erodes productivity without necessarily making the codebase safer any faster. The alternative a growing number of engi

What’s up everyone. My name is Theodore Ochsen, founder of DaemonCore. I’ve been a developer for well over a decade, and my background goes back to running three PC repair shops before eventually moving heavily into software development, cybersecurity and building applications with my team. My road here has been anything but normal. A serious auto accident in 2015 basically nuked the life I had built. I lost the shops, lost my ability to walk and spent almost three years in rehab learning to walk again. Eventually I lost my marriage, my home and ended up in a wheelchair with pretty much one thing I could still do: code. I used to park myself at Barnes & Noble and read programming books for hours because I couldnt afford to buy all the damn things. Then I'd go back and try what I learned. I just kept building. In 2022 I went back to school for Forensic Psychology with a focus on cybercrime, and I graduate with my BA next month. At the same time, DaemonCore has grown into a team building software, security tools and some weird shit that occasionally starts as “what if we tried this?” and somehow becomes an actual product. One of our newest projects is DaemonCore Academy, which we started building last September and finally launched publicly about a week ago. The concept is pretty simple: cybersecurity education should be hands-on and the knowledge should be free. No three lessons followed by a credit-card screen. We start with fundamentals and work toward hands-on drills and environments where people can actually experiment, break things legally, understand WHY they broke, reset and try again. I'm joining DEV because I dont just want to drop links and disappear. I want to talk development. Architecture, Android, React, databases, security, stupid bugs that steal six hours of your life, things we've learned the hard way, and probably a few things we'll get completely fucking wrong and learn from publicly. I’ve spent enough years doing this to know one thing for certain