标签：#engineering

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

I used to fix weak AI drafts by asking for better prose. "Make it clearer." "Make it more persuasive." "Make it sound less generic." The output improved a little. Then it failed in the same place: the article looked polished, but nobody remembered what it was trying to say. TL;DR: Before you ask AI to write, fill a five-line editorial brief: audience, takeaway, material to use, first point to place, and scope delegated to AI. The prompt gets shorter because the decision-making moved back to the human. Quick answer: what should I decide before asking AI to write? Decide these five things before the first draft: Who is the reader? What should that reader take away? Which material should be used, and which material should be cut? What should appear first so the reader can follow the argument? Which part is the AI allowed to decide, and which part stays with you? That is the difference between an AI writing prompt and an AI writing workflow. A prompt says, "write a useful article about this." A workflow says, "write for this reader, to deliver this point, using this material, in this order, while leaving these decisions untouched." Here is the copy-paste version I now use before drafting: cat > ai-writing-brief.md << ' BRIEF ' Audience: Takeaway: Material to use: First point to place: Scope delegated to AI: BRIEF Output: a five-line brief that makes the human decisions visible before the AI starts drafting. If those five lines are empty, a better prompt usually will not save the article. It will only make the generic answer prettier. Why polished AI writing still feels empty AI can satisfy the instruction you give it. If you ask for more detail, it adds detail. If you ask for simpler language, it removes jargon. If you ask for a friendly tone, it softens the edges. All of that can be correct and still useless. The missing part is not grammar. It is aim. A draft can have headings, clean paragraphs, and natural transitions while still leaving the reader with no decision,

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

Tilt a CD or DVD under a desk lamp and a band of color sweeps across its surface. The disc is not painted; it is a spiral of microscopic pits, packed so tightly that they act on light the way a finely ruled scientific instrument does. Each wavelength of white light leaves the surface at its own angle, and your eye sees the result fanned out as a rainbow. That is a diffraction grating at work. The same principle that decorates a CD is the engine inside spectrometers that identify chemical elements, tune lasers, and read the composition of distant stars. This article explains how a grating spreads light, how to compute the angles, and where the analysis goes wrong. Why this calculation matters A prism also splits white light, but a grating does it with far more control and far more precision. Because the spreading depends on a countable number — the spacing between lines — a grating can be designed to send a chosen wavelength to a chosen angle. That predictability is what makes it the heart of the spectrometer. Spectroscopy underpins a remarkable range of work. Astronomers read a star's chemistry and velocity from the dark lines in its spectrum. Chemists identify unknown compounds by the wavelengths they absorb. Telecommunications engineers use gratings to combine and separate the many wavelengths sharing a single optical fiber. In every case the first task is the same: given the grating and the light, predict the angle at which each wavelength emerges. Get that wrong and a spectral line lands on the wrong detector pixel, and the measurement is meaningless. The core formula A diffraction grating is a surface ruled with a large number of equally spaced, parallel lines. When light passes through or reflects off it, each line acts as a source of secondary waves. Those waves interfere, and they reinforce each other only in specific directions — the directions where waves from neighboring lines arrive exactly in step. The condition for that reinforcement is the grating equ

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

InfoQ has opened enrollment for a five-week AI Security & Privacy Engineering cohort for senior engineers and architects in regulated industries, focused on applying security, privacy, threat modeling, observability, and governance practices to production AI systems. By Artenisa Chatziou

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

The Model Context Protocol team has promoted its Enterprise-Managed Authorisation extension to stable status, adding a centralised way for organisations to control access to MCP servers through their identity provider. The project states the aim is to replace per-server consent prompts with a zero-touch flow in which users sign in once and then access approved servers without further setup. By Matt Saunders

The Problem Nobody Talks About Everyone's posting AI-generated videos — characters speaking with lip-sync, manga panels coming alive, virtual idols dancing. The pitch: "just describe what you want." I tried. For months. Here's what I got: Character's face morphed by frame 2 "Slowly looks up" became "violent head shake" Voice-over sounded like Google Translate Same prompt, 3 runs, 3 completely different results No idea what to include or how long the prompt should be Tutorials were either too vague ("be detailed") or too technical (parameter tuning from line 1). The real issue: video prompts are structurally different from text/image prompts. You need to simultaneously control visuals, motion, audio, camera, and consistency constraints — in the right order, at the right length. What I Found A Skill in the Model Studio official repo called happyhorse-prompt-studio . It doesn't teach you theory — it asks you questions and assembles the prompt for you . 4-phase flow: 1. Inspiration Menu Shows you 4 "flavors" of what HappyHorse can do: Flavor What it does A · Voiced Manga Drama Characters talk to each other, with voice + lip-sync B · Character Voice PV Single character self-introduction, 8-10 sec C · Manga Panel Motion Static manga panel starts breathing D · Virtual Idol MV Idol performance with choreography 2. Discovery Asks you conversationally: character appearance, scene, emotion, dialogue, voice type, art style, camera. 3. Prompt Assembly Assembles using the HappyHorse Formula : Scene + Subject + Motion + Audio + Quality Key techniques: @「Image n」 syntax locks character identity across shots Dialogue ≤15 characters (split shots if longer) Japanese prompts work best (HappyHorse is JP-optimized) Always end with キャラの顔・髪・衣装が変わらない (face/hair/outfit stays unchanged) 4. Quality Check Auto-reviews: completeness, compliance, cost estimate, optimization tips. Before vs. After Dimension Writing myself With Prompt Studio Attempts needed 10-20 before one usable 2-3 to satisfacti

Most prompts ask AI to explain things. The best ones ask it to show you something instead. That distinction sounds cosmetic. It isn't. It changes what the model generates, how you process it, and — more importantly — whether it actually sticks. I came across this idea while watching an interview with Amanda Askell — a philosopher and researcher at Anthropic whose work sits at the intersection of AI alignment and what you might loosely call Claude's inner life. She's a primary author of the document that defines Claude's values and character — the framework that governs how the model reasons when the rules run out. Almost as an aside near the end of the interview, she mentioned a prompting technique she uses to understand complex concepts. It stopped me cold. Not because it was elaborate. Because it was disarmingly simple, and it worked in a way I hadn't thought to ask for. The Exact Prompt Template Here it is, cleaned up and ready to use: I want to understand [concept]. Please explain it by writing a fable — an indirect, narrative version of the concept. The story should embody the concept completely without naming it directly. Ideally, the reader should only start to realize what the concept actually is near the end of the story. After the fable, add a short explanation that names the concept clearly and connects it back to the key moments in the story. That's it. No elaborate scaffolding. No chain-of-thought trigger. No persona assignment. Just a deliberate decision about the order in which understanding should arrive. Why This Works (and Why Direct Explanation Often Doesn't) When you ask AI to explain a concept directly, you get a definition. Definitions are accurate and forgettable. The model produces the statistical center of everything written about that concept — clear, complete, and utterly without friction. Friction, it turns out, is how things get encoded. When a concept arrives wrapped in a story, your brain does something different. It tracks characters,

Honestly it's not a new concept. this feature already existed in models before. problem was the models were just weak. Looping only works if each attempt gets the agent closer to the correct solution. Earlier models weren't consistent enough for that. They often misunderstood feedback, repeated the same mistakes, or got stuck in an infinite loop. Instead of improving with each iteration, they frequently failed to make meaningful progress, eventually consuming large numbers of tokens without solving the problem. The Context Window Limitation Earlier language models had much smaller context windows. As the agent went through more iterations, the conversation history and reasoning gradually filled the available context. Once the context window was exceeded, older messages had to be dropped or compressed into summaries. As a result, the agent could forget previous failed attempts, lose important clues or reasoning, and sometimes repeat the same mistakes it had already made. So what did modern models actually fix? Bigger context windows Models can now hold way more of the conversation/history without forgetting, so the agent doesn't need to spin up a fresh session every few iterations. it can just keep looping with the full history of what failed and why. modern models also got way more consistent earlier if you asked a model to fix the same bug 5 times you'd get 5 different half-baked answers, now it actually converges toward the real fix. and tool use got better too . Old models could write code but couldn't run it and read the actual error, now they call a test runner, see the real failure, and fix that exact thing which is literally what makes the "verify" step possible. And then there's inference it is simply the process of a model generating an answer. like when you type "write a java binary search," the model reads your prompt, thinks, and generates code that whole process is inference. every time the model generates text, that's one inference. now here's the thin

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

Cycle recently introduced a separate EU-based control plane, allowing European customers to keep platform management data and telemetry within Europe. The new offering is designed to improve compliance, operational isolation, and responsiveness for European organizations. By Renato Losio

Cloudflare details Town Lake, an internal unified data platform, and Skipper, an AI analytics agent unifying access to operational, billing, security, and business data. The platform processed ~91K billing queries, with billing forming majority usage. Built on a lakehouse architecture using Trino, Iceberg, R2, and DataHub, it enables governed cross-system analytics and natural language access. By Leela Kumili

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