DEV Community: Lian0123 (連永立)

Notes on Introducing AI into Vibe Coding Development (Part 1): Why Does AI “Cut Corners”?

Lian0123 (連永立) — Sun, 19 Jul 2026 04:03:02 +0000

Introduction

From Vibe Coding to Harness Engineering, integrating AI into software development has become one of the industry’s most discussed topics. Many companies are adopting AI to improve productivity, while new models and tools optimized for programming continue to emerge.

Choosing the right model can save you from many unnecessary detours. But if your prompt is poorly designed, AI may lead you even further away from your actual goal.

This article summarizes several common mistakes I have observed while introducing AI into development workflows. These principles apply not only to everyday prompting, but also to the design of reusable skills, project rules, and engineering workflows.

Keep one thing in mind: when AI starts to “cut corners,” humans usually pay for it with more tokens and more time spent fixing the result.

Why Does AI “Cut Corners”?

Anyone familiar with deep learning may have heard of specification gaming or reward hacking.

In simple terms, an AI system may exploit gaps in an instruction or evaluation rule to satisfy the visible objective at the lowest possible cost. The task may appear complete, while the output is useless—or even contradicts the real intention behind the request.

A Simple Example

Imagine a student named Xiaoming who receives 100 units of allowance every day. To encourage him to study, his parents require him to take a practice exam each day:

If his score drops by 10 points, his allowance is reduced by 10 units.
If his score rises by 10 points, his allowance increases by 10 units.

Xiaoming scores zero on the first day, so his allowance drops to 90 units. He soon realizes, however, that if he continues scoring zero every day, his score will never fall below the previous day’s result. He can keep receiving the full 100 units without studying.

Xiaoming has not violated the rules, but the system has completely failed to achieve its purpose. His parents wanted him to study, yet they accidentally created an optimal strategy in which he can avoid studying and still receive a stable allowance.

A Software Engineering Example

Suppose an engineer asks an AI agent to “fix the bug in this program.”

Without additional constraints, the AI could theoretically delete the faulty code—or remove the entire feature. If the program no longer exists, the error can no longer occur. That technically eliminates the bug, but it clearly does not satisfy the user’s real need.

In Vibe Coding, AI often gravitates toward the fastest, cheapest, and easiest-to-mark-as-complete solution. If a prompt describes only the surface-level objective without defining the intent, constraints, and acceptance criteria, the result can easily diverge from expectations.

Improving AI Behavior Through Better Instructions

Method 1: Provide a Reference Example

One of the most effective approaches is to provide a correct example and ask the AI to follow an established pattern.

The goal is not to prevent the AI from reasoning. It is to reduce unnecessary guesswork. When naming conventions, file structure, interface style, and implementation patterns are demonstrated clearly, the AI is less likely to misunderstand the task, make implementation mistakes, or hallucinate nonexistent behavior.

This approach is especially useful for:

interface development in large projects;
building a new page based on an existing one;
integrating third-party APIs;
reusing established components, tests, or data formats;
implementing features with complete official documentation.

Instead of saying, “Build me a new page,” say, “Implement page B by following page A’s directory structure, component boundaries, and error-handling pattern.”

Method 2: State Explicit Prohibitions

Another common technique is to turn known risks and failure modes into explicit prohibitions.

For example:

Do not remove existing functionality.
Do not disable tests to make the test suite pass.
Do not replace a production API with mock data unless clearly instructed.
Do not change the public interface.
Do not place keys, tokens, or personal data in source code.
Do not perform a large refactor before confirming the impact.

This reflects a useful practice in AI-assisted development: turn previous mistakes into reusable rules. Whether those rules live in AGENTS.md, CLAUDE.md, a skill, or a team knowledge base, the purpose is the same—to prevent known failures from happening again.

This method works well when the risks and operational boundaries are already understood. However, more prohibitions do not automatically produce better results. Too many rules, conflicting rules, or rules without priorities can overload the context and bury the constraints that matter most.

Method 3: Require a Detailed Plan First

One of the central benefits of plan modes and skills is that they break work into reviewable steps.

A useful implementation plan should include at least:

goals and non-goals;
the expected scope of changes;
implementation order;
potential risks;
testing and verification methods;
completion criteria.

When the workflow is written down, humans can identify misunderstandings before the AI begins making changes. This also reduces the chance of unexpected actions during execution.

This approach is particularly suitable for new projects, large refactors, and feature development in projects with an established knowledge base.

Its limitation is equally clear: the quality of the plan depends on the completeness of the available information. If an important condition is missing during planning, the AI may faithfully execute a plan that looks complete but is fundamentally wrong.

A more mature approach is to maintain the following information at the documentation level:

development rules;
architecture and feature responsibilities;
change history;
risk assessments;
acceptance criteria;
known issues and the reasoning behind past decisions.

Together, these materials form a living project knowledge base. I will explore this topic in a future article on AI Living Documentation.

Method 4: Define the Expected Outcome Clearly

If you can describe exactly what “done” should look like, the AI’s output is more likely to converge on the intended result.

For front-end work, this may include a wireframe, design mockup, interaction flow, target screenshot, or existing page. For back-end work, it may include an API specification, input and output examples, error codes, and performance requirements.

In addition to explaining what must be built, define:

which existing behaviors must remain unchanged;
which scenarios must succeed;
which errors must be handled correctly;
how completion will be demonstrated.

Clear acceptance criteria prevent the AI from treating “the code has been written” as equivalent to “the feature is complete.”

Common Problems in Practice

Problem 1: Claiming Completion Without Verification

Suppose a user asks an AI agent to integrate a particular library. If the model misunderstands the library’s version, API, or documentation, the generated code may look plausible while failing at runtime.

The original instruction might be:

Add Live2D to this web page so that the character on the page can be animated.

This describes the feature but does not require the AI to verify the result. A stronger instruction would be:

Add Live2D to this web page so that the character on the page can be animated.

Confirm that the Live2D assets load correctly, the model is visible, and its animation plays.

Run the project and verify that no related errors appear in the browser console.

Do not break existing page functionality. If any item cannot be verified, clearly identify it and explain why.

When finished, list the changed files, verification method, and test results.

“Please ensure code quality” is still too abstract. A better approach is to translate quality into executable and observable conditions:

the project builds successfully;
automated tests pass;
the feature works in the specified environment;
no new errors appear in the browser console;
existing functionality remains intact;
any unperformed verification is clearly disclosed.

The key principle is that development, testing, and verification are separate steps performed in sequence. Writing the code does not mean the tests have passed, and passing tests does not necessarily mean the user’s need has been satisfied.

If this workflow is used repeatedly, encode it in a skill, project rule, or standard checklist instead of relying on an ad hoc reminder every time.

Problem 2: Ambiguous Terms Create Divergent Interpretations

Humans cannot read minds, and neither can AI.

When a requirement is unclear, the AI can only fill in the missing information using its prior knowledge, the current context, and common conventions. Its answer may be reasonable without being what the user actually wanted.

For example, “menu” in an application could refer to:

the main menu;
the settings menu;
a context menu;
the top navigation bar;
a mobile side menu.

Consider this instruction:

Add an “Open File” option to the menu.

The AI has to infer which menu should be changed. Even if it chooses the wrong location, it may still conclude that the task is complete.

A clearer version would be:

In the desktop application’s top-level File menu, add an “Open File” option directly below “New File.” When clicked, it should open the system file picker and allow the user to select a .json file. Cancelling the picker must not display an error. Do not modify the context menu or the settings page.

The more concrete the description, the fewer semantic branches remain—and the less likely the AI is to make the wrong assumption.

Conclusion

When AI “cuts corners,” the cause is often not attitude but incomplete definitions of the goal, constraints, and acceptance criteria.

If you tell an AI only what to finish, it may choose the shortest path. If you also explain why the task matters, what must not be broken, how the result should be verified, and what counts as complete, the quality of its output becomes far more consistent.

An effective AI development workflow is not simply a longer prompt. It is a system that continuously accumulates reference examples, prohibitions, implementation plans, acceptance criteria, testing procedures, and project knowledge.

Next: Why Am I Burning Through Tokens So Quickly?

Have you ever asked AI to solve one simple problem, only to watch the token usage grow until your wallet starts to worry? The reason may not be that the model talks too much. Your development process may be repeatedly paying the cost of misunderstandings.

Stay tuned for the next article.

The original article was written in Traditional Chinese, and the Japanese and English versions were translated using ChatGPT.

Notes on Introducing AI into Vibe Coding Development (Part 0) - Why I Am Writing This Article

Lian0123 (連永立) — Thu, 02 Jul 2026 16:57:35 +0000

What Is Happening in the Software Industry Now?

In recent years, with the emergence of general-purpose artificial intelligence such as ChatGPT and Claude Code, often referred to as AGI, companies have increasingly begun introducing AI into their workflows.

Starting in June 2026, GitHub Copilot AI made a major change. It moved away from the PRU model, or premium request units, which was based on request counts, and shifted toward a model calculated using AI Credits. As a result, the execution cost for an engineer developing a feature, reviewing PRs, organizing documentation, and performing other tasks has gradually increased.

Some developers even used up an entire month’s allowance on the very first day GitHub Copilot AI adopted the AI Credit model. This shift toward token-based pricing is becoming increasingly mainstream. It also places more restrictions on using AI within workflows. If you are not careful, your usage can run out quickly, and costs can continue to rise. Worse still, this type of pricing model is likely to become a broader trend among AI service providers.

Jensen Huang once said:

If that $500,000 engineer did not consume at least $250,000 worth of tokens, I am going to be deeply alarmed.

The question today is no longer whether we should use AI. After all, not every company is like NVIDIA, with the freedom to consume tokens at scale. The real issue is the conflict between problem-solving, money, and time.

Solving problems and controlling costs have already become conflicting forces. The future direction of the software market will be about solving problems effectively while keeping costs under control. It will not be about how many tokens you used to solve something, but about achieving the greatest benefit with the lowest possible cost.

What Should Business Managers and Development Leads Do Next?

Clearly, the first step is to identify what qualities and capabilities future technical talent should have:

The ability to break down large problems and requirements, extract the key points, group them properly, and find the best solution
The ability to simplify AI behavior so it can be executed at the lowest possible cost
The ability to achieve maximum benefit with the fewest tokens

Here is an evaluation framework for companies, including both positive and negative evaluation points.

Positive Evaluation Points

If the company is willing to spend money to solve problems:

Has this problem been troubling the company for a long time? Was it difficult to execute through conventional methods because of staffing, scheduling, or other reasons?
Has AI effectively replaced existing talent resources in the way an expert system might? While ensuring correctness, has it saved human effort?
Was the problem solved quickly? Did it create additional time costs?

Negative Evaluation Points

If the company is relatively conservative:

Will this adjustment reduce future changes, or will it increase them? How should we limit the damage?
If problems occur, are the losses acceptable? For example: time, reputation, and financial cost.
How much benefit can this adjustment bring? Compared with problem-solving costs and personnel costs, how much money does it actually save?
Will future maintenance costs decrease? Or will AI make them higher and unnecessarily so?

In practice, what business managers need even more is a cost plan:

How much cost are we willing to invest in solving the problem?
Is the risk of cost increase controllable?
Are there audit points in place to control costs?

Regarding the common online discussion that AI will replace software engineers, my view is relatively optimistic. There are many detailed technical issues that bosses or non-engineering project managers simply cannot fully grasp. When a company truly lays off all of its software talent, that is when the real disaster begins.

That said, it is undeniable that Junior Engineers will become increasingly rare in the future. The technical threshold will become higher, because using AI well requires the corresponding knowledge. In contrast, Senior Engineers who can combine experience and expertise will become one of the strongest resources in the market.

The knowledge and experience of software professionals will become an important dividing line.

Here is a simple example. Suppose a project developed through Vibe Coding suddenly encounters a serious bug in production. Every minute the problem exists causes the company to lose money.

If you were the manager, would you want the developer to search for the answer as if rolling dice? Or would you want the developer to quickly identify the root cause?

I also like this saying:

People can never imagine what lies outside their own understanding.

The knowledge of a project member is the key to future product maintenance.

Felix Rieseberg, Engineering Lead at Claude Cowork, also said:

The biggest barrier to AI adoption is people not realizing they can ask AI to solve almost any problem… The gap isn't technical; it's psychological.

Felix Rieseberg points out that the reason people fail to use AI well lies in imagination. What you can think of determines what you can ask. When using today’s top-tier models, the core problem is not always that the result falls short of expectations. More often, it is that the user has not described the requirements clearly enough, causing the AI to produce results that do not match what was expected.

Of course, the input and output limitations of model context, as well as the model’s byte-processing issues, must first be addressed.

Next Article: Why Does AI Get Lazy?

The next article will discuss a common phenomenon:

Why is it that when two teams use the same AI, one team significantly improves its efficiency, while the other sees almost no improvement in productivity?

Many times, it is not that AI does not understand. Rather, it is...

Stay tuned.

The original article was written in Traditional Chinese, and the Japanese and English versions were translated using ChatGPT.