Six months of AI assisted study

New, published 19 October 2026. What else is new

This is one of the first pages I am rolling out significantly by hand. Well, at least in time taken. You should be able to readily see what I have written by hand, what i have prompted AI, and the AI output.

The question I have refelcted on recently is "has AI been useful in these studies, and would I encourage others to do use AI in bible studies"?

The one measure I have for myself at the front of my mind, that says resoundingly yes, is; after six months of study I have personally developed far more skill than I would have alone. I have been able to know my postion, and explain it to people far better than i have previously. Part of this is because I am having allot of fun studying Scripture, especially through original languages, that was far out of reach for me.

This includes theology, and languages, and inspiration to go deeper. It has just been so easy to chain one thought or inspiration to another and see that come to a clearly communicated message quickly.

However, for those new to AI - this was and is not something I just tasked up a fresh AI chat window each time to say - "write me a study on the Melchizadek preisthood as presented in scripture"

Can you get the same value. Maybe - this site is not just what you see from prmpting an AI chat. You will notice consistancy, accuracy, extra features like the verse holdovers, references to different source texts.

When you look at the repository - you will see skills, code, tests, data. All of that adds the 90% value and accuracy over just a raw prompt - and constitues what is the six months of rather allot of work.

There was actually quite a journey to go through. And right now I am thinking do I get AI tolook over my git log for a better history than what I recall, or do I just do my best to recall...

Dave's recall

Circa 2025 - I had already set up a repository and was making some notes, publishing as a mkdocs site, and sharing with family.

Aiming to move from handwritten notes i have all over the place, to actually tracking it like I do with code. Aiuming to move from learning one thing, to forgetting it the next moment if I never even wrote it down to review ten years later.

Progress was slow. I (fought) spent as much time with the techncial set up as I did with the content

Then came the first month after I had been using AI to help me with software developemnt and research, I had seen it transform how i code - can I use AI to help me study the bible, when it is such a Holy Spirit led practice. Can any good come out of Nazereth (insert any other verse I may misquote just to make my point).

I was already using AI to assist with software developemnt, so had already realised the benefits of:
Experience many AI failure modes and work arounds (hallicinations, context window limitations, model differnces, provider differnces, harness differences)
Setting up deterministic (code) to improve repeatability of AI and reduce hallucinations
Grounding in truth and particularly enabling code based lookup of data (think like how we look up a Chapter and verse)

So the first step was tidy up my mkdocs build - massive win

Then play around with some side quests - like the timeline - this led to a re-architecture (in the wrong direction) to an astro site - just because the ai model favoured astro at the time.

Then I realised the benefit of original language studies, first just to help me learn Hebrew, but thenn realising the AI was going to be far better at Hebrew and Greek than I will be in 6 months.

So there was a month or three of source data collection and normalisation, and building a query layer and mcp on top of that.

Then there were the skills to make the study generation repeatable, then allot of iteration on that skills development.

One of the biggest struggles was getting rid of AI-isms - so much time was spent countering that. Yes I reviwed it, before I published it originally, but it is so hard fighting all the time with hedging bets langauge. Then the models improved signifincntly - and not I am going over all of the hard to read AI content to review it. And really enjoying much easier to read content

Then I realised the text and progrmming models could be really good at writing code to make SVG files- like diagrams and comics! - That has been so much fun!

This has taken me about 40 minutes to write, after reviews, reordering, fixing my spelling etc. Now. Lets see how Ai summarises that for you...(in about 10 minutes total it took)

You will see my exact prompts below...

AI summary below

"Please develop a summary of the journey this repository and site has taken, include points mentioned in 'Dave's recall', add accurate times and events summarised from git history. Show the ups and downs, and highlights as the work has progressed. Add some innovation and insights to what has supriosed you. Write to docs/content/blog/2026-10-19-ai.md"

Written by Claude (Opus 5.5) from this repository's git history on 19 October 2026: 944 commits, read from the first to the last. Dates are commit dates.

The shape of it in one table

When	Commits	What the history shows
Apr 2024 – Oct 2024	9	The repository starts on 11 April 2024 as `bible_end_times`: "added some structure", "added content on deliverance", then "feat: add mkdocs" on 29 May. Seven months, nine commits.
Apr 2025	40	A refactor and a slide-deck pipeline, most of it in one day: on 25 April the log reads "fixing ci", "fix ci", "fix filepath", "fix run", "simplify", "too many changes". Your "fought the technical set-up" is right there in the commit messages.
May 2025 – Dec 2025	20	A daily-reading run through Proverbs ("ch 15", "add 20") in June, then near silence: one commit in August, one in December, "early drafting".
Jan 2026	15	The Astro rebuild, on 11 January: a full directory restructure, a genealogy Gantt chart and a GitHub Pages workflow for Astro.
Jul 2026	88	The turn. On 9-11 July the site splits into mkdocs for prose and Astro for the tools. On 18 July the first skill appears (the word-study method in develop-bible-study). On 19 July the data arrives in one day: MACULA Hebrew and Greek, the open- and restricted-data submodules, the Septuagint, the cross-reference index. On 23 July the MCP server. On 27 July the style guide and the review skill.
Aug 2026	110	On 8 August, one commit adds automated checks for AI-tell prose, and six more cut hedging from every section of the site. On 23 August the tools are found to be 404ing silently on the live domain; on 24 August Astro is removed and the timeline becomes an ordinary mkdocs page.
Sep 2026	384	The peak: two in five of all the commits ever made. Cloudflare Workers on 5 September, the readability skill on the 19th, the simplify skill and word budgets on the 25th, the readability sweep on the 26th (57 commits, the busiest day in the history), verse and word pop-ups on every page on the 27th.
Oct 2026	277 so far	Comics (12 October), Learn Hebrew (17 October), and today a printable History Chart, Daniel's kingdoms and a study of Nebuchadnezzar's image.

The first two years and three months hold 85 commits. The last four months hold 859.

What your recall gets right, with the dates on it

"The first step was tidy up my mkdocs build: massive win." The 10 July commits rebuilt the mkdocs side ("serve docs/content with auto nav and home page"), and 19 July added generated section landing pages and the light and dark toggle. Publishing followed: commits that publish a page number 2 in January, 20 in July, 32 in August and 61 in September. About 190 hand-written pages are live today.

"A re-architecture in the wrong direction to an Astro site." Astro arrived on 11 January 2026 and left on 24 August 2026, seven and a half months later. The cost showed up as a bug class: two build systems disagreed about where the site root was, and every tool asset 404'd on the live domain without an error (fixed 23 August). The lesson is written into the repo's own instructions: "a second build system is how that class of bug comes back." Today's change, folding the History Chart into the timeline page, applies the same lesson one level up: one page, one data path.

"A month or three of source data collection." It started as one very dense day, 19 July, and kept growing: 16 open-licence sources and 3 restricted ones, a 737 MB bible-text.db, and a study-notes.db of commercial study Bibles kept outside the repo because the repo is public. The MCP server (23 July) put all of it behind tool calls, so that "what does the ESV say at John 6:34" became a lookup in place of a recollection. The repo records why that mattered: a study drafted from memory had "Lord, give us this bread" where the ESV reads "Sir".

"Getting rid of AI-isms." This is the longest-running thread in the history. It starts with the style guide on 27 July and the hedging purge on 8 August. It returns as the "virtue contrast" and "reader-reassurance" checks in the validator, then the readability skill, then the simplify skill. One line in the repo's notes says it all: prayer-as-communion.md carried 38 "not X but Y" constructions after two adversarial reviews, and the count went up between revisions. The rule that finally held was a prohibition applied before writing. Detecting and deleting the tics never kept them out.

"Then the models improved significantly." The commit trailers date it. Sonnet 5 co-authors from 18 July, Opus 5 from 25 July, and Opus 5.5 from 24 September. The readability sweep, the busiest day in the history, came two days later.

"SVG diagrams and comics: so much fun." The first architecture diagram is from 19 July, the Larkin-style prophecy charts from August, and the one-minute comic system from 12 October. There are 21 comics now, and a script checks every bubble quoted from the ESV against the ESV's own text before it is drawn.

The downs, honestly

The Astro detour, above: seven months, and the silent 404s at the end of it.
Drafts that were live. For a long time draft: true hid a page from the site's own lists while mkdocs went on publishing it. Three drafts were reachable on the live site when it was found on 1 September; a hook now drops them from the build.
Studies that only grew. Every pass added words: the Bride of Christ study went from 4,362 to 14,393 words in three weeks. The answer was a skill whose single rule is "add nothing", and a word budget the validator enforces.
Errors the checks did not catch. Even this week: a page said Shem outlived Abraham's birth "by centuries" (it is 150 years), and a draft said Daniel's image had "ten toes" (Daniel 2 never numbers them). The first was caught by re-querying the dates and the second by a review pass that re-derived every claim. Neither was caught by the agent that wrote it.

The highlights

Pop-ups on every page (27 September): every Bible reference and Strong's number on the site opens the verse, its context, its cross-references and the studies that treat it. It changed how studies are written. References are now plain text, and a study quotes only what its argument stands on.
Exegesis before hermeneutics as a workflow. The develop skill keeps a state file per study, so a study can be resumed, and a review can check the reasoning, months later.
Four skills that answer four questions: build it, is it true, can it be read, is it the right size. Each exists because one of the others could not do its job.
One set of chronology facts: every dated event is stored once, so the timeline, the genealogy, the printable chart and Daniel's kingdoms all agree. The creation epoch moved on 1 October in a 374-number rewrite, which is what led to storing each date once; the next move is one edit.

What surprised me

The scaffolding outweighs the writing, and that is why the writing can be trusted. Since July, 142 of the 859 commits are fixes or refactors, and most of the "feat" commits build checks, data or tools. Each check in the validator carries the story of the mistake that made it necessary. A reader sees about 190 pages; behind them is a record of every way those pages once went wrong.

The model's weaknesses shaped the design more than its strengths. Recall is unreliable at the level a Bible quotation needs, so quotations come from a database. A model that wrote a sentence cannot see its own composition order as a reader would, so the readability pass runs in a separate session. A model's state notes repeat its own errors in its own handwriting, so load-bearing claims are re-queried from source. Each of those is a tool or a rule in this repo, with a date on it.

Your own measure is the one that matters, and the history agrees with it. You wrote that after six months you have more skill than you would have had alone. The log shows a reader who sent the agent back: to the Hebrew, to the textual footnotes, to "what does this show about God?" The tools did the lookups. The questions in the history are yours.

"Please give your reasoning, and approach to answering the above questions, to a non-technical audience. Include why their answer to the question will be differnt to the answer on this computer. Please add that after you see this same priompt in the document we are editing at docs/content/blog/2026-10-19-ai.md. Keep the response brief but informative."

How I answered, in plain terms

I read the diary first. Every change to this site is saved with a date, a short note and the name of whoever helped: 944 of those entries since April 2024. I read through them in order and counted them month by month, then grouped them into chapters: the slow start, the move to a new website builder and back again, the July turn when the study tools arrived, and the busy weeks since.

I set Dave's memories beside the record. For each thing he recalled, I looked for the entry that dated it. Most matched. Where his memory and the record differed, I went with the record and said so.

I checked every number twice. A first count is the easiest place for an AI to be confidently wrong. Rechecking found four mistakes, and I corrected them before handing the page back.

I kept his words and mine apart. His introduction and recall stay as he wrote them, typos included. My summary sits in its own section, so a reader can tell who said what.

Why your answer would be different

If you asked an AI the same question on your own computer, you would get a different answer, for four reasons:

It would not have the diary. My answer comes from this site's full change history, and a fresh chat window has none of it. Without the record, an AI can only guess, and a guess written fluently looks just like a fact.
It would not have the tools. On this computer I can look up Bible text, original-language dictionaries and study notes in databases Dave has built, along with the written rules for how studies here are made. Those rules hold the lessons of earlier mistakes. A general chat starts with none of that.
It would not have the conversation. I had been working with Dave all day on this site, so I knew what had just been built and what had gone wrong this week. That context shaped what surprised me.
The same question never gets exactly the same words twice. An AI writes each answer fresh, and different versions of the model write differently. The facts should agree when they come from the same record. The wording and the emphasis will not.

The answer is only as good as what the AI can look at. Give it the record and it can check itself against the record. Without one, all it has is its own guesses.

"Please move your answers into expanding text boxes on the page docs/content/blog/2026-10-19-ai.md, as per the same sort of expanding text on docs/content/index.md"

"Please add an svg diagram showing git commits velocity and volume (select an approprate measure to indicate the amount of work over time) since this repository was created, to today. Feel free to innovate the display. Add it below where you see this prompt in docs/content/blog/2026-10-19-ai.md"

How to read the chart

Two measures. Velocity is commits: how often a piece of work was finished and saved. Volume is lines changed, added plus removed, which says how big each piece was. A commit can be a typo or a new tool, so neither measure tells the story alone.

Only hand-made files are counted. The 789 generated commentary pages, lockfiles, data exports and drawings are left out, and a moved file counts once. Without that, one script run or one reorganisation would tower over a month of real writing.

The top strip is the whole history at true scale. It shows the shape plainly: 85 commits in the 27 months to June 2026, then 859 in four. The lens opens those four months out, week by week.

What it shows. Before July the site changed 28,000 lines and kept no research records at all. Since July it has changed 249,000: 55% studies and pages, 32% tools and checks, 13% research records, the state files that say what was checked and against which source. The week of 20 July, when the MCP server arrived, was mostly tools; the next big week, 3 August, was mostly writing. The busiest week for commits was 21 September (134), the week Opus 5.5 arrived; the biggest for volume was the week after.

The chart is drawn from git by utils/build_commit_chart.py, so it can be redrawn at any time.