标签：#engineering

If your pipeline isn't idempotent, it isn't production-ready; it’s just a fragile script waiting to ruin your weekend. Most engineers treat "idempotency" as an academic concept for distributed systems papers, but in the trenches of fintech and healthcare, it’s the difference between a minor blip and a regulatory filing. If you can’t run your job five times in a row with the exact same input and get the exact same state, you aren't doing data engineering—you're doing data gambling. I’ve spent six years cleaning up the messes left by "append-only" thinking. I’ve seen millions of dollars in duplicate ACH transactions and patient records corrupted by "just one more retry" logic. This guide covers the patterns I use to make sure that when the scheduler kicks off at 3 AM, I can sleep through the alarm because the system knows how to fix itself. 1. Stop relying on "Append" mode The biggest sin in data engineering is assuming that your destination table is a clean slate. When a job fails halfway through, you don't want a partial load sitting in your production warehouse. Never use INSERT INTO blindly. If you are using BigQuery, Snowflake, or Databricks, use MERGE or overwrite-on-partition. If you are using SQL-based ELT, write your transformations to stage data in a transient table before swapping it into production. Never push directly to the target. -- The wrong way: INSERT INTO target_table SELECT * FROM staging -- The right way: Use an atomic swap or a MERGE statement MERGE INTO production . transactions AS T USING staging . transactions AS S ON T . transaction_id = S . transaction_id WHEN MATCHED THEN UPDATE SET T . amount = S . amount , T . status = S . status WHEN NOT MATCHED THEN INSERT ( transaction_id , amount , status ) VALUES ( S . transaction_id , S . amount , S . status ); Photo by 🇻🇪 Jose G. Ortega Castro 🇲🇽 on Unsplash 2. Partitioning is your safety net If your pipeline runs daily, your data must be partitioned by that day. If you are loading data without a

⚡ TL;DR Four things about controller mechanics are widely half-understood: what Reconcile receives, where its work comes from, what a periodic resync is, and what a predicate turns off. I built an operator, broke it five ways, and measured each mechanism directly. The reconcile function runs in 2.71ms mean, 77/77 under 25ms , a short resync period costs zero additional API requests , and GenerationChangedPredicate cut steady-state reconciles by 48.5% without touching live repair at all. That last combination is the one that matters at scale. Repo, raw data, and harness: kirPoNik/k8s-drift-operator . 🧩 The four barriers Everyone who runs Kubernetes knows the platform repairs itself. Delete a pod, it comes back. Scale a Deployment by accident, something puts it back. Almost nobody who relies on that property can say how it works, and the gaps are specific and consequential. I keep meeting the same four: People think a controller is told what changed. It is not, and the reason it is not is the single most important design decision in Kubernetes. People think a controller polls the API server. It does not, and knowing what it does instead tells you where your API load actually comes from. People think a resync is a re-check against the cluster. It is not, which is why a short resync period is nearly free — and why the number that is expensive sits somewhere else entirely. People treat a predicate as a pure optimisation. It is a filter with a silent cost, and the cost is not the one the documentation warns you about first. So I built the smallest system that has the self-healing property, broke it on purpose ten times per failure mode, and instrumented each of those four mechanisms until I could state what it does rather than what it is said to do. What I built. One CRD called Echo , holding an image, a replica count, and a greeting. A controller keeps three child objects in sync with it — a Deployment, a Service, and a ConfigMap holding the greeting — with owner referen

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

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

If you're prepping for a Business Intelligence (BI) Engineer, Data Analyst, Data Engineer, or Data Scientist role at Amazon, you probably already know SQL matters. It's a core part of the hiring bar. But Amazon isn't just checking your syntax. They want to see if you can think in sets, write clean queries under pressure, and reason about data the way the business actually uses it. Here's exactly how to prepare based on what the interview actually rewards. What the Interview Really Tests Amazon's SQL rounds usually show up in one of two ways. It's either a technical screen using a shared coding tool, or a whiteboarding case-study during the main loop. Either way, the interviewer is watching for a few specific signals. For starters, correctness always beats speed. A working query is far better than a clever one that fails. Communication is also huge. Do you talk through your logic before you even touch the keyboard? You'll often get a vague ask, like finding the "best" customers. You are completely expected to define what "best" means out loud before you start writing Common Table Expressions (CTEs). And watch out for messy data. Nulls, duplicates, and mismatched grain are almost always baked into the problem on purpose. The Core Topics to Master Focus your prep time on a few specific areas. Actually, it turns out this is where almost all the interview questions live. Joins Inside and Out You need to know your INNER, LEFT, RIGHT, and FULL OUTER joins cold. Be ready to explain exactly why row counts change after each one. A classic Amazon-style question is finding customers who placed orders but never left a review. That's just a LEFT JOIN with a NULL check. The interviewers want to see you reach for it right away. Window Functions Functions like ROW_NUMBER() , RANK() , DENSE_RANK() , and LAG() or LEAD() show up constantly. You might see a common pattern—like finding the second-highest order value per customer, or calculating month-over-month growth. If you're shaky he

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

JupyterGIS is a GIS-focused extension for Jupyter notebooks. The recent 0.16 release enhances collaborative features, real-time editing, and support for large-scale data processing, including remote sensing. It introduces better visualisation tools and extends compatibility to R users. Community feedback highlights practical concerns and a desire for improved portability. By Olimpiu Pop

On September 4, Anthropic published something that sounds like a headline from a decade in the future: the first complete, computer-checked proof of Fermat's Last Theorem, written by a team of Claude agents working largely autonomously over 11 days. Thirteen million lines of Lean. Nearly 30,000 intermediate theorems. About six billion output tokens. I want to talk about a detail that most coverage will bury, because it is the only part that matters if you build software with agents instead of reading about them. The first attempts failed. Not because the model was too weak. The agents had early success, then lost track of the project's state and stopped collaborating effectively. What fixed it was not a smarter model. It was a shared directed acyclic graph acting as the team's memory. If you have ever run two AI agents on the same codebase and watched them trample each other's work, you already understand this failure. You just have not seen it dramatized at the scale of one of the hardest proofs in mathematics. What actually happened, in numbers First the facts, because they are dramatic enough on their own. Fermat scribbled his claim around 1637: no positive integers a, b, c satisfy aⁿ + bⁿ = cⁿ for any n greater than 2. Andrew Wiles proved it in 1995 after a 129-page proof, and even that is underselling the drama. He presented the proof in June 1993, a reviewer's question exposed a critical gap two months into verification, and Wiles spent a year, first alone and then with his former student Richard Taylor, fixing it. Formalizing that proof, meaning rewriting it so a proof assistant like Lean can verify every step algorithmically, has been a community project since 2024, led by Kevin Buzzard at Imperial College London. The blueprint for just the initial phase runs 86 pages. It was scoped as a multi-year effort. Then Tianyi Peng, an Anthropic researcher whose group at Columbia University builds AI formalization tools, tested whether Claude could make progress on i

บทวิเคราะห์ "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 จะเอาไปรันได้ แทนการเขียนโค้ดเอง ถ้าให้อุปมา: วิชาเดิมเหมือนวิชา "สถาปัตรกรรมสำหรับอาคารอิฐ" ที่สอนว่าจะกออิฐทีละก้อนอย่างไรให้บ้านไม่พัง วันหนึ่งปรากฏเครนอัตโนมัติที่รับแบบจากคำบอกของเจ้าของบ้านแล้วสร้างเองได้ทั้งหลัง วิชากออิฐยังมีคนใช้อยู่ แต่คำถามสำคัญที่สุดของวิชาย้ายจาก "กอยังไงไม่ให้พ

I have spent more than six years shipping production software and I have no public repositories worth showing you. Everything substantial I have written at work lives in private repositories belonging to the companies I wrote it for, and confidentiality obligations do not lapse when a role ends. So I cannot hand you the code, and I am not going to. That is not caution for its own sake. An engineer who sends a prospective employer another company's source code has told you exactly what they will do with yours. The restraint is part of what you are assessing, and I would want the same restraint applied to my work later. Which leaves a real problem. "I was the principal author of the web application" and "I contributed to the web application" are the same sentence to a reader who cannot check either. Most engineering CVs resolve this by getting louder. I think the only honest resolution is to publish the measurement method rather than the artefact, in enough detail that someone familiar with the tools can judge the figure on its own terms without ever seeing the repository. Here is the method I actually used, what it does badly, and the places where applying it forced me to shrink a claim I would have preferred to keep. Three measurements, in increasing order of rigour All-branch commit count. Total authored activity. Do not use this. It counts abandoned branches, spikes and experiments, and it inflates — usually in favour of whoever is most willing to commit. It is the number that makes contribution graphs look impressive and says the least about a codebase. Production-branch commit count, scoped to tenure. What reached customers, while you were there. Better, because it excludes work that never shipped, and because scoping to tenure stops you either taking credit for years of history that predate you or being penalised for them. But it still counts commits, and a commit is a unit of activity, not a unit of code. Commit share rewards granular committers and punishes p

The standard objection to writing the design down is that it is what you give up in exchange for speed. Early-stage companies are meant to be the place where you skip it: no specifications, no plans, just build the thing and find out. Documentation is treated as a tax that mature organisations can afford and small ones cannot. I have worked the other way round, and I want to make the argument properly rather than just assert it. At Cendra , across a twelve-month tenure as one of two founding engineers, the work produced 255 design specifications, 207 implementation plans and 17 production runbooks. Over the same period: 377 production releases coordinated across four repositories, and 482 merge commits across those repositories (an all-merges count, broader than the frontend-only first-parent integration figure on the Cendra page), across 239 active development days. That release figure works out at roughly one every twenty-two hours. All of those figures are tenure-scoped, and self-measured against private repositories while I held authorised access to them, which is a caveat I will come back to. But the shape is the point: the documents and the shipping happened together, at the same time, by the same person. What I am not claiming I cannot prove the specifications caused the cadence. There is no control group. It is entirely possible to imagine a version of that year with no documents and more releases, and I have no way to rule it out. What I can do is describe precisely what the artefacts removed from the critical path, and let you judge whether that is worth the hours. The mechanism matters more than the correlation, because the mechanism is the part that transfers to your codebase rather than mine. The specification is a comprehension test I administer to myself The honest reason I write a design down before building it is not communication. It is that writing it is how I find out whether I actually understand the problem. There is a specific and reliable exp

This eMag examines how architects can lead with clarity in a rapidly evolving engineering world, distilling industry insights into field-tested practices for teams. Together, these stories reveal a core theme: the technology leader’s role is expanding from building systems to guiding how tech behaves and learns, while enabling engineers and organizations to bring out their best. By InfoQ

I built the pipeline that publishes this site's content in versioned code instead of n8n. Not a philosophical stance against no-code tools, a practical call, and one specific bug is why I still think it was the right one. Why code, not a canvas Four reasons drove it, in order of how much they actually mattered: Review parity. Every change to how a post gets approved or published goes through the same PR review as the rest of the site. A workflow-canvas change doesn't get that by default. Headless operation. Claude Code drives the queue directly, no GUI dashboard sitting between the agent and the task. Existing infrastructure. A Telegram bot already handled approvals; there was no gap a workflow tool needed to fill. One fewer service. Every extra tool in the stack is something else to patch and keep secure. Skipping it was the cheap option, not just the principled one. The bug that proved it On July 20, 2026, a scheduled post silently failed. The Buffer API adapter treated an error response as a normal one, never checked the status, so the X post never actually went out while the pipeline marked it published. Nothing threw, nothing alerted, the queue just quietly lied about what had shipped. I found it the way you'd expect: read buffer.py , saw exactly where the status check was missing, fixed one line. Cheap once you can see it. That's the part I can't picture happening the same way in a workflow canvas. I genuinely don't have a mental model for debugging that failure mode there, a canvas doesn't hand you the same thing a stack trace and git blame hand you in code. You'd be reading node configuration and hoping the tool's own logging caught the edge case, instead of reading the exact line that skipped a check. What this is actually about It isn't code versus no-code as a philosophy. It's about legibility when automation is wrong in a way that doesn't throw an error. A silent-fail bug is the worst kind, because nothing tells you to go look. The only thing that saved

The code you can change today is worth more than the code you cannot. 👋 I'm Anton - a software engineer working mostly in PHP/Symfony and Go, currently carving Go services out of a live PHP monolith. This is the last part of a block about the platform, the service template and generated skeletons, and I want to close it with the one idea that decided most of the calls in it. Maybe it is useful to you; maybe you look at this the other way round and I'd like to hear that. Notes: github.com/brilliant-almazov . As with every part of this series: this is what I do on one codebase, not advice for yours. The thesis Between a decision I can change today and a decision that is better but changes on someone else's release, I take the first one. Not because it is written better - it usually isn't - but because the cost of changing it is known in advance. "Foreign" here doesn't mean bad. It means not moved by me : a shared library, a platform package, a dependency with its own release cadence. Those are often the better piece of code. They are also the piece whose change window I don't own. Where the rule shows up in the layout Universal code is born in a service, because that's where you can see it is needed, and it lives in the platform. That gives three phases, and they are deliberately two different bodies of work: Phase A - preparation, inside the service. No imports of any domain package, the public API frozen, tests moved into the concern's own subfolder, a context-cancellation test present. Closed by a green run in the service's own repository. Phase B - the move into the platform. Files relocate, the package name becomes the target folder's name, service imports are cleaned out. Only on a direct instruction from the platform's owner. Phase C - the service switches to the platform version. Exactly the given tag goes into the modules, the local package is deleted, imports are replaced. No pseudo-versions, no replace . No tag - the work doesn't start. Phase C is a separat

Master Prompts in 2026: Stop Prompting Like It's 2023 I still see people paste a 40-line “act as a senior expert with 20 years of experience” block into ChatGPT and call it engineering. That stopped working as a strategy a while ago. Models got better. Context windows got bigger. Agents started calling tools. And the failure mode shifted. It’s rarely “the model is dumb” now. It’s “your system has no contract.” This is a long, practical write-up on master prompts — the stable policy layer above individual tasks. How to write them. How to force planning. How to run Plan → Act → Observe → Verify without theater. How to make the same prompt useful to a tired human at 11pm and to an agent loop that only understands schemas. I’ve broken enough production prompts across GPT-4o, Claude 3.5 Sonnet, and Gemini-class stacks to have opinions. Some of them are uncomfortable. TL;DR / Key Takeaways A master prompt is not a clever sentence. It’s the policy layer : role, success criteria, process, constraints, output contract, failure handling. Production reliability comes from LLM orchestration patterns — plan JSON, single-task executors, and explicit done_when checks — not from longer personality blocks. JSON contracts + verification beat free-form answers. Agents that can’t prove completion will invent it. Treat prompts like code: version them, eval them, and put a real verify step after generation (including SEO/quality checks when you publish). Table of Contents What a master prompt actually is The 7-part anatomy that doesn’t collapse under pressure Frameworks worth keeping (and which ones to ignore) Planning is the real skill From plan to agent loop Context engineering beats clever wording Few-shot, JSON contracts, and the anti-hallucination rule Copy-paste masters you can actually deploy A real publish pipeline (including the verify step people skip) Eval or you’re guessing Failure patterns I keep seeing PromptOps: treat prompts like code One universal master prompt Ship chec

abandoned open source package vulnerability EOL dependency strategy fork vs patch security alert open source risk mitigation OSS abandonment decision tree tech lead security SLA abandoned dependency vulnerability end of life open source package unpatched upstream dependency replace abandoned OSS library isolate vulnerable code fork open source package internal maintenance OSS fork formal risk acceptance InstaSLA accepted risk logging vulnerability SLA deadline EOL package remediation open source dependency risk unmaintained open source library patching abandoned packages Upstream OSS Abandonment An Engineering Decision Tree for EOL Dependencies Back to blog The Silent Crisis of Upstream Abandonment Option 1: Replace the Dependency (The Ideal, but Costly Path) Option 2: Wrap and Isolate the Code (The Tactical Defense) Option 3: Fork and Maintain Internally (The Ownership Commitment) Option 4: Formal Risk Acceptance (The Compliance Reality) What 2025–2026 Actually Looked Like Conclusion Upstream OSS Abandonment: An Engineering Decision Tree for EOL Dependencies When an active vulnerability SLA deadline looms over a critical application, the standard playbook is straightforward: update the package, run the tests, merge the pull request. But what happens when the underlying open-source library has been quietly abandoned by its maintainer? Engineering teams are running into this exact scenario more often, and the numbers back that up: Veracode's 2025 State of Software Security report found that half of organizations carry critical security debt, and 70% of that debt originates from third-party code and the software supply chain. As the software supply chain grows more complex, the odds of an EOL package sitting somewhere in your dependency tree keep climbing. This article lays out a step-by-step decision framework for tech leads and security teams managing an EOL dependency when no upstream patch is coming — and updates it with what's actually happened in the open-source

Cohere has launched Parse 5, a multimodal foundation model designed to extract structured data from complex enterprise documents. The 2.3-billion-parameter system converts visually rich PDFs into Markdown while providing bounding box coordinates for visual grounding. It has been evaluated against over 2,000 enterprise pages, achieving an average score of 79.2 in key performance areas. By Olimpiu Pop