DEV Community: Thanh hung Pham

Laya – An Alternative to Jev for AI Decision-Making

Thanh hung Pham — Thu, 01 Oct 2026 09:23:17 +0000

When building an application that uses AI, the most common choice today is almost always an LLM.

Application sends a prompt:

Context + Instruction
        ↓
       LLM
        ↓
Generated response

We use GPT, Claude, Gemini, or other models to chat, summarize, generate content, write code, analyze documents, and so on.

But there is a rather interesting question:

What if the application does not need AI to generate text?

For example, the application only needs AI to answer:

What category does this ticket belong to?
Which team should this request be routed to?
Is this document related to the case?
Is this transaction suspicious?
Which branch should the workflow follow?
Does this user belong to group A or B?

In these cases, the application does not really need a long answer.

It only needs:

Input
  ↓
Decision

This is where the concept of an AI Decision Model becomes interesting.

One notable example is Jev. And if you are looking for an open-source/self-hostable approach for this type of workload, Laya is a project worth exploring.

1. What is Jev?

Jev is an AI decision model from TypeSafe AI.

The fundamental difference between Jev and a typical LLM is the intended use case.

LLMs are designed to process and generate language.

For example:

User:
I cannot login to my account.

LLM:
It looks like you're having trouble accessing
your account. Please try resetting your password...

Meanwhile, a decision model focuses on a different question:

User message
     ↓
Which category?
     ↓
ACCOUNT

Instead of asking the model to generate a free-form answer, the application defines a decision space in advance.

For example:

BILLING
TECHNICAL
ACCOUNT
SALES

Then the model selects one result from these options.

The result could contain a decision and probability, for example:

{
  "decision": "ACCOUNT",
  "probability": 0.94
}

This is quite an interesting abstraction for a software system:

AI does not always need to talk to the user. Sometimes AI only needs to provide a decision to the application.

2. Why not use an LLM for this?

This is a completely reasonable question.

We can tell an LLM:

Classify this support ticket.

Possible categories:
- BILLING
- TECHNICAL
- ACCOUNT
- SALES

Return JSON only.

Then receive:

{
  "category": "ACCOUNT"
}

So why do we need a separate decision model?

Not because LLMs cannot do it.

LLMs are very good at this.

The issue is the fit between the model and the workload.

When using an LLM, the flow is still:

Prompt
   ↓
Understand context
   ↓
Reason
   ↓
Generate tokens
   ↓
Produce JSON
   ↓
Parse response

While the application only needs:

Input
  ↓
Classification
  ↓
Result

If your workload is primarily classification, routing, scoring, or yes/no decisions, a model designed for decision tasks can be a reasonable approach.

This is not about:

Decision Model is better than LLM.

It is about:

Choose the type of model that fits the type of workload.

3. What is Laya?

Laya follows a similar AI Decision Model approach.

What makes Laya interesting is its open-source/open-weight and self-hostable approach.

Instead of the application being completely dependent on an external decision API, developers can deploy the model within their own infrastructure.

From an architecture perspective:

Hosted approach

Application
     │
     ▼
External AI API
     │
     ▼
Decision

Self-hosted approach

Application
     │
     ▼
Laya Server
     │
     ▼
Decision Model
     │
     ▼
Decision

This provides another option for teams that want more control over:

Data
Network
Deployment
Infrastructure
Cost
Model lifecycle

Especially for enterprise applications, being able to run a model within internal infrastructure can sometimes be very important.

4. How can Laya replace Jev?

This is probably the most important part.

If Jev represents the approach:

AI as a Decision API

then Laya can be considered another option for the same class of workloads.

For example, the application needs to classify a ticket:

Incoming Ticket
       │
       ▼
Decision Model
       │
       ├── BILLING
       ├── ACCOUNT
       ├── TECHNICAL
       └── SALES

If using Jev, the decision is made through the Jev service.

If using Laya, the developer can deploy the decision model within their own infrastructure.

However, "replace" here should not be understood as:

Laya is a drop-in replacement for Jev in every case.

The two systems may differ in:

Model
API
Performance
Capability
Deployment
Ecosystem

The main point is:

If your workload is suitable for an AI Decision Model, Laya can be an option to consider alongside Jev.

Especially if your requirements include:

Decision Model
+
Self-hosting
+
Open-source/open-weight

then Laya becomes more interesting.

5. How is Laya different from an LLM?

It can be viewed simply as follows:

              AI Models
                  │
        ┌─────────┴─────────┐
        │                   │
        ▼                   ▼
      LLM             Decision Model
        │                   │
        ▼                   ▼
Generate content       Make decision

LLMs are suitable for:

"Write an email."
"Summarize this document."
"Explain this code."
"Generate a report."
"Answer this question."

Decision Models are more suitable for:

"Which category?"
"Which route?"
"Yes or No?"
"Which option?"
"What score?"

An important point is that a Decision Model does not necessarily have to replace an LLM.

They can be used together.

6. Combining Laya and an LLM

This is where the architecture becomes interesting in production.

For example, imagine building a Customer Support system.

The user sends:

"I was charged twice for the same transaction."

The first step could use Laya:

User Message
      ↓
    Laya
      ↓
    BILLING

Then the application routes the request to the billing flow:

BILLING
   ↓
LLM
   ↓
Generate response

Architecture:

                  User Message
                       │
                       ▼
                  ┌─────────┐
                  │  Laya   │
                  └────┬────┘
                       │
                       ▼
                  Classification
                       │
             ┌─────────┼─────────┐
             ▼         ▼         ▼
          Billing   Account   Technical
             │
             ▼
            LLM
             │
             ▼
      Generate Response

Here, each model has a clear responsibility.

Laya:

Where should this request go?

LLM:

Now that we know which flow the request belongs to, generate the response.

This is how AI can become part of the software architecture instead of simply being a chatbot called from somewhere in the application.

7. Another use case: Workflow

Imagine a workflow for processing documents.

Upload Document
       ↓
Extract Information
       ↓
Decision
       ↓
┌───────────────┐
│ APPROVE       │
│ REVIEW        │
│ REJECT        │
└───────────────┘

A decision model can act as a source of a decision signal:

{
  "decision": "REVIEW",
  "probability": 0.81
}

Then the business application decides what to do:

probability >= 0.90
        ↓
    automatic flow

0.60 - 0.90
        ↓
    human review

< 0.60
        ↓
      fallback

The important point here is:

AI does not necessarily have to have the authority to decide the entire workflow.

AI can simply provide a signal.

The business application still controls:

Business rules
Authorization
Validation
Workflow
Audit
Final action

This is an approach worth considering when introducing AI into enterprise systems.

8. Problems that are suitable for Laya

Laya is particularly worth experimenting with for problems that have a relatively clear decision space.

Classification

Document
   ↓
INVOICE
CONTRACT
ID_DOCUMENT
OTHER

Routing

Request
   ↓
TEAM_A
TEAM_B
TEAM_C

Binary decision

Request
   ↓
YES / NO

Scoring

Input
   ↓
Risk Score
0.0 ───────── 1.0

Workflow decision

Application
      ↓
Decision
      ↓
Next Step

Intent detection

User message
      ↓
LOGIN
PAYMENT
REFUND
ACCOUNT

These are all very common operations in backend systems.

9. Self-hosting: Why does it matter?

One of the reasons developers may be interested in Laya is its self-hosting capability.

With an external AI service:

Your System
    ↓
Internet
    ↓
AI Provider

With a self-hosted model:

Your System
    ↓
Internal Network
    ↓
Laya
    ↓
Model

This can be suitable for systems that need tighter control over data or infrastructure.

But self-hosting is not free in terms of operations.

You will need to care about:

CPU/GPU
Memory
Deployment
Monitoring
Scaling
Availability
Model updates
Security
Operational cost

Therefore, the question should not simply be:

"Is Laya open-source?"

Instead, it should be:

"Does self-hosting actually fit my workload and infrastructure?"

10. Laya vs Jev

If we look at them at the architecture level, we can place the two approaches side by side:

                 Decision AI
                     │
          ┌──────────┴──────────┐
          │                     │
         Jev                   Laya
          │                     │
   Hosted Decision        Self-hostable
       Service             Decision Model

The differences to consider are not only model accuracy.

When evaluating a solution in practice, developers should look at:

API compatibility
Model capability
Latency
Throughput
Accuracy on real-world data
Hardware requirements
Deployment complexity
Monitoring
Cost
Data privacy
Licensing
Ecosystem

In particular, you should not benchmark using only a few simple examples.

A model may perform very well in a demo but produce different results when running on production data.

11. When should you not use Laya?

Not every application needs a Decision Model.

If the problem is:

Generate a 2,000-word report

then an LLM is more suitable.

If you need:

Have a conversation with user

then an LLM remains the natural choice.

If you need:

Analyze a large document
and explain the reasoning

then a generative model is also more suitable.

A Decision Model is most suitable when:

Input
   ↓
Defined decision space
   ↓
Structured result

If the decision space is too open-ended or the application needs generated content, you may be using the wrong abstraction.

12. A Different Way to Look at AI Architecture

What I find most interesting about Laya is not the question:

"Can Laya replace LLMs?"

But rather, it raises a different question:

Does every AI problem necessarily need an LLM?

In software engineering, we do not use the same technology for every workload.

There are many types of databases.

There are many types of message brokers.

There are many types of storage.

There are also many programming languages.

AI can follow a similar direction.

Instead of:

Everything
    ↓
LLM

We could have:

                    AI Layer
                       │
          ┌────────────┼────────────┐
          │            │            │
          ▼            ▼            ▼
        LLM       Decision Model   Embedding
          │            │            │
          ▼            ▼            ▼
      Generation    Decisions     Retrieval

AI then becomes a collection of capabilities rather than a single LLM.

13. Conclusion

Laya is an interesting project if you are interested in AI Decision Models and want to explore an open-source/self-hostable option alongside decision services such as Jev.

The important point is not to view Laya as a "new LLM."

It solves a different type of problem:

Input
  ↓
Understand
  ↓
Decision
  ↓
Application takes action

Instead of:

Input
  ↓
LLM
  ↓
Generate everything

This opens up a rather interesting way to design AI applications.

LLMs can handle generation.

Decision Models can handle decision-making.

The application still retains control over business logic and the final action.

Therefore, if you are building an AI-powered application, perhaps the first question should not be:

"Which model should I use?"

Instead:

"What does my application actually need AI to do?"

If you need to generate → use a generative model.

If you need to retrieve → use embeddings/retrieval.

If you need to make decisions → a Decision Model such as Laya can be an option worth trying.

And that is exactly what makes Laya interesting:

AI does not necessarily have to generate everything. Sometimes, AI only needs to help software make a structured decision.

AI-Native Software Development: Redesigning the Software Development Workflow with AI

Thanh hung Pham — Sun, 27 Sep 2026 04:12:17 +0000

AI is changing the way software engineers develop software. From analyzing requirements, designing solutions, writing code, creating tests, debugging, to code review, more and more tasks can be supported or automated by AI.

However, most of the ways we currently apply AI are still focused on individuals or individual stages. Developers use AI coding assistants, QA uses AI to generate test cases, BA uses AI to analyze requirements, while DevOps uses AI to support CI/CD operations.

This helps individuals work faster, but it does not solve a bigger problem: the entire engineering workflow has still not truly been redesigned for AI.

A developer can code faster, but still has to wait for requirement clarification. QA still has to understand the context again. Developers still have to explain the design to QA. Reviewers still have to read a large amount of code generated by AI. Knowledge is still scattered across documentation, tickets, source code, chat, and the minds of individual team members.

Therefore, instead of only asking, "How much faster can AI help developers code?", we should ask a different question:

How can AI make the entire software engineering workflow faster, more continuous, and less prone to rework?

That is the problem of AI-Native Software Development.

1. The Problem Is Not Only Coding

A software feature does not only involve writing code. A typical workflow may start with Product or BA analyzing requirements, followed by a Tech Lead or Architect designing the solution, Developer implementation, QA verification, Code Review, and finally Deployment.

Throughout this entire process, coding is only one part.

Actual time is also spent searching for information, clarification, design discussions, handoffs between roles, waiting for reviews, writing tests, debugging, handling CI failures, and especially rework when part of the context is misunderstood.

For example, a requirement may be passed from BA to Developer in the form of a ticket. The Developer reads the ticket, asks additional questions, and searches for documentation. After the implementation is completed, QA has to read the ticket and code again to understand the system behavior. When an issue is found, the information goes back to the Developer. Each handoff creates coordination cost.

Therefore, if we only optimize coding time, we are optimizing only one part of the system.

The larger goal should be to reduce lead time, cycle time, waiting time, coordination cost, and rework across the entire engineering process.

2. AI Fragmentation Is a New Problem

As AI begins to be introduced into teams, a new problem appears: AI fragmentation.

Developer A uses one AI tool. Developer B uses another tool. QA has a separate workflow. BA uses another AI to write specifications.

Each AI may have different context, instructions, and knowledge.

This creates a paradox: the team has more AI, but does not have a unified AI engineering workflow.

Knowledge is fragmented in a similar way. Business rules may exist in documentation, architecture decisions may exist in tickets or discussions, implementation knowledge exists in source code, and production knowledge exists in incidents or postmortems.

When an AI agent handles a task, if it can only see part of this information, its output may lack context or fail to comply with the team's engineering standards.

Therefore, AI-Native Software Development needs to address not only AI execution but also context and knowledge management.

3. AI Should Not Be Added to Each Role Independently

A natural approach is to build AI for each role:

BA + AI, Architect + AI, Developer + AI, QA + AI, and DevOps + AI.

But this approach still keeps the old workflow. AI simply becomes a tool alongside each role.

Another approach is to integrate AI throughout the workflow.

Requirements are analyzed with AI support and transformed into specifications. Specifications become the context for design. Design becomes the context for implementation. Implementation creates code and tests. QA uses requirement, design, and implementation context for verification. Verification results and production feedback continue to become engineering knowledge.

Here, AI is not a separate tool for Developers or QA. AI becomes a layer that runs throughout the software development workflow.

Humans still retain the decision-making role. AI supports analysis, generation, verification, and automation; humans are responsible for business decisions, architecture decisions, approvals, and accountability.

4. Artifacts Are the Bridge Between Roles

One way to reduce context loss is to turn the output of each phase into a structured artifact.

Instead of a Requirement existing only in a ticket or a meeting, it can be transformed into a Specification. The Specification is used to create a Technical Design. The Design is used to create an Implementation Plan. The Implementation Plan leads to Code and Test Cases. Then the Verification Report and Production Feedback continue to contribute to engineering knowledge.

The important point here is that artifacts are not just documentation.

Artifacts become context contracts between phases.

Developers do not need to start from an empty ticket. QA does not need to rebuild the entire context by themselves. An AI agent in a later phase can use artifacts from the previous phase to understand intent, constraints, and decisions.

The handoff between BA, Tech Lead, Developer, and QA is therefore no longer simply about "sending information" but about transferring structured context.

5. Knowledge Must Become a Continuous Loop

A typical AI system has a relatively simple flow:

Knowledge → AI → Answer.

In software engineering, the flow should be longer.

Knowledge is used to create artifacts. Artifacts are used to implement software. Software generates test results, production behavior, and incident data. This information is then transformed into new knowledge.

The lifecycle can be visualized as:

Knowledge → AI → Artifact → Implementation → Verification → Production Feedback → Knowledge.

For example, a production incident occurs. The team performs root cause analysis, fixes the issue, and creates a postmortem. If the postmortem only remains in a document without being added back into engineering knowledge, its value is limited to the current incident.

If it becomes part of the shared context, the next time a developer or AI agent handles a similar problem, the system can use the previous experience.

In this way, each task not only creates software but can also create additional knowledge for subsequent tasks.

This is an important point for AI-Native Software Development to become a system that can improve over time rather than just a collection of AI tools.

6. Company Rules Must Become Part of the Context

Another issue is governance.

AI can generate code very quickly, but that code must comply with the company's architecture, security policies, coding standards, API conventions, database rules, testing requirements, and deployment process.

If every developer has to manually provide these rules in AI prompts, it is difficult to ensure consistency.

Instead, company rules should become part of the shared engineering context.

When an AI agent handles a task, it receives not only the business requirement but also the engineering constraints.

For example, a task to create a new API may need to understand API conventions, authentication requirements, logging standards, database guidelines, testing requirements, and deployment policies at the same time.

Then AI is no longer simply answering the question, "How should I implement this feature?", but must solve the question, "How should I implement this feature within the team's engineering environment?"

7. Automation Is What Makes the Workflow Truly Change

If developers still have to copy requirements from Jira into AI, copy the output back into the IDE, manually create tests, create a PR, and run each step themselves, then AI is only supporting individual actions.

The workflow truly changes when the steps can be connected.

A new task can trigger context collection. The context is used to create a specification and implementation plan. After approval, an AI agent can perform the implementation, generate tests, and create a pull request. CI/CD continues with automated verification. AI can analyze failures and propose or perform fixes within the permitted scope.

Humans only need to intervene at important decision gates.

This transforms the workflow from a sequence of manual actions into a continuous engineering flow.

8. Humans Still Own Decisions

AI running throughout the workflow does not mean removing humans.

On the contrary, as AI participates more, clearly defining human responsibility becomes even more important.

AI can analyze requirements, but Product or BA confirms the business intent. AI can propose architecture, but the Tech Lead or Architect decides the design. AI can generate code, but the Developer is responsible for the implementation. AI can generate and execute tests, but QA still confirms the quality criteria. AI can support deployment, but production releases still require appropriate approvals based on the risk level.

A simple principle can be used:

AI accelerates execution. Humans own decisions.

This also allows the workflow to divide steps into automatic execution and human approval instead of trying to automate everything.

9. Productivity Must Be Measured at the System Level

If we want to prove that AI actually helps a team increase productivity, we should not only measure the amount of code generated by AI or the time a Developer spends writing code.

More important metrics exist across the entire software delivery flow.

For example, we can track Lead Time, Cycle Time, PR Throughput, Review Time, Rework, Defect Rate, Deployment Frequency, and Change Failure Rate.

Suppose that before applying AI, a feature takes 10 days from requirement to deployment. After redesigning the workflow, the time spent on requirements, design, coding, testing, review, and rework is reduced, and the total cycle could decrease to 4.5 days.

This number is only an illustrative example, not a guaranteed level of improvement.

The important point is that the way we measure must change.

We should not ask:

"How much faster does AI help developers write code?"

Instead, we should ask:

"How has AI changed the entire engineering cycle?"

If coding time decreases but rework or review time increases, the productivity of the system may not actually increase.

10. From SDLC to Continuous Engineering Flow

Traditional SDLC is often described as a sequence of phases: Requirement, Design, Development, Testing, and Deployment.

AI allows us to connect these phases more closely.

Requirement creates Specification. Specification creates Design. Design creates an Implementation Plan. Implementation creates Code and Test. Verification creates Feedback. Production creates Knowledge. Knowledge flows back into Requirements and subsequent tasks.

The workflow is no longer simply a linear pipeline.

It becomes a continuous loop.

AI can operate throughout this loop, using artifacts and knowledge from previous phases while simultaneously creating artifacts and knowledge for subsequent phases.

This is the difference between "adding AI to the SDLC" and redesigning the engineering workflow for AI.

Conclusion

AI Engineering does not necessarily mean building a better AI coding assistant.

The bigger challenge is redesigning how engineering teams work when AI is capable of participating in most phases of the software lifecycle.

AI-Native Software Development needs to combine workflow, shared knowledge, context continuity, artifacts, AI agents, automation, governance, human decision-making, and measurement.

The ultimate goal is not to make AI write more code.

The goal is to reduce context switching, waiting, manual coordination, and rework, while increasing knowledge reuse and software delivery automation.

Instead of each role using a separate AI, the team moves toward a unified engineering flow:

Requirement → Specification → Design → Development → Testing → Review → Deployment → Feedback → Knowledge → Next Requirement.

AI runs throughout the flow.

Humans own decisions.

Artifacts preserve context.

Knowledge accumulates through each cycle.

Automation connects the steps.

And measurement tells us whether the entire system is actually getting better.

This is how AI-Native Software Development can be viewed not as a collection of AI tools, but as a new way to operate the entire software engineering workflow in the AI era.