DEV Community: Valentine Shi

Jev vs OpenAI Decisions API: A Follow Up

Valentine Shi — Mon, 12 Oct 2026 08:12:27 +0000

In my recent article about Jev by TypeSafe AI, I questioned whether its speed, cost, and confidence scores offered enough advantages over conventional LLMs with Structured Outputs.

And here is an interesting development.

On October 6, OpenAI announced its Decisions API became available in public beta (see the announcement and the API doc links below).

Typed decisions: predicates, predefined choices, and numeric scores.
Probability and confidence estimates.
Text and image inputs.
Claimed ~10× faster responses than the Responses API.
$0.10 per million input tokens, with no output-token charges.

The functionality is remarkably similar to Jev. OpenAI now offers a specialized API for essentially the same tasks, with comparable pricing.

I would be interested to see independent benchmarks comparing the two APIs, particularly on accuracy, latency, cost, and confidence calibration.

And this development supports my original conclusion about Jev. We already had much of this functionality with Structured Outputs. Specialized decision APIs may make it faster and cheaper, especially at scale.

Pricing, High Load, SLA

Let's start with pricing. Jev costs $0.042 per million input tokens, while OpenAI Decisions API costs $0.10. So Jev is about 2.4 times cheaper. Neither charges for output tokens.

Looking at the upper capacity limits, Jev supports 6 million input tokens per minute, compared with up to 180 million for GPT-6 Luna. That's a 30-fold difference, although the OpenAI figure has yet to be confirmed for Decisions API.

On the infrastructure side, Jev is still expanding its GPU capacity, and its limits may change. OpenAI already offers enterprise capacity reservations, so they may be available for Decisions API.

Finaly, Jev has a clear pricing advantage, while OpenAI appears better positioned for high-load workloads and potentially better SLA. Whether the price advantage is sufficient vs OpenAI's solutions remains an open question. OpenAI definitely has greater bargaining power, capital, and infrastructure resources. If the niche is attractive, competitors will need more advantages than just pricing to survive in it.

Decisions API is now available in Public Beta

The API Official Docs

Git Submodules: When and How

Valentine Shi — Mon, 05 Oct 2026 06:52:03 +0000

Contents

Use Cases
Submodules, Subtrees, Mono- or Multirepo?
A Practical Setup Example
- fork.dev
- Terminal
Daily Workflow

Git submodules are a built-in Git mechanism for composing repositories at fixed commits. Unlike a monorepo, separate repositories, or worktrees, they let a root repository record exact revisions of independently owned submodules.

The basic idea is simple: the root repository records a nested repository at an exact commit. The root repository stores the path and remote URL in .gitmodules, and records the submodule commit as a gitlink. A clone can later reconstruct the same combination of repositories.

Use Cases

Briefly: use a submodule when a root repository must record an approved revision of code maintained elsewhere. Here are some useful applications of submodules:

Keep private documentation and deployment configuration in the root repository, with public source code in a submodule.
Pin the exact revision of a shared library maintained and released separately.
Record the approved revisions of independently released services or tools.
Pin a reviewed commit from a maintained fork of an external project.

In product development, the root repository represents the product release context: its documentation, configuration, integration decisions, and approved component revisions. Each submodule represents a component with its own codebase, maintainers, and delivery cycle.

Submodules, Subtrees, Mono- or Multirepo?

Here are some key distinctions, briefly.

A submodule keeps source independent while the root repository records the exact revision used by the product. It fits when public source and private product material must remain separate but form one reproducible product revision.

A subtree copies external source into the root repository. Use it when the root repository should own that source.

A monorepo works well when code, access rules, and release cadence belong together. Nx and similar monorepo tools allow for task execution, caching, project boundaries, and releases conveniently from the single root repository.

A multirepo gives each component its own repository, ownership, and history, but does not by itself record which revisions belong together.

A Practical Setup Example

Consider a product with private documentation and deployment configuration, and public source code maintained in a separate repository.

Root repository: private; contains private material and one or more submodule references.
Submodule: public; contains source code and is its own source of truth.

root/
├── .gitmodules
├── docs/                    # private specifications and operational material
├── deployment/              # private deployment configuration
└── submodule/               # separately owned source repository
    ├── README.md
    └── src/

The root repository tracks .gitmodules and the exact commit recorded at submodule/. The files inside submodule/ belong to the submodule repository.

fork.dev

I use here the Fork Git client. The setup via terminal is in the next section.

Create the local folder structure:

   mkdir root
   cd root
   mkdir docs deployment submodule

In Fork, create a Git repository in root/.
Open submodule/ in Fork and create a separate Git repository there. Add an initial file such as README.md, commit it, and keep this repository independent from root/.
Create two empty repositories in your Git hosting service, for example: private: https://github.com/example/root.git, public: https://github.com/example/submodule.git.
In Fork, add https://github.com/example/root.git as the origin remote of the root/ repository.
Add https://github.com/example/submodule.git as the origin remote of the submodule/ repository, then push its initial commit.
Return to the root/ repository. In the sidebar, right-click Submodules → Add New Submodule. Enter repository URL: https://github.com/example/submodule.git, local path: submodule. Fork registers the existing local repository as the submodule.
Commit .gitmodules and the new submodule gitlink in the root repository, then push the root repository to its private origin.

Terminal

The same setup from a terminal, creating both repositories locally first and then attaching their remotes:

# Create the local folder structure.
mkdir root
cd root
mkdir docs deployment submodule

# Initialize the private root repository.
git init -b main
git remote add origin https://github.com/example/root.git

# Initialize the public submodule repository.
cd submodule
git init -b main
echo "# Submodule" > README.md
git add README.md
git commit -m "Initial commit"
git remote add origin https://github.com/example/submodule.git
git push -u origin main

# Return to the root repository and register the existing local repository
# as a submodule.
cd ..
git submodule add --force https://github.com/example/submodule.git submodule

# Commit the root repository state.
git add docs deployment .gitmodules submodule
git commit -m "Add submodule"
git push -u origin main

Daily Workflow

Treat the submodule commit as a dependency lock. Change code in the submodule repository, then deliberately update the root repository's pointer.

With that workflow, the repositories keep their separate ownership, history, and visibility, while the root repository still records the exact combination that belongs to the system.

Example:

Doble-click on Submodules->submodule repository to open its tab. Add its source files, stage them, commit them, and push them to the public origin.
Return to the root repository. Add private files under docs/ and deployment/. Stage docs/, deployment/, commit them, and push them to the private origin.

For private documentation or configuration changes, work in the root repository directly. For source changes, commit and push them in the submodule first, then commit the changed submodule reference in the root repository.

When cloning later, use recursive initialization:

git clone --recurse-submodules <root-repository-url>

For an existing clone, use:

git submodule update --init --recursive

References: Git submodule documentation and Git submodules guide.

AI Layoffs Seem To Be Reversed

Valentine Shi — Tue, 29 Sep 2026 05:11:00 +0000

The economics of replacing people with AI are proving more complicated than expected. Two recent studies provide some interesting evidence.

1. KPMG: The cost vs value of AI are becoming a serious challenge.

KPMG's Global AI Pulse Q2 2026 (surveyed 2,145 senior executives across 20 countries) found that:

29% report difficulties understanding and controlling AI operating costs.
33% identify limited understanding of AI costs as a challenge to deploying AI agents.
49% have delayed, paused, narrowed, or scaled back AI agent deployments because expected costs began to outweigh anticipated value.

2. Careerminds: Companies are already rehiring after AI-related layoffs.

In February 2026, Careerminds surveyed 600 HR professionals from organizations that had conducted layoffs in the preceding 12 months. More than 75% (approximately 450–460) reported AI-related layoffs. Out of them:

32.7% reported rehiring for 25–50% of eliminated roles.
35.6% reported rehiring for more than half of eliminated roles.
Among organizations that rehired, 52.1% reported doing so within six months.
30.9% reported that rehiring costs exceeded the savings achieved through the original layoffs.

Another interesting finding: 54.6% reported that AI required more human oversight than anticipated, making the layoffs not worth it.

What the evidence does establish is that AI replacement strategies have already failed economically or operationally in a considerable amount of organizations, resulting in reduced AI deployment, revised workforce decisions, and renewed hiring.

Links:

KPMG — Global AI Pulse Q2 2026

Careerminds — AI-led layoffs: What HR leaders wish they knew before making job cuts

Jev by TypeSafe AI: Hype, Tool or Threat?

Valentine Shi — Mon, 21 Sep 2026 09:47:13 +0000

Series: Backends in Node.js and TypeScript

A few days ago, TypeSafe AI introduced Jev, a new model designed to make fast, structured decisions that software can use directly.

I read the announcement and had two questions: Is Jev more of a hype? Is it really useful for me as a backend engineer? And does it present a new threat of replacing me as a software engineer? Jev also reminded me of the OpenAI REST API "structured outputs" endpoints. I wondered whether Jev would offer any advantages over OpenAI.

Here is what I found.

What Does Jev Actually Do

Jev (by TypeSafe AI) belongs to a class of narrowly specialized models that provide structured outputs rather than just prose. It accepts application state as input and returns structured decisions. The possible outputs and their types are defined in advance.

For example, an application could provide information about a customer and ask Jev to classify the customer's churn risk, determine which support department should handle a request, or score a potential business opportunity. The application receives predefined values that it can use in its business logic.

Very similar to OpenAI "structured outputs", I think.

TypeSafe AI claims that Jev provides several advantages:

Response times of 70–500 ms.
Input costs of $0.042 per million tokens.
Guaranteed adherence to predefined output types.
Calibrated probabilities and confidence scores accompanying its decisions.

The company also claims substantial improvements in speed and cost compared with existing LLMs performing similar tasks.

These are the company's published results. Jev is currently in early access, and I haven't tested it myself.

Jev vs OpenAI Structured Outputs

I have already worked with OpenAI's API to implement structured classification and decision-making workflows. OpenAI introduced Structured Outputs in August 2024. With strict: true, developers can define a JSON Schema and receive responses conforming to that schema.

We can already classify incoming data, select values from predefined enums, extract structured information, and use the results in application code. ([OpenAI][2]). Jev provides essentially the same capabilities for these use cases.

Jev's underlying generation mechanism (it generates its decision outputs in parallel and provides associated probabilities - confidence scores) is interesting, but there is little reason to judge Jev's advantage based on its implementation details.

The practical question for a backend engineer is whether Jev produces decisions of comparable accuracy, faster and at a lower cost, for the same workload. They claim it has an edge in this. But with OpenAI Structured Outputs we can select the seriously cheaper model still very capable of producing structured outputs with a large focused (cached) context.

Jev: Useful in Real Backend Systems?

At one innovation analytics startup, I worked on backend architecture and LLM-powered ingestion and scoring pipelines. The system needed to process incoming information, classify it using controlled vocabularies, and produce structured results that could be used by subsequent application components.

I implemented deterministic validation gates to check model outputs before allowing the code to proceed through the workflow. Looking at Jev's capabilities, I can see where it could fit into this architecture. For example, I could use it to classify incoming records or calculate particular scores.

I had great results with GPT-4o Mini (quite cheaper than GPT Luna that TypeSafe AI compares Jev with) with latencies well within 100ms and costs like $0.15 per 1,000 requests of ~2K prompt and ~700 bytes JSON response.

Separately, Jev's confidence scores may seem to be useful for workflows where an application needs to decide whether to accept a model's decision or send the case for further processing. But these scores can be equally misleading requiring additional deterministic validation gates, thus adding the complexity to a workflow.

My conclusion is Jev deserves some A/B testing under realistic production workloads vs OpenAI structured outputs before any decision. With millions of requests it may offer an advantage. As well its confidence scores may be used in some cases.

A Tool Or an Engineer's Replacement.

This was my original concern. A usual senior backend engineer's work involves designing application architecture, domain models and service boundaries, implementing APIs, working with databases, and building distributed systems, and often, implementing business workflows that involve classification, scoring, and other decisions based on incoming data.

Jev could automate some decision-making operations. As well as OpenAI structured outputs does. But hardly presents any threat to the entire engineering process. So the answer is "a tool", that has had alternatives for already ~2 years.

My Conclusion

After examining Jev and comparing it with OpenAI's existing Structured Outputs, I see it as a potentially useful addition to my backend engineering toolkit with advantages that have yet to be proven for production systems already using OpenAI structured outputs.

For now, I am interested in seeing how Jev performs on real business workloads and whether its claimed performance improvements justify replacing existing LLM calls in production systems.

I Enjoy Software Development Even More With AI

Valentine Shi — Thu, 20 Aug 2026 06:56:24 +0000

I keep reading that AI turns an engineer into a reviewer of generated code and removes the enjoyable part of the work. My experience with Codex is quite opposite (will try Claude one day). I have always enjoyed software engineering, and now I enjoy it even more.

Before I get to TDD and implementation, I use the agent to analyse the problem and technical domains and model the system in detail. Most of my design decisions happen there.

I can examine more alternatives and find missing decisions earlier. However, to judge the output, I have to know beforehand how and why the system should work, and how the test and code should look like. The agent makes the analysis and modelling many times faster and helps me update the entire model while the design changes.

The largest difference appears after a redesign. Updating diagrams and specifications and then reworking the code and tests used to consume a lot of time. Now it happens like 50 times faster (gut feeling). So I can redesign more freely and do not have to keep a weaker decision just because changing everything around it would take too long.

The agent also does much of the routine work of propagating my decisions through specifications, code and tests. This allows me to spend much more time analyzing the domain and designing the system.

Pure joy.

AI in Development: Speed vs. Hidden Defects

Valentine Shi — Sat, 15 Aug 2026 10:14:06 +0000

The article linked here describes a telling case: a senior developer discovers that Claude Code reduced the time needed to complete a task from a week to just two days. However, later on, the generated functionality caused failures in production twice. At first glance, the code looked plausible, but it contained hard‑to‑detect errors, and it turned out to be significantly more difficult to thoroughly verify AI‑generated implementation than one’s own.

The code looked plausible, but identifying subtle defects was challenging because the developer hadn’t built a sufficient mental model of code they didn’t write themselves.

I keep coming to the same conclusions. AI requires a clear engineering understanding of what the code should look like. Speeding things up without having a full mental model of the system leads to costly production errors and rework.

I’m curious — are there any seriously experienced developers here who intensively use AI for production development, especially in unfamiliar, complex domains or when implementing major new functionality?

How successfully are you able to delegate implementation to AI while still truly understanding, verifying, and being fully accountable for the result?

Real-Life Refactoring Example: ~3x Less Code to Read

Valentine Shi — Tue, 11 Aug 2026 13:24:24 +0000

There is a popular idea that refactoring is making code shorter. It is not entirely wrong. Repetition, pointless conditional branches, and dead variables do make code longer for no reason. But the usual topmost problems are when the intentions of a class's main public method, the business or operational ones, are unclear to a reader.

I had such a case in an S3 document-upload adapter.

The adapter was not doing anything unusual. It had to stream a document to S3-compatible storage, count actual bytes, calculate a checksum, reject empty or too-large content, normalize S3 errors, clean up a stored object where needed, and write technical logs. This is a substantial piece of work. The problem was that the public store() method contained most of it directly.

At a glance it looked like a method that stores a document. In practice, reading it meant walking through AWS SDK setup, try/catch blocks, S3 error-object construction, cleanup, and a large logging payload before reaching the returned value.

The code was not unreadable because it had many lines. It was unreadable because the important lines had no space to stand out.

The Main Method Refactor

The main method did not show the adapter's use case. Before the refactoring, upload execution was part of store() itself:

try {
 response = await new Upload({
  client: this.#s3_client,
  params: {
   Bucket: this.#bucket_name,
   Key: documentStorageKey,
   Body: countedStream,
   ContentType: file.mime_type
  },
  leavePartsOnError: false
 }).done();
} catch (error: unknown) {
 // Detect validation errors.
 // Build an S3 error object.
 // Build an application exception.
 // Log it.
 // Throw it.
}

How do I decide what to refactor? The rule of thumb for production code is to watch the nesting depth. In my book, a class should not contain more than three levels of nesting. The first is the class declaration, the second is the method level, and the third is at most one level of nesting within a method - inline object literals and deeply nested objects are not allowed.

The second rule - the main public methods must reveal their intention clearly by their names and their internal code must reveal the story of how the method does what it does in the domain or integration terms.

So the first refactoring was to extract that try/catch into a story-telling method:

const response = await this.uploadToStorage(documentUUID, documentStorageKey, file, countedStream, startedAt);

It was "Extract Method" refactoring, described by Martin Fowler in his Refactoring book. The main method started to read as a story because the implementation was hidden and the method name revealed intention. It packed 40+ lines into one intention-revealing call — roughly 40x less implementation detail to scan in the main flow.

I used the same approach to extract two conditionals converting a raw S3 error into an application error, and to delete an empty object and throw another error. The first turned ~20 lines into one call, and the second reduced another ~30 lines to one call. Together, roughly 90 lines of implementation detail became three intention-revealing calls — about 30x less code to scan at this level. And look at the method names — they continue the story

this.throwIfS3Error(storedObjectKey, response, httpStatusCode, startedAt);
await this.throwIfUploadedFileIsEmpty(storedObjectKey, file, countedStream, startedAt);

Moreover, now a reader can answer the first useful question quickly: what happens when a document is stored? It is uploaded. The response is checked. Empty content and errors are dealt with.

The helper methods still contain difficult code. That is fine. Difficult code should exist where it belongs. It should not hide the business flow of the public method.

[!INFO]
The main store() method shrank from 121 lines to 39 — a 68% or 3x reduction in code to read.

A Private Helper Is Not Automatically a Public API

The next request looked small. The upload service needed to delete the object it had just stored when a duplicate document was found, or when persistence failed later in the transaction.

There was already a private cleanup method.

private async cleanupStoredObject(documentUUID: string, documentStorageKey: string, startedAt: number): Promise<void> {}

A tempting change was to make it public. That would have been wrong.

The private method accepted a document UUID, a storage key, and a timestamp. The timestamp existed only because the method wrote a cleanup-failure log. It also swallowed a deletion error. That was correct for the empty-upload path: the caller must receive the original “empty upload” error even when cleanup itself fails.

It is not a public removal contract. The public operation became this instead:

public async remove(storedObjectKey: string): Promise<void>

It now owns the S3 request. It owns the timing of the S3 operation. It normalizes the provider error. It writes the technical storage event. It throws the normalized error to its caller and it is universally used by the adapter and its caller.

public async remove(storedObjectKey: string): Promise<void> {
    const removalStartedAt = Date.now();

    try {
        await this.#s3_client.send(new DeleteObjectCommand({
            Bucket: this.#bucket_name,
            Key: storedObjectKey
        }));
    } catch (error: unknown) {
        const normalizedFailure = this.normalizeStorageFailure(error);

        this.logStorageEvent({
            logLevel: ELogLevel.ERROR,
            eventName: EDocumentStorageLogEventName.DOCUMENT_STORAGE_CLEANUP_FAILED,
            outcome: ELogOutcome.FAILURE,
            operationName: DOCUMENT_STORAGE_LOG_CONSTANTS.operation.remove,
            storedObjectKey,
            startedAt: removalStartedAt,
            error: normalizedFailure
        });

        throw normalizedFailure;
    }
}

The caller decides what to do with that error.

The remove() itself catches it for an empty upload because empty content remains the reported result. The adapter's caller - the upload service - will catch it for a duplicate upload because a duplicate remains the domain concern, not the adapter's one. These are different decisions made by different owners.

One String, Two Names

Naming was not cosmetic in this refactoring. The application has a document UUID. The S3 adapter uses an object key. They were used in the multiple adapter logging methods extracted from the main store() method.

private logFailure(documentUUID: string, documentStorageKey: string, error: MinimalRAGException, startedAt: number): void {}

The document UUID is part of the key:

const storedObjectKey = `raw/${documentUUID}`;

The domain value object returns it as document_storage_key, because it is document metadata from the domain side. Inside the S3 adapter, it is storedObjectKey, because it is passed to the AWS SDK as Key.

The difference matters most when deleting an object.

At one point, removal was proposed as remove(documentUUID), with the adapter reconstructing raw/<UUID>. It looked tidy. But the exact key is already known after store() returns. Rebuilding it makes removal depend on a key layout which may later change. Passing the known stored object key is simpler and more honest.

The final refactoring replaces multiple log methods with one (Parameterize Method), parameterized with an object instead of a long list of positional parameters (Introduce Parameter Object). The method signature becomes 2x shorter, with intention-revealing names that are clear at first sight.

private logStorageEvent(options: TLogStorageEventOptions): void {}

Logging Had Become Its Own Mini-Application

This refactoring describes the other dimension of the refactoring result shown above.

The adapter had a method for successful storage. Another for successful removal. Another for S3 failure. Another for validation failure. Another for cleanup failure.

They all built nearly the same event:

{
    event_name,
    event_type: ELogEventType.INTEGRATION,
    outcome,
    resource: { storage_key: storedObjectKey },
    operation,
    error_code?,
    error?
}

Different logging events are useful. Five separate ways to construct 70%-identical logging event are not.

private logSuccess(documentUUID: string, documentStorageKey: string, startedAt: number, actualByteSize: bigint, httpStatusCode: number | undefined): void {}

This is where a long argument list becomes a real problem. Six positional arguments might compile. Nobody wants to remember their order during a production incident.

The final code uses the single logging method and one parameter object:

type TLogStorageEventOptions = TLogStorageSuccessOptions & {
 logLevel: ELogLevel;
 outcome: ELogOutcome;
 error?: MinimalRAGException;
};

// ...

this.logStorageEvent({
 logLevel: ELogLevel.WARN,
 eventName: EDocumentStorageLogEventName.DOCUMENT_STORAGE_VALIDATION_FAILED,
 outcome: ELogOutcome.FAILURE,
 operationName: DOCUMENT_STORAGE_LOG_CONSTANTS.operation.store,
 storedObjectKey,
 startedAt,
 actualByteSize: countedStream.actual_byte_size,
 error: rejection
});

The refactoring reduced roughly 90 lines the reader previously had to scan to about 30.

Deeply Buried Intention

The builder of the logged object initially contained code like this, which is completely opaque:

{
    operation: new LogOperationVO({
        // other fields
        ...(cause?.request_id ? { provider_request_id: cause.request_id } : {})
    }),
}

That conditional object spread was very far from readable.

I extracted values into interim constants with intention-revealing names and used them in the logged object construction:

// Extract all ternaries to the clearly named constants
const actualByteSize = options.actualByteSize?.toString() ?? null;
const httpStatusCode = options.httpStatusCode ?? cause?.http_status_code ?? null;
const providerRequestId = cause?.request_id ?? null;
const storageError = cause
 ? new LogErrorVO({
    name: cause.error_name,
    message: cause.error_message,
    dependency: DOCUMENT_STORAGE_LOG_CONSTANTS.dependency
   })
 : null;

// Call the logger
this.#logger.log(options.logLevel, {
 operation: new LogOperationVO({
  // Other fields
  actual_byte_size: actualByteSize,
  http_status_code: httpStatusCode,
  provider_request_id: providerRequestId
 }),
 error: storageError
});

This makes the final log event construction boring. That is good. Logging is repeated often enough throughout an application that it should better be DRY.

Actual Refactorings Used

For readers who care about Fowler’s refactoring names, here is the short record.

Make The Public Storage Flow Readable

Change	Fowler refactoring
Move inline upload and its error handling into `uploadToStorage(...)`.	Extract Method
Move raw S3 error conversion into `normalizeStorageFailure(...)`.	Extract Method
Move empty-object deletion into `cleanupStoredObject(...)`.	Extract Method
Move response and empty-stream checks into named methods.	Extract Method
Move successful-storage logging out of `store()`.	Extract Method

Clarify Storage Vocabulary and Logging

Change	Fowler refactoring
`documentUuid` to `documentUUID`.	Rename Variable / Rename Parameter
Repeated S3 literals into `DOCUMENT_STORAGE_LOG_CONSTANTS`.	Replace Magic Literal with Symbolic Constant
`documentStorageKey` to `storedObjectKey` inside the adapter.	Rename Variable
Long logging parameters into `TLogStorageEventOptions`.	Introduce Parameter Object
Conditional payload expressions into named locals.	Extract Variable
Separate log methods into `logStorageEvent(...)`.	Extract Method

The public remove(storedObjectKey) method is not a Fowler refactoring. It is a new adapter capability. The validation event rename is not one either. It changes the meaning of the logged outcome. Calling every improvement a refactoring only makes the word less useful.

Result

The adapter did not become magically small. It should not. It now does more than it did before: it exposes removal, logs useful operational information, returns a named S3 response type, and gives the upload service a clean cleanup operation.

And the public path is now readable as a path:

const response = await this.uploadToStorage(...);
this.throwIfS3Error(...);
await this.throwIfUploadedFileIsEmpty(...);
this.logStorageEvent(...);

That is the result I want from refactoring - saving the reader's cognitive capacity for the really important work: deciding what, when and how the application should do in business and integration terms.

NB: The initial code implementation I had to refactor was written by AI.

AI Prototype as an Executable Requirements Draft

Valentine Shi — Thu, 06 Aug 2026 10:28:06 +0000

10× Faster Development with AI prototypes.

A prototype generated by a non-technical stakeholder can be very useful, but I do not treat it as an unfinished production system.

I treat it as an executable requirements draft.

The prototype gives stakeholders and domain experts something concrete to think of, build, analyze and react to, which makes product ideation and requirements elicitation much faster. Instead of discussing an abstract idea, they can directly build their ideas and visions into a prototype, actually designing the product without distracting business analytics or engineers.

The prototype code itself is a throwaway. It is usually written in a non-modular, code-and-fix style; it may lack meaningful error handling, fail to cover the use cases fully, or contain security flaws. Trying to clean it up directly can take longer than building the product correctly from the extracted requirements. But it already contains roughly formalized live product intentions, expressed by and aligned with non-technical stakeholders.

When the prototype is made, the actual engineering starts. I analyze the prototype with an AI agent and extract actors, use cases, business rules, user stories, scenarios, failure modes and edge cases. Then I model the domain context, components, interfaces and core workflows, align the result with stakeholders, and only after that design and implement the real system.

The speed gain comes from shortened ideation, stakeholder alignment and requirements formalization phases. That is the AI prototype part. It also comes from using AI across the whole engineering process, not only for code generation. It helps analyze the prototype, maintain C4 and UML models, update OpenAPI contracts, explore alternatives, generate tests and code, and keep related artifacts aligned when the design changes.

As one recent example, I designed a queue and transactional outbox subsystem, then aligned and refactored the surrounding architectural and behavioral models and aligned them with the contract and code in about four to five hours. Without AI assistance, that alignment work alone would take me a day or two.

Based on my practical experience, three to ten times faster is a reasonable ballpark for the entire stack of tasks, depending on the system and how much uncertainty exists at the beginning. It is not a universal benchmark, but it is also not only faster typing.

Engineering is freed from a big portion of requirements elicitation, prototyping and alignment and is granted more speed in analysis, modeling and implementation. I find that I enjoy development noticeably more than before AI. It is worth mentioning that I have greatly enjoyed it all the time.