You don't get stuck because the model won't give you more code. You get stuck when nothing says how far to change, what to leave untouched, and what counts as done. Those four boxes are the map.
1. The sticking point is the map, not the code
The session runs and patches come out. But what should go into the transport and what must not are mixed into one bundle, and whether you touched the standard or kept it in an extension exists only in the commit message. The sticking point is not how much gets generated. It is the lack of coordinates to judge against.
The way Andrej Karpathy described vibe coding does not assume those coordinates. He said you can forget the code (forget that the code even exists), and he placed it in the context of a throwaway weekend project. (Andrej Karpathy, X, 2025-02-02)
Apply that sentence as-is to a production repository and the model is not wrong; you are recreating a weekend without a map.
2. What vibe coding originally meant
The definition is short. On February 2, 2025, Karpathy framed vibe coding as pushing forward on feel without touching the code, and placed it in a throwaway weekend project. Production migration, authorizations and backward compatibility are not part of that definition. (Andrej Karpathy, X, 2025-02-02)
GitHub later splits the term in two: full vibe, where you barely look at the code and leave it to the model, and human-led, where a person holds the direction and uses the model. (GitHub, What Is Vibe Coding?)
Production code needs the latter. Bring the former into production and it easily reads as failure. The cause is not model performance; it is swapping a throwaway premise for a production premise.
This is where the idea of the spec as the source of truth comes from. Microsoft's Spec-Driven Development ties output quality to spec quality. You write down intent, constraints and acceptance criteria and run from Constitution to Validate. A blurry spec produces blurry output. (Apoorv Gupta, Microsoft, Spec-Driven Development: A Spec-First Approach to AI-Native Engineering, 2026-06-10)
3. Why even experienced developers get lost
Even for experienced developers working in large, familiar repositories, how AI feels and what is measured can diverge. In a study METR published on July 10, 2025, 16 developers worked on 246 issues using Cursor and Claude 3.5/3.7. Measured task time increased by about 19%. Beforehand, participants expected to be about 24% faster, and afterward they still believed they had been about 20% faster. (METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025-07-10)
This post takes only one claim from it: self-reports and measurements can diverge. It does not use "AI slows even experts down" as a general law.
For the same reason, it does not treat the 19% as a general fact for 2026. On February 24, 2026, METR stated that the figure reflects early-2025 tools and data, and that later experiments could not establish the current effect because of selection bias. It noted that, based on conversations with participants, developers may be faster now. (METR, We are Changing our Developer Productivity Experiment Design, 2026-02-24)
Feel cannot replace the map. Even if it looks faster, whether something outside the scope was deleted, whether a forbidden interface changed, and whether the acceptance criteria passed are separate judgments.
4. The four boxes of the map
The map is not a prompt sentence. It is the spec (intent), scope, prohibitions and verdict.
What Microsoft's SDD asks you to write down is intent, constraints and acceptance criteria. You set a Constitution and confirm with Validate. (Apoorv Gupta, Microsoft, Spec-Driven Development: A Spec-First Approach to AI-Native Engineering, 2026-06-10)
Chat history cannot take that place. Writing in Datanet, AWS solutions architects Jaeyoung Ha and Yejin Kim note that history evaporates, and that is why they argue for SDD. (Jaeyoung Ha and Yejin Kim, Datanet, "The Trap of Vibe Coding, Solved with Spec-Driven Development" (in Korean))
An August 12, 2026 opinion column in the Electronic Times points to instructions without scope, prohibitions or verification as the problem. Adding "do it well" to a request is a different task from writing down what not to touch and what the finished state looks like. (Electronic Times, "In the Age of Vibe Coding, Is Prompt Design Really Over?" (in Korean), 2026-08-12)
A long context does not create coordinates. Kurly's tech blog cites Lost in the Middle to argue for breaking work down. Put a whole system into one session and the middle drops out. Only after you split the four boxes finely does the model fill them in. (Kurly Tech Blog, "A Predictable Vibe Coding Strategy with Claude Code" (in Korean))
The bottleneck is not typing speed or model choice. Gyuha Shin sees the real bottleneck as the verdict criteria, not feature implementation. (Gyuha Shin, "The Real Bottleneck in Vibe Coding Is Verdict Criteria, Not Building Features" (in Korean), 2026-05-04)
Written one line each, the four boxes look like this.
- Spec: What are you trying to change? Does the intent survive as one sentence?
- Scope: Which objects, which modules, which interfaces are included?
- Prohibitions: What must not be created, modified or deleted?
- Verdict: Which output for which input counts as a pass? Who checks it, and in which environment?
If these boxes are empty, experienced developers, good models and long prompts all stop in the same place.
5. An SAP developer's map
This post has no statistics saying SAP is harder than other stacks. What is needed is to move items you already know from operations into the boxes of the map.
Transports. Which request this change goes into and which requests it must stay out of. The sequence and target systems. If you don't write these under scope and prohibitions, the model puts "everything related" into one transport.
Authorizations. Who must be able to run this function, and which authorization objects are off limits? Hide authorizations behind the code and the verdict gets pushed back to role testing.
Standard vs. extension. Do you allow modifying the standard, or only extensions, BAdIs and enhancement points? Without this one line, generated code takes the shortest path, and that path is usually the standard.
Interface contracts. BAPI and RFC signatures, commit control, error returns. State fields outside the contract and workaround calls explicitly in the prohibitions box. Module boundaries are the same. If you don't write the call direction and owning module into the scope, the model reads the boundary as something to refactor.
Joule for Developers and ABAP MCP exist. (SAP Community, Our 2026 Roadmap for Joule for Developers ABAP AI capabilities) Tools do not fill in the four boxes for you. The developer fills in the input.
6. One map to paste
Fill in the following and paste it at the top of the session.
Goal:
- One sentence. What changes for the user/process?
Scope:
- Objects included:
- Modules included:
- Interfaces included (BAPI/RFC/events):
- Target transport:
Prohibitions:
- Standard modification allowed?:
- Authorization objects not to touch:
- Interfaces/fields that must not change:
- Module boundaries not to cross:
- What stays out of this transport:
Verdict (sample input/output):
- Input A → output A':
- Input B (exception) → output B':
- Authorization: allowed role / denied role:
- System to check in:
Done when:
- Is it finished once the samples above pass?:
- Remaining manual checks:
- What to hand to the next transport/migration:Before adding "please do it well" for the model, fill in the empty boxes. Any box left empty is one the model guesses, and guesses come back as bugs in production.
Have you filled in the map? The next piece of work starts after you paste that one page.