Computing

Construx principal consultant Steve Tockey makes a profound observation: “If you are not basing your software technical decisions, at least in part, on engineering economy, then you are not—by definition—doing software engineering.” He points to a quote by Leon Levy:  “ ...software economics has often been misconceived as the means of estimating the cost of programming projects. But economics is primarily a science of choice, and software economics should provide methods and models for analyzing the choices that software projects must make. ”  This got me thinking about the current state of agentic engineering. We are essentially lacking the engineering economy required to make sound investment choices. To highlight this gap, this blog compares traditional cash-flow streams before adding a modern perspective. FinOps —including tokenomics—is a vast field, and this discussion only scratches the surface. Its aim is to highlight a growing trend: companies replacing human softwar...

I have worked in software engineering for more than thirty years and witnessed several combinatorial explosions firsthand. The AI-driven explosion now under way is different, and that distinction should shape our response. In both software and agentic engineering—the extension of software engineering to ecosystems of software and autonomous agents—quality must remain the central concern. If code can now be produced at a staggering pace, what limits our ability to deliver high-quality products quickly? The bottleneck lies in the scaffolding surrounding construction. Writing code faster isn't the danger; the danger is what happens when that code starts talking to itself. The desire to scale agentic engineering is understandable given how deeply software permeates society. At the time of ENIAC , few could have anticipated that software would enable fly-by-wire aircraft, self-driving cars, embedded medical devices, machines that surpass humans at chess and go, or unmanned missions suc...

Software rarely fails because it lacks a feature; it fails because it cannot scale, cannot recover, or cannot be securely maintained. Yet, Non-Functional Requirements (NFRs) are routinely treated as an afterthought, reduced to vague, untestable wishes like "the system must be reliable." This upfront ambiguity is the leading cause of crippling technical debt, endless refactoring, and late-stage architectural collapse. Enter the NFR Refiner (submitted as part of Kaggle's AI Agents: Intensive Vibe Coding hackathon project): an intelligent assistant that transforms static engineering methodologies into a live, interactive experience. The NFR Refiner agent doesn't just passively record requirements. It actively interviews stakeholders, enforces strict quality standards, fetch real-world industry benchmarks, and translates fuzzy human intent into strictly verifiable Planguage based specifications. Brief Historical Context Software process engineering has long struggled wi...

The Turing test was created to distinguish intelligent machines from human thinkers, and the question it raises is nearly as old as computer science itself. Over time, countless variations of the test have focused on one familiar idea: spotting errors, awkwardness, or other signs of imperfection that might reveal a machine behind the answer. That approach is becoming less useful as modern systems grow better at sounding polished and convincing. In this blog, I explore a simple extension to the classic test: instead of asking whether an answer is flawless, I ask whether it is stereotypical. My argument is that this shift reveals a more subtle weakness—one that many of today’s leading AI systems still struggle to hide. The New Test Harness The core idea behind this new test harness is straightforward: instead of judging an answer in isolation, the evaluator would run it through multiple AI systems and measure how strongly it reflects the same familiar patterns; see the image below. The ...

In mathematics and computer science, asymptotic expansions provide a fundamental framework for managing complexity and reasoning about underlying processes at an appropriate level of granularity. For example, the discrete quantity represented by the n-th harmonic number , H n , can be approximated as ln n + O(1). This approximation offers the intuitive insight that harmonic numbers grow logarithmically, while also indicating that the omitted terms remain bounded by a constant. When greater precision is required, additional terms may be introduced—for instance, Euler’s constant —yielding a refined expression of the form H n = ln n + γ + O(1/n). A similar analogy applies to AI-friendly publications, such as my study helper for An Introduction to the Analysis of Algorithms, Second Edition , by RS and PF. This type of document is built around expandable AI prompts, which function in a manner analogous to asymptotic expansions for quantities of interest. The initial prompt (a solution of...

Vibe coding is the latest technological breakthrough related to AI assisted software development. It truly changes how we think about the software engineering discipline. The crucial question is can we tame, control and regulate the underlying AI engines to do exactly what we want without a fear of dangerous side-effects? This blog tries to shed some light on available approaches, that ironically have always been part of industry best-practices: requirements engineering and API-centricity . To make the exposition concrete, I've developed an educational unit Vibe Coding Demo , purely generated via Google Antigravity ; the repository contains all the technical details of the project, together with useful external reading materials. The key point is that the core input was the product requirements document, all the rest just happened . Why API-Centricity? By starting with an API-centric paradigm, we are able to harness AI productivity while maintaining strict architectural and securit...