标签：#softwareengineering

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

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

For decades, developers were judged by one thing: How much code they could write. The best programmers wrote faster. Debugged faster. Built faster. That era is ending. The next generation of developers won't spend most of their time writing code. They'll spend it directing AI. Welcome to the age of the AI Orchestrator. The Evolution of Software Development Software development has always evolved. First, developers wrote machine code. Then came assembly. Then high-level languages. Then frameworks. Then cloud platforms. Then DevOps. Each evolution removed repetitive work and let developers focus on bigger problems. AI is simply the next step. But this time, it isn't replacing a tool. It's becoming a teammate. Coding Is Becoming a Smaller Part of the Job Building software isn't just writing code. A typical project includes: Understanding requirements Researching documentation Designing architecture Writing code Reviewing code Debugging Testing Writing documentation Deploying applications Monitoring production Fixing incidents Only one of those is coding. Everything else is coordination and decision-making. That's where AI is changing the game. From Programmer to Orchestrator Think about how modern teams work. A tech lead rarely writes every line of code. Instead, they: Assign work. Review solutions. Provide feedback. Make architectural decisions. Remove blockers. Developers are beginning to work with AI in much the same way. Instead of writing every function, they'll: Define the goal. Provide the right context. Choose the right tools. Review AI-generated code. Run tests. Improve weak areas. Approve the final result. The value shifts from typing code to guiding its creation. What Does an AI Orchestrator Do? An AI orchestrator doesn't ask one question and accept one answer. They manage a workflow. For example: Break a large project into smaller tasks. Give each AI the context it needs. Decide when to retrieve documentation. Decide when to search the codebase. Ask AI to g

CodeTrace-AI v1.0.1 — Stop Reading Code. Start Understanding It. Every developer has experienced this. You clone a repository, open it, and suddenly you're staring at thousands of files. You spend hours answering questions like: Where is this function called? Which files depend on this module? What happens if I modify this class? Is this code even used anymore? Traditional tools like grep , IDE search, or AI chat assistants can help you find code. They don't help you understand the architecture . That's why I built CodeTrace-AI . What is CodeTrace-AI? CodeTrace-AI is an AI-powered code intelligence tool that transforms your repository into a searchable structural knowledge graph. Instead of treating your project as plain text, it understands your codebase structurally by analyzing: 📂 Folder hierarchy 📄 Files 🏛 Classes ⚙ Functions 📦 Imports 🔗 Function calls 🌐 Cross-file dependencies Think of it as having an AI Software Architect that understands your entire repository. 🚀 What's New in v1.0.1 This release focuses on speed, privacy, and understanding large repositories. 🕸 Interactive Code Graph One of the biggest additions is the interactive repository graph. Instead of reading hundreds of files manually, you can visualize relationships between: Folders Files Classes Functions Imports Function calls Understanding a new project becomes dramatically easier. ⚡ SHA-256 Delta Sync Engine One feature I'm particularly proud of is the new Incremental Indexing Engine. Most code intelligence tools rebuild their entire index every time. CodeTrace-AI doesn't. It computes a SHA-256 fingerprint for every tracked file and detects: ✅ Modified files ➕ Newly added files ❌ Deleted files Only those files are: Re-parsed Re-embedded Re-added to the knowledge graph Everything else is skipped. This makes repeated indexing dramatically faster, especially for large repositories where only a few files change between runs. Under the hood The sync engine includes: SHA-256 fingerprinting Parallel f

We all use AIs today - From a 5th grader to a retired pensioner, from a small-time business owner to a multimillionaire businessman, from a software engineer to a medical expert. AI exists everywhere! And to be honest its making our lives very simple. Yes, it does!. Response in no time, flexibility, reliability - yes, AI gives all and even more And as Software Engineers, we are getting more inclined towards AI. Back in the days, we used to rely on Stackoverflow to get our queries resolved. Sometimes it did, sometimes it didn't. But, AI changed that landscape completely - asking a query, retrieving data, asking follow-ups and so and on so forth. But, honestly, how many of us have thought - Wow this looks amazing! But how does it actually work! Let's say I type this in Chat GPT or Gemini or Claude etc: "Hi, how is the weather today?". The AI assistant takes the input and processes it and returns the response. But , there is a lot of processing and workflow happening under the hood. As a Software Architect, I struggled a lot to get these answers. Different sources, different suggestions. And the suggestions at some point seemed too overwhelming for me. So, I decided to break it down and start a series which will enable people to understand AI. I want to make people understand AI in the simplest way possible and make every developer leverage AI - not just to get their job done, but also to help in upskilling, so that they don't get lost in the overwhelming world of AI as I did initially! Follow me for more updates!

Security Team: “I have a major Grype...with what I Syfted out of your provided image." Developer: “Well your Grype is slowing me down...let’s tone it down a notch.” While deploying bookstack into my local environment, this issue surfaced. It is true for many organizations today deploying images and packages in their environment. How can this noise fatigue in the software supply chain be remedied? Add a .gype.yaml file to the root directory of your project. This will allow grype to ignore certain CVE's that do not execute or pose a threat in your environment. The yaml config can be as simple as below: Linux Environment # grype.yaml ignore : - vulnerability : CVE-2026-32631 reason : " Platform-specific false positive. Git for Windows only; not applicable to this Linux-based image." - vulnerability : CVE-2016-2781 reason : " Chroot escape via ioctl. Containers rely on namespaces/cgroups, not chroot, so this path isn't exploitable here." OR # grype.yaml ignore : - vulnerability : CVE-2026-32631 - vulnerability : CVE-2016-2781 This will help developers and security engineers get along better. 😃 Grype config reference: https://oss.anchore.com/docs/reference/grype/configuration/

When most people hear Bitcoin , the conversation usually starts with price. But for developers, Bitcoin is much more than a chart. Bitcoin is a distributed system operating without a central authority. It combines networking, cryptography, game theory, economics, and software engineering into a protocol that has remained operational for years while processing value globally. As a software developer, what fascinates me most is not speculation it’s the architecture. Some concepts every developer can appreciate: ⚡ Distributed Consensus Thousands of nodes independently verify the same rules without trusting each other. 🔐 Cryptography in Practice Digital signatures make ownership verifiable without revealing private keys. ⛏️ Proof of Work A mechanism that converts computation into security and coordination. 🌍 Open Source at Global Scale Anyone can inspect the code, run a node, contribute, or build on top of the ecosystem. 📦 Immutability Through Design Data integrity is achieved through incentives, validation rules, and chained blocks. Studying Bitcoin changes how you think about: System reliability Security models Network design Incentive structures Building software that survives failure Whether you plan to build in blockchain or not, Bitcoin is worth studying because it teaches principles that extend far beyond finance. Curious to hear from other developers: What concept in Bitcoin architecture changed the way you think about software systems?

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

AI เขียนโค้ดแทนเราได้แล้ว — แล้วเราจะเหลืออะไรให้ทำ? มีประโยคที่ได้ยินบ่อยขึ้นทุกวัน: "เดี๋ยวนี้ใครยังไม่ใช้ AI ช่วยเขียนโค้ดบ้าง?" คำตอบคือ — แทบไม่มีแล้วครับ ตั้งแต่ GitHub Copilot, Cursor, Claude, ChatGPT ไปจนถึง agent ที่เขียนโค้ดเองได้ทั้ง project — เราใช้ AI ใน level ที่ต่างกัน: Level หน้าตา ตัวอย่าง 🎵 Vibe Coding พิมพ์สิ่งที่อยากได้ กด accept อย่างเดียว "เขียนหน้า login ให้หน่อย" → กด tab tab tab 🧩 Prompt-Guided คิดก่อน ถามทีละส่วน ตรวจทุกอย่าง "สร้าง UserService ที่ใช้ bcrypt hash password" 🛠️ Skill/Lint-Guided ใช้ AI เป็น editor ชั้นสูง — lint, refactor, test "refactor function นี้ให้เป็น table-driven test" 🏗️ Agent-Based ให้ AI run ทั้ง project — spawn subagent, PR, deploy "พอร์ต microservice นี้จาก Express ไป Fastify" แล้วคำถามคือ — ถ้า AI ทำทั้งหมดนี้ได้ แล้วมนุษย์อย่างเราเหลืออะไร? Unit Test — ตัวอย่างที่เห็นชัดที่สุด ลองดู unit test ที่ AI เขียนให้: // 🤖 AI-generated test func TestCalculateDiscount ( t * testing . T ) { tests := [] struct { name string input float64 expected float64 }{ { "zero" , 0 , 0 }, { "normal" , 100 , 90 }, // 10% discount { "max" , 1000 , 800 }, // 20% discount } for _ , tt := range tests { t . Run ( tt . name , func ( t * testing . T ) { result := CalculateDiscount ( tt . input ) if result != tt . expected { t . Errorf ( "got %v, want %v" , result , tt . expected ) } }) } } ดูเผิน ๆ — สวย, table-driven, ถูกต้องตาม Go convention 1 แต่ถามหน่อย — test นี้บอกอะไรเกี่ยวกับ business? "ส่วนลด 10% สำหรับยอด 100 บาท" — ทำไมต้อง 100? เป็นกฎจากที่ไหน? "ส่วนลด 20% เมื่อยอดถึง 1000" — แล้วถ้าลูกค้าเป็น member ได้เพิ่มอีก 5% ล่ะ? input: 0, expected: 0 — test นี้ cover edge case หรือแค่ cover บรรทัด? AI test ได้ถูกต้องตาม function — แต่มัน ไม่รู้ว่า business จริง ๆ คืออะไร AI ไม่รู้ Business Context — และจะไม่มีวันรู้ นึกภาพระบบ e-commerce: ลูกค้าซื้อสินค้า → ระบบตัดสต็อก → คำนวณส่วนลด → คิดค่าส่ง → ออกใบเสร็จ AI แยก test ทีละ function ได้: ✅ TestDeductStock — "ตัดสต็อก 1 ชิ้น" ✅ TestCalculateDiscount — "ส่วนลด 10%" ✅ TestCalculateShipping —

When I write code in unfamiliar territory, I write three lines, then I run it. Then I write three more lines, and I run it again. I've been doing this for twenty-four years. It's the most specific habit I have. I almost didn't write this article, because the habit feels too small to be worth describing — but then I noticed that it's the part of my way of working that I can never seem to explain to someone in real time. It needs writing down. Three principles The discipline rests on three things I believe about writing code. They're not deep. They've just stayed with me. 1. Trust nothing but your own code. If you can't trust the code you wrote yourself, what can you trust? Not a library, not a vendor's documentation, not your own assumption from yesterday. The only thing in the system whose behavior you can fully verify is the code you just typed, by running it. 2. Write in code, not in language. If you're describing what the code should do in Japanese or English, you're spending the same time you could have spent writing the code itself. By the time the code runs, the description is already done — by the code, in a more precise form than any language could give it. 3. Make three lines complete. The three lines you just wrote should be complete. Error handling included. Validation included. Logging included. Not "I'll add validation later." Not "I'll wrap it in a try-catch later." Three lines, complete, then run. (There's a small exception to this. Sometimes you do want to ignore every error and move on — for instance, when you're trying to understand whether the happy path works at all before you care about anything else. That's a different mode, used deliberately. It's not the same as "I'll handle errors later.") Why three lines Three lines is roughly the unit of thought I can hold completely. Five lines, and I start guessing what the third line did. Ten lines, and I'm reading the code as if it were someone else's. Three lines is the size that stays mine. When thre

The design doc is fourteen pages. Clean service boundaries, thoughtful API contracts, a deployment story that handles rollback without incident. Six months of work. The team is proud of it, and the work is genuinely good. Three questions will tell more about this system than all fourteen pages. Not questions about implementation details or technology choices. Questions about how the system was designed to age, to fail, and to be understood by someone who didn’t build it. Most architecture conversations never reach these questions, which is part of why the gap between a good system and a great one is often invisible until it is suddenly very visible. What does this make hard? Good architecture conversations focus on what a design enables: faster deployments, independent scaling, and clearer ownership. The question that separates architectural thinking from implementation thinking is the inverse . What does this make hard? Every decision forecloses options. The service boundary that gives teams autonomy makes cross-service transactions expensive. The data model that reads cleanly under expected load makes certain write patterns awkward. The abstraction that simplifies onboarding makes some categories of refactoring nearly invisible as possibilities. These are not arguments against the decisions. They are the other side of every decision, and that other side exists whether or not anyone names it. The design doc that holds up over time is not the one where nothing is difficult. It is the one where the difficult things are named. “This approach makes distributed transactions impossible, and here is why we have decided to accept that constraint.” That sentence, or something close to it, belongs in every significant architecture document. Its absence is not a sign that the constraint wasn’t considered. Often it was. But without the name, the constraint becomes invisible to everyone who wasn’t in the room, which eventually includes the original team. When joining a system s

Habit stacking is one of my goals this year. I've been so focused on improving my software...

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

Anthropic's engineers ship eight times more code than they did a few years ago. And they had to start scheduling lunches so people would talk to each other. Fiona Fung, who leads the Claude Code team, said it on Lenny's Podcast last week. Working with agents all day had started to feel isolating. The team was fast, but they'd stopped running into each other. So they added pairwise programming lunches and hackathons — rituals to put back the thing that used to happen on its own. Eight times the output. Scheduled conversation. That ratio is worth sitting with. Whatever goes missing here doesn't show up in the metrics. It doesn't throw an error. It just quietly stops being available. Here's the part that bugs me most. Ask an AI whether your approach is sound and it mostly tells you it is. Not because it's lying — because it's answering the prompt. No stake in the outcome, no history with the system, no memory of the last three times this exact idea was tried and quietly failed. A colleague pushing back is a different thing. They've got context you never typed into the window, because they were there when it was earned. They're going to maintain this too. They might be wrong — but wrong in a direction you hadn't thought of. An agent can't disagree with you like that. It agrees faster. Same with scope. The agent builds what you ask for, all of it, thoroughly. It won't mention that the third feature is the one nobody will use, or that "good enough" happened two iterations ago, or that something next door already solves most of this. Knowing when to stop comes from someone who's watched a codebase rot under a hundred individually-reasonable decisions. And it only knows what you put in front of it. The person who worked on payments remembers the edge case you're about to recreate. The junior who joined three months ago still sees the thing everyone stopped noticing. That gap — between what's in the window and what isn't — is where the expensive mistakes live. Then the part

I noticed something a few months ago. I was talking less to my colleagues. Not because anything was wrong. I had a question, I described it to an AI, I got something useful back. Why loop in a human if the loop is already closed? It took a while to name what was actually happening. There's a version of the AI story where the interesting work disappears. The agent implements. The spec session produces the plan. Humans review the output. What's left? Ticket hygiene and rubber stamping. Engineering as a series of approvals. I think that's wrong. But I understand why it feels true. Here's what I think is actually happening instead. The agent produces the increment. But the agent doesn't decide what the increment should move toward. It doesn't know whether this library is the right bet for the next three years. It doesn't know which of two implementation approaches leaves options open and which quietly closes them. It doesn't know whether the architectural call made today creates a problem nobody will notice until the system is under load eighteen months from now. That work — giving the project direction, validating trade-offs, deciding what the system becomes — isn't specable. You can't write a ticket for it. And it's not going away. The craft didn't disappear. It moved. Direction is the word I keep coming back to. The agent executes well. It implements against a spec. It generates options when you ask for them. But it doesn't carry a point of view about where the system should go. It doesn't have a stake in the decision. It will implement the wrong architectural direction just as confidently as the right one, if that's what the spec says. Someone has to hold the direction. Someone has to know enough about the codebase's history, the team's constraints, and the product's trajectory to say: not that library, we've been down that road. Not that pattern, it doesn't survive the load we're heading toward. This approach now, that refactor later, in this order, for these reaso

"A fool with a tool is still a fool." — often attributed to Grady Booch I keep coming back to this quote when I watch teams adopt AI. In my last post ( https://schrottner.at/2026/06/18/The-Wrong-End-of-the-Problem.html ) I wrote about shifting the engineering process left — spec sessions, autonomous agents, humans reviewing output rather than writing it. A few people asked the obvious follow-up: if an agent implements and an AI reviews, why do I need a team at all? It's a fair question. And I think the answer is in that quote. The agent validates against your prompt. That's it. If your thinking is muddled, the output will be muddled — just faster and at greater cost. An agent doesn't tell you that you're solving the wrong problem. It solves whatever problem you gave it, thoroughly and without complaint. Most AI usage right now treats AI as a tool. Which means the quality of the output is bounded by the quality of the thinking that went into the prompt. A fool with a tool is still a fool. The tool just makes the foolishness more expensive. The team is the check on intent. Not after the agent has burned three sprints on the wrong thing — before it starts. That's what mob planning actually is, when you think about it. Not a meeting. Not process overhead. It's the place where bad ideas get caught before they get expensive. Where someone asks "wait, why are we building this" before an agent runs with it for a week. But there's something else happening in that room that I think gets underestimated. It's where the learning happens. Not just prompting. System thinking. Architectural patterns. How to decompose a problem. Why a certain approach fits this codebase and another doesn't. How a senior frames a problem before an agent ever touches it — the mental model that makes the output actually good. Right now that knowledge isn't transferring. Everyone is heads-down with their own tools, developing their own habits in isolation. Engineer A gets dramatically better output than

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