

Ideas Vibe coding with veracity Developed through the building of drkishanrees.com, July 2026 Read as: HTML Markdown Vibe coding is one of the most democratising developments in software I have seen. It gives people who understand a problem, but have never learnt the syntax of programming, a way to turn an idea into something they can see, test and share. It shortens the distance between imagination and implementation. That is worth celebrating. But access to code generation is not the same as readiness to ship a product. Throwing prompts into a model, accepting code you have not read, and leaving no audit trail is no way to build or scale something other people will depend on. It may produce a convincing prototype. It may even produce something that works today. It does not tell you what changed, why it changed, what assumptions were made, what remains untested, or whether tomorrow’s change will quietly break yesterday’s success. That is the gap I mean by vibe coding with veracity. Veracity is not another prompt technique. It is the discipline around the prompt: the evidence that lets a person understand, verify and remain accountable for what the model has built. Vibe coding with veracity is AI-assisted software creation in which speed and creative flow are preserved, but every material change remains reviewable, testable, attributable and reversible. The model may write the code. The human still owns the decision. In practice, that means being able to answer six questions: What were we trying to change? What was the model allowed to touch? What source, component or rule was it told to follow? What did it actually change? How was the result verified? Who approved it for release, and when? What it looks like in practice This site is the worked example. It was vibe coded, yet by deliberate design it keeps the record that vibe coding usually throws away. The mechanisms are ordinary once you name them, and every one of them is in the repository behind this page. The conversation is the easy part. The paper trail is the craft, which will be explored in detail in an upcoming dispatch. What it does not claim Naming a discipline is not the same as claiming to have invented it, so let me be precise about the edges. It is not an argument against vibe coding. Vibe coding is the thing worth protecting here; veracity is what lets you trust it with something that matters. It does not require a human to type every line. The point is not authorship of the code, it is ownership of the decision and a record good enough to stand behind. It does not replace security review or professional engineering expertise. A paper trail tells you what changed and why; it does not tell you the change is safe. It does not pretend that records alone make unsafe code safe. Evidence supports judgement, it does not stand in for it. Verification has to stay proportional to the risk. A weekend project and a system other people depend on do not warrant the same scrutiny, and pretending otherwise is its own kind of dishonesty. And, since the words are not original to me: I did not coin “vibe coding with veracity”. The pairing was in the air in 2026, and it appears in published work by others (see Related work). What I am naming is the practice I have applied to the development and delivery of this website. Not a phrase I own. It is an approach to web design, no doubt informed by my medical training. A philosophy founded on showing one’s workings, always questioning and keeping records that are auditable. Related work In May 2026, Yongge Wang published “From Vibes to Veracity: An Adversarial AI Agentic Role-Play Framework for Software Engineering and Security”, a framework that uses structured planning, multiple AI agents, formal software inspection and security auditing to bring greater engineering discipline to vibe coding. Vibe coding with veracity, as I describe it here, approaches the same underlying problem through the working practice behind drkishanrees.com. Its emphasis is the accountable record around the code: bounded briefs, durable project memory, version control, preserved provenance, review benches, reproducible checks and explicit human approval. The overlap in language and intent is real. The methods are related, but they are not the same. Reference: Yongge Wang, “From Vibes to Veracity: An Adversarial AI Agentic Role-Play Framework for Software Engineering and Security”, UNC Charlotte, 26 May 2026. Read the paper (PDF) Related links: From Vibe to Veracity, the Amalithlab project site at UNC Charlotte led by Professor Wang, and Professor Wang on LinkedIn. The claims, classed I sort what I publish by how strong the claim is, so here is this page graded by my own rubric. The classes are Observation, Hypothesis, Coined term, Internal result and Externally validated finding; each claim names its evidence and where that evidence comes from. The ledger Vibe coding with veracity, as a named principle. Working principle, not a coined term. I did not invent the phrase and I do not claim it: the pairing of vibes and veracity was in the air in 2026, and Yongge Wang used it in a paper of his own that May. What is mine is the practice set out here, developed by building this site. Evidence: the site’s own build and review record. Source: owner-supplied, primary; not externally validated as a method. The mechanisms described here exist and are used on this site. Observation. Evidence: the repository itself, its governing instruction file and build gates, the review benches, the version history, the preserved session transcripts and the public error ledger. Source: owner-supplied, primary; anyone I show the repository to can check it, but it is my own record, not an independent audit. Vibe coding with veracity is worth adopting as a working discipline. Hypothesis. Evidence: the argument on this page and one worked example, this site, built to it. Source: my own proposed principle, not yet tested anywhere but here; that it holds up on one project is not proof it generalises, and this page will say so until there is more. Yongge Wang published a related framework in May 2026. Externally sourced fact. Evidence: the paper itself, read directly, with its title, author, affiliation and date checked against the source PDF. Source: independent, a third party’s work, cited and kept distinct from mine rather than absorbed into it. This definition, and the longer story This page is the canonical, quotable definition: what vibe coding with veracity means, and where the practice came from. The fuller account, how the discipline was actually built across the making of this site, with the catches and the climbdowns kept in, belongs in a longer field report. That Dispatch is planned. When it exists it will be linked from here; until then, this definition stands on its own. Share: Dr Kishan Rees first published 26 July 2026 Dr Kishan Rees · first published 26 July 2026 Saved from https://drkishanrees.com/ideas/vibe-coding-with-veracity/

Vibe coding with veracity

Developed through the building of drkishanrees.com, July 2026

Read as: HTML Markdown

Vibe coding is one of the most democratising developments in software I have seen. It gives people who understand a problem, but have never learnt the syntax of programming, a way to turn an idea into something they can see, test and share. It shortens the distance between imagination and implementation. That is worth celebrating.

But access to code generation is not the same as readiness to ship a product.

Throwing prompts into a model, accepting code you have not read, and leaving no audit trail is no way to build or scale something other people will depend on. It may produce a convincing prototype. It may even produce something that works today. It does not tell you what changed, why it changed, what assumptions were made, what remains untested, or whether tomorrow’s change will quietly break yesterday’s success.

That is the gap I mean by vibe coding with veracity.

Veracity is not another prompt technique. It is the discipline around the prompt: the evidence that lets a person understand, verify and remain accountable for what the model has built.

Vibe coding with veracity is AI-assisted software creation in which speed and creative flow are preserved, but every material change remains reviewable, testable, attributable and reversible. The model may write the code. The human still owns the decision.

In practice, that means being able to answer six questions:

What were we trying to change?
What was the model allowed to touch?
What source, component or rule was it told to follow?
What did it actually change?
How was the result verified?
Who approved it for release, and when?

What it looks like in practice

This site is the worked example. It was vibe coded, yet by deliberate design it keeps the record that vibe coding usually throws away. The mechanisms are ordinary once you name them, and every one of them is in the repository behind this page.

The conversation is the easy part. The paper trail is the craft, which will be explored in detail in an upcoming dispatch.

What it does not claim

Naming a discipline is not the same as claiming to have invented it, so let me be precise about the edges.

It is not an argument against vibe coding. Vibe coding is the thing worth protecting here; veracity is what lets you trust it with something that matters.
It does not require a human to type every line. The point is not authorship of the code, it is ownership of the decision and a record good enough to stand behind.
It does not replace security review or professional engineering expertise. A paper trail tells you what changed and why; it does not tell you the change is safe.
It does not pretend that records alone make unsafe code safe. Evidence supports judgement, it does not stand in for it.
Verification has to stay proportional to the risk. A weekend project and a system other people depend on do not warrant the same scrutiny, and pretending otherwise is its own kind of dishonesty.

And, since the words are not original to me: I did not coin “vibe coding with veracity”. The pairing was in the air in 2026, and it appears in published work by others (see Related work). What I am naming is the practice I have applied to the development and delivery of this website. Not a phrase I own. It is an approach to web design, no doubt informed by my medical training. A philosophy founded on showing one’s workings, always questioning and keeping records that are auditable.

In May 2026, Yongge Wang published “From Vibes to Veracity: An Adversarial AI Agentic Role-Play Framework for Software Engineering and Security”, a framework that uses structured planning, multiple AI agents, formal software inspection and security auditing to bring greater engineering discipline to vibe coding.

Vibe coding with veracity, as I describe it here, approaches the same underlying problem through the working practice behind drkishanrees.com. Its emphasis is the accountable record around the code: bounded briefs, durable project memory, version control, preserved provenance, review benches, reproducible checks and explicit human approval.

The overlap in language and intent is real. The methods are related, but they are not the same.

Reference: Yongge Wang, “From Vibes to Veracity: An Adversarial AI Agentic Role-Play Framework for Software Engineering and Security”, UNC Charlotte, 26 May 2026. Read the paper (PDF)

Related links: From Vibe to Veracity, the Amalithlab project site at UNC Charlotte led by Professor Wang, and Professor Wang on LinkedIn.

The claims, classed

I sort what I publish by how strong the claim is, so here is this page graded by my own rubric. The classes are Observation, Hypothesis, Coined term, Internal result and Externally validated finding; each claim names its evidence and where that evidence comes from.

The ledger

Vibe coding with veracity, as a named principle. Working principle, not a coined term. I did not invent the phrase and I do not claim it: the pairing of vibes and veracity was in the air in 2026, and Yongge Wang used it in a paper of his own that May. What is mine is the practice set out here, developed by building this site. Evidence: the site’s own build and review record. Source: owner-supplied, primary; not externally validated as a method.

The mechanisms described here exist and are used on this site. Observation. Evidence: the repository itself, its governing instruction file and build gates, the review benches, the version history, the preserved session transcripts and the public error ledger. Source: owner-supplied, primary; anyone I show the repository to can check it, but it is my own record, not an independent audit.

Vibe coding with veracity is worth adopting as a working discipline. Hypothesis. Evidence: the argument on this page and one worked example, this site, built to it. Source: my own proposed principle, not yet tested anywhere but here; that it holds up on one project is not proof it generalises, and this page will say so until there is more.

Yongge Wang published a related framework in May 2026. Externally sourced fact. Evidence: the paper itself, read directly, with its title, author, affiliation and date checked against the source PDF. Source: independent, a third party’s work, cited and kept distinct from mine rather than absorbed into it.

This definition, and the longer story

This page is the canonical, quotable definition: what vibe coding with veracity means, and where the practice came from. The fuller account, how the discipline was actually built across the making of this site, with the catches and the climbdowns kept in, belongs in a longer field report. That Dispatch is planned. When it exists it will be linked from here; until then, this definition stands on its own.

Dr Kishan Rees first published 26 July 2026