DEV Community: Oduor Jacob Muganda

The over looked.

Oduor Jacob Muganda — Mon, 27 Jul 2026 10:11:09 +0000

Oduor Jacob Muganda

Jul 27

The Oracle Problem Never Went Away, It Just Got a Rebrand

#testing #ai #qa #softwareengineering

4 min read

The Oracle Problem Never Went Away, It Just Got a Rebrand

Oduor Jacob Muganda — Mon, 27 Jul 2026 10:08:50 +0000

The Checkmark Was Never Proof

I don't write test suites for a living. My job is grading them, and grading the AI models that write and judge code in the first place. The rubric I work under does not allow ties. Every verdict needs a named file, a line number, a concrete before and after. "This one feels cleaner" is not a reason, it is a rejection.

Sitting in that seat long enough teaches you something the rest of the industry mostly avoids saying out loud: the green checkmark was never proof of anything. It was always a claim, and I have watched that claim fail the same way in three completely different settings.

Failure one: the retry that hides the bug

Flaky tests are the most visible version of this. Google's own engineering team reported in 2016 that around 16 percent of their tests displayed some flaky behavior, and about 1.5 percent of all test runs across their corpus came back flaky on a given day, meaning roughly one in seven tests written by their engineers would occasionally fail for reasons unrelated to any real code change.

The standard fix, a retry count in the CI config, does not remove the underlying bug. It just changes the odds. A test with a genuine 25 percent failure rate will statistically pass on the order of 99.6 percent of the time once you allow three retries. The bug is still there. The pipeline just stopped telling you about it.

A 2014 study by Luo, Hariri, Eloussi and Marinov analyzed 201 real flaky test fixes across 51 open source projects and found the leading causes were concurrency, async waits, and test order dependency, not randomness. These are deterministic bugs that only manifest under specific timing. That is exactly why Carnegie Mellon's PASTA lab built Fray, a tool that deliberately controls thread scheduling to force the bad interleaving instead of hoping a rerun stumbles into it by chance.

Sources: https://www.googblogs.com/flaky-tests-at-google-and-how-we-mitigate-them/ and https://mir.cs.illinois.edu/lamyaa/publications/fse14.pdf

Failure two: the assertion that proves nothing

You do not need an exotic system to see this one. You need a test method with five assertions and no messages. When it fails, you find out something broke, not what, and the rest of the method never even runs to tell you.

In 2015, researchers at UCL and Sheffield gave the broader version of this a name. Barr, Harman, McMinn, Shahbaz and Yoo published "The Oracle Problem in Software Testing: A Survey" in IEEE Transactions on Software Engineering, laying out why deciding whether an observed behavior is correct is often the harder half of testing, harder than generating the input that triggers it. When no specification or contract can make that call automatically, the job falls back to a human eyeballing the result. The paper has been cited well over a thousand times since and is still the reference point a decade later, which tells you how far the field has actually moved.

The everyday version of this has a name too. Assertion Roulette, a pile of asserts with no message telling you which one actually failed, is one of the original test smells catalogued in the early 2000s. An empirical study of eighteen open source Java projects found it present in roughly 62 percent of JUnit test classes, the most common smell in the codebases studied. A separate large scale study of open source Android apps put the figure above 50 percent as well.

Sources: https://www0.cs.ucl.ac.uk/staff/M.Harman/tse-oracle.pdf and https://www.cs.loyola.edu/~binkley/papers/icsm-12-smells.pdf

Failure three: the agent that remembers nothing

Here is where my actual day job comes in. Every coding agent I evaluate starts each session with no memory of the last one. No recollection of the convention it was corrected on last week, the mistake it already made once, the file it already touched. So it re-derives from scratch, sometimes reintroduces a bug it already fixed, and still reports the run as a success.

This is not a training failure, it is an architectural fact. Recent survey work on agent memory, including a 2026 paper on codified context infrastructure for large codebases, makes the same point every practitioner in this space eventually rediscovers on their own: a stateless model, however capable in the moment, cannot carry forward what it learned last session without an explicit memory layer built for that purpose. That is the actual reason informal conventions like a persistent project context file have caught on across agentic coding tools. Nobody solved statelessness. Everyone independently hit the same wall and built the same workaround.

It gets more interesting once a second AI enters the loop as the judge. Recent evaluation reliability research shows that even when multiple LLM judges review the exact same output side by side, their agreement with each other, and with human raters, is inconsistent enough that researchers now argue standard inter rater metrics understate how shaky the judgment actually is, given the randomness baked into the judge itself. Which is exactly why the rubric I work under bans ties and demands a cited line number for every call. Not because the rule is elegant, but because without it, "verified" quietly turns into "I skimmed it and it looked fine."

Sources: https://arxiv.org/pdf/2602.20478 and https://arxiv.org/html/2412.12509v2

Same lie, three settings

A CI pipeline, a JUnit test class, and an AI evaluation run look nothing alike on the surface. Underneath, they fail the same way. Each produces a single bit of output, pass or fail, good or bad, and each lets that bit stand in for a judgment nobody actually made carefully. Retries hide it in the first. Unlabeled asserts hide it in the second. Statelessness makes the third worse, because a system with no memory of what it already got wrong has no way to notice it is repeating itself.

What actually helps

Not a smarter checker bolted on after the fact. The thing that has actually moved the needle, in my experience grading this exact failure mode daily, is refusing to accept "it passed" as a complete answer to "how do you know." Require the file. Require the line. Require the reviewer, human or model, to show their work instead of returning a verdict. It is slower. It is also the only version of green that means anything.

The AI assistant enhances shopping by answering product questions, offering personalized recommendations, and simulating an in-store sales associate. It refines suggestions over time and improves discovery by highlighting trends and deals.

Oduor Jacob Muganda — Sat, 22 Mar 2025 08:27:33 +0000

iViatu: E-Commerce App with AI Shopping Assistant

kimani karaba🇰🇪 ・ Mar 22

#devchallenge #kendoreactchallenge #react #webdev

Top 5 alternatives to Webpack

Oduor Jacob Muganda — Wed, 15 May 2024 11:08:07 +0000

Introduction

Complex front-end applications demand reliable build tools that resolve dependencies, improve code quality, and ensure smooth workflow. Choosing the build tool is one of the most crucial decisions that depends solely on your project's needs. Though Webpack can be considered a powerful and versatile tool, sometimes it is not the most optimal choice. Fortunately, some modern options are very appealing and have convincing attributes.

What is Webpack?

WebPack is a module bundler that processes your application and creates a dependency graph. It is a C++ preprocessor for Javascript, making it possible to process imports. It has a good customization capability and can perform numerous functions. It is the most established module bundler in JavaScript. However, the landscape is in a constant process of change, and this fact gives developers multiple opportunities to try out differently. This comprehensive guide explores the top five alternatives to Webpack, and each is deeply analyzed in terms of their features, performance qualities, optimal applications, configurations, integrations, and migrations. You will have learned how to pick the right building system for your future projects.

Vite

Vite is a Javascript-built tool that simplifies how we build and develop front-end applications. At its core, it does two things: serves your code locally during development and bundles your javascript, CSS, and other assets together for production. Vite simplifies and speeds up the build process. Vite allows developers to import and export code for different files in the browser. It leverages modules in the browser to load your code instantly, no matter how large the app is. It also supports Hot Module Replacement for the first feedback loop for development. For production, it uses Rollup under the hood.

Key Features of Vite

Minimal Configuration: Vite's user-friendly approach and minimal configuration make it a breeze to get started. In contrast, Webpack's extensive configuration can be a hurdle for complex projects.
Rich Plugin Ecosystem: Vite is smaller than Webpack, but its plugin library is constantly growing to accommodate more functionalities. You can customize the Vite capabilities to meet your project's requirements.
Blazing-Fast Build Speeds: Vite shows remarkable build speeds for the production builds. This consequently makes it ideal for projects where development iteration speed and quick prototypes are very much necessary.

Comparison

Development Speed: Vite, on the other hand, allows for significantly faster development server startup both on smaller and larger projects compared to Webpack.
Configuration Complexity: Webpack has more granular configuring system, which makes for fine-tuning complex settings and Vite uses a simple approach.
Features: Fast cold start capacity, unlike Webpack, which needs a development bundle, which causes slower cold starts compared to Vite. Reduced configuration overhead for TypeScript, JSX, and CSS with no extra configuration, similar to Webpack.

Use Cases and Considerations

Ideal: Ideal for Settling on rapid iteration and developer experience focus, Vue.js or React project build.
Considerations: In cases of complex builds that need a lot of different configurations or limited loaders, Webpack might be a better option.

Configuration

Run the command below in your terminal to kick start the development server.



npm init vite my-app

Then, select a starter project with your favorite front-end framework. The project comes with Vite config files. It has a plugin ecosystem that can be extended with additional features. You can also install plugins such as vite-plugin-ssr that perform server-side rendering. To serve the application locally, run the following:



npm run dev

Migration

Migrating from Webpack to Vite for simple projects with basic configurations can be smooth. Remove your Webpack setup and run vite in your terminal. Vite often handles basic bundling needs without additional configuration.

Integration

Vite integrates well with existing project structures. It offers native support for popular frameworks like Vue.js and React.
For the Vue.js project with index.html and main.js files:

Remove your existing Webpack configuration. Locate your existing Webpack configuration file. Delete the Webpack configuration file named webpack.config.js.
Install Vite globally using the command npm install -g vite.
Initialize a new project with Vite: npm create vite@latest my-vue-project --template vue. Remember to replace my-vue-project with your project name.
Navigate to your project directory and run vite in your terminal. Vite will automatically set up a development server with native ES module support and HMR for Vue.js.

Parcel

Parcel is a Zero Configuration Bundler that requires little to no setup to get started. It makes use of multicore processing to speed up build times and comes with out-of-the-box support for many file types.

Key Features of Parcel

Automatic code splitting for faster page loads: Traditional bundlers like Webpack often create a single large bundle containing all your project's code. This can lead to slow initial page loads, especially for users with limited bandwidth.
Parcel automatically analyzes your code and splits it into smaller bundles based on how and when different parts of your application are used.
Friendly error logging experience: Instead of confusing error codes, Parcel displays clear messages that pinpoint the exact line and file where the error occurs. It even highlights the relevant code snippet, making identifying and fixing the issue easier. This reduces development time and frustration.
Built-in support for Hot Module Replacement: HMR is a powerful feature that allows developers to see changes to their code reflected in the browser almost instantly without needing full page reloads. Any changes made to the code are automatically detected and injected into the running application, making the development process not only simple but also fast.

Comparison

Ease of Use: Percel stands out in this area. Its minimal platform is perfect for newbies or projects that focus mainly on fast prototyping.
Performance: While Parcel offers good performance, Webpack provides finer control over bundle optimization, potentially leading to smaller bundle sizes for complex builds.

Use Cases and Considerations:

Ideal for: Quick prototyping and small to medium-sized projects. It is for developers who want a simple workflow without lots of setup.
Considerations: For highly complex projects with specific optimization needs, Webpack might offer more granular control.

Configuration

Parcel prides itself on minimal configuration. Run the command below to install Parcel.



npm i parcel

If you use yarn, you could install it using the command below:



yarn add parcel

Simply run the command below in your terminal to initiate the bundling process.



npx parcel index.html

This command will start the development server for a project using index.html as entry point, parcel will handle the rest including processing assets referenced in your html.

Migration

Migrating to Parcel is straightforward. Simply remove your Webpack setup and run parcel index.html in your terminal. Parcel automatically handles most tasks.

Integration

Parcel excels at integrating with existing project structures. It can handle various file types without additional configuration.

It is a good practice to back up your existing Webpack configuration files before making significant changes.
Locate your project directory in your file system. This is typically where your main code files index.html and main.js reside. Ensure to remove your Webpack setup.
Install Parcel globally using the command npm install -g parcel
Run parcel index.html in the terminal. Parcel automatically detects and bundles the relevant files.

You will need to integrate a custom Parcel plugin to handle the process for custom transpilation projects.

Rollup

In particular, Rollup's module bundling focus is on reusable JavaScript libraries mostly.

Key Features of Rollup

Tree-Shaking: Rollup is the best when it comes to tree-shaking as a method to automatically find and remove dead code. This technique analyzes your code and excludes the unused parts, this leads to smaller and more effective library bundles.
Highly Customizable Configuration: With Rollup, there is a powerful configuration order system that you can use to customize the libraries according to your requirements. This level of control makes it an awesome tool for large scale builds.
Extensive Plugin Ecosystem: Rollup is based on a rich plugin ecosystem. It lets you expand its functionality with other plugins, such as for code transformation.

Comparison

Focus: Rollup excels in library creation. It removes unused code. This makes library bundles smaller and better. It does this using code tree-shaking. Modern alternative tools such as Parcel, Vite, and ESBuild are in demand as they are capable of working with a large range of application bundling tasks.
Configuration: Rollup offers extensive configuration options, allowing you to tailor the bundling process to your specific library's needs. Modern alternatives prioritize minimal configuration for a streamlined experience.
Performance:Rollup's build times could rival Webpack's build times that are highly dependent on configuration and performance optimization. The modern stuff like Vite and esbuild has a reputation for loading quicker, especially for the simple projects.
Use Cases: Rollup comes top for creating reusable JavaScript libraries with optimized bundle sizes. Modern alternatives like Parcel and Vite are great for fast web development cycles. This is especially true for web apps that use Vue.js or React. esbuild is the best choice for projects where build speed is a key issue and where the application sizes are small to medium.

Configuration

To install Rollup, run the following command:



npm install --global rollup

Assumming the entry file is main.js, the build command for both browser and Node.js environment is:



rollup main.js --format umd --name "myBundle" --file bundle.js

To configure Rollup, create a JavaScript file rollup.config.js. The entry point will be specified in the main.js file. The config object gives you the capability to configure advanced features like external dependencies and plugins for code-splitting and tree-shaking. Run rollup -c rollup.config.js in the terminal for the building of your library.

Migration

Identify the code specific to the library within your Webpack config file.
Get that code and dependencies into the newly created one.
Set up Rollup for this separate project making use of its tree-shaking abilities to optimize the bundle.

Integration

Install rollup using the command npm install -g rollup globally.
create a different project for the library.
Configure Rollup in your project library, indicating input files, output formats and the desired plugins of tree- shaking and other operations.
Build your library using rollup -c.
Integrate the just generated library bundle .js into you project file directly with it reference in your HTML.

ESbuild

esbuild has become successful. It won the hearts of developers with its amazing, lightning-fast builds. The image below compares the build times of esbuild and other web bundlers.

The image above is from https://esbuild.github.io/.

Key Features of esbuild

Blazing-Fast Builds: esbuild is known for its best build speeds. So, it's the perfect choice for projects where build time is crucial. This is achieved through applying techniques such as parallelism and caching.
Command- Line Interface (CLI) & JavaScript API: esbuild provides a command-line interface for easy use and a javascript API for programmatic integration.
Minimal Configuration: Just like Parcel, which relies on a user-friendly interface, esbuild has a similar approach, with easy setup mostly for almost all projects.

Use Cases for esbuild

Rapid Prototyping: esbuild's fast builds suit it to rapid prototyping. They are for the development cycles that need swift iteration.
Simple to Medium-Sized Projects: No advanced features like code splitting are needed. The bundling is straightforward. esbuild is a good option.

Configuration

Globally install ESBbuild with the command below:



npm install -g esbuild

Type the following command esbuild index.js --outfile=bundle.js in your terminal, replacing index.js with your main entry point file. This creates a bundled file named bundlef containing your code.

Migration

Get rid of the current config files for Webpack or Parcel.
Identify your project's main entry point file, which could be index.js.
Run esbuild index.js --outfile=bundle.js in your terminal. This creates a bundled file bundle.js containing your main code and its dependencies.

Integration

ESBuild primarily focuses on bundling for production. Here's how to integrate it.

The recommended approach is using the ESBuild command-line interface. Run the command below to build your project.



esbuild index.js --outfile=bundle.js

Browserify

Browserify is a module that allows us to include node modules in our web project and run on the browser. In simplest terms, it is executing server-side code in client-side.

Key Features of Browserify

Browser-Side Bundling: In essence, Browserify's main role is to combine multiple JavaScript files into a single file. This file is best for use in an HTML file. This helps to avoid hassle of adding different JavaScript files to the webpage.
require Statement Usage: Similarly to Node.js, Browserify also uses require statements to manage the dependencies within separate JavaScript modules. This enables you to employ the modular approach in structuring your code, leading to code organization and reusability as a result.
Built-in Browser Compatibility: Browserify has built-in support for running Node.js-style modules in the browser. This leads to a use of Node.js modules in your web-project.

Comparison
Focus: Browserify is specifically developed for bundling JavaScript for the browser. While newer alternatives go beyond others functions like development servers, code splitting and tree-shaking.
Configuration: One of the advantages of Browserify and Parcel is the less configuration. Vite and esbuild focus on users. Rollup gives developers control and resources to create libraries.
Performance: The build time for Browserify is good enough, but Vite and esbuild outrun it with excellent speeds. Moreover, Parcel offers quick build speeds for the straightforward initiatives.
Use Cases: Browserify is good fit for small, browser-centric projects where complex bundling features are not required.

Configuration

Configuration of Browserify requires you to install it globally by running the command below:



npm install -g browserify

For bundling, run the command below:



browserify main.js -o bundle.js

in your terminal. This creates a bundle file bundle.js including your main file and all the dependencies.

Migration

The transition from Webpack to Browserify is a bit tricky. Webpack provides code splitting and tree shaking. These are not in Browserify's tools making it incompatible.

Integration

Install Browserify globally by issuing the command: ```bash

npm install -g browserify

2. Identify and locate your main JavaScript entry point file which could be `main.js`.
3. In your terminal, run the command below:

```bash


browserify main.js -o bundle.js

This creates a bundled file bundle.js containing your main file and its dependencies.

In your index.html file, add a <script> tag referencing the generated bundle. Below is an illustration with a code snippet.




<!DOCTYPE html>
<html>
<head>
  <title>My Browserify Project</title>
</head>
<body>
  <script src="bundle.js"></script>
</body>
</html>

The table below gives a summary of our discusion above.

Feature	Vite	Parcel	Rollup	esbuild	Browserify
Focus	Development server, Rapid iteration	Zero-configuration bundling	Library creation	Blazing-fast builds	Browser-side bundling
Configuration	Minimal	Minimal	Highly customizable	Minimal	Minimal
Code Splitting	No (requires plugins)	Automatic	No	No	No
Tree-shaking	No	No	Yes	No	No
HMR	Yes	Yes	No	No	No
Framework Support	Built-in (Vue.js, React)	Built-in (Vue.js, React)	No	No	Limited
Build Times	Good	Fast	Moderate	Extremely fast	Moderate
Use Cases	Rapid development cycles, Vue/React	Simple to medium projects, prototyping	Library creation	Blazing-fast builds, simple apps	Legacy projects, small browser apps

This comparative analysis serves as a valuable reference point for choosing the most suitable JavaScript bundler for your next web development project.

Conclusion

Webpack reigns supreme in bundling, but consider alternatives. Parcel and Vite offer minimal configuration for rapid development, ideal for small to medium projects. Rollup excels in creating optimized libraries, while Esbuild prioritizes blazing-fast builds. Choose your weapon based on project complexity. Also, consider the workflow and target environment. This will give you a smooth and efficient bundling experience.