标签：#software

myna 0.15.0: myna update I typed myna update today and got Unknown command "update". Run: myna help . That is a fair answer and a bad one. The installer already knew how to put a myna binary on a machine correctly, so there was no reason the binary could not do the same thing to itself. myna update # replace this binary with the newest release myna update --check # only say whether one is waiting /update works in the TUI too. The parts that are easy to get wrong An in-place self update is one of those jobs that looks like four lines of curl and is not, so it is worth saying what this one actually does. It compares versions numerically. A string compare puts 0.9.0 above 0.10.0, which would have parked every install on the 0.9 series the moment 0.10 shipped. It picks the asset the machine can run. Bun's default x86_64 build uses AVX2, and on a CPU without it the binary dies with an illegal instruction rather than a message you could act on, so an older x86_64 Linux box gets the baseline build. That check happens before the download, not after. It verifies the download against the published SHA256SUMS and refuses to install when the sum is missing or does not match. This is an executable that a background daemon then runs unattended, which is not the place to shrug about provenance. It stages the file in the destination directory and renames it over the target. Two reasons. Writing into the running binary truncates the file the kernel is currently executing. And a rename is only atomic within one filesystem, so staging in /tmp and moving across would give up the property that makes this safe at all. A download that fails leaves the working binary exactly as it was, mode included. Flags worth knowing --check reports and exits 1 when an update is waiting, so a cron job can branch on it without parsing anything. --version <x.y.z> installs a specific release in either direction. Going backwards says "Installed" rather than "Updated", because calling a downgrade an update i

Automated test coverage for the Batch transaction feature (XLS-56), grouped by the invariant or execution mode each test exercises with 189 tests. Category Test Count Execution Modes 42 Multi-Account & Multi-Sign 23 Tickets, Replay & Metadata 7 Vault, Loan & Transaction Types 24 Signature & Structural Validation 10 Security & Adversarial 56 Cross-Feature Interactions 27 Total 189 1. Execution Modes AllOrNothing Test Batch allornothing all payments succeed Test Batch allornothing submit batch multiple times Test Batch allornothing one payment fails Test Batch allornothing all payments fail Test Batch allornothing mixed transaction types Test Batch allornothing fee calculation Test Batch allornothing max inner transactions Test Batch allornothing more than max inner transactions Test Batch allornothing cash same check multiple times Test Batch allornothing fail and then succeed Test Batch allornothing with tickets Test Batch allornothing deep rollback on late inner failure Test Batch allornothing value conservation OnlyOne Test Batch onlyone first succeeds Test Batch onlyone first fails second succeeds Test Batch onlyone all fail Test Batch onlyone offer priority Test Batch onlyone max inner transactions Test Batch onlyone more than max inner transactions Test Batch onlyone cash same check multiple times Test Batch onlyone fail and then succeed UntilFailure Test Batch untilfailure all succeed Test Batch untilfailure stops at first Test Batch untilfailure stops at second Test Batch untilfailure stops at third Test Batch untilfailure sequential setup Test Batch untilfailure progressive payments Test Batch untilfailure mixed success failure pattern Test Batch untilfailure max inner transactions Test Batch untilfailure more than max inner transactions Test Batch untilfailure cash same check multiple times Test Batch untilfailure fail and then succeed Independent Test Batch independent all succeed Test Batch independent some fail Test Batch independent all fail Test Batch

Coding agents become much more useful when you stop treating the prompt as a request for code and start treating it as a specification for a change. A request such as: Fix the login problem. contains almost none of the information required to review the resulting implementation. Which login problem? Which files may change? What behavior must remain unchanged? How will we know the fix actually works? For work inside an existing repository, a simple four-part framework is usually more useful: Task → Context → Scope → Acceptance Criteria 1. Task: define observable behavior Start with the smallest useful description of what should change. Instead of: Add filtering. Try: Task: Add a Completed / Incomplete filter to the task-list page. Expected behavior: - "Completed" shows only completed tasks. - "Incomplete" shows only incomplete tasks. - "All" remains the default. - The filter must work together with the existing text search. The agent now has a behavior to implement instead of a vague direction. 2. Context: make the repository part of the prompt You usually do not need to paste half the codebase. Ask the agent to inspect the relevant project files first: Context: - Read src/components/TaskList.tsx. - Read src/hooks/useTasks.ts. - Follow the patterns already used by the project. - Check the project's existing instructions before making changes. The goal is not to dictate the implementation. The goal is to make the agent learn the local conventions before inventing new ones. Permanent conventions are better stored in project-level instructions when your coding tool supports them. For example: - Use the package manager already configured in the repository. - Do not edit generated files. - Discover validation commands from project configuration. - Preserve unrelated changes. This keeps individual prompts focused on the task. 3. Scope: control the size of the diff A coding agent can solve the right problem in the wrong way. One common failure mode is unnecessary expansion

There is a piece of advice that circulates endlessly through mentoring conversations, coding bootcamps, and LinkedIn posts aimed at people trying to break into the tech industry. Get certified. Build something for your GitHub. Put together a portfolio. Contribute to open source. Let’s call this “the checklist”. It’s not bad advice, and it wasn’t bad advice when people started giving it. The problem is that enough people have followed it that it has stopped being advice and started being a floor. The rise of LLMs has only sharpened this, making it far easier to write a polished, tailored CV that hits every mark on a job description, or to spin up a portfolio project. The checklist looks less distinctive than ever. It’s the minimum, not the differentiator. I see this clearly through my work with CodeYourFuture, a charity that provides free technical training and career support to people from underrepresented backgrounds. The people I mentor there have worked hard to get where they are; some are still learning and trying to land their first role, others are already in the industry and trying to figure out how to progress. What I notice, talking to them, is that the checklist items are rarely what’s holding them back. They have the certifications. They have the GitHub repos. They are doing everything they were told to do, and they are still finding it difficult to stand out. Standing out requires something else, and that thing is not to add another certification to their LinkedIn. At London Tech Week this year, I listened to speakers from some of the biggest names in the industry. The same hiring wishlist kept coming up: curiosity, adaptability, and the ability to learn. They want evidence that someone can pick up an unfamiliar codebase, work in a different context, shift between problem domains without falling apart. These qualities matter more to them than any specific technical credential. The difficulty — and every speaker acknowledged it — is that these qualities a

The build process for iOS applications involves multiple technical stages, including source code compilation, resource packaging, code signing, and IPA generation. Xcode is the first choice for most iOS developers, but build tools are not limited to Xcode alone; choosing the right tool for different development scenarios can significantly improve efficiency. xcodebuild: The Command-Line Version of Xcode xcodebuild is a command-line build tool bundled with Xcode that compiles and packages without opening Xcode. Common commands include: xcodebuild build to build the project, xcodebuild archive to create an Archive, and xcodebuild -exportArchive to export an IPA. xcodebuild is suitable for integration into CI/CD. CI/CD platforms such as Jenkins, GitHub Actions, and GitLab CI can invoke xcodebuild to perform automated builds. Its downside is that there are many parameters, with over a dozen common parameter combinations, requiring time for initial configuration. Moreover, xcodebuild depends on the Xcode environment and can only be used when Xcode is installed on a Mac. Fastlane: An Automated Build Tool Fastlane, written in Ruby, is an automation toolchain built on top of xcodebuild. It defines the workflows for building, testing, signing, and releasing through a Fastfile configuration file. For instance, lane :release defines a release pipeline that executes operations such as incrementing the version number, compiling, packaging, and uploading to TestFlight in sequence. Fastlane's match feature manages certificates and provisioning profiles, solving the problem of certificate synchronization in team collaboration. gym encapsulates the complex parameters of xcodebuild, allowing an IPA to be generated with a single command. Fastlane also has a rich plugin ecosystem covering push notifications, screenshots, and metadata management. Project Management with CocoaPods and XcodeGen CocoaPods handles the integration of third-party dependencies. Declare the dependent libraries

I built an agent last year, and I was proud of it. It had a planner. It had tools. It had a...

In two weeks, I built Retro Dynamics Agent, an app that generates retrospective activities for teams, facilitates them on a real-time collaborative board, and turns the outcomes into Jira or Azure DevOps tickets. I built it working with an AI coding agent, Claude Code, throughout almost the entire process: design, implementation, production debugging, and documentation. I do not want to tell another “I used AI and it wrote the code for me” story. We have heard that one enough. What I found more interesting were the parts of the project where there was no obvious answer in a tutorial, and how the work was divided in those situations. I defined the constraints and made the underlying decisions. The agent proposed concrete technical solutions and implemented them. Then the responsibility for verifying that everything actually worked, not just that it compiled, came back to me. Here are three examples from the project. 1.- Connecting to Jira without server-side sessions or frontend memory I wanted any team to be able to connect its own Jira account through OAuth, instead of relying on a global token that only I could configure. The problem was that my application runs entirely on serverless functions. Nothing stays in memory between requests, and the frontend does not maintain its own state either. No localStorage. No router. An OAuth login means leaving the application, authenticating with Atlassian, and then coming back. But coming back to what, if nothing remembers which screen you were on? Before touching the code, I asked the agent to create a complete implementation plan, including the files that would need to change, the design decisions, and the scope. I reviewed that plan as if it were a pull request from another developer. I made decisions such as: For now, only Jira would use OAuth. Azure DevOps would keep its manual token flow because setting up OAuth there is considerably more involved. Tokens would be encrypted before being stored in the database, never sa

Picture, you join a new team working on a big system. Everybody who knew anything has left, either to find greener grass or to enjoy a well deserved pension. You and the team struggle to build new features for the system or to adapt functionality to match changes in legislation. Not to mention the trouble it is to figure out what to fix when things go wrong. At the same time, the business that you support is screaming for innovation and pushing for more and more changes. Recognize this situation? Ever experienced it yourself? A world full of legacy systems “Legacy. What is a legacy? It’s planting seeds in a garden you never get to see.” – Lin-Manuel Miranda, “Hamilton” Legacy, the thing that you are remembered for, typically the word has a positive meaning… how come that in tech the word “Legacy” has such a bad connotation? When we call out a legacy system, we usually mean: code without tests ( Michael Feathers ) or code you “got” from somebody else, or code that you’re scared to touch. However, there is a reason these legacy systems are still around. In almost all cases, that system still brings in money or is somehow still valuable. If it did not bring any value anymore, wouldn’t it be decommissioned? There must be something in these systems that makes them survive, where other systems did not. How systems become “Legacy” So legacy systems are those that have become hard or scary to change. In my experience, that not because something is wrong with the code or technology. The major contributing factor is usually that the knowledge about the system has left the organization. And then I don’t mean the documentation, but the people that built, maintained and ran the system. When those people are gone, you know that nobody else is going to be happy touching that thing. The value of software Code is like a mapping of desired real world behavior to a program that can be executed by a machine. So where is the value of a system, is that in that code? Over the past years I

Payment reconciliation can look completely reliable until a calendar edge case exposes a hidden...

Humanistic Architecture Learning to See Problems Differently I had the opportunity to attend a class called “Humanistic Architecture” by Mr. Chakrit Riddhagni. The class was about applying humanistic principles to software development . Before talking about what I learned, I would like to share a little about my own perspective on software development. Personally, I have a quote and a belief about software development: it is both a science and an art. I see software development as something that has an artistic side, while being grounded in logic, with almost endless possibilities. “Crafting software requires artistry, guided by imagination, grounded in logic, endlessly enduring.” This quote has been one of my inspirations since I started working as a developer. What I mean by this is that I have always liked thinking about software development as a kind of literature . We are not simply writing code. We are solving problems. We are developing and creating something to solve a problem that either we or our customers are facing. Because of this, as a developer, I naturally work with problems every day. But… I never really thought much deeper about what a “problem” actually is. Usually, when we solve a problem for a customer or develop software for them, we receive an issue or a scope of work and then start working on it. We know that something is a problem, so we focus on solving it. But we do not always stop and ask What is the actual structure of this problem ? Is this really the problem? And does the solution we are building actually address the problem we are trying to solve? That changed when I attended the “Humanistic Architecture” class. One of the biggest things I gained from this class was a new perspective and a set of tools for defining what a “problem” really is. Anatomy of a Problem We can look at a problem through the Anatomy of a Problem , which consists of three parts: Current State — where we are now Gap — the difference between where we are and wher

A random game is easier to debug when the same inputs produce the same result. In HoopTrait, a browser basketball project, the Lab mode combines eight selected traits and generates a fictional career. The interesting engineering problem is keeping replay, sharing and validation consistent. This is a technical development note, not a claim that a game score predicts an athlete's real performance. Store the decisions, not just the result The Lab state records a seed, a dataset version and an ordered list of actions. An action is a pick or a reroll. Replaying those actions reconstructs the build. A seed alone is not a complete replay contract: changing the player pool or its order can change a seeded draw. A dataset version therefore matters alongside the random seed. For a future release, the same principle should apply to changes in the rules themselves. Test invariants across many runs The Lab test suite iterates through 1,000 seeds. For each seed it shuffles the order of the eight skills, uses the two allowed rerolls, and completes a build. It checks that: Eight distinct players were selected. All eight traits are present, and no player remains to be drawn after completion. The overall game score stays between 0 and 99 and matches the shared rating function. Packing and unpacking the share state returns the original state. Recomputing the fictional career returns the same output. The ten simulated seasons sum to the displayed career earnings. Those assertions catch different problems. A stable score does not prove that a shared link reproduces the same selections. A complete build does not prove that its season totals add up. Reject impossible histories A share payload is untrusted input, even in a client-side game. Negative or fractional seeds, duplicate skill picks, a third reroll, unknown action types, a mismatched dataset version and actions after completion are rejected. The tests also cover malformed encoded payloads and unexpected fields. Local state is usef

In December 2024, Google quietly updated its closed testing rules for personal developer Console accounts. For months, indie developers had to recruit at least 20 testers to keep their app opted in for 14 consecutive days before applying for production access. Under the revised guidelines, that threshold dropped from 20 to 12 testers. Understanding the nuances of the Google Play 20 testers vs 12 testers shift helps you plan your release schedule accurately without running into unexpected delays during Google Play Console verification. While lowering the number by eight testers sounds like a major relief, the core requirements behind closed testing have not changed. Google still enforces a strict 14 consecutive day duration, and the Play Console continues to monitor tester retention and engagement. A lower numerical requirement means less logistical hassle, but maintaining a stable group of committed testers remains the primary hurdle for independent developers. The Policy Shift: From 20 to 12 Testers Google originally introduced mandatory closed testing in November 2023 to improve app quality and curb low-effort submissions on the Play Store. Initially, all new personal accounts registered on or after November 13, 2023, were required to run a closed test with at least 20 opted-in testers for 14 days without interruption. After roughly a year of developer feedback regarding how difficult it was for solo creators to find 20 reliable participants, Google reduced the requirement to 12 testers in December 2024. It is crucial to understand who this rule applies to. The requirement exclusively targets personal developer accounts created on or after November 13, 2023. If you operate an organization or business developer account, or if your personal account was registered before November 13, 2023, you are currently exempt from this mandatory closed testing gate. However, if you fall under the new personal account category, reaching 12 continuous opt-ins is a strict prerequis

readm3 can edit now, and it speaks Reddit readm3 started as a markdown reader for the terminal. File browser on the left, rendered document on the right. Version 0.3.0 adds the obvious missing half: you can change the file you are looking at. Press e , type, press esc . The preview has already re-rendered by the time you get back to it, because both modes read the same buffer. There is no second preview to keep in sync, which is the part that usually goes wrong in editors with a live preview pane. ctrl+s saves. Quitting with unsaved work asks first. enter continues the list you are in, so the same bullet, the next number, or an unchecked box for a task, and pressing it on an empty item ends the list. There is no selection and no cut and paste. This is for fixing a typo and adding a paragraph. Your editor is still your editor. Two dependencies, not forty The old parser was a few hundred lines of hand-rolled regex, and it got reference links, nested lists and bare URLs wrong. Every fix was another regex. Parsing moved to marked. The reason it won was not features, it was weight: marked is CommonMark plus GFM with zero dependencies of its own . readm3 went from one dependency to two. markdown-it would have been seven. A remark and micromark pipeline is somewhere between twenty and forty packages, for a program whose whole point is that it starts instantly in a terminal. Only the parsing moved. The layout code that wraps text, draws code gutters and sizes tables is untouched, so readm3.com still renders through the exact same functions the terminal does. There is still no second renderer. The swap fixed reference links, nested and loose lists, bare URL autolinks and hard line breaks for free. The dialects actually disagree marked does not ship GitHub alerts, footnotes, :emoji: , or anything Reddit added. Those are tokenizer extensions in readm3 now, still with no new dependency. They are behind a --flavor switch rather than all on at once, because the dialects contradic

Why building reliable AI features requires more than better prompts A few years ago, building an AI feature often looked surprisingly simple. Write a prompt. Send some text to a model. Look at the response. Improve the prompt. Repeat. Eventually, the output gets good enough and the feature ships. That approach still works for many things. It works especially well when the task is simple, the consequences are low, and a human remains responsible for the final result. But production software introduces a different set of questions. What context should the model receive? Which data is it allowed to access? Which tools can it use? What happens when it chooses the wrong tool? How do we know a model or prompt change didn’t make the system worse? How do we debug a failure that happened only once? What happens when the model produces valid JSON containing an invalid business decision? And perhaps the most important question: How much autonomy should we give a system whose behavior is probabilistic? These are not prompt engineering questions. They are engineering questions. That is why I think we are seeing a shift from prompt engineering toward AI engineering. I don’t mean that AI engineering is a completely new discipline. Much of it comes from software engineering, MLOps, LLMOps, distributed systems, security, testing, and platform engineering. What is changing is the combination. The model has become a new kind of software component — one that can interpret, reason, generate, and increasingly act, but cannot be treated like deterministic code. That changes the engineering problem. From Prompts to Systems Prompt engineering is useful because it addresses a real problem. A model needs instructions. The way we formulate those instructions can have a significant effect on the result. But a prompt is only one part of the system. Consider a CRM application that asks an AI assistant to recommend the next action after a customer meeting. A prompt might look like this: Review the

Agentic Methods: Coding With AI Agents, Designing For Agents TL;DR "Agentic methods" covers two distinct things colliding right now: AI agents that code alongside the team (read, write, run, verify, in a loop), and agentic architectures we design into our own systems (orchestrating autonomous agents on the product side). In both cases, the same principle applies: an agent is only useful if the contract around it is explicit — scope, errors, permissions, stopping points. The Tech Lead role doesn't disappear, it shifts: fewer lines typed, more specification, review, and governance. The underlying topic isn't tooling, it's clarity — exactly like a well-modelled business workflow. Table of Contents Introduction — one word, two meanings Coding with AI agents: what actually changes From autocomplete to the agentic loop The developer's role shifts toward review Explicit guardrails Designing agentic architectures An agent is a box with a contract Orchestration or autonomy: a choice, not a default Observability: if you can't replay it, you can't debug it Where humans remain irreplaceable A Tech Lead checklist for adopting these methods Conclusion — agents reveal a team's maturity Introduction — one word, two meanings "Agentic" has been everywhere for a few months, but it means two different things depending on who's talking: Coding with AI agents : a tool that reads code, writes diffs, runs commands, launches tests, and iterates until it reaches a correct result — instead of suggesting one line at a time. Designing agentic systems : a software architecture where autonomous agents (often themselves LLM-based) make decisions, call tools, and cooperate to accomplish a business task — a support chatbot that triggers refunds, a document pipeline that routes complex cases to a human on its own. These are two separate topics, but the same underlying principle runs through both: an agent — human, AI, or service — is only reliable when it operates inside an explicit frame. It's the s

Much of the traditional software operations we deal with are online, we click a button, wait for a moment, and the transaction or operation is completed. But there is a big area that deals with software operations that require offline processing. For example, background processing of jobs, e.g., OpenAI training/improving its existing GPT models behind the scenes using the data it gathers from its users. Batch Processing Whenever such an offline system runs a job that typically generates output from a batch of inputs, we call that batch processing. Inputs here are immutable, which avoids side effects. Benefits of batch processing: You can time travel. In case of any failure or unintentional outputs, you can jump to the last input checkpoint before a batch processing job. This handling is often referred to as human fault tolerance. Using batch processing and offline systems, compute usage efficiency can be improved. For example, whenever a heavy computation needs to be done, it's better to do it in bulk on maybe a GPU compute rather than crashing the CPU host where the server is online. Though the boundary between online and batch processing is not always clear. For example, a long-running database query could also be categorised as batch processing. Another alternative to batch processing is stream processing, which we will understand in the next article. MapReduce MapReduce is a batch processing algorithm that is utilized by Hadoop, CouchDB, and MongoDB as well. It is a balanced approach that is less extreme than completely parallelizing the jobs. There are several other frameworks like this that are now replacing MapReduce. For example, DataFrames APIs, query languages, etc. We will see MapReduce in detail sometime later. Simulating Batch Processing with Unix Tools (Single Host) If you are a Linux user, this simulation could be very easy for you to grasp. If not, just put it in ChatGPT or any AI tool to understand the command in detail if interested. A typical Ngin

Under-the-hood breakdown of Huawei’s “Pure HarmonyOS” SDK for engineers and architects. For the past decade, mobile operating system architecture has been dominated by two paradigms: Android’s JVM-based, garbage-collected model, and iOS’s Darwin/Mach kernel with Swift/Objective-C. Huawei’s HarmonyOS NEXT introduces a third path. Often referred to as “Pure HarmonyOS,” this iteration completely drops AOSP (Android Open Source Project) compatibility. It is a microkernel-based, distributed operating system built from the ground up around a custom AOT compiler and a declarative UI framework. If you are a senior engineer or architect, looking at the HarmonyOS SDK can feel disorienting. The terminology shifts from Activities to UIAbilities, from ViewGroups to ArkUI, and from Java/Kotlin to ArkTS. To truly master this ecosystem, we must strip away the IDE abstractions and marketing terminology. Let’s reconstruct the HarmonyOS NEXT SDK from the silicon up — the Feynman way — to understand exactly how the machine breathes. The Core Engine: How Does HarmonyOS Execute Code Without a JVM? Press enter or click to view image in full size Android translates Java/Kotlin into Dalvik bytecode, which runs on the Android Runtime (ART) virtual machine atop a Linux kernel. HarmonyOS NEXT takes a fundamentally different path, utilizing the ArkCompiler and the Ark Runtime. JavaScript and TypeScript are dynamically typed. A virtual machine spends massive amounts of CPU cycle time inferring types and managing garbage collection. This overhead is unacceptable for a high-performance OS UI layer. ArkTS is a strict subset of TypeScript. It explicitly bans any , dynamic property addition, and eval . Why? Because the ArkCompiler is an AOT (Ahead-of-Time) compiler. When you trigger a build in DevEco Studio: 1.The ArkTS code is statically parsed. 2.Because the compiler possesses absolute type certainty (due to strict typing), it translates ArkTS directly into C/C++ data structures. 3.These structures

บทวิเคราะห์ "Agentic Software", paper ที่เลิกใช้ชื่อ "The End of Software Engineering" เพื่อเล่าเรื่องวิชาใหม่ที่กำลังเกิด โดย Nokka (นก-กา), นักเขียนอิสระสายเทคโนโลยี ผู้เขียนบทความอธิบายเทคโนโลยีให้คนทั่วไปเข้าใจ 30+ บทความบน dev.to | 5 กันยายน 2026 บทความนี้เขียนโดย AI (glm-5.3 via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา), อ้างอิงจาก paper วิจัยบน arXiv ฉบับเต็ม (2606.05608v1) ของ Zhenfeng Cao มี paper หนึ่งบน arXiv ที่จัดเป็นประเด็นที่สุดของปีหนึ่งงาน: "Agentic Software: How AI Agents Are Restructuring the Software Paradigm" โดย Zhenfeng Cao จาก Lingxi Intelligent Investment เมืองเสิงเจ๋น [1] เกร็ดที่ทำให้ paper นี้น่าสนใจกว่าชื่อที่เห็นคือมันเคยใช้ชื่อห้าวห้าสุดมาก่อน: ฉบับแรก (v1, มิ.ย. 2026) มีชื่อว่า "The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm" ก่อนผู้แต่งจะตัดคำว่า End ทิ้งเองใน v2 ซึ่งออกมาหกวันต่อจาก v1 พอดี เหมือนยอมรับว่าคำนั้นกลายเป็นการตัดสินประเด็นเกินเนื้อหาจริง เรื่องนี้ไม่ได้แค่เล่าจับฉาก แต่มีโครงเหตุผลจริงเป็นสามชั้น: วิชา software engineering เกิดจากข้อตั้งต้นหนึ่งที่ใช้มา 50 ปี, ข้อตั้งต้นนั้นกำลังหมดความหมายเพราะ agent, และสิ่งที่จะเกิดขึ้นแทนมีชื่อใหม่ที่ผู้เขียนเรียกว่า Agentic Engineering บทความนี้พาไล่ดูตามเหตุผลของเขาทีละชั้น พร้อมบอกด้วยว่าจุดไหนควรเชื่อแค่ไหน ก่อนอื่น, ทำความเข้าใจศัพท์ Software engineering : วิชาวิธีสร้างซอฟต์แวร์อย่างเป็นระบบ เกิดเป็นศัพท์ทางการที่ประชุม NATO ปี 1968 จากวิกฤต "ซอฟต์แวร์บวม" ของยุคนั้น AaaS (Agent-as-a-Service) : ศัพท์ที่ paper ตั้งใหม่ สำหรับยุคที่ผู้ใช้จ่ายเงินแลก "ผลลัพธ์จาก agent" ไม่ใช่ "ชั่วโมงหรือสิทธิ์ใช้ซอฟต์แวร์" Intent architect : บทบาทมนุษย์ยุคใหม่ที่ paper ทำนาย คนที่เขียน "เจตนา" ให้ชัดพอที่ agent จะเอาไปรันได้ แทนการเขียนโค้ดเอง ถ้าให้อุปมา: วิชาเดิมเหมือนวิชา "สถาปัตรกรรมสำหรับอาคารอิฐ" ที่สอนว่าจะกออิฐทีละก้อนอย่างไรให้บ้านไม่พัง วันหนึ่งปรากฏเครนอัตโนมัติที่รับแบบจากคำบอกของเจ้าของบ้านแล้วสร้างเองได้ทั้งหลัง วิชากออิฐยังมีคนใช้อยู่ แต่คำถามสำคัญที่สุดของวิชาย้ายจาก "กอยังไงไม่ให้พ

The Shift from Syntax to “Vibe Coding” Writing code used to be the bottleneck. Now, code is free and that’s precisely the problem. If you had told me Five years ago that my terminal would routinely spin up background execution agents, draft full-stack features, and push PRs before I finished my morning coffee, I would have assumed you were selling a tech startup pipe dream. Back then, GitHub Copilot was a neat trick: an glorified tab-completion tool that occasionally saved you from typing out a boiler-plate fetch request or regex string. Fast forward to today, and we’ve entered the era of “Vibe Coding.” You state intent in natural language. You direct agents in your editor. You prompt terminal workflows. Code manifests at conversational speed. You aren’t typing out syntax line-by-line; you’re steering an autonomous orchestra. The developer experience feels almost magical, fluid, and dizzyingly fast. But as the velocity of code creation hits lightspeed, an uncomfortable truth is beginning to surface across engineering teams: the cognitive load of software engineering hasn’t disappeared — it has simply shifted. We traded the friction of writing syntax for the far more taxing chore of evaluating architectural integrity, managing context drift, and catching silent edge-case failures in code we didn’t actually write. Code is easier to generate than ever, but system comprehension is at an all-time low. And nowhere is this trade-off creating more friction than in the middle tier of the software engineering workforce. The “Middle-Tier” Squeeze Senior engineers act as directors; AI handles the grunt work. Where does that leave everyone in between? For decades, the career progression of a software engineer followed a reliable, well-trodden path. You entered the industry as a junior, grinding away on bug fixes, writing unit tests, and building basic CRUD endpoints. Slowly, through hundreds of hours of raw syntax exposure, you built up mental models. You learned how state manag

I built a checker for a configuration directory. The time went not into adding rules, but into deciding what not to add . Things you could detect are easy to think of. That was never the constraint. One false positive is enough to get the tool thrown out A checker is asymmetric. A miss goes unnoticed. The cost is only that you did not learn something you could have. A false positive stops the reader and demands a decision: is this actually wrong? And once someone has been burned, they read every finding with suspicion . Twice, and the tool comes out of CI. So a checker that calls a valid configuration broken is worse than no checker. Better ten rules with no false positives than thirty with one. That is obvious in the abstract and hard in practice, because while you are writing the code, every "oh, I could check that too" pulls in the other direction. No citation, no rule So I fixed one condition for adding a rule: Only check what the official documentation states outright — as an error, as skipped, or as ignored. If the documentation does not say it, the rule does not go in, however wrong the pattern looks. What this buys is that the judgement stops living in my memory. "I'm fairly sure that form was invalid" is not a citation, and my memory goes stale the moment the tool it describes releases a new version. In the implementation, every finding carries its reason: export interface Finding { severity : " error " | " warn " ; file : string ; line ?: number ; /** what is wrong, in one sentence */ message : string ; /** why that can be claimed — includes the source URL */ because : string ; } Making because required is the point. A rule you cannot justify cannot be written , because the type will not let you leave the field out. If no source comes to mind, the rule never gets implemented. The tests enforce it too: for ( const f of findings ) { if ( ! f . because . includes ( " https:// " )) fail ( `no source: ${ f . message } ` ); } One finding without a source URL fai