标签：#work

This is the Engineering Culture Trends Report for 2026. Featuring a panel of QCon speakers and InfoQ contributors, they discussed AI adoption maturity and risk, the transformation of engineering team structures and roles, and the human dimensions of software development that must not be lost in 2026. By Ben Linders, Rafiq Gemmail, Craig Smith, Vanessa Formicola, Shawna Martell, Phillip Mortimer, Yinka Omole

This report summarizes how the InfoQ Culture and Methods editorial team sees the ongoing and emergent trends in the culture and methods space in 2026. By Shane Hastie, Ben Linders, Vanessa Formicola, Shawna Martell, Rafiq Gemmail, Craig Smith, Phillip Mortimer, Yinka Omole

The Scenario Every Developer Recognizes It is mid-2026, and you have a feature to ship. You open ChatGPT or Claude, type something like "build me a function that parses webhook payloads and routes them to the right handler," and wait. The model returns something plausible. You paste it in, run it, and it almost works. So you prompt again: "fix the edge case where the payload is missing the event key." Another round. Then another. Forty-five minutes later, you have code that functions, but you also have a conversation thread that looks like a debugging session rather than a build session. You never actually described what you were building. You just started building it. This is the default mode for most developers using AI coding assistants in 2026, and it is expensive. According to McKinsey's State of AI in 2024 report ( source ), organizations that adopt structured design and planning approaches before implementing AI tools report higher success rates and better integration outcomes compared to those using ad-hoc implementation strategies. The pattern holds at the individual developer level too. Jumping straight into prompting skips the step that makes prompting useful: knowing precisely what you want before you ask for it. The fix is not a better model. It is a different sequence. What Design-First Actually Means in Practice Design-first means producing a written artifact that describes your system before you write a single prompt asking an AI to build it. Not a full technical document. A tight, structured description of inputs, outputs, constraints, and edge cases. Think of it as the brief you would hand to a contractor before they start work. The contractor analogy is useful because it reframes the relationship: you are not collaborating with the model in real time, you are commissioning it with a clear scope. Here is what that looks like concretely. Instead of opening Google Gemini and typing "help me build a webhook router," you spend ten minutes writing this

A reverse proxy sits between clients and one or more upstream services. Instead of clients communicating directly with your application, every request first passes through the proxy before being forwarded to an upstream. Mature reverse proxies such as Nginx, Envoy, and HAProxy do much more than simply forward requests. They perform tasks such as load balancing, health checks, rate limiting, metrics collection, and much more. I wanted to better understand how some of these concepts work in practice, so I built a reverse proxy in Go. Along the way I implemented request forwarding, multiple load-balancing strategies, health checks, circuit breakers, rate limiting, request logging, metrics, and graceful shutdown. If you'd like to explore Proxify as we go, you can find the project here: https://github.com/Rahmannugar/proxify Table of Contents Request Lifecycle Project Structure Configuration Reverse Proxy Load Balancing Health Checks Circuit Breakers Middleware Graceful Shutdown Running Proxify with Docker 1. Request Lifecycle At a high level, every request follows the same path through the reverse proxy. A client sends an HTTP request to Proxify instead of communicating directly with an upstream service. Proxify receives the request, selects a healthy upstream using the configured load-balancing strategy, forwards the request, waits for the upstream's response, and finally returns that response to the client. Client │ ▼ +---------------+ | Proxify | +---------------+ │ Select Healthy Upstream │ ┌───────┴────────┐ ▼ ▼ Upstream A Upstream B │ ▼ HTTP Response │ ▼ Client Although the overall flow is straightforward, every step introduces additional considerations. Which upstream should receive the next request? What happens when an upstream becomes unhealthy? How can requests be distributed efficiently across multiple upstreams? How do we prevent a failing upstream from continuing to receive traffic? The remainder of this article answers those questions by gradually buildin

I needed a VPS to run CyberPanel. Simple enough: 1 vCPU, 1 GB RAM, 10 GB SSD, IPv6 only. CyberPanel...

HubSpot has redesigned its Just-In-Time Access (JITA) authorization system using a rule engine architecture. The system evaluates access requests through independent rules organized as a directed acyclic graph, adding structured decision metadata, rule-level observability, and governance workflows to replace complex conditional authorization logic. By Leela Kumili

I hit Ctrl-F more than any other key combination on this machine. It runs a shell function called fts — "find tmux session," which is not a good name but it's four years too late to change it. I press it, a fuzzy finder opens listing every project directory I have, I type a few characters, and I'm sitting in a tmux session for that project with the panes already laid out. If the session already existed, I'm back in it exactly where I left off. If what I typed doesn't exist yet, it offers to create it. Somebody watched me do this over a screen share recently and asked what was going on. So: here's the whole thing, the four tools it's built on, and a breakdown of every part that isn't obvious. What you'll end up with: One keystroke from anywhere to any project Fuzzy search across every repo you own, with a live directory tree preview Type a name that doesn't exist → it offers to scaffold and place it Never accidentally start a second tmux session for a project you already have open The same window/pane layout in every project, every time The problem it solves Before this, starting work looked like: cd ~/repo/work/some-project-i-half-remember-the-name-of tmux new-session -s some-project # split some panes, badly, slightly differently each time Three or four commands, one of which needed me to remember a path. None of it hard. All of it friction at exactly the wrong moment — the moment you've decided to start something, which is the moment you're most likely to get distracted instead. I'd also collected tmux sessions named 0 , 1 , 2 and some-project-2 , because I kept starting new ones instead of attaching to the one already running. So the goal wasn't really speed. It was making the right thing the automatic thing. Prerequisites Four tools plus zsh. All four are worth having on their own, and three of them are things you'll reach for daily once installed. Tool Version I'm on What it does here tmux 3.6a The terminal multiplexer. Holds the sessions, windows and panes. fz

AWS Builder Center now offers free, time-limited sandbox environments for workshops, so developers no longer need to use their own AWS account and credit card or worry about unexpected charges. This has been a long-standing request from the community and removes one of the biggest friction points for practitioners learning new AWS technologies. By Renato Losio

Por que usar o Cloudflare em vez do DNS padrão do seu registrador Escrevi esse texto depois de um perrengue aqui na empresa onde trabalho. Precisei registrar uns subdomínios, entrei no painel da Cloudflare esperando achar os registros lá e não tinha nada, fui atrás do time para entender onde aquilo estava apontando e a resposta foi que tudo passava direto pelo provedor de domínio. Quando você registra um domínio na GoDaddy, Namecheap, Registro.br ou qualquer outro provedor de domínio, ele já vem com um par de nameservers configurados por padrão. Funciona, mas "funcionar" e "ser a melhor opção para produção" são coisas diferentes, e trocar esses nameservers pelos da Cloudflare é uma das mudanças de maior custo-benefício que dá para fazer em um projeto. O que muda ao trocar os nameservers Um provedor de domínio só precisa resolver DNS: publicar seus registros A, CNAME, MX e afins, e responder consultas. A infraestrutura por trás disso varia muito de provedor para provedor e raramente é otimizada para latência global ou resiliência a ataques, porque não é o produto principal deles. A Cloudflare constrói a rede em torno de DNS, CDN e mitigação de DDoS como núcleo do negócio, e isso aparece em números concretos: a rede anycast cobre mais de 330 cidades, então uma consulta DNS ou uma requisição HTTP é respondida pelo ponto de presença fisicamente mais próximo do usuário, não por um servidor central do outro lado do mundo. Hoje a Cloudflare responde por algo em torno de 23% de todos os sites da internet. Vantagens técnicas O anycast é a base de tudo. Não existe "o servidor DNS" que pode cair: se um ponto de presença fica indisponível, o tráfego é roteado automaticamente para o mais próximo, o que reduz latência de resolução e risco de indisponibilidade. A mesma arquitetura, combinada a TTLs baixos, também acelera a propagação de mudanças: um registro DNS alterado costuma valer em minutos, enquanto em boa parte dos provedores de domínio tradicionais não é incomum esperar ho

AI is an amplifier; strategic focus on the organizational system brings the greatest returns. DORA's 2025 research on AI in software development provides team profiles and success capabilities that can be used to put the research into practice. By Ben Linders

I was already a big fan of SwitchBot's big circulator fan I recently reviewed, and now we're getting the SwitchBot Battery Circulator Fan 2 Pro. Priced at $119.99, it ditches the height-adjustable stand but increases battery life, throw distance, and wind speed while adding native Matter-over-Wi-Fi, allowing it to join your smart home without needing […]

Most VPN troubleshooting goes wrong in the same predictable way: three things get changed at once, and whatever happens next, nothing has been learned. The alternative is boring and effective — check one layer at a time, in an order that rules things out, and write down what each layer shows. One boundary before starting: troubleshooting means finding where a problem lives, not working against anyone's rules. On a network you don't control, or a device your organization manages, the policies in place stay in place. If a managed device is part of the picture, your organization's IT function is part of the troubleshooting — and switching off device security tooling is never a troubleshooting step. 1. Device basics first Start embarrassingly simple, because this layer resolves more than anyone likes to admit. Restart the VPN client. If that changes nothing, restart the device. Confirm that the operating system and the client are updated. An update that has been pending for weeks is a suspect, not background noise. Note whether anything changed around the time the problem started: an update, a new app, different settings, a different location. 2. Does the internet work without the VPN? Disconnect the VPN entirely and test ordinary browsing. If the connection is broken without the VPN, this isn't a VPN problem yet. Solve the underlying connection first, because nothing downstream is testable until this layer works. If the internet is fine without the VPN and wrong with it, you have genuinely narrowed something down. Write that down. 3. Client state: connected to what, exactly? Open the client and look, rather than assume. Is it actually connected, or still trying? Is the right profile selected — the current one, not an older entry left over from a previous setup? Disconnect and reconnect once, deliberately, and watch what the client reports. If multiple profiles have accumulated in the client, that is a finding in itself. Stale entries are a classic source of "it connect

When you open a website, send a message, or watch a YouTube video, many technologies work together in the background. As a beginner in DevOps, understanding these basic networking concepts will help you understand how applications communicate over the internet. **What Is a Protocol? A protocol is a set of rules that devices follow when communicating with each other. Think about two people having a conversation. For communication to be successful, both people must speak the same language and follow simple rules, like taking turns to talk and listening before responding. Computers work the same way. They use protocols to know how to send, receive, and understand information. Without protocols, computers would not be able to communicate with one another. **2. What Is Packet Switching? **Imagine you want to send a large book to a friend. Instead of sending the entire book in one huge package, you divide it into many smaller packages. Each package travels separately and, when they all arrive, your friend puts them back together in the correct order. This is exactly how the internet works. When you visit a website, your data is broken into small pieces called packets. Each packet travels across the internet and is reassembled when it reaches its destination. This process is called packet switching, and it makes internet communication faster and more reliable. **3. What Is an IP Address? **Every house has a unique address that helps delivery drivers know where to deliver packages. Similarly, every device connected to the internet has a unique Internet Protocol (IP) address. An IP address helps the internet know exactly where information should be sent. Without an IP address, websites, computers, and phones would not know where to send or receive data. **4. What Is TCP/IP? **Breaking data into packets is not enough. The packets must also arrive correctly. This is where TCP/IP (Transmission Control Protocol/Internet Protocol) comes in. IP finds the correct destination for ea

Introduction Small teams don't need GitFlow or other complex branching models. They need a workflow that's easy to understand, quick to execute, and minimizes merge headaches. Here's a practical workflow I've used with teams of 2-8 developers. The Core Idea: Main and Short-Lived Feature Branches We keep it simple with one long-lived branch ( main ) and short-lived feature branches. Every change starts from main and is merged back as soon as it's ready. git checkout main git pull git checkout -b feature/my-feature Branch Naming Convention Use a consistent prefix to keep branches organized: feature/ for new features fix/ for bug fixes chore/ for maintenance tasks Example: feature/user-authentication , fix/login-error The Workflow Step by Step 1. Start from an Up-to-Date Main Before creating a branch, make sure your local main is up to date: git checkout main git pull --rebase 2. Create a Feature Branch git checkout -b feature/awesome-feature 3. Make Small, Frequent Commits Commit early and often. Each commit should represent a logical unit of work. git add . git commit -m "Add user model with email validation" 4. Push and Open a Pull Request Even if the branch isn't finished, pushing early allows others to see your progress. git push -u origin feature/awesome-feature Then open a PR against main . Keep PRs small (under 400 lines if possible). 5. Keep Your Branch Updated If main moves forward, rebase your branch to avoid conflicts later: git checkout feature/awesome-feature git rebase main # resolve conflicts if any git push --force-with-lease --force-with-lease is safer than --force because it prevents overwriting others' work. 6. Code Review At least one other team member reviews the PR. Look for logic errors, readability, and test coverage. 7. Merge via Squash Merge When the PR is approved, use squash merge to keep main history clean: git checkout main git pull git merge --squash feature/awesome-feature git commit -m "Add awesome feature" Or use the GitHub/GitLab squ

Originally published at https://blog.pathvector.dev/protocol-in-code-bgp-07/ — part of the free Protocol Lab series. This post is part of Protocol in Code , a free series that reads network protocols as logic — inputs, state, and branches — rather than as configuration examples. Every module points at one real Python file and asks you to read it the way you'd read any other code: what comes in, what mutates, where does control leave early. The source lives at github.com/pathvector-studio/protocol-in-code . Note: If you're newer to this and want to run things before you read things, start with Protocol Lab — the hands-on companion series that builds the muscle memory this one assumes. The question How does local import policy change or reject a path before best-path selection runs? That's the whole module in one line, and it hides a claim worth being suspicious of. Best-path selection in BGP is the famous part — the ordered tiebreaker list everyone half-remembers: highest weight, highest local_pref , shortest AS path, and so on. It's easy to treat that comparison as the decision point, as if routes arrive from peers and get ranked. They don't arrive and get ranked. They arrive, get rewritten , and then get ranked. Import policy is a function that runs between the wire and the comparison, and it has two powers: it can change the values the comparison reads, and it can make the candidate not exist at all. Which means the interesting question isn't "who won best-path" but "what did best-path actually receive." Read the code The file is src/protocol_in_code/bgp/import_policy.py . It's short enough to hold in your head all at once, which is the point — the shape is the lesson. Start with the policy object: @dataclass ( frozen = True ) class ImportPolicy : local_pref_override : int | None = None weight : int = 0 reject_next_hops : tuple [ str , ...] = () reject_invalid : bool = False Four knobs, and notice they're not four of the same thing. Two of them ( local_pref_overri

Framework's latest modular laptop trades one set of problems for another.

The same parser, four times Over the last year I kept running into the same shape of problem: A docs site generator that wanted Markdown chapters turned into navigation JSON. A RAG ingestion script where each Markdown file needed to become a list of text chunks plus its frontmatter metadata. An n8n flow that took Markdown emails and extracted only the tasklists. A static-site backend that accepted user Markdown and needed to validate structure before persisting. Each one is small on its own. But every time I reached for a different library — remark here, gray-matter there, marked once, a hand-rolled regex once too many — and every time one of them broke on the same edge cases: Nested GFM tasklists where the checked state was silently lost YAML frontmatter that included quoted booleans (parsed as strings, not booleans) Tables whose headers contained spaces (regex parsers treated them as one key) Code blocks containing Markdown — re-parsed as Markdown instead of fenced code So I built one endpoint that does it once, properly. What it returns POST /v1/parse takes a Markdown body ( text/markdown ) or a JSON envelope ( application/json ) and returns one stable JSON shape: { "success" : true , "data" : { "title" : "Project Alpha" , "frontmatter" : { "title" : "Project Alpha" , "status" : "shipping" }, "headings" : [ { "level" : 1 , "text" : "Project Alpha" , "id" : "project-alpha" } ], "sections" : [ { "heading" : { ... }, "children" : [ ... ], "content" : [ ... ] } ], "lists" : [ { "ordered" : false , "items" : [ "ship MVP" , "write README" ] } ], "tasklists" : [ { "items" : [ { "text" : "ship MVP" , "checked" : true } ] } ], "tables" : [ { "headers" : [ "Module" , "Status" ], "rows" : [{ "Module" : "API" , "Status" : "Done" }] } ], "codeBlocks" :[ { "lang" : "js" , "value" : "..." } ], "links" : [ { "text" : "..." , "url" : "https://..." } ], "paragraphs" :[ "..." ], "ast" : null } } The sections tree is the part I care most about. It's not just a flat list of headings

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

Originally published at https://blog.pathvector.dev/protocol-in-code-bgp-05/ — part of the free Protocol Lab series. This post is part of Protocol in Code , a free series that reads network protocols not as configuration examples but as logic with inputs, state, and branches — actual code you can read and run. The whole series lives here: github.com/pathvector-studio/protocol-in-code . If you're newer to this material and want a more hands-on, guided on-ramp first, start with the companion Protocol Lab series and come back. Today's module is from the BGP track, Session 05. The source file is src/protocol_in_code/bgp/policy.py , and it builds directly on the origin-validation logic from Session 04. The question to keep in your head Here's the one thing to turn over as you read: What happens after origin validation returns valid , invalid , or not_found — and why does the result still need routing policy before anything happens to the route? There's a piece of folk knowledge that says "RPKI invalid means the router rejects the route." It's the kind of statement that sounds like a rule of the protocol. It isn't. It's one possible policy decision built on top of a validation result . The whole point of this session is to separate those two things in your head, and the code makes the seam impossible to miss. Two layers, not one Validation answers a factual question: does this route's origin AS match what the ROAs say it should be? That's Session 04's job, and its output is a ValidationState . Policy answers a completely different question: given that fact, what do we do ? Drop the route? Keep it but make it less preferred? Accept it normally? That's a local decision — different operators configure it differently, and the same validation result can lead to different actions on different routers. The file models the second layer with three small pieces. First, the set of actions the router can take: class PolicyAction ( str , Enum ): ACCEPT = " accept " DEPRIORITIZE = " de

Originally published at https://blog.pathvector.dev/protocol-in-code-bgp-04/ — part of the free Protocol Lab series. This post is part of Protocol in Code , a free series that reads network protocols as logic — inputs, state, and branches — rather than as configuration examples. The full source, walkthroughs, and site lessons live in the repo: pathvector-studio/protocol-in-code . If you're newer to this and want to build the protocols hands-on before dissecting them, start with the companion Protocol Lab series instead. Today we're on the BGP track, session 04, reading a single small file: src/protocol_in_code/bgp/validation.py . It's about 40 lines. The idea inside it is one that trips up a lot of engineers who've been running BGP for years. The question to keep in your head BGP's best path selection already ran. It compared local preference, AS_PATH length, MED, and the rest of the tiebreak ladder, and it picked a winner. So here's the question this module wants you turning over: Core question: How do we decide whether the origin AS is authorized — even after BGP has already selected this route as the best path? The trap is the sentence "it was the best path, so it must be fine." Best and authorized are two different words, and in the code they are two different decisions made by two different pieces of data. Best path selection asks which of these routes do I prefer? Origin validation asks is the AS at the end of this path actually allowed to originate this prefix? A route can win selection and still be a hijack. RPKI origin validation is the mechanism that answers the second question, and the file we're reading is a toy model of exactly that. Two kinds of information The first thing to read isn't a function — it's the two dataclasses, because the whole session is really about keeping them apart. @dataclass ( frozen = True ) class BGPRoute : prefix : str origin_as : int @dataclass ( frozen = True ) class VRP : prefix : str max_length : int origin_as : int BGPRout