标签：#dev

A conference sold out three separate ticket tiers before the doors even opened. Not "almost sold out." Sold out — Leadership track, gone. Workshops, gone. Late bird tickets, gone. The organizers stopped counting around 6,000 attendees and said they'd officially call it once they crossed 7,000. That's the AI Engineer World's Fair in 2026, and if you've spent any time building with LLMs over the last three years, you already know the name even if you've never been able to get a ticket. I want to walk you through what's actually happening on the ground this week at Moscone West in San Francisco — not the marketing copy, but the track list, the speaker lineup, and the quiet signals buried in the schedule that tell you where AI engineering is actually heading next. Table of Contents What is AI Engineer World's Fair? Why It Matters What Makes It Different Key Technologies AI Agents LLM Engineering MCP RAG Fine-tuning AI Infrastructure Workshops Networking Startups Enterprise AI Major Takeaways Future of AI Engineering Final Thoughts What is AI Engineer World's Fair? AI Engineer World's Fair is the flagship conference run by AI Engineer, the company behind a whole circuit of events — the AI Engineer Summit, Code Summit, and standalone editions in London, New York, Paris, Miami, Singapore, Shanghai, and Melbourne. The World's Fair is the biggest of them all: a four-day event with 29 tracks, 300 speakers, 100 expo partners, and more than 6,000 AI engineers, founders, and VPs of AI in attendance. The 2026 edition runs from Monday June 29 through Thursday July 2, with a Sunday evening orientation night tacked on for first-timers. It's held at Moscone West, 747 Howard Street, in San Francisco. This is the fourth year the event has anchored in San Francisco, and the organizers have leaned into that — discounted hotel blocks at the Marriott Marquis, Parc 55, and InterContinental, all walking distance from the venue. The person behind all of it is Shawn "swyx" Wang. He's the cofou

A customer texted me a screenshot last month. It was my own landing page, open on their Pixel. The headline — "Financial infrastructure to grow your revenue" — was clipped at "...grow your reven". The signup button below it was gray-on-slightly-lighter-gray, basically unreadable. And the hero image? A broken-image icon. Here's the part that stung: every check I had was green. Lighthouse: 98. My Playwright tests: passing. CI: all checkmarks. I had shipped that page an hour earlier feeling good about it. None of my tooling caught any of it. I want to walk through why , because I think a lot of us have this blind spot, and then I'll tell you what I did about it. CI tests the DOM. It does not test what a human sees. This is the core issue. My tests asserted things like "the signup button exists" and "the form has an email input." All true. The button was in the DOM . It just rendered unreadable on a 412px-wide screen with the system in light mode. Lighthouse runs one viewport (usually a throttled Moto G4 emulation) and scores performance/SEO/a11y heuristically . It does not look at your page across the actual range of devices your visitors use and say "this headline is physically clipped on a Pixel 8." And my "responsive testing"? I was dragging the Chrome devtools responsive bar to two breakpoints — 375 and 1440 — eyeballing it, and moving on. That's not testing. That's hoping. The three bugs that slipped through Let me get specific, because the category of each bug is instructive. 1. The clipped headline — a measurable, deterministic bug .hero-title { white-space : nowrap ; /* the culprit */ width : 100% ; overflow : hidden ; } On desktop, the headline fit. On a narrow viewport, white-space: nowrap refused to wrap, overflow: hidden clipped the overflow, and the last word vanished. The brutal thing: this is trivially detectable in code . The element's scrollWidth was greater than its clientWidth . That's a one-line check: const clipped = el . scrollWidth > el . clientW

The Quest Begins (The "Why") Honestly, I was tired of playing “guess the state” every time I spun up a new environment. One day I clicked “Apply” in the AWS console, watched a handful of EC2 instances, S3 buckets, and IAM roles appear, and then realized I had no idea how to recreate that exact setup six months later when the team needed a staging copy. It felt like trying to rebuild the Death Star from memory after a single glance at the blueprints—frustrating, error‑prone, and definitely not the heroic saga I signed up for. That moment was my “aha!”: I needed a repeatable, version‑controlled way to describe infrastructure. Enter Infrastructure as Code (IaC). I’d heard the buzz, but the real question was which tool to wield—Terraform or CloudFormation? Both promised declarative provisioning, but they spoke different dialects. I decided to embark on a quest to learn both, slay the configuration drift dragon, and come out with a reusable spellbook I could share with anyone on the team. The Revelation (The Insight) The breakthrough came when I stopped thinking of IaC as “just another config file” and started seeing it as a storytelling language . Every resource block is a character, every variable a plot twist, and the state file the ever‑growing script that remembers what happened in previous chapters. When I wrote my first Terraform module, it felt like Neo realizing he could bend the spoon—suddenly the impossible became trivial. I could define a VPC, subnets, security groups, and an RDS instance in a few dozen lines, run terraform init , terraform plan , and watch the plan show exactly what would change before any resources touched the cloud. No more surprise “you created a public‑facing DB!” moments. CloudFormation, on the other hand, felt like the loyal sidekick that already lives in the AWS universe. Its JSON/YAML templates are native to AWS, so there’s no extra provider to install, and drift detection is built‑in. The trade‑off? A bit more verbosity and a steepe

Last week we introduced Upsun Dispatch™: a platform for the agentic software development lifecycle, where workflow is the primitive , not the agent. Today, prerelease is open. Starting July 1, a founding cohort of design partners gets early access. This is not a traditional beta. We are looking for engineering teams already running AI workflows and hitting the limits of what individual tools can do: teams who want to help shape what Upsun Dispatch becomes, not just use what we ship. Design partners get direct access to the core team, real input on the roadmap, and charter terms that reflect a genuine partnership rather than a vendor relationship. Apply at upsun.com/dispatch . Read the full announcement: Upsun Dispatch™ is now open for prerelease Starting July 1, 2026, Upsun Dispatch™ is open to a founding cohort of design partners. Here is what joining early means and how to apply upsun.com

Let's be honest—traditional A/B testing is broken. If you've ever implemented client-side testing, you know the drill. Your users load the page, wait for JavaScript to execute, and then—flicker—the content changes. It's jarring. It hurts your Core Web Vitals. And worst of all, your experiments might be measuring user frustration instead of genuine engagement. But what if you could run A/B tests with zero flicker? What if you could modify your HTML before it even reaches the browser? That's exactly what Cloudflare Workers make possible . The Server-Side Advantage A/B testing at the edge means making decisions about which variant a user sees before any HTML is sent to their browser . Instead of: Load the page Execute JavaScript Flicker Apply the variant Track the result You get: Decision made at the edge Correct HTML streamed immediately Zero flicker Better performance Companies like Ninetailed are already using Cloudflare Workers to achieve 2-3x cost savings compared to traditional serverless platforms, all while delivering personalized experiences with minimal latency . How It Actually Works The concept is surprisingly elegant. Your Cloudflare Worker intercepts incoming requests, checks for a cookie to maintain user consistency, and routes users to the appropriate variant . Here's a simplified version that's production-ready: javascript const NAME = "myExampleWorkersABTest"; export default { async fetch(req) { const url = new URL(req.url); // Determine which group this user is in const cookie = req.headers.get("cookie"); if (cookie && cookie.includes(`${NAME}=control`)) { url.pathname = "/control" + url.pathname; } else if (cookie && cookie.includes(`${NAME}=test`)) { url.pathname = "/test" + url.pathname; } else { // New user—randomly assign them (50/50 split) const group = Math.random() < 0.5 ? "test" : "control"; url.pathname = `/${group}` + url.pathname; // Fetch and modify the response to set a cookie let res = await fetch(url); res = new Response(res.body, res

Recentemente percebi uma coisa meio curiosa: eu simplesmente tinha um problema ao consumir o conteúdo do 4noobs do jeito que ele é organizado hoje. Não porque a organização seja ruim — muito pelo contrário. Acho que a comunidade fez um trabalho incrível organizando o projeto. O ponto é que eu percebi que meu jeito de estudar é diferente: tenho muito mais facilidade quando consigo seguir listas, trilhas ou um caminho de aprendizado mais visual. Foi aí que pensei: "Se esse problema existe para mim, talvez exista para mais alguém. E se, de quebra, eu aproveitar isso para praticar consumo de APIs?" Foi assim que nasceu a Central 4noobs . A proposta era simples: consumir todo o conteúdo disponível no GitHub do 4noobs e apresentá-lo de uma forma que fizesse mais sentido para o meu jeito de estudar, organizando os materiais em listas e trilhas de aprendizado. A ideia nunca foi substituir a organização do projeto original, mas oferecer uma forma diferente de navegar pelo mesmo conteúdo. Essa era a ideia inicial... mas, como acontece com praticamente todo projeto pessoal, ela foi crescendo conforme o desenvolvimento avançava. Mas ainda é uma alternativa . Tenham em mente isso. :) O que aprendi durante o projeto O projeto foi desenvolvido utilizando Next.js , TypeScript , Drizzle ORM e Supabase como banco de dados (e hoje já não tenho tanta certeza se essa foi a escolha mais inteligente 😅). O maior aprendizado foi entender melhor como funciona o consumo de APIs. Antes eu entendia o conceito na teoria (com o próprio 4noobs , inclusive), mas foi durante o desenvolvimento da Central que realmente comecei a compreender como tudo se conecta. Depois desse projeto, passei a enxergar melhor como uma API é estruturada e, principalmente, como consumir seus dados sem simplesmente despejar tudo na tela. Outra parte interessante foi aprender a tratar os dados recebidos. Uma coisa é receber uma resposta gigantesca da API. Outra completamente diferente é filtrar apenas as informações que re

Sriram Madapusi Vasudevan discusses industry-converging patterns for securing autonomous AI agents in production. He explains the critical vulnerabilities hidden inside the ReAct loop across context, reasoning, and tool execution. He shares how to mitigate risks like memory poisoning and rogue tool execution using defense-in-depth strategies, LLM-as-a-judge critics, and MAESTRO threat modeling. By Sriram Madapusi Vasudevan

Yesterday, we kicked off our physical newspaper, The Daily Context, at the AI Engineer World’s Fair...

Hi, I’m David. I’m close enough to middle age that I have no interest in pretending I discovered the future of software development in a week. What I did do was spend one serious week building a small local app with AI assistance, while trying to keep the project understandable. That turned out to be harder, and more interesting, than I expected. The coding agent could move quickly. Sometimes very quickly. It could generate code, refactor, write boilerplate, and help move the project forward. But it could also widen scope, preserve the wrong assumption, “helpfully” redesign something I wanted to keep boring, or act on context that was never meant to become implementation work. The main lesson I took from that week was simple: AI-assisted development is not only a coding problem. It is a context management problem. So I started using a lightweight loop: Task Brief -> think through the problem Codex Contract -> give the coding agent a bounded instruction set Final Review -> test, inspect, patch, and update project memory The result was not perfect AI coding. The result was reviewable AI coding. That distinction felt important enough to write down. The three articles I published three companion articles from that first week. They are meant to stand on their own, but together they describe the workflow, the memory system, and the objections I think are worth taking seriously. 1. Vibe Coding Done Right This is the accessible starting point. It explains how I used a lightweight, spec-driven workflow as a solo developer working with ChatGPT, Codex, VS Code, PowerShell, and a local LLM through LM Studio. The point is not the exact stack. The point is the separation: one place for thinking, learning, and review; another place for bounded implementation; documentation as the memory that keeps the next task grounded. 2. Documentation as Project Memory in AI-Assisted Development This is the more technical case-study piece. The part that surprised me most was documentation. Not

When I first started programming, I thought the best developers had one superpower. They remembered everything. Every function. Every method. Every API. Every piece of syntax. So I spent hours trying to memorize things. JavaScript methods. SQL queries. Regex. CSS properties. I thought that would make me valuable. I was wrong. The Day Everything Changed One day I watched a senior developer solve a difficult production issue. They opened Google. They opened the documentation. They searched Stack Overflow. They experimented. They tested. They failed. Then they fixed it. That's when I realized something. They weren't valuable because they remembered everything. They were valuable because they knew how to solve problems. Google Doesn't Make You Less of a Developer For a long time I felt guilty every time I searched for something. "Real developers shouldn't need Google." That's what I believed. Then I realized... Even experienced engineers search for documentation every day. Not because they're bad. Because technology changes constantly. Nobody remembers every detail. Syntax Is Temporary Think about the last five years. How many frameworks have changed? How many libraries disappeared? How many APIs were deprecated? Technology moves fast. Problem-solving doesn't. If you know how to think... You can learn any syntax. Companies Don't Hire Human Compilers Nobody pays you because you know where to put a semicolon. Nobody promotes you because you memorized every React hook. Companies pay developers who can: understand problems communicate clearly debug effectively make good decisions work with people deliver reliable software Those skills don't disappear when a framework becomes outdated. The Questions That Matter Instead of asking: "Do I know this syntax?" I started asking: Can I understand the problem? Can I break it into smaller pieces? Can I explain my thinking? Can I find reliable information quickly? Can I learn something new when I need it? Those questions changed the wa

SokoFlow Build Log — Month 1 of 4 Last semester I set out on a new strategic plan to level up my software development skills through deliberate, project-based learning. That work produced one of the most ambitious things I've built so far: Sim-Pesa , a local-first transactional appliance that lets developers working in the M-Pesa ecosystem test and simulate STK Push workflows entirely on their own machines, without depending on the Daraja sandbox. I documented that build in 16 weekly posts, which you can find here . This semester, the focus shifts — from fintech foundations to cloud-native integration and real-world systems. The flagship project is SokoFlow , a conversational ERP for small Kenyan shopkeepers to track inventory and record sales entirely through WhatsApp chat. No app to download, no training session required — just natural language. Where Sim-Pesa lived in a controlled, predictable transactional world, SokoFlow steps into the mess of cloud-native reality: third-party API failures, webhook signature verification, the statelessness of HTTP, and container orchestration. The target audience shifts too — Kenyan SMEs operating on infrastructure that is often unreliable by design, not by exception. It's an ambitious project, but the goal was always to learn as much as possible from it. With the plan in place, I got to work. 1. The Vision of a Headless ERP The first real question I had to answer before writing a line of code: what does "headless" actually mean? Headless architecture decouples the frontend — the "head," or user interface — from the backend, the "body" that holds the data and business logic. A conventional ERP bundles both: backend plus a dashboard or UI on top. A headless ERP, by contrast, is just the engine. The brain. There's no built-in screen. So how do users interact with a system that has no interface of its own? SokoFlow doesn't actually care. It could be: WhatsApp SMS A web app A mobile app A voice assistant In this case, the "frontend

Every WordPress developer knows the feeling. A host emails: "PHP 7.4 reaches end of life — we're moving you to 8.x." Or you finally want the performance and security of PHP 8.4. You stage it, click upgrade, and… white screen. Somewhere in the 40 plugins and 3 themes on the site, something called a function PHP removed years ago — and now the whole site is down. The frustrating part: the broken code is almost never yours. It's buried in third-party plugins and themes you didn't write and can't easily read. So how do you find out what breaks before you upgrade, instead of after? This post walks through exactly that, using an open-source tool called Pressready . Why "just test it on staging" isn't enough Staging tells you that something broke, rarely what or where — and only for the code paths you happen to exercise. A fatal in an admin screen or a checkout edge case you didn't click won't surface until a real user hits it. You need something that reads all the code statically and reports every risky symbol, whether or not that path runs during your manual test. That's a job for static analysis across the whole stack. Two kinds of "breakage": PHP and WordPress Upgrades break sites along two axes, and a good audit covers both: The PHP axis — language features that get removed (e.g. create_function() is gone in PHP 8.0, each() in 8.0) or change behaviour between versions. The WordPress axis — core APIs that WordPress deprecates or removes from one release to the next. Pressready checks both in a single pass: it runs PHPCompatibility for the PHP axis and a custom PHP_CodeSniffer sniff — driven by a generated dataset of WordPress core deprecations — for the WordPress axis. Install it (pick whatever fits your setup) No Composer in the project? Use the standalone PHAR or Docker: # Standalone PHAR — single self-contained file, just needs PHP curl -L https://github.com/itzmekhokan/pressready/releases/latest/download/pressready.phar -o pressready.phar chmod +x pressready.phar #

There's a paradox nobody wants to say out loud: the same frameworks companies pick because they're "enterprise-ready," "scalable," and "industry standard" are, for an LLM writing code, a minefield. Angular , React with its whole ecosystem, Nx with its monorepos: these are powerful tools, built by humans to coordinate teams of humans on massive codebases. And for that purpose, they're often the right choice — if your primary constraint is coordinating hundreds of engineers over a decade, the conventions and tooling of an established framework earn their keep. But there's a second actor in the room now. When the one writing the code is an AI, the very traits that make these frameworks "robust" turn into pure friction. The argument I'm making isn't "Angular and React are obsolete." It's narrower: we've historically optimized software architecture for human cognition, and LLMs introduce a different cost model that may favor simpler, more deterministic architectures — at least in some domains. Let's break down why, in three points. 1. The Token Tax (and the Cognitive Bottleneck) An LLM doesn't "understand" code the way we do — it processes it token by token, and every token costs something: money, latency, and context window that could otherwise be spent reasoning about the actual problem. Try asking an AI to generate a simple input form in a typical Angular/Nx context. To do it "properly" it has to: create the component (separate .ts , .html , .css files) declare the @Component with all its metadata import and wire up the right modules possibly touch an NgModule or a standalone-components config navigate 4-5 folder levels inside a typical Nx structure ( apps/ , libs/ , feature-x/ , data-access/ , ui/ ...) All of this before writing a single line of actual logic. That's architectural complexity that, for a human, pays for itself over time thanks to tooling, autocomplete, and internalized conventions. For an LLM generating text sequentially, it's a tax paid on every singl

Microsoft has announced the limited public preview of Copilot Autofix for GitHub Advanced Security for Azure DevOps, extending AI-powered vulnerability remediation to teams using Azure Repos. By Craig Risi

TL;DR Anthropic recently published When AI Builds Itself, an essay explaining how AI is...

I had a lot of work to get through, and for once I didn't want to crawl through it one ticket at a...

Introduction I keep hearing the term loop engineering. It's all over my feed, every AI...

Remember when Artificial Intelligence (AI) felt like something from a science fiction movie? Well, it's not just for movies anymore! AI is here, and it's rapidly changing how businesses of all sizes operate. From making customers happier to solving tricky problems faster, AI is becoming a vital tool for success. But how exactly is AI making such a big difference? Many business owners wonder about the real-world uses of AI. That's why we've put together this comprehensive guide. We're going to explore 50 specific ways AI development is transforming modern businesses, helping them work smarter, grow faster, and serve their customers better. Get ready to see how AI isn't just a buzzword, but a powerful engine driving real change in the business world! Boosting Customer Service & Experience (CX) (1-10) AI is making customer interactions smoother, faster, and more personal. Instant Customer Support (Chatbots): AI-powered chatbots answer common questions 24/7, so customers get help right away. Personalized Recommendations: AI suggests products or services customers might like, based on their past choices, making shopping feel more personal. Faster Problem Solving: AI helps support agents quickly find solutions by sifting through information. Predicting Customer Needs: AI can guess what a customer might want or need before they even ask, allowing businesses to be proactive. Voice Assistants for Support: AI voice assistants can handle basic customer calls, freeing up human agents for more complex issues. Sentiment Analysis: AI understands how customers feel about a product or service by analyzing their feedback (reviews, social media posts). Automated Email Responses: AI can draft quick, helpful replies to common customer email inquiries. Targeted Customer Outreach: AI helps businesses send the right message to the right customer at the right time. Improved Loyalty Programs: AI personalizes rewards and offers, making customers feel more valued and increasing their loyalty.

Stop Writing the Same Laravel Boilerplate: Generate a Complete Module with One Artisan Command Every Laravel developer has experienced this. You start implementing a new feature and immediately create the same files you've created dozens of times before: Model Migration Repository Service Form Request API Resource Policy Filter Status Enum Feature Tests Unit Tests Swagger/OpenAPI annotations The process is repetitive, time-consuming, and easy to get wrong. The Problem While Laravel provides excellent generators, building a production-ready API module still requires running many Artisan commands and wiring everything together manually. For large projects following Repository and Service Layer architectures, this becomes even more repetitive. The Solution I built Laravel Base , an open-source package that generates an entire production-ready module from a single command. php artisan make:module Product The generated module includes: ✅ Model ✅ Migration ✅ Repository Pattern ✅ Service Layer ✅ Form Requests ✅ API Resources ✅ Filters & Pagination ✅ Policies ✅ Status Enums ✅ Swagger/OpenAPI annotations ✅ Feature Tests ✅ Unit Tests Modern Development Experience The package is actively maintained and includes: Laravel 10–13 support PHP 8.1–8.4 compatibility GitHub Actions CI PHPStan static analysis Laravel Pint code style Automated releases Repository automation Why I Built It After working on multiple Laravel projects, I noticed I was spending too much time generating the same project structure instead of focusing on business logic. I wanted a tool that lets developers start implementing features immediately rather than setting up folders and classes. Feedback Welcome Laravel Base is open source, and I'd love to hear your thoughts. GitHub Repository: https://github.com/MuhammedMSalama/LaravelBase Packagist: https://packagist.org/packages/muhammedsalama/laravel-base The package was recently featured by Laravel News, and I'm continuing to improve it based on community feedbac