标签：#Development

AI takes the path of least resistance. That one characteristic explains most of what changed for me about architecting a system once an agent was in the loop. It is genuinely faster than I am on frameworks, patterns, and the standard way to wire something up . Since it has read more on them than I have. But "least resistance" means it optimizes for the thing in front of it, e.g., getting an endpoint to work or a test to pass. It cannot optimize for the shape the system needs for your use case because it does not know all details. You still own 100% of that part. Two ways least-resistance goes wrong Left alone, the path of least resistance breaks in two opposite directions. It cuts a corner to make the immediate thing work: collapses a boundary, hardcodes a value, skips the seam that would have let two pieces move independently later. And when you try to correct it, it will over-engineer and reach for patterns, layers, and abstractions you did not ask for and don't need yet. Both come from the same place: it is solving the prompt, not steering the architecture . Here is the version I lived with. My app is layered the usual way: an API layer, a service layer under it, a data-access layer under that, with clear rules about what each one is allowed to do. Database transactions belong in the service layer. The agent kept ignoring that. Commits I had scoped to the service layer kept turning up in the data layer, or up in the API. The worst one was a transaction that opened in the service layer and got committed two layers down. If left at simple prompts, it will run and deliver you something that works, but you'll find that along the way it has quietly broken the boundary and created a brittle system. Here is the flip side, from just the other day. I was working on a bug fix with the agent on its own branch off main. Mid-test, I hit a separate gap, related to the feature but not the bug, and asked the agent to fix that too. It sensibly put the gap on its own branch, but b

Building an AI Operating Layer Episode 1 Why I Didn't Start Sooner Most engineering projects begin with an idea. This one began with a question. For months I found myself watching the explosion of AI tools, frameworks, models, and agent platforms. Every week there seemed to be another breakthrough, another library, and another opinion about where everything was headed. I could have started building immediately. Part of me thought I should have. But I realized something, and it kept bothering me. I wasn't afraid of writing code. I was afraid of solving the wrong problem. When a new technology appears, it's easy to jump straight into implementation. Pick a framework. Choose a model. Build something. Ship it. I didn't want to start there because I had a feeling there was a much bigger picture that I wasn't seeing yet. So I waited. I spent my time reading, experimenting, asking questions, and trying to understand how all of these pieces connected. The more I learned, the more I realized I wasn't actually interested in building another AI application. What fascinated me was the system behind the systems. What happens when you stop looking at models, memory, orchestration, tools, policies, and execution as separate ideas and start seeing them as parts of a much larger ecosystem? That question became the beginning of this project. This isn't a story about predicting the future. It's a story about trying to understand it. I'm sure some of my assumptions will be wrong. I'm sure parts of this architecture will change. If they do, you'll see that too. I don't want this journal to only show the polished results. I want it to capture the discoveries, the wrong turns, the redesigns, and the moments where a better idea replaces an old one. At the center of this journey is a project I'm calling the AI Operating Layer. Today it's mostly architecture, documentation, research, prototypes, and a growing collection of ideas. Maybe that's exactly where projects like this should begin. I'

You correct someone once. Not perfectly, but they get it. Next time, they do not make the same mistake. That is not optimism. That is just how correction works, "with people". I worked with agents on that assumption for a long time before I even noticed I was doing it. The plan that never held Before I had a single written rule anywhere, I would open a new session and ask for a plan first. Resolve the edge cases before touching a line of code, I said. The agent would agree, in whatever way a chat window agrees, and go straight to implementation anyway. I corrected it. Same session, it adjusted. New session, next day, same repo, same everything except the chat history: straight to implementation again. Every single time! So I did what looked reasonable. I wrote the plan myself. I resolved the edge cases myself, the open questions, the gaps the agent skipped past on its way to code. ' Tedious ' is the polite word for it. I was doing the one task I brought the agent in to do, and calling it collaboration. The same recipe, again The second correction arrived the same way. Every repo had its own shape. A recipe, a standard, a way things were supposed to be built here and not there. I would explain it. Full session, good results, the agent following the standard like it understood the standard. New session. Same repo, sometimes the new repo. Explain it again. Word for word, close enough. It was not that the agent forgot how to code. It was that nothing from the last conversation traveled with it into this one. Nothing said in the chat survives it I kept treating this like a training problem. Say it clearer. Say it earlier. Say it with an example next time. None of that was wrong exactly. It was aimed at the wrong layer. The actual mistake was assuming correction compounds the way it does with a person. It does not. A person carries what you told them into the next conversation without being asked to. An agent starts the next session exactly where it started the first one.

This article presents a defense-in-depth approach for securing Model Context Protocol (MCP) deployments in production. It outlines four architectural control layers: safe execution, management infrastructure, outbound trust, and semantic integrity, arguing that production security requires enforcement beyond the gateway at the earliest trustworthy control points. By Nik Kale

Microsoft has released .NET 11 Preview 6 with several architectural and reliability improvements for .NET MAUI. The update brings the next-generation CollectionView implementation to Windows, moves Android Shell toward the handler model, improves Native AOT compatibility, and adds recovery support for interrupted media-picker operations. By Edin Kapić

As software developers, we often spend most of our time building APIs, databases, authentication systems, and web applications. That's certainly been my focus recently, especially working with Go, JWT authentication, and backend services. Last week, however, I had the opportunity to participate in the KijaniSpace Hackathon , held at Zone01 Kisumu , and it introduced me to an entirely different side of software development. Our challenge was to build solutions using: Geographic Information Systems (GIS) The Copernicus API IoT devices where applicable It was an opportunity to see how software can interact with our physical world. What is GIS? GIS (Geographic Information Systems) is a technology used to collect, analyze, visualize, and manage data that has a geographic location. Imagine not just storing information like: Temperature Population Vegetation Buildings Roads ...but also knowing exactly where that information exists on Earth. That location data allows developers to build intelligent systems capable of answering questions like: Which farms are experiencing drought? Which roads are likely to flood? Which areas are losing forest cover? Where should new infrastructure be built? GIS transforms ordinary data into meaningful geographic insights. Discovering the Copernicus Program Before this hackathon, I had heard very little about Copernicus. Copernicus is the European Union's Earth Observation Programme. It provides free satellite imagery and environmental data collected by the Sentinel satellite missions. Through its APIs, developers can access information about: Land cover Vegetation health Weather patterns Water bodies Air quality Climate changes Disaster monitoring What amazed me most is that much of this data is openly available for developers to build impactful applications. Where IoT Fits In Some teams also explored Internet of Things (IoT) solutions. IoT devices can collect real-world information through sensors measuring: Soil moisture Temperature Humidi

The call usually comes about eleven months in. Go-live happened, sort of. Finance is still closing the month in a spreadsheet, the warehouse team keeps a parallel notebook, and someone has quietly stopped using the CRM entirely. The system technically works. Nobody trusts it. Odoo rarely fails because Odoo is bad software. It fails because the implementation encoded somebody's misunderstanding of the business into 40 custom modules, and now every fix breaks two things. Panorama Consulting's 2026 ERP Report still puts cost overruns and schedule slippage among the most persistent problems across ERP projects of every size — and in our experience the overrun is almost never in licensing. It's in the rework. Here's the triage sequence we actually run when we inherit a broken deployment, in the order we run it. Step 1: Read the database before you read the code Skip the codebase for a day. Open PostgreSQL and ask the system what people are really doing. A few queries tell you more than a week of stakeholder interviews: Row counts per model over time. If crm.lead stopped growing in March, sales abandoned the module in March. Nobody will volunteer this in a meeting. ir.model.fields where state = 'manual' . Every field created through Studio or a quick patch. A healthy mid-size deployment has a few dozen. We've opened databases with 900. That number is a direct measure of how much undocumented business logic is floating outside version control. stock.quant versus what the warehouse counts. Any gap here means inventory valuation is wrong, which means the P&L is wrong, which is usually the real reason finance went back to Excel. ir_cron last-run timestamps and failure counts. Silently dead crons are behind a surprising share of "the system doesn't update" complaints. Direct SQL writes. Grep the custom modules for self.env.cr.execute with UPDATE or INSERT . Every one of those bypasses the ORM, so computed fields never recomputed and stored values are now lying to you. This ste

We're Byte Me , a software agency from Alkmaar, the Netherlands. The most valuable advice we give clients is usually not "Let's build something new"; it's "Let's not touch the thing that works." Here's why and how. The rebuild reflex Every company running a 15-year-old ERP has had this meeting. Someone opens the ancient interface on the big screen, everyone groans, and a decision crystallizes: "We need to replace this." We understand the reflex. The UI looks like Windows XP. The one person who understands the database retired. Adding a field takes a change request and three weeks. Every new hire asks why orders live in a system older than they are. And yet, when companies come to us with "We want to replace our legacy system," our first answer is almost always: you probably don't. Not because rebuilds are impossible but because the odds are terrible. Big-bang legacy replacements are among the highest-risk projects in software. They take longer than planned, cost more than planned, and the scariest part isn't the code: it's the twenty years of business rules buried in that old system that nobody documented. The weird discount logic for that one big customer. The field that means something different depending on which decade the record was created in. The nightly job everyone forgets exists until you turn it off. That old system isn't just software. It's your company's institutional memory, compiled. Ugly ≠ broken Here's the reframe that changes these conversations: most legacy systems don't have a functionality problem. They have an access problem. The ERP still processes orders correctly. It's been doing so, reliably, for fifteen years, a track record your rebuild won't have on day one. What's actually painful: Customers can't see their own orders, so they email and call Sales can't check stock from the road Data has to be retyped into the accounting tool, the webshop, the planning board Reporting means exporting to Excel and praying None of those problems require r

Remix 3 is a full-stack web framework that moves away from React, focusing on web platform primitives. It integrates routes, request handlers, and UI components into a single structure, utilizing a forked Preact for the frontend. Unlike previous versions, it emphasizes server ownership of the request lifecycle. Migration from Remix 2 is not straightforward, as it requires changes to existing apps. By Daniel Curtis

Neander has no exceptions. No try , no catch , no finally . A call to one of the host application's APIs returns something closer to Rust's Result : either the answer, or the reason there is no answer. In place of a catch block there is one type marker, three operators, and a guarantee that every submission comes back in the same shape no matter what happened. Last time the foundational series closed with isolation. This is the first of two encores, and it takes the subject that came up in nearly every entry without ever being laid out in full: what happens when something goes wrong. There are two answers, because there are two audiences. An error is a value while the program runs, and a verdict once it has stopped. The two are made of the same parts, on purpose. The failable type Every call returns a failable type, written T! . It carries either a value of type T or an error with a code, a message, and the name of the function that produced it. T! is the mirror of the nullable type T? . Same shape, different question: one asks whether a value is there at all, the other asks whether obtaining it worked. The mirroring runs deeper than the notation, because the same three operators serve both types. A failure gets no unwrapping vocabulary of its own. Those three are =? , ?? and is : // narrow, or throw the error out of the enclosing block let order : Order =? call orders .get ( id : 42 ) // or substitute a default let order : Order = call orders .get ( id : 42 ) ?? emptyOrder // or inspect it and decide let result : Order! = call orders .get ( id : 42 ) if result is error { if errorCode ( result ) != 404 { throw result } return emptyOrder } A standalone call statement, one without a let , narrows implicitly: the error is thrown and the success value is discarded. One property does the heavy lifting throughout the rest of this post: T! originates only from a call . No expression picks up a ! along the way, and no widening rule introduces one. The marker means exactly o

TanStack Table V9 is a beta release of a headless UI library for creating tables in various JavaScript frameworks. It features improved state management, memory usage, and extensibility. The notable change is an opt-in feature model, allowing developers to load only necessary components. Migration is gradual, with tools provided for legacy support. The library remains free and developer-focused. By Daniel Curtis

Every few weeks I'd end up rewriting the same 10 things from scratch: rate limiter middleware, webhook signature check, retry-with-backoff, connection pool config. So I built AutoSnippets. 50 snippets across Python, JS, TS, Java, C#, C++, Go, PHP, Rust, and SQL. All production-ready, and even more are being made. Favorites of mine: Go channel-based worker pool (snippet #32) Rust Arc + Mutex safe counter (#41) SQL recursive CTE for org charts (#50) PHP RBAC in like 8 lines (#38) Free, no signup. Bookmark it if you find it useful.

AI-Driven Development: How Machine Learning is Reshaping Software Workflows in 2026 The software development landscape of 2026 looks almost unrecognizable compared to just a few years ago. Artificial intelligence has moved from being a novel assistant to a core pillar of the development workflow. Today, AI doesn't just autocomplete a line of code; it helps architect entire systems, automatically detects and fixes bugs before they reach production, and continuously learns from the organization's codebase to accelerate every phase of delivery. This article explores the key transformations and practical examples of how AI is reshaping software development in 2026. AI-Powered Code Generation and Completion By 2026, AI-powered code assistants have evolved far beyond simple autocomplete. Modern systems understand natural language requirements, project architecture, and even business logic. Developers can describe complex features in plain English, and the AI generates multi-file implementations, including dependency management, configuration, and tests. Example: Generating a REST API with AI A developer might request: "Create a FastAPI endpoint for user registration with email verification, rate limiting, and an asynchronous database call." The AI would produce: from fastapi import APIRouter , HTTPException , Depends from sqlalchemy.ext.asyncio import AsyncSession from app.database import get_async_session from app.models import User from app.schemas import UserCreate , UserResponse from app.services import create_user , send_verification_email from app.rate_limiter import rate_limit router = APIRouter ( prefix = " /auth " , tags = [ " auth " ]) @router.post ( " /register " , response_model = UserResponse ) @rate_limit ( max_requests = 5 , window_seconds = 60 ) async def register ( user_data : UserCreate , db : AsyncSession = Depends ( get_async_session )): existing_user = await User . find_by_email ( db , user_data . email ) if existing_user : raise HTTPException ( statu

When you need process orchestration — approval workflows, business rules, data pipelines — the usual answer is a heavyweight engine: BPMN 2.0 XML, database schemas, a management UI, and a framework that drags in half of enterprise Java. Solon Flow takes a different approach. It's a ~200KB engine that treats process definitions as flat YAML or JSON, runs without a database, and lets you resume interrupted processes from a JSON snapshot. You can embed it in any JVM framework — Solon, Spring Boot, Quarkus, or even a plain main() method. This article walks through the core API, node types, context persistence, and driver customization — all verified against the official documentation at solon.noear.org . Getting Started Add the dependency: <dependency> <groupId> org.noear </groupId> <artifactId> solon-flow </artifactId> </dependency> Define a flow in YAML ( flow/demo1.yml ): id : " c1" layout : - { id : " n1" , type : " start" , link : " n2" } - { id : " n2" , type : " activity" , link : " n3" , task : ' System.out.println("hello world!");' } - { id : " n3" , type : " end" } Load and execute: FlowEngine engine = FlowEngine . newInstance (); engine . load ( "classpath:flow/demo1.yml" ); engine . eval ( "c1" ); That's it. No database, no XML schema, no deployment step. In a Solon application, you can inject the engine directly and let it auto-load flow definitions: solon.flow : - " classpath:flow/*.yml" @Component public class DemoCom implements LifecycleBean { @Inject private FlowEngine flowEngine ; @Override public void start () throws Throwable { flowEngine . eval ( "c1" ); } } The engine scans all matching files on startup, so adding a new flow is just dropping a YAML file. Node Types Solon Flow supports seven node types via the NodeType enum: Type Description Task Condition Parallel In Out start Entry point — — — 0 1 activity Default node Yes — — 1..n 1..n exclusive Exclusive gateway (if/else) Yes Yes — 1..n 1..n inclusive Inclusive gateway (multi-select) Yes Yes — 1

Every time I wanted to paste a whole project into Claude or ChatGPT, I ended up guessing whether it would even fit — and often found out the hard way, mid-conversation, that it didn't. So I built Tokenazire, a small CLI tool that solves exactly that. What it does Scans a local folder or a GitHub repo (just pass the URL, it clones it for you) Counts tokens per file using tiktoken (the same tokenizer OpenAI models use, a solid approximation across most LLMs) Shows a color-coded breakdown (green → yellow → orange → red) so you instantly see which files are "heavy" Calculates what percentage of a model's context window (default 200k, configurable) your whole project takes up Ignores .git, venv, node_modules, and other noise automatically Has an --export flag that bundles the entire project — folder structure plus every file's content — into a single text file, ready to paste straight into an LLM chat I kept hitting the same annoying loop: copy a project into a chat, get cut off or told the input's too long, then manually trim files and try again. This automates the "will it fit, and if not, what's taking up the most space" question up front. The --export step came later — once I knew what would fit, I still had to manually copy-paste files one by one into the chat. Now it just spits out one clean file with a project tree on top and clearly separated file contents, ready to paste. Tech stack Plain Python, tiktoken for tokenization, rich for the terminal output (tables, colors, progress bar). No config files, no external services beyond git for cloning. Try it Repo: https://github.com/DeKlain4ik/token-counter (MIT licensed) Still early — feedback, issues, and PRs are welcome.

Engineers are increasingly arguing that modern LLMs can already reason through root cause analysis once given correctly prepared context, shifting the hard problem to the pipelines that correlate telemetry. A Coroot experiment across eleven models offers early evidence for the claim. By Mark Silvester

Most backend engineers implement multi-tenant quota checks using a standard "read-then-write" pattern. In production, this pattern is highly unsafe: SELECT grading_scans_remaining FROM profiles; If greater than 0, execute the application logic. UPDATE profiles SET grading_scans_remaining = grading_scans_remaining - 1; Under high volume or rapid concurrent requests, two independent processes will read the exact same balance before either one deducts usage. This race condition allows multi-tenant users to bypass your billing gates entirely. To solve this, you have to bypass the frontend and application-level checks, enforcing an atomic database operation that serializes the row update first. I have open-sourced a reference framework that outlines explicit subscription enums, core multi-tenant schemas, and a native VS Code / Cursor snippets configuration to speed up your local database modeling. 📂 Check out the repository on GitHub: { https://github.com/dollykm49/PostgreSQL-SaaS-Multi-Tenant-Subscription-Architecture-reference-framework- } What's inside the repository: Strictly Typed Enums: Centralized business rules handled natively by the database engine. Granular Balance Tracking: Optimized data-layer mapping for profiles and reset states. postgres-saas.code-snippets Engine: A local IDE configuration file that lets you deploy this core schema straight from your code editor by typing pg- shortcuts. For teams building commercial applications looking to skip weeks of writing custom migrations, testing concurrency edge-cases, and debugging row-locking security rules, the repository also includes a link to the extended 28-page production system bundle. Feedback on the multi-tier validation parameters is highly welcome!

Models are improving quickly, but the cheaper options are often good enough.

As part of my learning journey with Django, I wanted to build a project that would challenge me beyond the basics. I decided to create RecipeHub, a web application where users can create, manage, and share recipes while exploring recipes from other users. The project started from a Django starter template, but I customized it by adding new features, redesigning the interface, and deploying it online. Features RecipeHub allows users to: Register and log in Create, edit, and delete recipes Browse recipes by category Save favourite recipes Upload recipe images Access a personal dashboard Use the application in both light and dark mode The application is fully responsive, making it easy to use on both desktop and mobile devices. Technologies Used I built the project using: Python Django Django Allauth PostgreSQL Tailwind CSS DaisyUI HTMX Vite Gunicorn Render GitHub was used for version control throughout the project. Challenges One of the biggest challenges was deployment. While everything worked locally, deploying to Render required configuring PostgreSQL, environment variables, and static files correctly. I also encountered an issue with uploaded recipe images. Since the application is hosted on Render's free tier, uploaded media is stored on an ephemeral filesystem, meaning uploaded images are lost after redeployment. Learning why this happens gave me a better understanding of the difference between development and production environments. Another challenge was redesigning the dashboards. I wanted them to feel clean and modern instead of looking like a default Django application, so I spent time improving the layout, spacing, and responsiveness. What I Learned This project helped me improve my understanding of: Django project structure Authentication and user management CRUD operations Database relationships Responsive UI design Git and GitHub workflows Deploying Django applications Debugging real-world issues More importantly, it taught me how to troubleshoot proble

Jotai v2.20.0 has been released, focusing on improved performance for high-throughput scenarios. Key changes involve adjustments to internal building blocks and addressing previous performance regressions. While the API for everyday use remains unchanged, library authors should note some deprecations as the groundwork for Jotai v3 begins. By Daniel Curtis