标签：#engineering

Quotient CEO Lizzie Matusov explains why soaring AI spend often fails to improve software delivery. She presents a research-backed AI maturity framework designed to help engineering leaders move beyond vanity metrics like token usage, align organizational AI adoption, and address critical bottlenecks across the software development life cycle to deliver measurable business outcomes. By Lizzie Matusov

When you start as a junior developer, you think software engineering is about writing code. A few years in, you think it's about choosing the right architecture and frameworks. After ten-plus years in the trenches - shipping features, surviving on-call disasters, and watching "perfect" codebases turn into unmaintainable monsters - you realize the truth: Software engineering is mostly about managing complexity, human communication, and trade-offs. Here are 25 mistakes I made, witnessed, or had to clean up over the past decade. Hopefully, reading them saves you a few years of painful trial and error. 1. Code & Architecture 1. Abstracting Too Early The DRY (Don't Repeat Yourself) principle is heavily drilled into beginners, but premature abstraction is far worse than duplicate code. Abstracting before you have 3–4 concrete use cases leads to rigid, over-engineered abstractions that are nightmare-inducing to change. Duplication is far cheaper than the wrong abstraction. 2. Falling in Love with "Clever" Code If your code requires a three-minute internal monologue or a complex diagram just to parse a single line, it's not smart - it's a liability. Write obvious, clear, and boring code. Your future self on a 2 AM incident response call will thank you. 3. Misunderstanding the Cost of Dependencies Adding a third-party library to solve a small problem feels like a quick win. In reality, every dependency is a contract you sign with an external team. You inherit their bugs, security vulnerabilities, breaking updates, and maintenance cycles. Ask yourself: Can we build the 5% of this library we actually need in 20 lines of code? 4. Over-Architecting for Scale You Don't Have Designing a system for 10 million daily active users when you currently have 500 is a classic trap. You end up with distributed microservices, message queues, and complex caching strategies that slow down development speed by 10x. Build for today's scale, but keep the boundary clean enough to refactor tomorrow

"A Stack isn't designed to store data. It's designed to make the most recent piece of work the easiest to access." In the previous article, we discovered a new kind of design problem. Some systems don't need to find the fastest item. Some don't need to process tasks in arrival order. Instead, they need to work with whatever happened most recently . That's exactly the problem a Stack solves. In this article, we'll understand how a Stack works and why its behavior appears naturally in many software systems. Imagine a Stack of Plates Think about a stack of dinner plates. Plate 4 ────────── Plate 3 ────────── Plate 2 ────────── Plate 1 ────────── When you need a plate, which one do you take? The one on the top. You don't pull out the bottom plate. Likewise, when placing a new plate, you put it on top. This simple rule defines the behavior of a Stack. What Is a Stack? A Stack is a data structure where both insertion and removal happen from the same end. The last item added is always the first one removed. This behavior is called LIFO (Last In, First Out). Push A ↓ Push B ↓ Push C ↓ Pop ↓ C Notice something important. A Stack isn't trying to preserve arrival order like a Queue. Instead, it preserves recency . The newest item is always the easiest to access. Every Data Structure Solves a Different Design Problem By now, we've seen several data structures, each answering a different question. A HashMap asks: Where is this object? A Heap asks: Which item has the highest priority? A Queue asks: Which task has been waiting the longest? A Stack asks: What happened most recently? Choosing the right data structure begins with identifying which of these questions your system needs to answer. Push and Pop Stacks are built around two simple operations. Push Adding a new item. Before Top ↓ B ↓ A Push C After Top ↓ C ↓ B ↓ A Pop Removing the most recent item. Before Top ↓ C ↓ B ↓ A Pop After Top ↓ B ↓ A Only the top item is removed. Everything below remains untouched. Real-World Examp

Introduction Artificial Intelligence has evolved far beyond answering questions and generating code. Modern AI systems can search databases, interact with APIs, read files, execute commands, access cloud services, and even coordinate multiple tools to complete complex tasks. This shift has given rise to AI agents - systems that don't just generate responses but can actively perform work on behalf of users. However, enabling an AI model to interact with external tools introduces a challenge. Every application, service, and API exposes its capabilities differently. Without a common standard, every AI platform would need custom integrations for every tool it wanted to support. This is where the Model Context Protocol (MCP) comes in. MCP provides a standard way for AI models to discover, understand, and use external tools, data sources, and services. Instead of building separate integrations for each AI model and every application, developers can expose capabilities through a common protocol that different AI clients can understand. In this article, we'll explore what MCP is, why it matters, how it works, and how it's changing the way developers build AI-powered applications. The Problem Before MCP Imagine you're building an AI assistant that needs to interact with: GitHub Slack Google Drive PostgreSQL Jira Notion Local files Internal company APIs Without a shared protocol, every integration becomes a custom implementation. For each tool, you need to define: Authentication API endpoints Request formats Response parsing Error handling Documentation Now imagine supporting multiple AI models. Every model may require different integration logic, increasing development effort and maintenance costs. This creates unnecessary complexity. What Is MCP? At its core, the Model Context Protocol (MCP) is a communication standard between AI models and external systems. Instead of hardcoding every integration, MCP defines a consistent way for an AI client to: Discover available tools U

Platform engineering maturity is emerging as an important factor in determining whether organizations can turn AI adoption into sustainable operational value, according to Perforce Software's 2026 Platform Engineering Report. By Craig Risi

Author: Skydu Summary: A form engine may look like the most basic capability in a low-code platform, but it is really the entry point for business modeling, data structure, permissions, workflows, and future AI understanding. Opening In the previous post, I wrote about why INFORMAT is not meant to be only a low-code tool. Starting from this post, I want to go into specific modules. The first module I want to write about is the form engine. The reason is simple: in a low-code platform, forms look basic, but a form is not just a page. Many enterprise business systems begin with a form. Customer registration, contract approval, project initiation, purchase requests, inventory receiving, equipment inspections, and production reporting are all, at their core, ways to collect, organize, and move business data. So a form engine is not about dragging a few input boxes onto a canvas. It is the entry point for the platform's business modeling capability. The initial requirement looked simple Before building the form engine, my most straightforward idea was this: users should be able to create business forms, configure fields, and let the system automatically generate data-entry pages and data lists. That idea does not sound complicated. A form name, a group of fields, a save button, and a data list seem like enough. But once implementation begins, a series of questions appear quickly. What field types should exist? Can fields be grouped? Can fields depend on each other? Should data be validated? Should a workflow be triggered after submission? Can different people see different fields? How will form data be used by reports, automation, and AI? When these questions stack together, the form engine stops being only a frontend component. It becomes a core module that connects the data model, permission system, workflow system, and automation system. A form is not a page, but a business model I gradually became more certain of one judgment: forms in a low-code platform should not

Security disclosures highlighted vulnerabilities in AI evaluations of autonomous cyber capabilities. Notably, OpenAI’s models escaped sandbox isolation, breaching Hugging Face’s systems. The incident involved a multi-stage attack, revealing flaws in evaluation containment and prompting calls for stricter infrastructure controls and local incident response tools. By Olimpiu Pop

Modern backend applications handle thousands or even millions of requests every second. Users perform actions simultaneously: buying products, transferring money, updating profiles, sending messages, and more. But what happens when two requests try to modify the same data at the same time? This is where race conditions appear — one of the most subtle and dangerous problems in backend development. A race condition can cause incorrect data, security issues, financial losses, and unpredictable application behavior. Understanding how race conditions happen and how to prevent them is an essential skill for backend developers. What Is a Race Condition? A race condition occurs when multiple processes or requests access and modify shared data at the same time, and the final result depends on the order in which those operations execute. The problem is that the developer expects operations to happen in a specific sequence, but the computer executes them based on timing, network delays, database speed, and system load. Simple Example: Bank Account Withdrawal Imagine a user has: Account Balance: $100 Two withdrawal requests arrive at the same time: Request A: Withdraw $80 Request B: Withdraw $50 The backend checks the balance: Request A: Balance >= 80? Yes Request B: Balance >= 50? Yes Both requests continue because they saw the original balance of $100. The system processes: $100 - $80 = $20 $100 - $50 = $50 The final balance might become: $50 instead of: -$30 (which should have been rejected) The application has allowed money to be withdrawn that does not exist. This is a race condition. How Race Conditions Happen in Express.js Express.js applications are often built around asynchronous operations: Database queries API calls File operations Background jobs Message queues Consider this simple inventory system: app . post ( " /purchase " , async ( req , res ) => { const product = await Product . findById ( req . body . productId ); if ( product . stock > 0 ) { product . stock -

100 城时区页给跨区调度当速查，DST 自动算 作者是 数据管道 / 跨时区调度 方向的开发者。这篇不是广告，是踩坑记录 + 顺手做的工具。 背景 做 数据管道 / 跨时区调度 时，时间戳转换是最常被低估的雷区。16 个时间戳工具(Unix 转换/时区/ISO8601/Cron/Duration…) 已覆盖日常；但每个语言/框架的坑都不一样，所以又补了 30 个语言/框架时间戳页(python/javascript/java/sql/…)，每页含 6 个真实坑。 我踩过的坑（举几个） 秒 vs 毫秒：前端 Date.now() 是毫秒，后端常存秒，混用差 1000 倍。 时区不是字符串：存 UTC、展示本地，别把本地时间当 UTC 落库。 2038 问题：32 位系统 time_t 在 2038-01-19 溢出，老系统要提前查。 夏令时：一年有两次重复/缺失的本地时间，跨区调度尤其坑。 我顺手做的东西 转换速查页： https://gotimestamp.com/timezone/new-york 相关语言页： https://gotimestamp.com/timezone/london 开源 MCP： https://github.com/caresotin/tsforge-mcp —— 把时间戳转换/校验直接接进 LLM 工作流，不用手算。 小结 时间戳没那么简单，但工具到位就省心。上面都是免费、开源、可直接用的，希望对同样踩坑的人有帮助。

In a recent Azure Architecture blog article, Azure lead engineer Kishorekumar Pattabiraman outlines practical criteria for choosing between skills, sub-agents, and other approaches when building AI systems, emphasizing reusability, simplicity, and long-term maintainability. By Sergio De Simone

Half the market is arguing about whether RAG or a semantic layer is the right foundation for enterprise AI. They are not competing. They answer different questions, and most teams need both. Two shapes of question Every question an agent receives breaks into one of two forms: "What did we say about X?" — lives in contracts, policies, tickets, docs. Unstructured. RAG was built for this. "What is true about X?" — lives in your warehouse and governed metrics. Structured. A semantic layer was built for this. Treating them as rivals is how teams end up with a system that can quote the pricing policy but cannot tell you this quarter's realised price. Where each one breaks RAG Semantic layer Good at Retrieving relevant prose Resolving definitions and joins Fails on Aggregation, math, current state Anything not modelled as data Permissions Flattened at ingest, rebuilt at query time Compiled per person, per query Answer stability Varies with retrieval ranking Identical by construction Audit story Cites a chunk Reproduces the exact SQL The permissions row is the one that ends pilots. A retrieval index that ingested everything has, by construction, assembled your most sensitive object — and reconstructing entitlement at query time is guesswork. The layer that actually decides Neither a document chunk nor a metric definition is worth much until something compiles it into a governed query and runs it. That is the piece most architectures are missing: intent → context resolution → constrained planning → governed execution . RAG can feed the first step. It cannot perform the last three. Point an agent at raw tables and the best models score in the low teens on real enterprise data. Give the same model compiled, governed context and it clears the high nineties. The retrieval quality was never the bottleneck. The full breakdown — the precise division of labour, why hybrid architectures win, and how compile-time governance closes the gap RAG cannot — is here: 👉 RAG vs. Semantic Layer

Alibaba officially launched Qwen3.8-Max on Monday, marking the debut of its most substantial artificial intelligence model. This new open-weight release aims at enterprise sectors, specifically targeting software engineering and complex reasoning. It represents a significant expansion of the company’s existing portfolio of digital tools for large-scale business operations. Technical architecture and performance benchmarks The Qwen3.8-Max model utilizes a mixture-of-experts (MoE) design, featuring a total of 2.4 trillion parameters. However, the system only activates approximately 95 billion of those parameters during any single inference cycle. This approach balances high-level processing power with the need for operational speed. Alibaba plans to make the open-weight versions of this technology available to the public through its cloud-based studio platform starting next week. Company representatives stated that this new architecture ranks among the most capable systems currently in existence. They position it as a direct competitor to the most advanced frontier models available globally. Internal data suggests the performance levels are trailing only the very top tier of experimental AI systems. This move signals a clear intent to capture market share from established western technology firms. Competitive testing and industry analysis To prove its capabilities, Alibaba released internal data comparing Qwen3.8-Max against top models from Anthropic and OpenAI. The tests focused heavily on coding benchmarks such as SWE-bench Pro. According to the company, their new model held its own against Claude Opus 4.8 and GPT-5.6 Sol. They utilized the specific coding frameworks recommended by each competitor to ensure a fair and rigorous comparison during the evaluation process. Industry analysts have noted that the gap between proprietary and open-weight models is closing rapidly. While proprietary leaders still hold certain advantages, the rise of open-weight alternatives pr

A practical calculator for turning an upload limit into a video bitrate, with enough margin for audio and container overhead. “Make this video smaller” is an open-ended request. “Make this three-minute video fit under 10 MB” is an engineering constraint. The second version sounds more precise, but a quality slider alone cannot solve it. A quality setting tells an encoder how aggressively to preserve detail. It does not directly tell us how many bytes the final file may contain. If the destination has a hard upload limit, the useful starting point is a bit budget. This article builds that calculation in TypeScript, then looks at the assumptions that make the answer less exact than the formula first appears. File Size Is Bitrate Multiplied by Time A video file contains several streams plus a container. For a simple MP4, the largest pieces are usually: the video stream; the audio stream; container metadata and indexing overhead. If we ignore overhead for a moment, the relationship is straightforward: file size in bits = total bitrate in bits per second × duration in seconds Rearranging it gives us the total bitrate available for a target size: total bitrate = target size in bits / duration in seconds That total must cover both video and audio. The approximate video budget is therefore: video bitrate = total bitrate - audio bitrate - overhead allowance The result is not a promise. It is a budget that an encoder can aim at. Be Explicit About MB and MiB Before writing code, decide what “10 MB” means. Storage vendors and many web services use decimal megabytes: 1 MB = 1,000,000 bytes Operating systems and developer tools often display binary mebibytes: 1 MiB = 1,048,576 bytes The difference is about 4.9%. That is large enough to turn a file that looks safe locally into a rejected upload. For a hard external limit, I prefer to calculate with decimal MB and keep an additional safety margin. For an internal tool where the unit is clearly MiB, I make that choice explicit in th

Arun Joseph shares real-world insights on scaling enterprise agentic platforms like Deutsche Telekom’s LMOS. He discusses bridging organizational fault lines, replacing tool sprawl with core platform abstractions, and moving beyond basic chatbots to operational intelligence systems through ephemeral agents and an Agent Definition Language (ADL). By Arun Joseph

GPT-Live enables continuous voice interaction with AI, using a turnless speech model and low-latency architecture for faster, more natural conversations.

One thing Microsoft is not good at is naming things, and sadly it's happened again. But let's go back to the beginning: what are Skills? Skills are targeted prompts/context that are modular, so they are not always included in the LLM session. They are Markdown files with selected metadata in YAML, all in a file normally named skill.md (the parent folder and YAML metadata identify it). They were created by Anthropic (Claude) and were designed for both the user to add in a prompt ( /Skill ), or for the LLM to decide. Similar to Skills are Plug-ins. These can (and often do) include skill.md files, but can also have scripts, MCP servers, and other tools. So back to Microsoft naming things badly. Copilot Studio (Azure Bot Framework version) had skills, but they were not skills. The new Copilot Studio has Skills, but they are not Skills, they are actually Plug-ins. Plug-ins include Skills, so why does it matter? Well, it doesn't really, but I like to moan, and it means sometimes cool functionality can be left on the table because we presume Microsoft names things accurately. Anyway I digress (I like to do that), now we understand what Skills/Plug-ins are I wanted to dive into them within Copilot Studio and cover: Why Are They Cool Building Powerful Skills Adding Scripts/Templates Using Skills 1. Why Are They Cool I often go on about skills being cool, but why? There are a few reasons. Context Management Before skills, the standard approach was to give the LLM everything and let it figure out what it needed. The problem with this is twofold. First, more context equals more tokens, which equals more cost. Second—and more importantly—too much unrelated context can have a detrimental impact on the LLM response. LLMs work by using input tokens to predict the next token, so polluted input tokens can make the LLM predict the wrong next token (this is a huge simplification, but you get what I mean). Transferable As skills are simple Markdown files, they can easily be transferred

Embabel has reached its 1.0 release, providing a framework for AI agents on Java It allows Java and Kotlin developers to define agents as typed domain objects. Built on Spring AI, Embabel supports multiple model providers and combines planning with predefined state machines, offering flexibility for agent workflows. By Erik Costlow

We live in an era where our wrists track every heartbeat, step, and sleep cycle. Yet, most of this "Quantified Self" data sits rotting in massive .xml or .json export files that are impossible to read. What if you could simply ask your AI, "How did my resting heart rate trend during the week I was stressed about the product launch?" In this tutorial, we are building a Quantified Self RAG (Retrieval-Augmented Generation) pipeline . We will take fragmented health data from Apple HealthKit and Google Health Connect, process it using DuckDB , and vectorize it into Pinecone using LangChain . By the end of this guide, you’ll have a production-grade Health Data RAG system capable of high-performance natural language queries over your personal biometrics. The Architecture: From Raw Logs to Vector Insights Handling health data at scale requires a robust ETL (Extract, Transform, Load) process. Vectorizing every single heart rate measurement (which can occur every few seconds) is inefficient and expensive. We need to downsample and summarize before embedding. graph TD A[Apple Health/Google Health] -->|Export XML/JSON| B[Raw Data Storage] B --> C{DuckDB Processing} C -->|Cleaning & Downsampling| D[Structured Parquet/JSON] D --> E[LangChain Document Loader] E --> F[OpenAI Embeddings] F --> G[Pinecone Vector Database] H[User: 'Why was my sleep poor last Tuesday?'] --> I[LangChain RAG Chain] G --> I I --> J[LLM Contextual Answer] Prerequisites 🛠️ To follow along, you'll need: Python 3.10+ Tech Stack : Pinecone , LangChain , DuckDB , OpenAI , and Pandas . An export of your health data (Apple Health export.xml or Google Takeout). Step 1: Efficient Data Crunching with DuckDB Apple Health exports are notoriously large XML files. Loading them directly into memory with standard Python is a recipe for a crash. We use DuckDB for its blazing-fast analytical capabilities to filter and downsample our data. import duckdb # Load and parse the XML (simplified logic) # Note: In a real scenario,

Most of the engineers consider documentation as an after-thought; a README on a finished system written in the final 20 minutes before a PR gets merged. That's the wrong way to do this relationship. Documentation is not a description of architecture. It is part of the architecture, and marking it as separate is the cause of so many rotting systems, which still pass all tests. The compiler doesn't care, your team does It could be a consistent codebase and yet it be undocumented garbage from the point of view of anybody who didn't write it. Only one sort of correctness is enforced by the compiler (or interpreter): does this code perform the operation that the instructions say it performs. It doesn't weigh in on why a specific table contains a deleted_at column, versus a hard delete, or why a service tries 3 times with exponential back-off, versus 5 times with a fixed interval. Those decisions include constraints that are not apparent in the diff, regulatory, historical, or performance. If these are only in the mind of the programmer who wrote them, the actual architecture is partially undocumented, and these constraints will be breached as soon as someone else messes with the code when it is under a tight deadline. Architecture is not only the shape of your services and schemas, it's the set of decisions and constraints that shape stayed within. Undocumented constraints are like walls that we don't see, or know about. They are walked through without anyone knowing they exist, and one of the assumed conditions is broken at a time. Documentation as a design artifact, not a report Good documentation should be done prior to and/or in the midst of implementation, not after. When writing a design doc that explicitly states the problem, the options you considered, the one you selected, and the tradeoffs you made, you are actually doing real design work, you are making mistakes in your thinking process that would only become apparent during production. There have been more ti

You've learned not to trust the first answer. So you read it carefully. You spot two problems. You fix them yourself, ship it, and move on. That's a reasonable way to work, and it's what separates an engineer who uses these tools well from one who copies and pastes. But there's a step you skipped. You never asked Claude to find the problems, and asking produces a different kind of output than reviewing does. 🔍 What actually happens Here's a specific case. You ask for an incremental load. You get something clean: a watermark column, a filter on records newer than the last run, an upsert into the target. You review it. You notice it assumes source records arrive in order, which yours don't, so you add a buffer window. You notice it doesn't handle the first run when the watermark is null, so you add a default. Two fixes, maybe fifteen minutes, and now it's correct. What you didn't find was the third problem: the upsert assumes a stable business key, and in your source system that key gets reassigned when records are merged. That one surfaces in production six weeks later as duplicate rows nobody can explain. You caught the problems you were looking for. You didn't catch the one you weren't. This is the normal outcome of self-review. You check against your own mental list of things that go wrong, and your list is good but finite. The problems that hurt are the ones outside it. 🧠 Why intermediates specifically miss this Beginners don't review AI output much at all, so this isn't their failure mode yet. Seniors have usually developed the habit after being caught out by something their own review missed. Intermediates sit in an awkward middle. They have learned, correctly, that AI output needs questioning. And they have concluded, understandably, that the questioning is entirely their job. That conclusion makes sense. Reviewing is what you do with a junior's pull request. It's what you do with your own code before you push. Review is a human activity performed on work some