标签：#software

When I wrote about shifting the engineering process left — spec sessions, autonomous agents, humans reviewing output rather than writing code — a question kept coming up. Where does the Product Owner fit in all of this? It’s the right question. And I think the answer is more interesting than “the PO disappears.” Let’s start with acceptance criteria. We invented them to bridge a gap. The team needed to know when something was done. The PO needed confidence that what got built matched the intent. Acceptance criteria were the contract between the two. But if the Spec Session is where intent gets defined — by the whole team, together, before the agent runs — that gap closes. What the team agreed on in the room is the definition of done. The spec is the acceptance criteria. You don’t need a separate validation step because the planning and the agreement happened at the same time. The tighter the loop, the less ceremony you need around it. There’s a caveat though. The spec is a necessary contract. It’s not a sufficient one. Simon Martinelli’s work on the AI Unified Process validates the spec-driven approach technically. But his model is about the artifact — requirements at the center, AI generating everything else from them. How the team actually builds shared understanding before the spec exists isn’t something it addresses. That’s not a criticism. It’s just a different question. A spec written after a real Spec Session — where the team worked through edge cases together, disagreed, got to resolution — is different from a spec written by one person and signed off asynchronously. Same artifact. Different quality of shared understanding. That distinction matters when the agent hits an edge case the spec didn’t anticipate. So what’s actually left for a dedicated PO? Two things. And they’re very different. The first is product thinking — challenging intent, representing user needs, asking why before the agent runs with something. That’s valuable. But it doesn’t require a ded

Hi everyone, I'm Marc, the founder of ClaimMate AI. I've been building an AI software engineering platform that helps developers generate code, explain existing code, debug issues, create tests, review code, and build applications from simple prompts or voice. I'm still in the early stages and would really appreciate honest feedback from other developers. Why I Built It I wanted one workspace where developers could chat with AI, generate code, debug problems, and iterate on ideas without constantly switching between multiple tools. I'd Love Your Feedback If you have a few minutes, I'd appreciate any thoughts on: Is the interface easy to understand? Which feature would you use most? What would stop you from using it regularly? What feature is missing? You can try it here: https://ClaimMateAI.pro I'm not looking for praise—I genuinely want constructive feedback that will help improve the product. Thanks for your time!

One of the biggest takeaways from Chapter 3 of AI Engineering was realizing that building an AI model is only part of the challenge. Figuring out 𝗵𝗼𝘄 𝘁𝗼 𝗲𝘃𝗮𝗹𝘂𝗮𝘁𝗲 𝗶𝘁 𝗳𝗮𝗶𝗿𝗹𝘆 𝗮𝗻𝗱 𝗮𝗰𝗰𝘂𝗿𝗮𝘁𝗲𝗹𝘆 can be just as difficult. With traditional software, it's usually easy to tell whether something works. If a calculation is wrong or a test fails, you know there's a bug. But AI doesn't always work that way. A model can generate multiple reasonable answers to the same question, making it much harder to determine which one is actually better. That made me think: 𝗛𝗼𝘄 𝗱𝗼 𝘄𝗲 𝗸𝗻𝗼𝘄 𝗶𝗳 𝗮𝗻 𝗔𝗜 𝗺𝗼𝗱𝗲𝗹 𝗶𝘀 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗶𝗺𝗽𝗿𝗼𝘃𝗶𝗻𝗴? 𝗕𝗲𝗻𝗰𝗵𝗺𝗮𝗿𝗸𝘀 𝗡𝗲𝗲𝗱 𝘁𝗼 𝗞𝗲𝗲𝗽 𝗘𝘃𝗼𝗹𝘃𝗶𝗻𝗴 Reading this section made me realize how difficult it is for evaluation benchmarks to keep up with the pace of AI development. The chapter explains that GLUE (General Language Understanding Evaluation) was introduced in 2018 to measure how well language models performed on common natural language tasks. But within about a year, models had already become so good at it that researchers introduced SuperGLUE in 2019 as a more difficult benchmark. GLUE evaluates tasks such as: Question answering Sentiment analysis Sentence similarity Text classification The chapter also mentions newer benchmarks like: SuperGLUE MMLU (Massive Multitask Language Understanding) MMLU-Pro Each one was introduced because the previous benchmark was no longer challenging enough. What I found interesting is that a model getting a higher benchmark score doesn't always mean it understands language better. Sometimes it simply means the model has become very good at solving that particular benchmark. 𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗘𝗻𝘁𝗿𝗼𝗽𝘆 𝗮𝗻𝗱 𝗣𝗲𝗿𝗽𝗹𝗲𝘅𝗶𝘁𝘆 Another section I really enjoyed was the explanation of entropy and perplexity. The chapter explains entropy as a measure of how much information a token carries and how difficult it is to predict the next token in a sequence. Perplexity measures uncertainty. If a model is very uncertain about what comes next, its perplexity will be higher. If

Every beginner developer hits the same issue at some point. You learn a few basics, finish a tutorial, and then you have no idea what to build next. That gap can feel bigger than learning the code itself, because now the question is not “How do I write this?” but “What should I build at all?” This article is for that moment. I want to make it simple, practical, and useful, because project ideas do not need to be too advanced to be valuable. A good project is one that teaches you something, keeps you going, and gives you enough confidence to build the next one. Why project ideas are important There’s a common thing that I have noticed in most of the beginners, that is, watching too many tutorials. Tutorials are helpful, but actual learning starts when you try to build something on your own. That is when you start facing real decisions, small bugs, unclear logic, and the feeling of connecting different parts into one working product. That is one of the reasons why project ideas matter so much. The right idea gives you direction, but it also gives you energy. When the project feels too huge, you get stuck. When it feels too small or boring, you stop caring. The sweet spot is a project that feels possible and still a little exciting. This matters even more today. Tools like ChatGPT or Copilot can help you write code faster, but that doesn't solve the real problem beginners have. Writing the code was never the hard part for long but knowing what to build is. Start with problems you already know The easiest project ideas often come from your own life. Think about small things you do every day that feel annoying, repetitive, or messy. A simple to-do list, habit tracker, note saver, expense log, study planner, or meal planner can all become strong beginner projects if you build them well. This works because the problem is already familiar to you. You do not have to invent a fake use case or force a complicated feature list. You already know what the app should do, what feel

I recently worked through the classic Word Break problem in an interview. My approach was solid from the start — recursion with memoization, a breakable helper that tests every prefix and recurses on the rest. The logic was right. What slowed me down was everything around the logic. Here's the solution I landed on: class Solution { public: bool wordBreak ( string s , vector < string >& wordDict ) { unordered_set < string > dict ( wordDict . begin (), wordDict . end ()); unordered_map < size_t , bool > memo ; return breakable ( s , dict , memo , 0 ); // missed: breakable was a free function defined below -> "not declared in this scope" } private : // missed: had int here, compared against s.length() (size_t) -> sign-compare warnings bool breakable ( const string & s , const unordered_set < string >& dict , unordered_map < size_t , bool >& memo , size_t starting ) { if ( starting == s . length ()) return true ; if ( memo . count ( starting )) return memo [ starting ]; for ( size_t e = starting + 1 ; e <= s . length (); e ++ ) { string word = s . substr ( starting , e - starting ); // missed: shadowed an outer `word`, and had substr(starting, e) instead of e - starting if ( dict . count ( word ) && breakable ( s , dict , memo , e )) { memo [ starting ] = true ; // missed: wrote == instead of =, so success was never cached return true ; } } memo [ starting ] = false ; // missed: this line, so failures were never cached and memoization broke down return false ; } }; The real lesson Most of what tripped me up was syntax and scope — a function declared in the wrong place, signed/unsigned mismatches, a shadowed variable, == where I meant = . None of these were about the algorithm. But because I spent my time chasing them, I had less room to focus on the one thing that actually matters in this problem: the logical correctness of the memoization. The takeaway I'm keeping: get the syntax and scoping clean early, so the debugging budget goes toward logic, not typos. That's the

In the previous article, we argued that a Locator is neither a UI control nor a search mechanism. It is an architectural concept that resolves business references within a specific business context and transforms them into canonical business identities. If that is true, however, an obvious question immediately follows. How can a Locator be described? Not how it is implemented. Not how it is executed. But how it can be described independently of any particular implementation. This question is more important than it may seem at first glance. If two different development teams decide to implement a Locator, how can they be sure they are implementing the same concept? How can we discuss a Locator without referring to a particular library, programming language, or framework? The answer is that, like any mature architectural concept, a Locator must first be separated from its implementation. This distinction appears repeatedly throughout the history of software engineering. Relational theory existed before relational database systems. SQL does not describe how a query will be executed. It describes only the result we want to obtain. The choice of indexes, execution plans, and optimization algorithms is the responsibility of the query optimizer. Exactly the same principle applies here. A Locator should not be defined by the mechanism that implements it. It should be possible to describe it independently of that mechanism. This naturally leads to three distinct levels of abstraction. Locator Pattern │ ▼ Locator Definition │ ▼ Execution Engine The Locator Pattern is the architectural concept itself. The Locator Definition is the declarative description of a particular resolution process. The Execution Engine is the component responsible for interpreting that description and performing the actual resolution. Each level has a different responsibility, and they should never be confused with one another. This means that a Locator Definition is not an implementation artifact. It

Here's the failure mode I keep running into. A team gives a coding agent a repo, a task, and maybe a README. The agent can find files and write code, but it still has to guess the operating rules. It guesses the package manager. It guesses which checks matter. It guesses whether generated files are safe to edit. It guesses what "done" means. A README is usually for humans: what the project is, how to run it, and where the important docs live. A coding agent needs different context. Setup rules. Test commands. Boundaries. Completion criteria. That's the gap AGENTS.md fills. The official AGENTS.md guidance describes it as a predictable place for coding-agent instructions: setup commands, test commands, code style, security considerations, and nested instructions for large monorepos. I find the split useful in a more boring way. The README answers, "What is this project?" AGENTS.md answers, "What should an agent know before touching it?" That second question is where the work usually gets fragile. Where Goose Fits Goose makes this less theoretical because it isn't just a chat box. It's an open source local AI agent with a desktop app, CLI, API, MCP extensions, and skills. Without AGENTS.md , I find myself writing prompts like this: Update the docs, but don't touch generated files, use pnpm, run the lint and test commands, keep the PR small, and tell me what you couldn't verify. With AGENTS.md , the prompt can get shorter: Update the quickstart docs for the new config flag. Goose can run the task in the repo. The repo can carry the standing instructions. I noticed this on a small docs/config update where generated files sat near source files. Without repo instructions, the prompt had to carry the package manager, generated-file boundary, checks, and the "tell me what you could not verify" rule. Once those rules lived in AGENTS.md , the prompt became just the task. Not magic. Just fewer chances to forget the boring parts. Where Skills Fit I would add one more layer once

The Evolution of Junior Developer Roles in the Age of AI In the tech industry, a pressing question has emerged: Is the role of junior developers disappearing? With the rapid advancement of artificial intelligence (AI), particularly generative models like ChatGPT, there's growing concern about the future of entry-level software development jobs. While some predict a decline, the reality is more nuanced. AI is transforming these roles, not eliminating them, creating new opportunities for junior developers who adapt to the changing landscape. TL;DR AI advancements are reshaping junior developer roles rather than removing them. AI tools reduce the need for routine coding tasks but create opportunities for those focusing on higher-order skills like problem-solving and collaboration. Junior developers should embrace AI tools to enhance creative problem-solving. Companies must adapt talent strategies to nurture junior developers for future senior roles. The Transformation of Junior Developer Roles AI's Impact on Routine Coding Tasks Artificial intelligence has significantly automated routine coding tasks. AI models, such as ChatGPT, can generate code snippets, debug errors, and optimize performance. This capability shifts junior developers' focus from these tasks, traditionally a large part of their responsibilities. Code Generation : AI can produce boilerplate code, reducing the time spent on repetitive tasks. Error Detection : AI-driven tools identify and propose fixes for common coding errors, streamlining debugging. Performance Optimization : AI algorithms can automatically enhance code efficiency, which previously required manual intervention. Changing Nature of Junior Developer Roles The employment rate for junior developers aged 22-25 has declined nearly 20% from its peak in 2022. This trend indicates a shift in how entry-level positions are perceived and utilized within tech companies. With AI handling routine tasks, the role of a junior developer is evolving to em

🧠 Building CogneeCode - AI Developer Memory Assistant The Problem Every developer faces the problem of lost context. "Why did I make this decision 3 months ago?" "How did I fix this bug last week?" Current AI tools forget everything between sessions. This is a real problem that wastes hours of developer time. My Solution CogneeCode is an AI developer memory assistant that builds a permanent knowledge graph using Cognee Cloud . It remembers every decision, bug fix, and code context you give it. What It Does ✅ Log architectural decisions with tags and context ✅ Log bug fixes with error messages and solutions ✅ Ask natural language questions about your codebase ✅ Get answers with evidence citations from the knowledge graph ✅ Semantic search across all memories ✅ Visual timeline of all decisions and bug fixes ✅ Analytics dashboard showing memory insights ✅ Knowledge graph visualization Tech Stack Backend: Flask (Python) Memory Layer: Cognee Cloud LLM: Groq Llama 3.3 Frontend: Vanilla HTML + CSS + JS Icons: Tabler Icons Cognee Cloud APIs Used remember() - Save decisions and bug fixes with metadata recall() - Natural language queries with evidence citations search() - Semantic search across memories visualize() - Knowledge graph visualization improve() - Memory graph enrichment forget() - Remove outdated memories Why This Matters When you return to a project after months, all your reasoning and solutions are still there, searchable in natural language. No more "Why did I do this?" or "How did I fix this bug?" Demo Watch the video: https://youtu.be/TNcBIBuPW7c Links 🔗 GitHub: https://github.com/JOSESAMUEL14/cogneecode 🔗 Live Demo: https://josesamuel.pythonanywhere.com AI Assistance Disclosure Built with assistance from Claude and Gemini AI. Built for WeMakeDevs x Cognee Hackathon 2026 Category: Best Use of Cognee Cloud ⭐ Star the repo if you find it useful!

Hello, DEV Community! 👋 Hi everyone! My name is Sulemana Abdallah , and I'm excited to be part of the DEV Community. I'm passionate about software development and enjoy building modern, responsive web applications using: HTML CSS JavaScript TypeScript React Python My goal is to become a skilled Full-Stack Developer and Software Engineer while continuously learning and building real-world projects. I joined DEV to: Learn from experienced developers. Share my projects and progress. Write about what I learn. Connect with developers from around the world. I'm looking forward to growing with this amazing community. Thanks for reading! 🚀

In Part 1 , we learned that building great AI applications isn't just about writing better prompts. It's about providing the right context . But that naturally leads to another question: How much context can an AI actually understand? If you've used ChatGPT, Claude, Gemini, Cursor or any AI coding assistant for a while, you've probably experienced something like this. 🤔 "Didn't I Already Tell You That?" Imagine you're debugging a production issue with an AI assistant. You start by explaining the architecture. Then you share the API flow. Then database schema. Then logs. Then stack traces. After 30 minutes of conversation, you ask: "So what's causing the bug?" Instead of giving the answer, the AI responds: "Could you share your database schema?" You stare at the screen. "I already did..." Sometimes it even forgets details from earlier in the same conversation. Naturally, people assume: The AI has bad memory. The model is unreliable. The conversation is broken. In reality, something completely different is happening. You're running into one of the most important concepts in modern AI systems: The Context Window. Understanding this concept changes how you interact with AI—and more importantly, how you build AI-powered applications. 🧠 Before We Talk About Context Windows… We first need to understand something much smaller. Tokens. Almost every AI provider mentions them. Pricing is based on them. Context windows are measured using them. Yet many developers still think: 1 token = 1 word That isn't true. 🔤 What Exactly Is a Token? A token is the basic unit of text that an AI model processes. Humans naturally read text as: Characters Words Sentences Large Language Models don't. Before text reaches the model, it's converted into smaller pieces called tokens by a tokenizer. The model never sees your original sentence. It only sees a sequence of tokens. Think of a tokenizer as a translator between humans and AI. You write English ↓ Tokenizer ↓ Sequence of Tokens ↓ LLM The toke

This is my first post here, so I'm going to use it as an introduction. I'm Usman, a software + data engineer who primarily works with data pipelines, backend systems. Not a huge fan of frontend development though. Although I do what I can, projects honestly feel incomplete without them, because at the end of the day you do have to showcase a working end to end system when you build something. I'm here after dozens of incomplete personal projects, and projects that never even got past the design phase, you know the drill. Procrastination and imposter syndrome kept stopping me from taking the next step, but I'm here now, gotta keep myself in check fr. I was scrolling through LinkedIn the past few days, and oh my god, the amount of AI-related brain rot there. Every single post written by AI, telling you how to use AI and how not to use AI. I mean I get it, yeah, the paradigm is shifting and AI is essential to development, but where are your personal anecdotes, stuff you solved, stuff you learned, the challenges you faced, how you overcame them. You know what maybe it's my fault, it's my algorithm after all. Anyway, here I am, looking to interact with like-minded engineers and learn from them. I'm also going to post regularly about my progress and what I am building, even though I have quite a bit of experience, and have built and contributed to large-scale production systems and pipelines, I'm going to start with something small, so I can stay consistent and keep myself in check. Software engineering fascinates me a lot, and there are so many domains that I wish to explore and have explored like game development, data engineering, web/app development. My significant other is graduating in a few days, and I'm thinking of making a small game for her, alongside which I'll be working on a small sales lead enrichment pipeline. Hoping to showcase my work and document it publicly, and hoping to get to know and learn from you all! Also, I'd love to know your thoughts on the am

Introduction Python's testing tools are lightweight enough that it's easy to write a lot of tests without writing good ones. A suite that mocks every collaborator, duplicates the same assertion ten times with different inputs pasted in by hand, or chases a coverage number will pass in CI and still miss real bugs. pytest gives you fixtures, parametrize , and monkeypatch — the tools that make it just as easy to write the right tests as the wrong ones. This post covers how to use them well. Test at the Right Level: the Pyramid Not every test should look the same. The test pyramid is a rough guide to where your effort should go: Unit tests — the bulk of the suite. Pure functions and classes, no I/O, no real database. Milliseconds each. Integration tests — fewer of these. Verify the seams : does your ORM query actually produce correct SQL against a real database, does your HTTP client actually parse a real response. End-to-end tests — a handful. Cover the critical flows through the whole stack, accepting they're slower and more brittle. # Unit — pure logic, no database, no framework def test_applies_ten_percent_discount_for_orders_over_100 (): calculator = DiscountCalculator () total = calculator . apply ( order_total = 150.0 ) assert total == pytest . approx ( 135.0 ) # Integration — the seam that matters: our query against a real database import pytest @pytest.fixture def db_session ( postgres_container ): # real Postgres in a test container, not mocked with postgres_container . session () as session : yield session def test_finds_orders_placed_in_the_last_week ( db_session ): db_session . add ( Order ( id = " ord-1 " , placed_at = datetime . now ( UTC ))) db_session . commit () recent = order_repository . find_recent ( db_session , within = timedelta ( days = 7 )) assert len ( recent ) == 1 A unit suite that never touches a database runs in seconds and catches most logic bugs. A handful of integration tests catch what only shows up at the boundary — the query that's s

An astrolabe doesn’t map every star. It gives you a way to find your position relative to the ones that hold still. That’s the instrument I reach for when someone asks which AI tool they should be using. The honest answer is that the tools will be different in six months. The layers won’t. I spent a week trying to make sense of a handful of names that kept showing up in the same conversations. Tessl . Goose . Archestra . Kestra . Modelplane . RAG , MCP , half a dozen others orbiting nearby. Each one has its own pitch, its own funding round, its own reason it’s the thing you should adopt next. Taken together they read like noise. Taken apart, they sit on different floors of the same building. The agent loop again, the one I keep coming back to. Once you place each tool on a floor, the noise turns into a map. Tessl sits left of the loop , at the intent layer. Turn a spec into something an agent runs against directly. This is the one tool on the list that pushes back instead of going along with it. A well-formed spec is not the same thing as a team that agrees on what the spec means. The Agora produces the second thing as a byproduct of producing the first. Tessl produces the first and assumes the second follows. It doesn’t, automatically. That’s the whole argument. RAG and MCP are plumbing. Protocol, not position. They carry context into the loop and don’t take a side in any argument about who should be in the room when the spec gets written. They’re also the one floor with an actual standard. MCP, A2A , ACP , all under Linux Foundation governance now, joint working groups, cross-protocol commitments. Passing data between systems is a solved problem with decades of precedent behind it, so it standardized almost on contact. Nothing else on this floor plan has that. Governance, orchestration, the harness, the spec layer: every vendor is still building its own version and calling it the obvious one. The standard showed up first at the floor that mattered least to this ar

Introduction: The Illusion of Productivity Metrics Traditional software development metrics—velocity charts, commit counts, bundle size—are the comfort objects of the coding world. They sit on dashboards, glowing with the promise of insight, but in reality, they’re often lagging vanity numbers . They don’t capture the narrative of a week’s work; they don’t reveal the decisions , the reversals , or the patterns that define progress. Instead, they deform the truth by oversimplifying it, much like a rubber band stretched too thin—it snaps under pressure, failing to hold the complexity of real work. Consider the mechanical process of a commit. A commit is a snapshot , a frozen moment in time. But software development isn’t a series of snapshots; it’s a sequence . When you string commits together without context, you miss the heat of decision-making—the back-and-forth, the undoing, the redoing. This is where traditional metrics fail. They don’t account for the thermal expansion of ideas, the way a decision made on Monday might cool by Friday, only to be reheated and reshaped. Without a narrative, these metrics are like a machine running without lubrication: they friction against reality, wearing down under the weight of their own inadequacy. The Mechanism of Metric Failure Let’s break down the causal chain: Impact: Developers rely on metrics like commit counts to gauge productivity. Internal Process: These metrics are lagging indicators , reflecting past actions without context. They don’t capture the why behind the numbers—the decisions, the reversals, the thought process. Observable Effect: Developers miss critical patterns, such as repeated decision reversals, leading to inefficiencies and missed opportunities for improvement. It’s like trying to diagnose a car’s engine by looking only at the speedometer—you’ll never catch the misalignment in the gears. Narrative-Driven Insights: The Optimal Solution Contrast this with a narrative-driven approach . When you narrate a

Why I'm Building the Fast Series I'm building the Fast Series because creator software has gotten too complicated. Plenty of tools are powerful, but they make you fight the software before you can make anything. You want to record a tutorial, stream a game, clip a useful moment, compress a file, or turn an idea into a short video. Instead, you're digging through settings, codecs, plugins, device permissions, export presets, and cryptic error messages. That's the problem I keep running into, and the Fast Series is my attempt to solve it: practical Windows software where each tool does one job clearly and reliably. Not everything needs to be a giant all-in-one platform. Sometimes the better product is a small tool that opens quickly, gives you sensible defaults, explains what's happening, and gets out of your way. That's the direction I'm taking with Sturm Technologies. The Problem With Creator Tools There are already great tools for recording, streaming, editing, clipping, and compressing. OBS is powerful. Professional editors are powerful. FFmpeg is powerful. There are cloud tools, browser tools, AI tools, and creator suites that promise to do everything. But power is not the same thing as clarity. Most creators don't want to become experts in capture APIs, bitrate math, encoder settings, audio routing, or export pipelines. They want to make something and publish it. The pain usually shows up in small moments. You record a video and the audio is missing. You compress a file and it still doesn't meet the upload limit. You spend more time scrubbing a long video than actually clipping it. You hit an error and the app hands you a technical dump instead of telling you what to fix. That's where I think there's room for better software. Not bigger software. Better software. Start With FastCast The first product in the series is FastCast , a Windows recording and streaming app for people who want OBS-level practicality without OBS-level setup. FastCast focuses on screen cap

A gente sempre ouve falar que o sistema operacional impede que um processo veja a memória do outro ou que o programa fale diretamente com o hardware, mas normalmente não explicam o "como". Eu sempre achei isso meio mágico até que eu resolvi ir atrás da resposta, e é bem interessante. Vou me basear na arquitetura x86, mas é provável que outras arquiteturas sejam parecidas. O problema: a CPU Pra CPU não existe processo, kernel, sistema operacional. Existe só endereços de memória de onde ela lê a próxima instrução e executa. Se a CPU pode falar direto com a RAM, SSD, teclado, mouse, tela... O que me impede de escrever um programa pra ler suas senhas e tokens direto da RAM? Ou de ler arquivos e alterar arquivos sensíveis direto no SSD? Por outro lado, se o kernel fiscalizasse cada instrução que da CPU antes dela executar, isso seria extremamente lento... Outro problema: os interrupts Se a CPU só executasse sequencialmente, seu sistema poderia executar várias coisas e esquecer de checar se uma tecla foi apertada, se o mouse mexeu, etc... Então certos eventos interrompem o que quer que a CPU esteja fazendo para serem tratados assim que possível. Alguns exemplos de interrupt são: Teclas do teclado pressionadas ou soltas Botões e movimento do mouse Timers Operações de disco assíncronas Pacotes de rede recebidos/transmitidos Uma solução: rings Os processadores da arquitetura x86 tem o esquema de rings. Pense em rings como grau de limitação. Ring 0 significa limitação zero, ou seja, acesso a todas as instruções da CPU e consequentemente acesso total ao hardware e memória. O kernel roda em ring 0, ou kernel mode. O kernel assim que é carregado configura todos os interrupts handlers da CPU para executar o handler apropriado do kernel, em kernel mode, claro. Em ring 3 a CPU fica limitada e não pode fazer instruções consideradas privilegiadas. E obviamente em ring 3 a CPU não consegue se colocar em ring 0 sozinha, pois dessa forma qualquer programa conseguiria se pôr em ring 0. O

개발 역량이 없어도 외주 개발사의 진행 상황을 명확하게 파악하고 피드백을 줄 수 있다. 필요한 건 기술 지식이 아니라, 올바른 협업 구조다. 이 글은 비개발자 제품 관리자가 바로 적용할 수 있는 투명한 피드백 루프와 점검 방식을 소개한다. 외주 개발에서 비개발자가 소외되는 이유는 무엇인가? 외주 개발사와 일을 시작하면 처음 며칠은 소통이 활발하다. 요구사항 정리, 계약, 착수 미팅까지는 순탄하다. 문제는 그 이후다. 개발이 시작되면 대화의 언어가 바뀐다. "API 연결 중", "백엔드 스키마 설계 단계", "프론트 컴포넌트 분리 작업"처럼 전공자가 아니면 체감하기 어려운 표현들이 보고서를 채운다. 이 상태에서 비개발자가 할 수 있는 질문은 사실상 하나뿐이다. "잘 되고 있나요?" 그리고 돌아오는 답도 하나다. "네, 잘 되고 있습니다." 이 구조는 어느 개발사가 나쁜 의도를 가져서 생기는 문제가 아니다. 개발자는 기술 언어로 사고하고, 비개발자는 결과와 흐름으로 사고한다. 이 두 언어 사이에 다리가 없을 때 소외가 생긴다. 그리고 이 소외는 감정의 문제가 아니라 실질적인 리스크다. 방향이 틀어진 채 몇 주가 흐르면, 다시 맞추는 비용은 처음보다 훨씬 커진다. 비개발자가 개발 과정을 직접 점검할 수 있는 구조가 필요한 이유가 여기 있다. 비개발자가 진행 상황을 파악할 수 있는 협업 구조란? 투명한 협업 구조는 "보고를 더 자주 받는 것"이 아니다. 받는 정보의 언어와 형식을 바꾸는 것이다. 포텐랩은 매주 진행 상황을 공유하는 주간 피드백 루프를 팀 표준으로 운영한다. 이 루프의 핵심은 세 가지다. 무엇이 완료됐는가 : 이번 주에 실제로 만들어진 것, 확인 가능한 것. 다음 주에 무엇을 만드는가 : 다음 단계에서 기대할 수 있는 결과물. 막힌 것이 있는가 : 결정이 필요하거나 확인이 필요한 사항. 이 세 가지가 매주 비개발자도 읽을 수 있는 언어로 정리된다면, 소통 구조는 이미 절반 이상 해결된 것이다. 기술 용어 없이 "로그인 화면 완성, 다음 주엔 상품 목록 화면 작업"이라고 쓸 수 있다면, 비개발자는 지금 어디쯤 왔는지 감을 잡을 수 있다. 주간 피드백 루프를 실제로 설계하는 방법 주간 루프가 형식적인 보고에 그치지 않으려면 구조가 있어야 한다. 아래는 포텐랩이 프로젝트마다 적용하는 주간 피드백 사이클의 구성이다. 1단계 — 주간 업데이트 문서 공유 매주 정해진 요일에 개발팀이 업데이트 문서를 공유한다. 이 문서에는 완료된 기능, 다음 주 작업 항목, 그리고 결정이 필요한 사항이 포함된다. 형식은 슬랙 메시지든, 노션 페이지든 팀이 합의한 채널이면 된다. 중요한 건 형식보다 주기와 언어다. 매주 같은 날, 비개발자가 읽을 수 있는 언어로. 2단계 — 화면으로 확인 가능한 결과물 공유 텍스트 보고만으로는 실제로 무엇이 만들어졌는지 체감하기 어렵다. 그래서 주간 업데이트에는 화면 캡처, 동영상 클립, 또는 테스트용 링크가 함께 제공된다. "로그인 기능 완료"라는 문장보다 실제 작동하는 화면을 보는 것이 훨씬 구체적인 판단 근거가 된다. 3단계 — 비개발자가 직접 테스트하는 시간 개발팀이 보여주는 것만 보는 게 아니라, 비개발자가 직접 써보는 단계가 필요하다. 이 과정에서 "버튼이 너무 작다", "이 순서가 직관적이지 않다" 같은 피드백이 나온다. 기술 지식이 없어도 할 수 있는 피드백이고, 이런 피드백이 제품의 방향을 바로잡는다. 4단계 — 다음 주 작업 범위 합의 이번 주 결과를 확인한 뒤, 다음 주에 무엇을 만들지 함께 정한다. 이 단계에서 비개발자는 우선순위를 조정할 수 있다. "이 기능보다 저 기능이 먼저 필요하다"는 판단을 매주 할 수 있는 구조다. 우선순위는 비개발자가 가장 잘 아는 영역이다. 비개발자가 개발 진행 상황을 점검하는 실질적인 기준은? 개발 진행 상황을 평가할 때 기술적 판단을 할 필요는 없다. 다음 세 가지 기준으로 충분히 점검할 수 있다. 점검 항목 확인 방법 좋은 신호 주의가 필요한 신호 완료 결과물 화면 또는 테스트 링크로 직접 확인 매주 눈에 보이는 결과물이 있음 텍스트 보고만 있고

Here are five architectural lessons we've learned from designing software for modern retailers.* Designing ERP Software for Retail: Five Lessons Every Software Engineer Should Know When people hear the word ERP , they often think of accounting software, dashboards, or inventory management. As software engineers, we see something different. We see distributed systems. Complex business workflows. Real-time data synchronization. Concurrent transactions. Event-driven architecture. And perhaps the biggest challenge of all—representing how real businesses actually operate. At RetailWings , we've learned that building an ERP for retail isn't simply a software engineering challenge. It's a business engineering challenge. Here are five lessons every engineer should understand before designing an ERP platform for modern retail. 1. Retail Doesn't Run in Modules—It Runs as One Business One of the biggest architectural mistakes in business software is treating departments as isolated applications. Many systems separate: Sales Inventory Finance Procurement HR But retailers don't experience their businesses that way. One sale immediately affects inventory. Inventory influences procurement. Procurement impacts finance. Finance drives reporting. Everything is connected. A well-designed ERP should reflect these relationships rather than forcing departments into disconnected silos. 2. Inventory Is More Than a Database Table To many engineers, inventory may appear to be a simple CRUD problem. Create. Read. Update. Delete. Retail quickly proves otherwise. Inventory changes through: Sales Returns Transfers Damages Procurement Stock adjustments Warehouse movements Manual reconciliations Every movement has financial implications. Every movement must be traceable. Designing inventory requires thinking in terms of events, not just records. 3. Real-Time Data Changes Everything Retail managers don't want yesterday's reports. They want answers now. How much stock is left? Which branch is sellin

There is a fascinating, quiet tension happening in the software engineering community right now. If you listen closely to late-night developer chats, team syncs, or tech forums, you will notice that our industry has rapidly split into two distinct schools of thought regarding the rise of AI coding tools like Cursor, Claude Code, and Copilot. On one side, you have the Traditional Developers. They argue that software engineering is a disciplined art form that cannot be replaced by text prompts. To them, unchecked AI coding is a recipe for buggy, unreadable spaghetti code, creating a technical debt nightmare for the future. On the other side, you have the Vibe Coders. This is a fast-moving generation of builders, both technical and non-technical, who believe in shipping fast, prompting quickly, and adjusting on the fly. They do not see a need to obsess over syntax when the AI can translate their intent into a working application in minutes. The reality is that both sides are entirely right. If we stop arguing over who is ruling the current meta and actually look at the core truths each camp holds, we can see exactly where the future of software development is heading. 1. The Traditional Developer is Right: Guardrails Matter The traditional development camp is fundamentally right about structure. Building a beautifully designed UI that works on a surface level is vastly different from building an enterprise-ready, scalable architecture. When you prompt an AI to build a feature, its primary objective is to satisfy the literal words in your core prompt. This is the "as long as it works" mentality. Unless you are practicing strict, spec-driven development and explicitly dictating your architectural doctrines, security protocols, and API patterns, the AI will make assumptions for you. Historically, those assumptions are optimized for speed and not long-term stability. Without deep technical oversight to catch anti-patterns, edge cases, and hidden security flaws, fast-shippe