DEV Community: Dekita

Your coding agent will call a function that does not exist. Here is the fix.

Dekita — Fri, 02 Oct 2026 01:28:27 +0000

Your coding agent will call a function that does not exist

You ask the agent to add a section to a site. It writes the template on the first try. The template calls a helper function, passes the right arguments, and looks like every other template in the codebase.

The build passes.

Then you run it, and you get a fatal error. Call to undefined function getCollectionBySlug().

Here is the part that wastes your afternoon: the code was plausible. A broken build is easy to catch. Plausible code pointing at an API that is not there gets past a fast read, because every individual token looks reasonable. Nothing about that template looks wrong until you run it.

Why it happens

The agent is not malfunctioning. It is working with what it has:

Training data that is months or years old, so it recalls an API that used to exist.
Documentation on a website that may describe a different version than the one installed.
A file tree where your helper sits next to nine other files, none of which say "this one is the entry point."

Better prompts do not fix this. You can paste the docs into the context window, write a long instructions file, and describe the correct signature. It helps a little. It does not solve it, because the docs you pasted are a copy, and copies drift from what is actually installed.

The real problem is the source of truth. The agent is guessing about a system that knows exactly what it is.

Your installed app already knows its own schemas, its own routes, and which functions this version actually exposes. Nothing was asking it.

The fix: let the install describe itself

Ship a small server inside the app that answers three questions. The protocol does not matter for this post; a plain HTTP endpoint works fine. What matters is that it is served from the running install, so it cannot drift from reality.

1. Schemas. The real collections and fields on this site, not the generic example from the docs.

2. Live content. Real records, so the agent can look at what exists before it changes anything. This one prevents a whole category of mistake: inventing plausible field values for a record that was never queried.

3. Documentation for this version. The docs ship with the install and are served from it, so an agent working on 3.6 reads 3.6's functions and field types. There is no gap between what the docs say and what the site does.

The third one did the most work in my case. Once the agent could look up a real signature instead of recalling one, it stopped guessing. The reason is obvious in hindsight: your installed version is authoritative about your installed version, and a website is not.

There is a second benefit that took me longer to notice. Customers do not always upgrade the moment you release. An agent that reads documentation from a marketing site will confidently use the feature you shipped last week, on the version they are still running. Documentation served from the install describes exactly what that site can do.

Writes should not get a special door

Reading is the easy half. Letting an agent write is where people are right to be nervous.

The rule I settled on: the agent gets no privileged path. Every write goes through the same validation and fires the same events as a save from the admin interface. Permissions come from the same access groups that govern human editors. A token issued to the agent gets exactly the checks a signed-in user gets.

The benefit is that "can the agent do this?" gets answered in one place, and that place already exists. You are not maintaining two authorization systems. You are not maintaining one authorization system and one audit trail that nobody reads.

If your answer to "can the agent touch this?" lives somewhere other than your existing permission code, that is the actual bug. The fabricated function was a symptom.

A worked example

Here is the shape of it, stripped down. The framework does not matter; the three questions do.

Suppose your CMS has a products collection. Each product has a handle, a title, and an optional discount that is either null or a number between 0 and 100. On version 3.6 the accessor is getCollectionBySlug(). On 3.5 it was findCollection(). The rename happened two releases ago.

An agent asked to render a discount banner will pick one. Which one it picks depends on what it has seen most often, and two releases apart is close enough that both appear in its training data. Nothing about the task signals that the version matters, so the agent has no reason to prefer the right one.

Now give it a way to ask, and the version question answers itself:

GET /__self/versions
-> { "app": "acme-cms", "version": "3.6.4" }

GET /__self/schemas/products
-> { "handle": "string", "title": "string", "discount": "number or null, 0 to 100" }

GET /__self/docs/3.6/functions
-> { "getCollectionBySlug": { "params": ["slug"], "returns": "Collection" } }

The agent now has the right name, the right shape, and the constraint it would otherwise have invented. Nobody had to teach it the rename. The install already knew.

The discount line matters more than it looks. An agent that guesses the field will happily render undefined% and hand you a bug report about the template. An agent that reads the nullable type will write the guard clause, because the type told it the guard is required.

Why the read path is the easy half

Reading is safe in a way writing is not, and it is worth being precise about why.

A read cannot change state. The worst outcome of a wrong read is a wrong answer that a human immediately sees and corrects. Writes invert that: the wrong write looks exactly like the right one until the data is already changed, and by then the original value is gone.

That asymmetry is the whole argument for keeping reads and writes on the same door. If the agent reads schemas through the install but writes through some convenience layer you added, the two paths drift. The read path is verified against reality on every call. The write path is verified against your assumptions, once, when you wrote it.

What this does not solve

Worth being clear about, because these posts usually skip it.

Logic bugs still need a human. The agent knows the signature is real now. It does not know your business rule was wrong.
Concurrency and boundary conditions still fail. The same edge cases fail with a perfect API description.
You still owe a review pass. Faster generation means more surface area, not less.
Prompt injection remains open. An agent that can read your content can be told by that content what to do. Self-description limits the blast radius; it does not remove it.

The rule I would start with

If your agent is working from documentation rather than from the running system, it is guessing with good manners. Make it ask the install instead.

That single change removed the fabricated-API class of bug from my work entirely, and it took an afternoon. The part that took longer was accepting that the fix belonged in the app, not in the prompt.

Your prompt won't fix AI-sounding writing. A lint rule will.

Dekita — Thu, 01 Oct 2026 14:54:10 +0000

I generate a fair amount of technical writing with models. For a long time I kept getting the same reaction from readers, and it took me too long to name it properly.

The posts were not wrong. They were tiring.

The failure had a shape. A section would open by announcing why the topic mattered before it said anything about the topic. A list would arrive as a column of bold labels, each followed by a colon and a restatement of the label. A section would end by hedging — "it is worth keeping in mind that..." — and commit to nothing.

None of that is a factual error. All of it is a reason to stop reading at paragraph three.

The prompt approach, and why it kept slipping

My first move was the obvious one. I described the problem to the model and asked it to stop.

So the system prompt grew. Do not open with a definition. Vary sentence length. Skip the three-item lists. Do not end on a vague note.

It held for a few days. Then it drifted back, and I could never tell exactly when.

The reason is structural. A prompt is a request, and requests get weighed against everything else the model is doing, on every token. There is no moment where the instruction passes or fails. Nothing is measured, so nothing stays fixed. I was negotiating with a system that had no memory of the negotiation.

There is a second problem, subtler. Style instructions in a prompt compete with each other. "Be concise" and "be thorough" both get weight. "Avoid lists" fights "be scannable." The model resolves that tension silently, differently on different days. You see the average of the conflict, never the conflict itself.

What a linter does differently

A linter flips the relationship. It does not ask for anything. It reads finished text and returns violations.

The property that matters: a linter can go red. That is a state a prompt cannot reach.

For English prose the tool I would start with is Vale. Single binary, MIT licensed, understands Markdown well enough to skip code blocks, and runs offline with no account.

Install it, then drop a .vale.ini at the repo root:

StylesPath = .vale/styles
MinAlertLevel = warning

[*.md]
BasedOnStyles = Vale, write-good

Run it against a directory of drafts:

vale articles/

If you want patterns aimed specifically at machine-written prose rather than general wordiness, there are community style packages for that. They tend to target the tells rather than any single word: participial padding ("...thereby ensuring that..."), contrastive negation used as a reflex ("not X, but Y"), and lead-ins that forecast a count ("there are three things to consider here") before delivering two.

Which package you pick matters less than the fact that the rule is written down once, runs identically every time, and produces a number you can look at.

Where you put the gate matters more than what is in it

This is the part I got wrong first.

I had a linter. I ran it manually, when I remembered to. Which meant I ran it maybe half the time.

A gate that depends on you remembering to open it is not a gate. It is a suggestion with extra steps.

So it goes on the publish path. For a GitHub-based flow, that is a workflow that runs on every push:

name: prose-gate
on:
  push:
    branches: [main]
  pull_request:
jobs:
  vale:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: errata-ai/vale-action@reviewdog
        with:
          files: all
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Now the text cannot reach a publishable state while it is failing.

One caveat I learned the hard way, and it is worth stating plainly: on some platforms the CI job and the actual deploy are completely separate systems.

I run a similar gate for Japanese articles on Zenn. Zenn deploys by watching pushes to the branch directly. A red CI check does not stop it, does not delay it, and does not warn anyone. It is a separate set of lights on a separate wall.

If your platform deploys outside CI, your CI gate is a notification, not a gate. The thing that actually blocks publication is the run that happens locally, before you commit. Check which one you have before you trust either.

Do not trust the style guide. Measure your corpus.

Here is the finding that changed how I write rules.

I was setting up a Japanese prose gate and hit a rule about spacing between full-width and half-width characters. The official style guide for Japanese technical writing says: do not add the space.

Before writing that into the config, I pulled the ten most-liked Japanese posts on the platform and counted. 78% of them added the space.

The official guide and the most-read actual writing disagreed, and not by a narrow margin.

I turned the rule off and followed the corpus. Not because the guide was wrong in principle, but because a rule that fights the audience's reading habit is a rule that makes your writing feel foreign — which was the exact problem I was trying to solve.

The general version: a style guide is a hypothesis about your readers. Your readers' own most-liked writing is evidence. When the two conflict, look at the evidence, then decide. Do not let a document win an argument against data.

This is also why I keep the rule config in the same repo as the articles. The rules are part of the content, and they should change when the corpus tells you to. A linter config that nobody revisits is a linter config that slowly becomes wrong.

What the linter cannot do

I want to be careful here, because this is easy to oversell.

A prose linter checks the shape of your writing. It does not check whether the writing is true.

Those are separate gates and you need both. The AI-content guidelines on both dev.to and Zenn are explicit that AI-assisted work has to be fact-checked before it goes out. No linter will do that for you. The smell of machine-written prose and the accuracy of a claim are independent axes, and passing one tells you nothing about the other.

It also cannot tell you whether the piece should exist. A clean lint run on an article nobody needed is still an article nobody needed.

The short version

A prompt is a request. It drifts, and you cannot see it drift.
A lint rule is a gate. It is deterministic and it can fail.
Put the gate where publishing actually happens. If your platform deploys outside CI, that is your local pre-commit run.
Write your rules from your own corpus. An official guide can be wrong about your readers.
The gate covers style. Facts are a different gate, and you still need it.

I still use prompts. I just stopped expecting them to be the thing that holds.

This article was written by a human and edited with AI assistance. The lint guidance described here was applied to this draft as well — the irony of shipping a piece about AI-sounding prose without running it through a gate was not lost on me.