标签：#development

Erik Steiger discusses the operational pain of legacy PDF generation in regulated banking and manufacturing. He explains how transitioning from resource-heavy engines like Puppeteer and LaTeX to a serverless Rust architecture powered by Typst can drop render latencies below 2ms. He shares how applying Git and Docker concepts to template registries ensures ironclad compliance and rapid debugging. By Erik Steiger

The AI Engineer World's Fair has attracted a lot of adults, and they brought their kids too, for...

GitLab's 2026 AI Accountability Report highlights an AI Paradox: although 78% of developers say they code faster, overall software delivery has not accelerated due to downstream testing and review bottlenecks and new challenges for enterprise governance and traceability. By Sergio De Simone

The AI Implementation Process I Use With Every Client Most AI projects do not fail at the model. They fail in the six weeks before anyone writes a prompt, and in the six weeks after the demo lands in a Slack channel and nobody knows who owns it. I have run enough of these now (from one-off automations to multi-agent content systems running unattended) that the process has converged into something stable. This is the version I actually use. It has five phases: scoping, POC, integration, evaluation, operations. Each phase has an exit criterion. If we cannot meet the exit criterion, we do not move forward. That single rule has saved more projects than any clever architecture choice. Phase 1: Scoping (1 to 2 weeks, fixed price) Scoping ends with a written document that names the workflow being automated, the system of record it touches, the success metric in hours or dollars, the data we have access to, and the smallest possible first slice. No model is chosen yet. No code is written. If we cannot produce that document, the engagement stops here and the client keeps the document. The hardest part of scoping is resisting the urge to solve the interesting problem. Clients almost always describe the AI-shaped fantasy ("an agent that handles all support tickets") when the real opportunity is narrower and uglier ("triage tier-1 tickets that mention billing, route to the right queue, draft a reply for human approval"). The narrower version ships. The fantasy does not. I run scoping as three sessions: Workflow walkthrough. Someone who actually does the work shows me their screen for an hour. I record it. I take timestamps. The point is to find the moments where a human is doing pattern matching that an LLM can do, and to find the moments where they are doing judgment that an LLM should not do. Data audit. Where does the input live? Where does the output need to go? What is the auth story? If the data is locked inside a SaaS product with no API and no export, that is the projec

Like most developers, I have a set of tools I use every day. Most of them work great, and I don't...

Hello Devs, for months, I felt confident about system design interviews. I'd watched endless YouTube videos. I'd studied architecture diagrams. I could explain how Netflix builds recommendation systems. I understood Kafka, Redis, load balancers, and microservices. I'd memorized the designs of Twitter, Uber, YouTube, and TinyURL. Then I sat down for my first real system design interview and froze. The interviewer asked: "How would you design a notification system?" I had memorized notification systems. I knew about push notifications, email queues, delivery workers, and retry logic. I could recite architectural patterns. But suddenly, none of that helped. I didn't know which questions to ask first. I started designing before understanding the actual requirements. I built architecture for problems that didn't exist. I missed obvious bottlenecks. I couldn't articulate why I made specific trade-offs. When the interviewer pushed back, I had no framework to adjust. I failed that interview. But that failure taught me something crucial: System design interviews aren't about knowing technologies. They're about knowing how to think. After that, I went back and systematically practiced 20 system design problems. Not passively watching solutions. Actually designing. Making mistakes and refining my approach. And somewhere around problem 12, a pattern emerged. The best candidates didn't know more technologies than anyone else. They had a framework . They asked the same questions in the same order. They structured their thinking consistently. They could handle curveballs because their framework was flexible. They reasoned through trade-offs explicitly. Here's the framework that finally made it click for me. The Problem with Memorization Before I share the framework, let me explain why memorizing designs fails. When you memorize " How to Design Twitter," you learn: Use relational databases for users and tweets Use NoSQL for timelines Cache with Redis Use message queues for fanout S

There is a popular misconception that if you do TDD, your design also stays correct. That if the tests pass, quality is guaranteed. In AI-assisted development, this misconception is the kind that quietly accumulates — the more tests you have, the more invisible damage builds up underneath. All tests passed. The design was still broken. Here is what happened today. A function called safe_post.py had its signature changed. Two arguments — notify_sh and doctor_sh — were removed. The test suite passed in full. But the callers were still using the old signature. They were silently broken. Why did the tests pass? Because the test code itself was using the old signature. The tests had been written (by AI) at a time when the design intent was already misunderstood. The misunderstanding was baked into the tests from the start. Tests passing and the design being correct are two different things. "All tests pass" tells you only one thing: the implementation matches what the tests expect. Whether the tests express the right design intent is a separate question. TDD verifies "implementation against tests" — nothing more Let me restate the TDD definition. Red → Green → Refactor. Write a test. Write the implementation that passes the test. Refactor. In this loop, what the test verifies is whether the implementation meets the test's expectation. That is one verification — and only one. What TDD does not verify is whether the test itself correctly expresses the design intent. The structure looks like this: Design intent → Tests (← this link is not verified) ↓ Implementation (← this link is verified by tests) If the person writing the tests misunderstands the design intent, the tests will pass and the design will still be wrong. Machine learning engineer Hamel Husain calls this the "Gulf of Specification" — the gap between what you intended to measure and what your metric actually measures. Optimize hard against a flawed metric and you optimize hard in the wrong direction. The same d

Michael Webster discusses the rise of headless AI agents and their impact on software delivery pipelines. He shares how massive, AI-generated pull requests create a severe bottleneck for human reviewers and introduce persistent technical debt. Learn how engineering leaders can leverage test impact analysis and automated validation pipelines to verify agentic output without sacrificing stability. By Michael Webster

Why adaptability beats perfection in startup software development The Startup Trap: Building for a Future That Doesn't Exist Yet Many startup founders make the same mistake. They spend months building the "perfect" product architecture. The code is clean. The design patterns are flawless. The test coverage is near 100%. The infrastructure can scale to millions of users. There's just one problem: They don't have any users. In the startup world, survival depends on learning faster than competitors, not on creating the most elegant codebase. Product-market fit is uncertain. Customer needs change weekly. Business models evolve. Features that seemed critical last month become irrelevant the next. In that environment, the biggest advantage isn't perfect code. It's malleable code . Code that can bend, adapt, and evolve as the business learns. What Is Malleable Code? Malleable code is software that is easy to change. It isn't necessarily perfect. It isn't over-engineered. It isn't designed to solve every future problem. Instead, it's designed to support continuous experimentation. Malleable code allows teams to: Launch MVPs quickly Test assumptions rapidly Respond to customer feedback Pivot when necessary Add new features without major rewrites Remove failed features with minimal effort Think of it this way: Perfect code optimizes for certainty. Malleable code optimizes for uncertainty. And startups operate almost entirely in uncertainty. When you're still searching for product-market fit, the ability to adapt is often more valuable than technical elegance. Why "Perfect" Code Often Hurts Startups Software engineers love solving technical problems. It's natural. Building a scalable architecture feels productive. Refactoring code feels productive. Designing the perfect system feels productive. But startup success isn't measured by code quality. It's measured by business outcomes. Questions such as: Are customers using the product? Are they paying for it? Are they returning? A

Cloudflare has recently shared how they uncovered an issue in their Rust implementation of CUBIC, a congestion controller algorithm, which prevented it from recovering from a scenario of heavy packet loss at the start of a connection. By Gianmarco Nalin

We talk a lot about what AI can build. Code generation. Faster prototypes. Automated debugging. One-shot apps. Entire products created in hours. And yes, AI is powerful. But there is a quieter cost we are not talking about enough: AI hype is starting to weaken the motivation to learn core engineering deeply. That should worry us. 1. The "Why Bother?" Mindset When the dominant narrative says AI can generate code instantly, many engineers start asking: Why should I spend months mastering frameworks, architecture, databases, networking, or system design? At first, that sounds practical. If a tool can help, why not use it? But there is a difference between using AI to move faster and using AI to avoid understanding. Core engineering is not just about writing code. It is about knowing why something works, where it breaks, how it scales, and how to fix it when the generated answer is wrong. If we skip that learning, we create engineers who can prompt systems but cannot reason deeply about systems. That is a dangerous tradeoff. 2. The Funding and Praise Monopoly Right now, AI gets most of the attention. Budgets move toward AI. Leadership praises AI initiatives. Teams are pushed to add AI features even when the fundamentals are still weak. Meanwhile, excellent core engineering often goes unnoticed. The people improving reliability, performance, developer experience, infrastructure, security, and maintainability are still doing high-impact work. But in many places, that work is being treated as less exciting simply because it is not branded as AI. This creates pressure. Engineers feel they must pivot to AI, not always out of interest, but out of fear. Fear of being left behind. Fear of being replaced. Fear that their existing expertise is no longer valued. That is not innovation. That is anxiety disguised as progress. 3. The "AI-First" Discount There is another subtle problem. When someone builds something impressive today, the reaction is often: AI probably generated that.

Spencer Judge discusses the architectural pattern of building a shared core in Rust with language-specific layers on top. Drawing from his work on Temporal's SDKs, he shares lessons on navigating FFI boundaries, bridging async concepts, and managing memory safely. He explains the limitations of native extensions and how emerging tech like WebAssembly can streamline cross-language architecture. By Spencer Judge

How to Decompose a Legacy Java Monolith Without Disrupting Business Operations The Java monolithic applications have been supporting businesses for years. In these applications, the entire business logic, presentation layer, and data access layer are bundled into a single unit. These architectures are functional but hard to scale, maintain, and improve due to changing business needs. An expert Java app development company helps growing organizations in addressing this issue through Java modernization services. Instead of developing a whole software application from scratch, firms can transform their software in stages with the right boundaries. The biggest challenge here is to determine where to make those cuts in a bundle. Poorly chosen service boundaries create operational complexity issues and long-term maintenance problems. Understanding how to identify seams in the monolith application helps in achieving modernization successfully. Let's take a look at what contributes to the success of monolith decomposing and how organizations can approach it wisely. Why Organizations Are Modernizing Legacy Java Monoliths The legacy Java monolith applications were built during a time when monolithic architecture was common. They were optimized for easy deployment and centralized management. But today, businesses require flexibility. This is due to challenges such as Slow release cycles Increasing maintenance costs Limited scalability Complex dependency management Difficult onboarding new developers Growing technical debt These issues have increased the demand for software architecture modernization in business sectors. Modern architecture gives the following advantages to the teams: Deploy features independently Scale services individually Improve system resilience Accelerate development cycles Support cloud-native environments The objective of architecture modernization is to create a technical foundation that supports future business growth. Understanding business goals of

Grab's security team built Palana, a Kubernetes-native secure execution platform, to run autonomous AI agents safely. Unlike deterministic software, model-driven agents exhibit unpredictable tool-use, code-writing, and prompt injection risks. Palana contains these threats at the infrastructure level using isolated namespaces, out-of-process control planes, and proxy-mediated, Vault-backed secrets. By Patrick Farry

Thariq Shihipar, engineering lead for the Claude Code team, recently published a blog post (Using Claude Code: The Unreasonable Effectiveness of HTML) arguing that HTML, with its richer visualizations, color, and interactivity, improves the productivity of human-agent communication in many settings, especially when compared to default Markdown outputs. By Bruno Couriol

Rethinking fake content in Symfony projects A prototype web page displaying pure placeholder content When building early UI prototypes or shaping design systems in Symfony, placeholder content becomes a constant companion. Lorem ipsum text. Dummy profile photos. Placeholder videos. Silent audio. Temporary avatars. Realistic fake user data. Every project needs them — and yet most setups rely on a patchwork of libraries, links and hardcoded values. Omnia Ipsum aims to fix that by giving Symfony developers a single, elegant toolkit for placeholder content of all kinds. In this article, I will walk you through the motivation behind the project, the conceptual patterns it follows, and its most advanced features — all designed to make your prototyping workflow faster, cleaner and more maintainable. Motivation: Why a placeholder library? Most Symfony projects start the same way: You add lorem ipsum text manually into Twig templates. You grab placeholder images from an external service. You generate avatars using yet another site. You paste in temporary YouTube or stock video URLs. You install Faker separately whenever realistic data is needed. The result is inconsistent, fragmented and difficult to maintain. And even worse: placeholder content often leaks into production unless guarded carefully. The idea behind Omnia Ipsum was simple: “If your UI needs placeholder content, it should come from one place — predictable, configurable, and accessible directly from Twig.” This cuts down on boilerplate, cognitive overhead, and the "temporary chaos" of early-stage templates. Quick Start Prerequisite Go to github.com/symfinity/recipes and follow the instructions to add the required recipe repository. Installation composer require --dev symfinity/omnia-ipsum Usage Use the Twig functions immediately: <img src= " {{ omnia_image ( 600 , 400 ) }} " alt= "Placeholder" > <img src= " {{ omnia_avatar ( 'John Doe' , 100 ) }} " alt= "Avatar" > <video src= " {{ omnia_video ( 1920 , 1080 ) }}

The Problem Typography should be one of the simplest parts of a project. In reality, it often ends up scattered across multiple layers: Bootstrap: $font-family-base variables Tailwind: JavaScript configuration TypeScript: type definitions Design systems: W3C Design Tokens The same font information gets copied and maintained in several places. Every update means touching multiple files, hoping everything stays in sync. It's repetitive, error-prone, and easy to get wrong. So I built Font Manager. Define your fonts once and export them in whatever format your project needs — CSS, Bootstrap variables, Tailwind configuration, TypeScript definitions, design tokens, and more. The Solution A simple Twig function: {{ font_manager ( 'Ubuntu' , '400 700' ) }} Configuration: symfinity_font_manager : export : formats : - scss_bootstrap - tailwind_config - typescript_definitions One lock command: php bin/console fonts:lock Every format, automatically generated. Perfectly synced. Bootstrap Example Before: // Manually copy font name $font-family-base : 'Ubuntu' , sans-serif ; // ❌ Duplication @import 'bootstrap/scss/bootstrap' ; After: symfinity_font_manager : export : formats : [ scss_bootstrap ] php bin/console fonts:lock // app.scss @import './assets/styles/fonts-bootstrap' ; // ← Auto-generated @import 'bootstrap/scss/bootstrap' ; Bootstrap uses your fonts automatically. No manual mapping. No duplication. Tailwind Example symfinity_font_manager : export : formats : [ tailwind_config ] // tailwind.config.js const fonts = require ( ' ./assets/fonts-tailwind.config.js ' ); // ← Auto-generated module . exports = { theme : { extend : { fontFamily : fonts . fontFamily } } }; <p class= "font-sans" > Your custom font, via Tailwind. </p> TypeScript Example symfinity_font_manager : export : formats : [ typescript_definitions ] import { fonts , type FontFamily } from ' ./assets/fonts ' ; applyFont ( element , ' sans ' ); // ✓ Valid applyFont ( element , ' invalid ' ); // ✗ TypeScript erro

AI has made it easier to produce working software. That part is real. It can write code, draft documents, research a topic, scaffold a prototype, and debug a problem faster than most teams can finish writing a decent ticket. But faster building doesn't automatically mean better product decisions. That's the part I keep coming back to. For decades, software teams optimized around delivery. Requirements, design, development, QA, release. Waterfall softened into Agile. Agile grew into DevOps. The practices changed, but the assumption underneath stayed pretty stable: building software is expensive, so plan carefully before you start. That made sense because, for a long time, it was true. Now that assumption is breaking. AI is doing to software what calculators did to accounting. It isn't eliminating the job. It's moving the job up a level. The syntax, boilerplate, first draft, and some of the debugging are getting offloaded. The work doesn't disappear. The bottleneck moves. Learning is still expensive Here's what didn't get cheaper: understanding what people actually need getting stakeholders aligned deciding what evidence would change your mind putting something real in front of users reading the signal without fooling yourself The old question was: Can we build it fast enough? The new question is: Do we understand the problem well enough? That sounds like a small shift, but it changes the work. It changes what strong engineers spend time on. It changes what product people need from engineering. It changes how teams should define "done." If the code ships but nobody learns anything, did the team actually move forward? Sometimes yes. Often no. Users don't know until they can touch it People are not great at specifying requirements up front. Not because they're difficult. Because they're human. Most of us don't know how we feel about something until we can react to a version of it. A mockup. A prototype. A rough slice. A real workflow with sharp edges. So the fastest pat

Lucide has released version 1.0 of its open-source icon toolkit, marking its first stable major release. The update features over 1,600 icons and removes trademarked brand icons due to legal and design concerns. Significant performance improvements have also been made, reducing package size and adding context providers for various frameworks. Users upgrading should be aware of breaking changes. By Daniel Curtis