<div class = 'img-link'><a href = 'https://martinfowler.com/articles/harness-engineering.html'><img src = 'https://martinfowler.com/articles/harness-engineering/card.png' width = '350px'></img></a></div> <p>上个月,<b class = 'author'>Birgitta Böckeler</b> 写下了她对 Harness Engineering 这一新兴概念的初步思考。过去几周里,她持续研究并深化了这一主题,如今给出了一套更完整的心智模型,帮助人们更有效地驱动 coding agents。</p> <p><a class = 'more' href = 'https://martinfowler.com/articles/harness-engineering.html'>更多…</a></p>
<div class = 'img-link'><a href = 'https://martinfowler.com/articles/harness-engineering.html'><img src = 'https://martinfowler.com/articles/harness-engineering/card.png' width = '350px'></img></a></div> <p>Last month <b class = 'author'>Birgitta Böckeler</b> wrote some initial thoughts about the recently developed notion of Harness Engineering. She's been researching and thinking more about this in the weeks since and has now written a <a href = 'https://martinfowler.com/articles/harness-engineering.html'>thoughtful mental model</a> for understanding harness engineering that we think will help people to drive coding agents more effectively.</p> <p><a class = 'more' href = 'https://martinfowler.com/articles/harness-engineering.html'>more…</a></p>
发布日期:2026-04-02 · 来源:Martin Fowler
Published: 2026-04-02 · Source: Martin Fowler
AIAIAI AgentAI Agent架构Architecture
零售商已经意识到,搜索与发现环节正在重构;接下来会发生什么仍未定型。从嵌入式结账到新兴第三方入口,文章梳理了电商与 AI 领导者如何把 agentic commerce 落进实际流程。
Retailers know search and discovery have already shifted. What comes next is less settled. From embedded checkout to emerging third-party surfaces, here’s how ecommerce and AI leaders are integrating agentic commerce.
发布日期:2026-04-02 · 来源:Stripe Engineering
Published: 2026-04-02 · Source: Stripe Engineering
AIAIAI AgentAI Agent
一个版本只花了 5 分钟,另一个用了 8 小时。作者解释了为什么更慢的那种做法,反而是更值得的决定。
One took 5 minutes. The other took 8 hours. Here’s why the slow one was the better decision.Continue reading on Medium »
发布日期:2026-04-03 · 来源:Medium Programming
Published: 2026-04-03 · Source: Medium Programming
AIAI随笔随笔
身份与同意是现代系统中最关键的两类信号,但它们往往不是以“报错”的方式失效,而是以设计错位的形式失真。
Two of the most critical signals in modern systems — identity and consent — often fail not as errors, but as design misalignments.Continue reading on Medium »
发布日期:2026-04-03 · 来源:Medium Design Systems
Published: 2026-04-03 · Source: Medium Design Systems
设计Design随笔随笔
在快速变化的数字世界里,企业需要的不只是一个基础网站,而是更强大、可交互、可扩展的 Web 应用能力。
In today’s fast-moving digital world, businesses need more than just a basic website. They need powerful, interactive, and scalable…Continue reading on Medium »
发布日期:2026-04-03 · 来源:Medium UI Design
Published: 2026-04-03 · Source: Medium UI Design
随笔随笔
一篇面向初学者的 CSS 布局与响应式设计入门文章,延续作者前一篇 CSS 基础内容,帮助读者继续搭建前端基本功。
Halo temen-temen, konnichiwa!! Gimana nih kabarnya? semoga masih semangat buat belajar ya! Setelah kemarin kita belajar tentang CSS Dasar…Continue reading on Amikom Computer Club »
发布日期:2026-04-03 · 来源:Medium Frontend
Published: 2026-04-03 · Source: Medium Frontend
前端Frontend设计Design随笔随笔
作者以初学者视角解释 Flutter 中的 Clean Architecture,梳理展示层、领域层、数据层的职责,以及从用户交互到 API 再回到 UI 的完整流转。
When I first started learning Flutter, my code worked, but it was messy! Everything was mixed together, like UI, API calls, logic, and debugging felt like a nightmare. Then I discovered Clean Architecture. At first, it looked complicated, but once I understood the flow, everything changed. Today, I want to share a simple, beginner explanation. 🧠 What is Clean Architecture? Clean Architecture is a way to organize your code into layers so that your app becomes: ✅ Easy to understand ✅ Easy to maintain ✅ Scalable for large projects In Clean Architecture, there are three layers. 🔵 1. Presentation Layer (UI) This is what users see and interact with. Screens (SignIn, SignOut) State Management (Provider, Bloc, GetX, etc.) 👉 Responsibilities: Take user input Show data Update UI automatically 🟡 2. Domain Layer (Brain) This is the core logic of your app. 👉 Includes: UseCases(SignIn, GetProfile) Repository (abstract class) 👉 Responsibilities: Decide what should happen Define rules and actions 🔴 3. Data Layer (Worker) This layer does the actual work. 👉 Includes: RemoteDatasource (API calls) RepositoryImpl (Implementation of Repository) Models (JSON to Dart) 👉 Responsibilities: Call backend API Convert JSON to objects Handle data logic 🔄 Full Flow (Step-by-Step) Here’s how everything works together: User Action (Button Click) ↓ UI (Screen) ↓ Provider (State Manager) ↓ UseCase (What to do) ↓ Repository (Contract) ↓ RepositoryImpl (How to do) ↓ RemoteDatasource (API Call) ↓ Backend Server ↓ JSON Response ↓ Model (Convert to Object) ↓ Provider (Update State) ↓ UI Rebuild (notifyListeners in Provider) 🎯 Real-Life Example Think of it like a restaurant 👤 User → Customer 🧑💼 Provider → Manager 🧾 UseCase → Waiter 🍳 API → Kitchen 📦 Model → Food Flow: Customer → Manager → Waiter → Kitchen → Food → Customer 💡 Why Use Clean Architecture? Because your future self will thank you! 🧠 Key Lessons I Learned ✔ Separate UI from logic ✔ Keep business logic in UseCases ✔ Use Repository as a contract ✔ Convert API response using Models ✔ Always update UI via state management 🚀 Final Thought At first, Clean Architecture feels complex… But once you understand the flow, it becomes powerful and addictive If you're learning Flutter, don’t skip this. This is what takes you from beginner → professional developer. 💬 Let me know: Have you tried Clean Architecture in your Flutter projects? If you have any suggestions for me, feel free to suggest them for me to do better. Thank You!
发布日期:2026-04-03 · 来源:DEV Community
Published: 2026-04-03 · Source: DEV Community
前端Frontend后端Backend架构Architecture移动移动
框架不只是样板代码,它还固化了项目结构、逻辑边界与请求处理方式。但“框架有用”并不等于“任何场景都该先上框架”。文章强调先理解语言本身,再决定何时引入框架,尤其是在小项目、受限部署环境或问题模型不匹配时。
Frameworks are good for more than just boilerplate. They encode decisions: how to structure a project, where logic belongs, how to handle requests. A developer picking up Laravel or Spring for the first time isn't just getting free code — they're inheriting years of hard-won conventions. That's valuable. It means a junior and a senior on the same team are solving the same problem in the same -almost- shape. But "frameworks are useful" doesn't mean "always use a framework." Knowing when not to reach for one is as important as knowing how to use one. When you're still learning the language This is the one that gets skipped most often, and causes the most damage later. When the only mental model is Laravel does it this way, it's not really programming — it's copying at a higher level. Instead of copying Stack Overflow snippets, copying framework patterns. The abstraction is more sophisticated, but the understanding underneath is the same. When a bug appears outside the framework's happy path, or something it doesn't support cleanly is needed, there's nothing to fall back on. A concrete example: webhook signature verification. // ❌ What you might write if you only know framework routing $expected = 'sha256=' . hash_hmac('sha256', $rawBody, $secret); return $expected === $received; // Vulnerable to timing attacks // ✅ What learning the language teaches you $expected = 'sha256=' . hash_hmac('sha256', $rawBody, $secret); return hash_equals($expected, $received); hash_equals() instead of ===. This is a language-level security detail that prevents timing attacks. No framework teaches this — it's just PHP. Learning PHP only through a framework, a developer might write === and never know it was wrong. Learn the language first. Write raw SQL before using an ORM. Handle routing yourself before adding a router. Not forever — just long enough to see what the abstraction is actually doing for you. When the project is small enough to not need one A framework has a cost beyond file size or boot time. The mental overhead of fitting your problem into its model is real. For a 200-line script, a standalone endpoint, or a cron job that reads a file and sends an email — that cost doesn't pay off. A script that runs once a day and calls one external service doesn't need routing, DI containers, or a migration system. It needs to work. The same principle applies to pulling in packages. PointArt's self-updater downloads release zips from GitHub with no HTTP client library: // ❌ Reaching for a package by default $client = new GuzzleHttp\Client(); $zip = $client->get($zipUrl)->getBody(); // ✅ PHP already handles this natively $ctx = stream_context_create(['http' => ['timeout' => 30]]); $zip = file_get_contents($zipUrl, false, $ctx); Knowing the language means knowing when the standard library is enough — and not adding a dependency graph to solve a problem that was already solved. The question isn't could I use a framework here? It's does this problem have enough surface area that shared conventions help me manage it? When the framework's model doesn't fit your problem Frameworks are designed around specific problem shapes. A web framework expects HTTP request/response cycles. An MVC framework expects controllers, models, views. If your project doesn't fit that shape — a long-running daemon, a CLI tool, a data pipeline, a batch processor — you spend as much effort fighting the framework as building the thing. When I built PointArt, I had to make this call explicitly: no middleware system, no async, single-process, designed for shared hosting. Not oversights — deliberate limits because the target problem is the web request/response cycle on constrained hosting. The AI angle There's a new version of the "framework without language knowledge" problem: using AI to generate framework code without understanding either. With enough prompting you can build something that looks like a working application. Frameworks help AI here — it's seen a lot of Laravel and Rails, so it generates plausible-looking code. But when something goes wrong, and it will, you have no model of what correct looks like. You can't debug what you can't read. You can't maintain what you don't understand. AI is a strong tool for developers who already know what they're doing. It fills in boilerplate fast. But the understanding it skips is exactly what you'll need when the generated code misbehaves. The practical signals Use a framework when: Multiple developers need shared conventions across a long-lived codebase The problem shape fits the framework's model well Skip it when: You're still learning the language fundamentals The project is small enough that the model costs more than it saves The deploy target rules it out Your problem shape doesn't match the framework's assumptions The goal is not to avoid frameworks. It's to know what they're doing — so you can choose when to use them, and know what to do when they stop working. I've been writing about building PointArt — a zero-dependency PHP micro-framework — from scratch. If you're curious about what it looks like to make these decisions at the framework level, you can take a look at PointArt Devlog Series.
发布日期:2026-04-03 · 来源:DEV Community
Published: 2026-04-03 · Source: DEV Community
后端Backend安全SecurityAIAI
随着 LLM 产出越来越多代码,团队开始用“认知债务”和“意图债务”来理解系统健康;Shaw 与 Nave 的论文把 AI 纳入 Kahneman 双系统认知模型,提出 AI 作为 System 3 的视角;Ajey Gore 则进一步指出,如果 coding agent 让写代码更便宜,那么真正昂贵的事情会变成 verification。Fowler 也补充说,在遗留系统理解与抽象命名层面,LLM 依然大有可为。
<p>As we see LLMs churn out scads of code, folks have increasingly turned to Cognitive Debt as a metaphor for capturing how a team can lose understanding of what a system does. Margaret-Anne Storey thinks a good way of thinking about these problems is to consider <a href="https://arxiv.org/abs/2603.22106">three layers of system health</a>:</p> <blockquote> <ul> <li>Technical debt lives in code. It accumulates when implementation decisions compromise future changeability. It limits how systems can change.</li> <li>Cognitive debt lives in people. It accumulates when shared understanding of the system erodes faster than it is replenished. It limits how teams can reason about change.</li> <li>Intent debt lives in artifacts. It accumulates when the goals and constraints that should guide the system are poorly captured or maintained. It limits whether the system continues to reflect what we meant to build and it limits how humans and AI agents can continue to evolve the system effectively.</li> </ul> </blockquote> <p>While I’m getting a bit bemused by debt metaphor proliferation, this way of thinking does make a fair bit of sense. The article includes useful sections to diagnose and mitigate each kind of debt. The three interact with each other, and the article outlines some general activities teams should do to keep it all under control</p> <p> ❄ ❄</p> <p>In the article she references a recent paper by Shaw and Nave at the Wharton School that <a href="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6097646">adds LLMs to Kahneman’s two-system model of thinking</a>.</p> <p>Kahneman’s book, “Thinking Fast and Slow”, is one of my favorite books. Its central idea is that humans have two systems of cognition. System 1 (intuition) makes rapid decisions, often barely-consciously. System 2 (deliberation) is when we apply deliberate thinking to a problem. He observed that to save energy we default to intuition, and that sometimes gets us into trouble when we overlook things that we would have spotted had we applied deliberation to the problem.</p> <p>Shaw and Nave consider AI as System 3</p> <blockquote> <p>A consequence of System 3 is the introduction of cognitive surrender, characterized by uncritical reliance on externally generated artificial reasoning, bypassing System 2. Crucially, we distinguish cognitive surrender, marked by passive trust and uncritical evaluation of external information, from cognitive offloading, which involves strategic delegation of cognition during deliberation.</p> </blockquote> <p>It’s a long paper, that does into detail on this “Tri-System theory of cognition” and reports on several experiments they’ve done to test how well this theory can predict behavior (at least within a lab).</p> <p> ❄ ❄ ❄ ❄ ❄</p> <p>I’ve seen a few illustrations recently that use the symbols “< >” as part of an icon to illustrate code. That strikes me as rather odd, I can’t think of any programming language that uses “< >” to surround program elements. Why that and not, say, “{ }”?</p> <p>Obviously the reason is that they are thinking of HTML (or maybe XML), which is even more obvious when they use “</>” in their icons. But programmers don’t <em>program</em> in HTML.</p> <p> ❄ ❄ ❄ ❄ ❄</p> <p>Ajey Gore thinks about <a href="https://ajeygore.in/content/the-expensive-thing">if coding agents make coding free, what becomes the expensive thing</a>? His answer is verification.</p> <blockquote> <p>What does “correct” mean for an ETA algorithm in Jakarta traffic versus Ho Chi Minh City? What does a “successful” driver allocation look like when you’re balancing earnings fairness, customer wait time, and fleet utilisation simultaneously? When hundreds of engineers are shipping into ~900 microservices around the clock, “correct” isn’t one definition — it’s thousands of definitions, all shifting, all context-dependent. These aren’t edge cases. They’re the entire job.</p> <p>And they’re precisely the kind of judgment that agents cannot perform for you.</p> </blockquote> <p>Increasingly I’m seeing a view that agents do really well when they have good, preferably automated, verification for their work. This encourages such things as <a href="https://martinfowler.com/bliki/TestDrivenDevelopment.html">Test Driven Development</a>. That’s still a lot of verification to do, which suggests we should see more effort to find ways to make it easier for humans to comprehend larger ranges of tests.</p> <p>While I agree with most of what Ajey writes here, I do have a quibble with his view of legacy migration. He thinks it’s a delusion that “agentic coding will finally crack legacy modernisation”. I agree with him that agentic <em>coding</em> is overrated in a legacy context, but I have seen compelling evidence that LLMs help a great deal in <a href="https://martinfowler.com/articles/legacy-modernization-gen-ai.html">understanding what legacy code is doing</a>.</p> <p>The big consequence of Ajey’s assessment is that we’ll need to reorganize around verification rather than writing code:</p> <blockquote> <p>If agents handle execution, the human job becomes designing verification systems, defining quality, and handling the ambiguous cases agents can’t resolve. Your org chart should reflect this. Practically, this means your Monday morning standup changes. Instead of “what did we ship?” the question becomes “what did we validate?” Instead of tracking output, you’re tracking whether the output was right. The team that used to have ten engineers building features now has three engineers and seven people defining acceptance criteria, designing test harnesses, and monitoring outcomes. That’s the reorganisation. It’s uncomfortable because it demotes the act of building and promotes the act of judging. Most engineering cultures resist this. The ones that don’t will win.</p> </blockquote> <p> ❄ ❄ ❄ ❄ ❄</p> <p>One the questions comes up when we think of LLMs-as-programmers is whether there is a future for source code. David Cassel on The New Stack has an article summarizing <a href="https://thenewstack.io/ai-programming-languages-future/">several views of the future of code</a>. Some folks are experimenting with entirely new languages built with the LLM in mind, others think that existing languages, especially strictly typed languages like TypeScript and Rust will be the best fit for LLMs. It’s an overview article, one that has lots of quotations, but not much analysis in itself - but it’s worth a read as a good overview of the discussion.</p> <p>I’m interested to see how all this will play out. I do think there’s still a role for humans to work with LLMs to build useful abstractions in which to talk about what the code does - essentially the DDD notion of <a href="https://martinfowler.com/bliki/UbiquitousLanguage.html">Ubiquitous Language</a>. Last year Unmesh and I talked about <a href="https://martinfowler.com/articles/convo-llm-abstractions.html">growing a language</a> with LLMs. As Unmesh put it</p> <blockquote> <p>Programming isn’t just typing coding syntax that computers can understand and execute; it’s shaping a solution. We slice the problem into focused pieces, bind related data and behaviour together, and—crucially—choose names that expose intent. Good names cut through complexity and turn code into a schematic everyone can follow. The most creative act is this continual weaving of names that reveal the structure of the solution that maps clearly to the problem we are trying to solve.</p> </blockquote>
发布日期:2026-04-02 · 来源:Martin Fowler
Published: 2026-04-02 · Source: Martin Fowler
测试TestingDevOpsDevOps架构ArchitectureAIAIAI AgentAI Agent
Cloudflare 表示,自 1.1.1.1 上线八年以来,他们持续把更快、更私密的互联网访问作为目标;最新独立审查结果显示,其隐私保护措施仍按承诺运行。
Eight years ago, we launched 1.1.1.1 to build a faster, more private Internet. Today, we’re sharing the results of our latest independent examination. The result: our privacy protections are working exactly as promised.
发布日期:2026-04-01 · 来源:Cloudflare Blog
Published: 2026-04-01 · Source: Cloudflare Blog