There was a time when updating 2,000 records in NetSuite began with a CSV file, a browser window, and a small prayer.
You opened the Import Assistant. You selected a record type. You chose Add, Update, or the excitingly ambiguous Add or Update. Then you dragged fields from one side of the screen to the other, checked the mappings, reconsidered the mappings, checked them again—and eventually pressed the button that could alter half the company’s item master.
It worked. Usually.
But it was slow, clumsy, and dangerous in a peculiarly human way. The danger was rarely dramatic code failure. It was a fleeting choice made in a temporary browser screen: the wrong field, the wrong reference type, the wrong overwrite option, or the right file mapped to the wrong place.
There was very little durable evidence of the thinking behind the change. The CSV survived. The resulting records survived. The exact sequence of decisions in between mostly evaporated.
Then the NetSuite developer began to evolve.
Stage One: CSV Import
The early NetSuite operator can be identified by several distinctive traits: a curved spine, a furrowed brow, and an unusual ability to stare at two columns for fifteen minutes without blinking.
CSV Import was—and still is—a legitimate, useful NetSuite tool. For a straightforward, well-understood update, it may be exactly the right tool. But a browser-guided import asks a human to translate business intent into a series of one-time interface choices.
The instruction might begin simply:
Change these 2,000 records from notImported to the correct status.
But the operator still has to select the correct record type, identify each record properly, map the field, decide how blank values should behave, choose the update mode, and verify the results.
The computer performs the repetitive work, but the human still assembles the machine by hand every time.
Stage Two: SuiteScript
The next evolutionary leap was SuiteScript.
Instead of telling NetSuite what to do through a temporary arrangement of browser fields, we could describe the rules permanently in code:
Read this file. Find this record. Confirm that its current value is what we expect. Change only this field. Skip anything suspicious. Log every result.
For large jobs, Map/Reduce was particularly well suited. NetSuite describes it as a script type for large volumes of data that can be divided into small, independent pieces. The platform can create the necessary jobs, run them in parallel, and automatically yield and reschedule work as resource limits are approached.
That was a substantial improvement. The update became repeatable. Validation could be explicit. One bad row did not necessarily destroy the entire job. Successes, skips, and errors could be counted and explained.
There was, however, a catch.
The actual business instruction might be one sentence, but a responsible Map/Reduce script could easily consume 100 to 200 lines:
load the CSV;
parse quoted commas correctly;
validate the headers;
identify each record;
check the existing value;
perform the update;
catch errors;
respect NetSuite governance;
log the outcome; and
summarize the execution.
The line that changes the field may be tiny. The other 199 lines are the guardrails.
Stage Three: Juicy Code Bytes
Once we had written a useful updater, naturally we saved it.
Somewhere in the NetSuite File Cabinet—or on somebody’s laptop—there appeared a file with a name like:
my_personal_little_item_updater.js
It was precious. Those were juicy code bytes: a concentrated chunk of hard-won knowledge about NetSuite records, internal IDs, governance, mandatory fields, and all the small ways an apparently simple update could go sideways.
So we copied it. We modified it. We saved another version:
This was progress, but it created a new species of problem. The code was reusable, yet personal. Its history was uncertain. Its deployment record might live somewhere else. Nobody was completely sure whether the version in NetSuite matched the version on the laptop—or whether the script built for customers in 2022 was now quietly updating inventory items in 2026.
We had graduated from temporary clicks to permanent code, but not necessarily to an organized development process.
Stage Four: AI Writes the Script
Artificial intelligence changed the economics of small, purpose-built software.
A 150-line script no longer had to justify several hours of typing. I could describe the outcome in ordinary language:
Here is a CSV containing 2,000 record IDs. Change the stale notImported value, but only if the record still contains the expected old value. Do not touch anything else. Log every success, skip, and error, and give me a final reconciliation.
AI could generate the Map/Reduce structure, CSV parsing, validation, update logic, error handling, and summary code in minutes.
That does not mean the thinking disappeared. It means the typing stopped being the expensive part.
The important work moved upward:
What exactly is the intended business result?
Which records are authorized to change?
What must remain untouched?
What conditions should cause a record to be skipped?
How will we prove that the result matches the request?
What is the recovery plan if our premise was wrong?
AI made code cheap enough that even a one-time repair could afford real validation, logging, and reconciliation. We did not eliminate the 200 lines of guardrails. We taught something else to write them.
Stage Five: AI Meets the CLI and SDF
Then AI got access to a proper workshop.
With the SuiteCloud CLI and SuiteCloud Development Framework, the work no longer begins and ends with a loose JavaScript file. It can live in a complete, file-based SuiteCloud project containing:
the SuiteScript source;
XML definitions for script and deployment records;
project dependencies;
deployment instructions;
configuration and preference files; and
other supported NetSuite custom objects.
Oracle’s own documentation describes SDF as a way to build, validate, and deploy SuiteCloud projects from a local computer. NetSuite objects can be represented in XML, and the CLI can validate a project before it is deployed. Deployment and validation logs provide another layer of evidence when something succeeds—or fails.
Put that project under version control and the change becomes inspectable:
What files changed?
What object or deployment was added?
What did the previous version contain?
Did validation pass?
Which account received the deployment?
What did NetSuite execute?
Which records succeeded, skipped, or failed?
This is the crucial distinction: the CLI does not magically make a change safe, and AI does not magically make it correct.
The CLI and SDF provide structure. Version control provides history. NetSuite permissions provide boundaries. Validation catches certain errors. Logs provide evidence. Backups and recovery plans provide recourse. A knowledgeable human still defines the intent and decides whether the evidence is convincing.
Safety is not one feature. It is the accumulation of constraints.
The Real Evolution: From Procedure to Intent
At first glance, the progression appears to be about speed:
Browser import → handwritten script → saved script → AI-written script → AI with CLI and SDF
But the more profound change is the gradual separation of intent from procedure.
In the browser-import era, the human personally executed much of the procedure.
In the SuiteScript era, the human encoded the procedure.
In the juicy-code-bytes era, the human reused the procedure.
In the AI era, the human described the procedure and AI wrote it.
In the AI-plus-CLI era, the human can increasingly state the intended outcome and the constraints, while AI constructs the procedure inside a controlled, inspectable delivery system.
That does not make the human less important. It makes human judgment more visible.
“Update these 2,000 records” is not enough.
“Update exactly these 2,000 records, only when the existing value is stale, change only this field, produce a before-and-after reconciliation, validate the project, retain the source and deployment definitions, and report every exception” is a specification.
And a specification is something both humans and machines can examine.
Darwin’s Missing Final Figure
The traditional evolution illustration ends with a human standing proudly upright, as though evolution has completed its work.
Our NetSuite version ends with a developer at a clean workstation, surrounded by CLI output, SDF XML, validation checks, Git history, and execution logs. On the desk is a coffee mug that reads:
SHIP IT WITH CONFIDENCE
But confidence is not certainty. The fully evolved operator is not the person who believes nothing can go wrong. It is the person who can explain:
what is about to happen;
why it should happen;
what is prevented from happening;
how we will know what actually happened; and
what we will do if reality disagrees.
That is a surprisingly large philosophical journey from dragging CSV columns across a browser window.
Darwin raises his pointer toward the final figure and observes:
The opposable thumb has been replaced by a deploy command.
Excerpt: NetSuite bulk updates evolved from nervous browser imports to scripted automation, reusable code, AI-generated SuiteScript, and finally AI working through the SuiteCloud CLI and SDF. The real evolution was not merely speed. It was the journey from performing procedures to describing intent.
SEO title: The Evolution of NetSuite Development: From CSV Imports to AI and SDF
Meta description: A humorous history of NetSuite development—from browser CSV imports and 200-line Map/Reduce scripts to AI, SuiteCloud CLI, SDF validation, XML deployments, version control, and logs.
Hero-image alt text: Victorian Darwin points to five stages in the evolution of NetSuite development: CSV Import, SuiteScript, saved “juicy code bytes,” AI-written scripts, and a modern CLI-and-SDF workflow.
Image caption: The evolution of the NetSuite developer—from dragging CSV columns to describing intent. Illustration created with AI from an idea developed by Jim Vanpetten.
30¢ a month. The Thermodynamics of Mom’s Favorite Warning:
The argument every child has lost
Mom: “Close the refrigerator door! You’re letting all the cold air out.”
Jim: “In science class we learned about thermal capacitance. I learned that air has very little mass and its corresponding thermal capacitance is negligible. If I’m applying that correctly, we can lose nearly all the cold air without losing much of the cold.” That’s the sort of thing that’s gotten me in the dog house many times, back then and now.
Mom was right about the direction of the heat flow. Warm room air does enter, the refrigerator must remove that heat, and electricity costs money. But young Jim was asking the more interesting question: How much money?
First: cold is not a substance
A refrigerator does not manufacture “cold.” It removes thermal energy from its interior and releases that energy into the kitchen. Cold air behaves almost like invisible water inside the refrigerator. Because it is denser than the warmer air surrounding it, opening the door is like opening the side of a water-filled tank: the cold air spills over the bottom edge, pours across the kitchen floor, and is replaced by warmer air flowing in from above. Nearly all that cold air can escape within seconds—but nearly all the refrigerator’s stored “cold” remains behind in the milk, food, shelves, and walls.
The temperature of that incoming air changes quickly. The temperature of the milk, food, shelves and refrigerator walls changes much more slowly. That difference is thermal capacitance.
Thermal capacitance: mass matters
The basic relationship is:
Thermal capacitance = mass × specific heat capacity
Or, in symbols:
C = m × c
Mass matters, but so does the material. Water can absorb about four times as much heat per pound per degree as air. Milk is mostly water, and a gallon weighs about 8.6 pounds. Refrigerator air weighs surprisingly little—perhaps about one pound in the entire empty cabinet and less when food occupies much of the space.
That gives us the useful mental picture: the air carries temperature, but the food and liquids carry most of the refrigerator’s thermal memory.
What happens when all the air escapes?
Consider an illustrative 18-cubic-foot refrigerator with about 0.35 cubic meter of free air after accounting for shelves and food. That air weighs roughly 0.4 kilogram. Replacing 38°F air with 72°F room air—a change of about 19°C—adds roughly:
Q = m × c × ΔT
Q ≈ 0.4 kg × 1.0 kJ/(kg·°C) × 19°C ≈ 8 kJ
That is only about 0.002 kilowatt-hour of thermal energy before allowing for compressor efficiency and humidity.
Now let a gallon of milk warm through that same temperature range:
Q ≈ 3.9 kg × 3.9 kJ/(kg·°C) × 19°C ≈ 289 kJ
The milk holds more than thirty times the sensible thermal energy represented by one cabinetful of air. Depending on refrigerator volume, free space and product assumptions, the practical comparison might be closer to twenty-five or thirty-five air changes. The point survives either way:
You can lose nearly all the cold air without losing nearly all the cold.
The part young Jim overlooked
Air is not the whole bill. Warm room air also carries water vapor. Inside the refrigerator, some of that moisture cools and condenses; in the freezer, it may freeze. Removing sensible heat from the air is cheap. Cooling and changing the phase of water requires additional energy.
A longer opening also allows warm air to circulate over exposed food, shelves, liners and evaporator surfaces. The refrigerator may run longer, cycle differently and incur normal system losses. That is why twenty seconds is worse than five seconds even though much of the original cold air may escape early.
Research supports the direction without providing one universal price tag. A Purdue refrigeration study reported that increasing door-opening duration while holding the number of openings constant increased energy use by roughly 7–8 percent under its test conditions. Other experiments produce different results because refrigerator design, room temperature, humidity, loading and opening frequency all matter.
Mom versus the indecisive kid
Let us build an intentionally transparent household model:
Adults make 20 refrigerator visits per day and keep the door open about 5 seconds.
One hungry child adds 5 visits per day and studies the inventory for 20 seconds.
The refrigerator has roughly 0.35 cubic meter of free air.
Electricity costs about 18.4 cents per kilowatt-hour, close to the recent U.S. residential average reported by the Energy Information Administration.
A single complete exchange of cabinet air costs only a small fraction of a cent to undo. A five-second opening may cause something on the order of one effective air exchange; a twenty-second opening may cause several, plus extra moisture and surface warming. Because real air exchange is turbulent and refrigerator-specific, pretending that every second has an exact universal price would be false precision.
A reasonable order-of-magnitude result is this:
Household without the indecisive child: roughly 10–20 cents per month attributable to ordinary door openings.
Five additional 20-second child visits per day: perhaps another 10–30 cents per month.
The portion caused specifically by lingering instead of completing those same visits in five seconds: probably measured in mere cents per month.
Not zero. Not imaginary. But not the household financial emergency implied by Mom’s tone.
The milk is the cold
Now return to the gallon of milk. Leaving it on the dinner table until it approaches room temperature and then asking the refrigerator to cool it again can impose a thermal load comparable to replacing the cabinet air dozens of times.
Mom: “Close the refrigerator door. You’re letting all the cold air out!”
Jim: “Mom, the air weighs almost nothing. The cold milk is still in there.”
Or the sharper version:
“Mom, leaving the gallon of milk out through dinner costs more than losing the refrigerator’s cold air over and over again.”
The verdict
Mom was thermodynamically correct and economically dramatic.
Closing the door promptly is still good practice. It limits warm, humid air infiltration, reduces frosting and protects food temperature. But the refrigerator does not lose its accumulated cold merely because its air is replaced. Most of its thermal capacitance resides in the massive contents and structure, especially water-rich food and drinks.
The profound version is simple:
The air tells you the refrigerator’s temperature. The milk remembers it.
And if young Jim had closed the door immediately, the family might have preserved several cents that month—although it would have lost an excellent argument.
Sources and calculation notes
This article uses an illustrative calculation rather than claiming a universal per-opening cost. Refrigerator geometry, product loading, room humidity, compressor performance and door behavior materially affect the result.
U.S. Department of Energy: energy-efficient residential refrigerator guidance and representative annual consumption.
Wilson Terrell, “Energy Requirements of Refrigerators Due to Door Opening Conditions,” Purdue University International Refrigeration and Air Conditioning Conference.
And then there are projects your wife starts digging while you’re still explaining why the project is a bad idea.
This was the second kind.
It began with a deck.
Not an unusual deck. A nice deck, actually. Composite decking, black railing, landscaping around it. The sort of project where you finally stand back, admire several weekends’ worth of labor, and begin mentally returning your tools to their rightful places.
My wife, Karen, looked at it differently.
She looked underneath it.
“I don’t want critters living under there.”
I knew immediately where this conversation was headed, and being a man with decades of experience in several trades, I was prepared to provide the necessary technical expertise.
“You can’t really keep critters out from under a deck.”
There.
Problem solved.
Except Karen had not asked whether critters could be kept out. She had announced that she did not want them there.
This distinction would become important.
I explained the obvious engineering problem. You couldn’t easily put lattice around it. You couldn’t put boards around it. You couldn’t put siding around it (her idea). It wouldn’t matter. A raccoon, rabbit, squirrel, chipmunk, groundhog, or whatever other furry excavation contractor happened along could simply dig underneath.
Karen considered this.
Then she said something along the lines of:
“Why don’t we dig a trench around it and pour concrete in the trench?”
This was clearly getting worse.
The Squirrel Foundation
Her proposal was wonderfully excessive.
We would dig an 8″ deep trench around the perimeter of the deck.
We would stand wood–cedar siding down into the trench.
We would pour approximately a dozen bags of concrete around the bottom of the cedar.
The cedar would continue upward behind the composite skirt board around the deck.
Thus, an animal attempting to get underneath the deck would encounter cedar.
If it attempted to dig underneath the cedar, it would encounter concrete.
Karen had, essentially, proposed building a foundation for squirrels.
I hated it.
I explained that this was ridiculous.
I explained that animals dig.
I explained that cedar was water resistant but that burying wood in concrete and dirt was not exactly the detail you’d expect to find highlighted in an architectural textbook.
Karen listened carefully to my professional assessment.
Then she got a shovel.
This is where an important biographical detail belongs.
Karen’s father was the man who taught me practically everything I know about the trades.
Carpentry, electrical, plumbing, construction, repair, fabrication. He was the kind of guy whose lessons stick with you because they weren’t really lessons about how to use a particular tool. They were lessons about how to think about a physical problem.
And apparently, while I was receiving the formal education, Karen had been taking the same class from the other side of the dinner table.
This became particularly evident whenever I attempted to declare some nearly completed detail “good enough.”
Karen possessed a devastating five-word building code:
“Dad wouldn’t leave it like that.”
There is no effective response to this when Dad is the guy who taught you how to do it.
And apparently Dad wouldn’t leave an opening beneath a deck for squirrels, either.
I Went on Strike
I seem to remember refusing to help dig the first ten or fifteen feet of trench.
This was my principled stand.
I had evaluated the design.
I had rendered my professional opinion.
I was not participating in the construction of the Great Wall of Chipmunk.
Unfortunately, Karen possesses a personality characteristic that seriously diminishes the effectiveness of this negotiating strategy.
If I refuse to take the shovel, she takes the shovel.
So there she was, digging.
And the problem with watching somebody stubbornly dig a trench for an idea you have already declared stupid is that every additional foot raises the stakes.
At five feet, you can still win.
At ten feet, you become concerned.
At fifteen feet, you begin realizing that this woman may actually dig the entire damn thing without you.
Eventually, I joined the winning contractor.
And somewhere during construction, something unexpected happened.
The stupid idea became clever.
The Cedar Was the Trick
We had leftover cedar siding.
Real cedar bevel siding, the same basic stuff used on the house.
A cedar bevel board is thick along one edge and tapers down toward the other. Normally you install these boards horizontally with one overlapping the next.
For our decidedly nonstandard application, we put the fat edge down.
And suddenly the material made enormous sense.
The bottom didn’t have to be cut perfectly because it disappeared into a trench that was about to be filled with concrete and covered with dirt and mulch.
The top didn’t have to be cut perfectly because it disappeared behind the composite skirt board.
Think about what that eliminates.
Normally, finishing the bottom of a deck against uneven ground is an exercise in measuring, cutting, fitting, trimming, checking, swearing, removing, cutting another eighth of an inch, reinstalling, and discovering that the ground three feet away is two inches higher.
We didn’t have to do any of that.
We put the cedar into the trench.
Wherever the bottom landed, it landed.
Wherever the top landed behind the skirt board, it landed.
Then I screwed through the composite skirt board into the cedar.
Done.
No precision cut at the top because nobody would ever see it.
No precision cut at the bottom because nobody would ever see that either.
The visible composite skirt board established the one line that mattered.
Straight.
Clean.
Finished.
Everything behind it could be gloriously indifferent to aesthetics.
This is one of my favorite kinds of construction trick: don’t become more precise than the project requires. Design the detail so precision isn’t required in the first place.
Need More Height? Add Another Board.
Some parts of the deck sat farther above grade than others.
That sounds like another problem.
It wasn’t.
Where one cedar board wasn’t tall enough, I used two.
They were siding boards, after all. Overlapping is literally what they were born to do.
Put one above the other with an overlap, fasten them together, and suddenly you’ve got whatever height you need.
No custom panel.
No sheet goods.
No elaborate framing.
No special-order product with seventeen proprietary clips and a 46-page installation manual.
Just another piece of cedar.
That was particularly satisfying because the entire assembly tolerated variation.
The ground could rise and fall.
The trench could vary slightly.
One section could require one cedar course.
Another could require two.
None of it mattered because the composite skirt board established a continuous visual line around the deck.
From ten feet away, you don’t see any of the engineering.
You see a deck that looks finished all the way to the landscaping.
Then Came the Concrete
Once the cedar was positioned, the trench was filled with concrete.
And this was the part of Karen’s idea I had originally dismissed.
I’d said animals could dig underneath whatever we installed.
Karen hadn’t disputed that.
She had simply removed “underneath” from the available options.
That’s actually very good problem solving.
Instead of asking:
“What kind of deck skirting keeps animals out?”
she had effectively asked:
“How would an animal defeat deck skirting?”
Answer: dig beneath it.
Okay.
Then make beneath it undiggable.
That’s a completely different way of approaching the problem.
The cedar closed the vertical opening.
The concrete closed the subterranean opening.
The composite board concealed the top of the entire contraption.
And the landscaping concealed the bottom.
The result was something that looked considerably more sophisticated than the construction method had any right to look.
But You Buried Cedar in Concrete
Yes.
I know.
There is undoubtedly someone reading this who has been waiting several paragraphs to say it.
You shouldn’t bury wood in concrete.
And as a general construction detail, I agree.
Wood plus persistent moisture is a longevity problem. Even naturally decay-resistant cedar is still wood. The transition around grade, where materials repeatedly get wet and dry, is particularly unfriendly territory.
If I were designing the same system today from scratch, knowing what I know now, I might substitute a modern rot-proof material for the buried vertical component.
PVC or an appropriate composite product immediately comes to mind.
But there are a few things working in favor of our original contraption.
First, it is cedar.
Second, the thick edge is down.
Third, we coated the hell out of it with a very durable black exterior stain/coating.
Fourth, this isn’t structural. The cedar isn’t holding up the deck. If it eventually deteriorates, my deck isn’t coming down.
And fifth, the thing has already spent years outside getting rained on, snowed on, frozen, thawed, splashed with mud, surrounded by mulch, assaulted by Illinois humidity, and generally subjected to everything nature could think of.
I recently crawled down and looked at it.
It’s still there.
Pretty damn solid, too.
Apparently nobody informed the cedar that it was installed incorrectly.
The Funny Part Is What It Looks Like
This whole story came back to me because I recently showed photographs of the deck to someone without explaining any of this.
They looked at the horizontal composite board around the bottom and essentially said:
“That’s a nice deck skirt detail.”
Exactly.
They didn’t notice the anti-squirrel fortification.
They didn’t see the cedar disappearing toward the ground.
They didn’t know there was concrete underneath.
They saw a clean horizontal architectural detail tying the deck into the landscaping.
That may be my favorite thing about the entire project.
The engineering disappeared.
Good construction often does that.
When something is really awkward, the finished result doesn’t necessarily have to advertise how difficult the problem was.
In this case, the solution doesn’t look like pest control.
It looks like trim.
The Skirt Board Couldn’t Skirt the Issue
Which brings me back to the skirt board.
A normal skirt board could have done exactly what its name suggests.
It could have skirted the issue.
Put something attractive around the bottom of the deck, hide the framing, call it finished and go have a beer.
Except Karen’s objection wasn’t aesthetic.
She didn’t merely want to hide what was underneath the deck.
She wanted to prevent anything from moving in underneath the deck.
So the skirt board couldn’t merely skirt the issue.
It had to solve it.
And that led to one of those wonderfully backwards DIY projects where the apparently excessive idea turned out to make the finished construction easier.
The trench eliminated the need for a finished bottom cut.
The composite skirt eliminated the need for a finished top cut.
The cedar accommodated changing heights simply by overlapping another board.
The concrete stopped digging.
The stain protected the cedar.
And the composite board concealed the entire operation behind one clean horizontal line.
What initially sounded like:
“Let’s dig a trench and bury cedar siding in twelve bags of concrete because Karen doesn’t like squirrels”
eventually became:
“That’s actually a pretty damn elegant way to finish a deck to grade.”
I hate when she’s right.
There Is, Unfortunately, a Larger Lesson Here
I’ve spent a lot of my life building and fixing things.
One of the great advantages of knowing several trades is that when somebody proposes an idea, you can immediately imagine the seventeen reasons it won’t work.
This is extremely useful.
It’s also occasionally a handicap.
Experience teaches you where things fail.
But sometimes that means the experienced person starts solving the problem by eliminating possibilities, while somebody else starts with:
“Well, why couldn’t we?”
Karen wasn’t thinking about conventional deck-skirt construction.
She had a squirrel problem.
Or, more accurately, she had a future hypothetical squirrel problem, which is arguably worse because there wasn’t even a squirrel yet.
She identified the failure mode.
They’ll dig underneath.
Then she attacked the failure mode.
Put concrete underneath.
That’s it.
The guy who knew how to build things had a list of reasons the idea was silly.
The daughter of the guy who taught him how to build things grabbed a shovel.
And that’s probably not a coincidence.
Her father taught me practically every trade I know.
But apparently he taught Karen something, too.
Maybe the more important thing:
If the problem is still there, you’re not finished.
Years later, I look at that deck and no longer see the ridiculous squirrel bunker I reluctantly helped build.
I see a clean composite skirt, a nicely finished transition into the landscaping, and a construction detail simple enough that I’d seriously consider doing it again.
Maybe not with cedar–unless, like this example, it was free/leftover.
Maybe with something completely rot-proof next time.
How two AI agents turned my IDE into a parallel development team, and why adding a third requires CI/CD discipline
When most people were making funny pictures with AI, I connected OpenAI directly to my development environment.
Not beside it.
Not in a browser where I would ask a question, copy the answer, paste it into another application, and continue doing all the actual work myself.
I put the AI inside Visual Studio Code, the IDE where the software work happens.
It could inspect the real project. It could read the files. It could search the codebase. It could use the terminal. It could run tests. It could examine errors. It could work with Git. And, most importantly, it could use the command-line tools provided by the major enterprise platforms I work with.
That changed AI from something I talked to into something that could operate a workbench.
After using it for a while, I estimated that one properly directed coding agent could sometimes perform the mechanical output of approximately twenty people.
Not twenty senior architects.
Not twenty people with business judgment, institutional knowledge, or accountability.
Twenty sets of hands.
Twenty people searching files, writing repetitive code, tracing dependencies, comparing configurations, testing variations, documenting changes, checking details, and polishing the hundreds of little pieces that separate a prototype from an actual application.
I was paying roughly $40 a month and directing what felt, under the right conditions, like forty coders.
Now I think I may be ready to hire twenty more.
First, What Is an IDE?
An IDE is an Integrated Development Environment.
For a nondeveloper, think of it as the workshop where software is built.
It contains the source code, project folders, search tools, terminals, testing utilities, version history, debugging tools, and connections to other systems.
A carpenter does not build a cabinet by discussing wood in a conference room. The carpenter works in a shop containing saws, clamps, measuring tools, plans, and the material itself.
Visual Studio Code is my software shop.
Connecting AI to that environment meant it was no longer giving me abstract advice about what someone could theoretically build.
It could see the actual cabinet.
It could inspect the joints.
It could find the warped board.
It could propose a repair and, when authorized, make the cut.
Every Major Platform I Use Has a CLI
Most of the major systems I work with provide a CLI, or command-line interface.
Do you know what that means?
The Average-Person Explanation
Most people operate software through a graphical interface.
They click buttons. They open menus. They fill in forms. They move from screen to screen.
A command-line interface provides a second entrance into the same system.
Instead of clicking through six screens to perform an operation, you may be able to type one precise command.
That command can often be:
• saved
• repeated
• reviewed
• combined with other commands
• placed in a script
• run automatically
• executed consistently
• recorded as evidence of what happened
Imagine asking a person to perform a complicated task in an application.
They open one menu, click another menu, choose an option, enter a value, check a box, upload a file, and click Deploy.
Now imagine replacing that sequence with a written instruction the computer understands exactly.
The first method is difficult to repeat perfectly.
The second can become a controlled process.
That repeatability is the doorway to automation.
It is also the doorway through which an AI agent can enter the actual work.
The Developer Explanation
At a technical level, a CLI exposes platform operations through structured commands, arguments, configuration files, credentials, environment variables, and machine-readable output.
Depending on the platform, a CLI may allow an authorized developer or agent to:
• create projects
• inspect metadata
• retrieve configuration
• validate source files
• compare environments
• run builds
• execute tests
• deploy components
• collect logs
• examine failures
• import or export data
• automate a sequence of operations
A CLI does not necessarily expose every capability of the platform.
Some are excellent. Some are incomplete. Some enterprise applications still trap important configuration inside graphical administration screens.
But even a limited CLI changes the nature of AI-assisted development.
Without tools, AI can tell you what code might look like.
With an IDE, terminal, files, Git, APIs, and CLIs, an agent can inspect the actual project, make a change, run validation, observe the result, correct the failure, and prepare the work for human review.
It now has hands.
One Agent Began to Feel Like Twenty People
When I say that one agent can feel like twenty humans, I am not claiming that an AI subscription replaces twenty complete employees.
People contribute experience, creativity, judgment, relationships, accountability, and an understanding of consequences that cannot be reduced to typing speed.
My estimate concerns execution capacity.
A conventional development team may distribute hundreds of small responsibilities among many people:
• one person creates the data structure
• one person builds the API
• another builds the screen
• someone adds validation
• someone handles errors
• another improves mobile behavior
• someone adds logging
• someone tests edge cases
• someone writes documentation
• someone adjusts spacing
• someone notices that the loading indicator feels wrong
• someone adds keyboard navigation
• someone makes the table sortable
• someone adds filtering
• someone builds drag-and-drop behavior
• someone adds gauges and status indicators
• someone handles empty states
• someone improves the confirmation dialog
• someone checks that the colors communicate status consistently
• someone notices that the entire thing is technically correct but unpleasant to use
Large teams do not merely add big features.
They add thousands of small refinements.
That is what surprised me most about a capable coding agent.
I could design down to the smallest interaction.
The cards should support drag-and-drop ordering.
The status gauge should animate smoothly but not distract the user.
The warning state should appear only when the threshold is materially exceeded.
The filter should remember the user’s last choice.
The table should remain readable on a smaller monitor.
The modal should explain what will happen before the user commits the action.
The empty state should tell the user what to do next rather than merely display “No data.”
The dashboard should show green when everything is healthy, yellow when attention is needed, and red only when action is required.
The agent could then move through the codebase and build those details.
Not always perfectly.
Not without review.
But rapidly enough that I no longer had to choose between building the primary function and adding the dozens of refinements that make the system feel complete.
That is where the “twenty people” comparison came from.
One agent could keep returning to the work.
It did not become bored with the small details.
It did not decide that the drag-and-drop behavior was outside its job description.
It could implement the gauge, revise the spacing, trace the error state, update the documentation, run the test, and then revisit the same component after I noticed one more improvement.
A traditional twenty-person team adds breadth because many people can work on many details.
An AI agent adds a strange form of compressed breadth because it can move rapidly across many disciplines while retaining the context of the overall design.
Again, the agent does not replace the judgment of twenty people.
But it can deliver a startling portion of the hands-on work those people would perform.
Then I Opened a Second Visual Studio Code Instance
After working this way for a while, I realized I was still operating the agent in a mostly single-threaded way.
I would give it a task. It would inspect the system. It would work. I would review the result. Then we would move to the next task.
But Visual Studio Code can run in multiple windows and workspaces.
Why not open another instance?
Why not give a second agent a separate lane?
One agent could build while another investigated.
One could modify the application while another reviewed existing architecture.
One could work on a NetSuite script while another examined the integration flow.
One could implement the primary function while another prepared edge-case tests, documentation, and deployment evidence.
That was the moment the model changed.
I was no longer using an assistant.
I was beginning to direct a team.
A Real Example: Two Agents, One Shared Conversation
Here is what the model looks like in actual use.
I keep ChatGPT open in an integrated browser inside Visual Studio Code. An integrated browser is a browser panel that lives inside the development environment instead of in a completely separate Chrome window. The conversation, the source files, the terminal, and the coding agent can all remain inside the same working cockpit.
ChatGPT and I first strategize around the goal. I provide the operational objective, the business process, the constraints, the risks, and the actions that must remain under human approval. ChatGPT helps translate that intent into architecture, work packages, validation requirements, and explicit instructions for Codex.
I remain the source of operational intent and the person who greenlights each material step. ChatGPT acts as the planning and translation layer. Codex works inside the IDE, where it can inspect the project, edit files, run commands, validate results, and report what it found.
A Targeted Handoff Instead of Copy and Paste
We created a lightweight XML-style instruction schema so Codex does not have to interpret the entire conversation as a task. It reads only the latest relevant block explicitly addressed to it.
Prepare the Northern Tool inbound 997 implementation for a controlled production preflight.
…
Post your findings in this chat.
</codex>
The mode tells Codex what kind of work to perform. The approval attribute defines the boundary of its authority. In this example, it may inspect and correct the implementation and prepare the production preflight, but it may not deploy.
The body defines the assignment and the expected return. When Codex finishes, it posts its findings back into the shared ChatGPT conversation.
That creates a closed loop:
Jim defines the operational goal and approval boundaries.
ChatGPT helps design the approach and writes the precise agent instructions.
Codex reads the targeted instruction, performs the IDE work, and reports the evidence.
Jim reviews the result and authorizes, redirects, or stops the next step.
A Real Parallel EDI Workstream
At one point, Agent One was building the inbound 850 purchase-order application in NetSuite and the outbound 855 purchase-order acknowledgment.
I got ahead of that workstream.
Rather than waiting for Agent One to finish, I opened a new Visual Studio Code instance and assigned Agent Two to the 856 advance ship notice, formally the X12 Ship Notice/Manifest.
Agent One continued developing the order and acknowledgment path. Agent Two began developing the shipping-notice path. I moved between their review points, answered operational questions, resolved dependencies, and approved the next controlled steps.
For roughly eight hours, I moved back and forth between the two agents, reviewing and greenlighting each material step while the equivalent of about forty sets of development hands produced thousands of lines of code, tests, corrections, interface details, and deployment evidence.
That is an important distinction. I was not personally typing tens of thousands of lines. My work was architectural and supervisory: defining the goal, correcting direction, resolving business decisions, checking evidence, and deciding when each workstream could proceed.
That was not simply two chat windows answering questions.
It was two technical workstreams advancing concurrently under one architecture, one shared strategy conversation, and one human release authority.
Then I Measured the Output
A few days later, in Visual Studio Code Instance Three, or VSi3, I asked Codex to perform a read-only audit of the repository instead of relying on my impression of the work.
The audit measured VSi3’s repository output over roughly two active development days. This was not the combined production of VSi1 and VSi2. It found 14 commits across 33 distinct files. Production source and deployable configuration accounted for 6,119 changed lines. Tests and test harnesses added another 2,072. Operational documentation added 809 more.
The complete verified total was exactly 9,000 changed lines: 8,838 additions and 162 deletions, producing a net increase of 8,676 lines. Based on the breadth of production code, deployable configuration, testing, documentation, validation, and release evidence, I estimate that VSi3 delivered roughly 20 to 40 human developers’ worth of execution over those two days, or approximately 40 to 80 person-days.
Those numbers were deliberately conservative. ZIP archives, screenshots, build packages, generated output, dependency trees, lockfiles, and raw EDI payloads were excluded. Untracked files were included only after their creation timestamps were verified. The audit separated committed, unstaged, and untracked work instead of flattening everything into one flattering number.
No single file dominated the result. The work crossed the entire delivery stack: SuiteScript application logic, REST services, operator interfaces, deployable SDF configuration, automated tests, and production operating documentation.
I did not personally type 9,000 lines. I designed the system, defined the operating rules, made the business decisions, corrected direction, reviewed evidence, and controlled what could proceed. The agents supplied the execution capacity.
That is the distinction at the center of this article. AI did not replace architecture, judgment, or accountability. It multiplied the hands available to carry them out.
Two Agents Create a New Problem
Two agents do not simply produce twice as much progress.
They can also produce twice as many collisions.
They may modify the same file.
They may make different assumptions.
One may depend on something the other has changed.
One may test an older version.
They may each create a solution that works independently but fails when integrated.
The faster the agents work, the faster confusion can spread.
Opening additional IDE windows was easy.
Creating a safe operating model for parallel development was not.
That is why a CI/CD-style architecture became necessary.
What CI/CD Means
CI/CD usually means Continuous Integration and Continuous Delivery, or Continuous Integration and Continuous Deployment.
The wording varies, but the basic purpose is consistent.
It creates a controlled pathway for moving software changes from development toward release.
The process generally includes:
• tracking changes
• separating work
• validating files
• running tests
• combining compatible changes
• detecting conflicts
• promoting changes through defined environments
• requiring approval where appropriate
• deploying through repeatable procedures
• retaining enough history to understand what happened
My enterprise environment is not a textbook, fully automated, repository-driven CI/CD system.
Some of the CLIs are restricted.
Some configuration still lives inside the platforms.
Certain settings cannot be represented perfectly as code.
Not every deployment can be reduced to one automated pipeline.
But the environment is CI/CD-aligned.
It uses the same essential principles:
• controlled development
• separated responsibilities
• repeatable steps
• validation before promotion
• documented changes
• testing
• integration controls
• human approval gates
• managed deployment
The architecture is necessary because parallel AI agents can create work more quickly than a loose development process can safely absorb.
Without control, speed becomes turbulence.
With control, speed becomes throughput.
CI/CD for a Nondeveloper
Imagine several mechanics working on the same vehicle.
One is modifying the engine.
One is repairing the electrical system.
One is replacing the brakes.
The assignments are deliberately separated. I would not put one mechanic on a bicycle tire while another works on the spokes of the same wheel. That is not parallelism. It is interference. The useful model is one mechanic working on the car’s tires while another handles the brakes, or one person repairing a window screen while another washes the windows. Separate lanes, shared outcome.
They can work at the same time, but only if each understands the assignment and their work is inspected before the vehicle returns to the road.
Otherwise, one mechanic may disconnect something another needs.
They may install incompatible parts.
Someone may test the vehicle before the brakes are operational.
A CI/CD-style system provides:
• separate work areas
• clear responsibilities
• a record of each change
• inspection points
• integration testing
• final approval
The mechanics can work concurrently.
The vehicle still passes through controlled gates.
My agents are extremely fast mechanics.
The development architecture is the shop procedure.
I still decide what vehicle we are building, what modifications belong on it, and when it is safe to turn the key.
Why This Matters for EDI Onboarding
EDI onboarding is an ideal example because it is not one task.
It includes a web of connected activities:
• partner requirements
• transaction specifications
• identifiers
• mappings
• test documents
• business rules
• acknowledgments
• order handling
• shipment messages
• invoicing
• exception paths
• validation
• deployment
• monitoring
Traditionally, these activities often move through a long sequence.
One person completes a piece and hands it to the next.
The next person discovers a missing dependency and sends it backward.
Someone waits for a sample file.
Someone else waits for a mapping decision.
Testing begins late.
Errors discovered near the end send the project back through the line.
With a CI/CD-aligned fast-track onboarding model, several workstreams can move concurrently.
One agent can analyze the partner specifications.
Another can inspect the existing EDI application and integration architecture.
One can develop mappings.
Another can prepare test cases and challenge exception paths.
One can build.
Another can review.
One can trace dependencies while another prepares deployment evidence.
That is not human multitasking in the traditional sense.
Human multitasking usually means one person switching rapidly between several jobs and performing each with fragmented attention.
Here, the agents perform the work in parallel.
I move among structured review and approval points.
The human remains intentionally single-threaded.
The delivery system becomes multi-threaded.
Then the Bottleneck Moved
After using two agents this way, I noticed something unexpected.
The agents were no longer the limiting factor.
I was.
Each could inspect, analyze, write, test, revise, and document at extraordinary speed.
But I still had to review and greenlight each material step.
I had to determine:
• whether the assumption was correct
• whether the architecture matched the business
• whether the solution belonged in the system
• whether one agent’s work conflicted with the other
• whether the validation was meaningful
• whether the risk was acceptable
• whether the next action should be authorized
• whether anything was permitted to reach production
The execution capacity had become abundant.
Human judgment had become scarce.
When My AI Developers Punch Out
When my AI developers get ahead of me, they punch out and take an unpaid break.
That sounds like a joke, but it points to another unusual economic advantage of this model. A human team still creates payroll, coordination, meetings, context switching, and pressure to keep everyone occupied when the supervisor becomes the bottleneck. An AI agent can stop at a review gate and wait. It does not become impatient, invent side work, or accumulate additional hourly labor cost while I catch up. When I return with the next decision, it resumes at full speed.
I do not have to keep the agents busy. I have to keep myself capable of reviewing what they produce.
The Third-Agent Question
That led me to a sentence I do not think most people I know would naturally say:
I think I am ready to hire another twenty coders.
What I really mean is that I may be ready to supervise a third AI agent.
The decision is not about whether the third agent can produce more work.
It can.
The question is whether I have enough structure and review capacity to keep another high-speed workstream useful and controlled.
A third agent needs a distinct lane.
Otherwise, I am not adding capacity.
I am adding noise.
Adding Another Agent Took One Click
The most startling part was how little effort it took to add another development lane.
I clicked Duplicate Workspace in Visual Studio Code.
The new instance opened on the same machine and development environment. The repositories were already available. The command-line tools were installed. The credentials and platform connections were already configured. The new agent inherited access to the same files, terminal, Git history, testing tools, and deployment utilities.
I added another integrated browser window, opened the same ChatGPT conversation, and assigned the new VSi its own workstream.
That was essentially the entire onboarding process.
All three Visual Studio instances could work independently, yet their findings and assignments flowed through one unified conversation. ChatGPT and I could see VSi1, VSi2, and VSi3 at the same time. I could review one increment, assign the next, rotate immediately to another instance, and continue without stopping to wait.
Review. Assign. Rotate. Never stop and wait.
By the time I completed the circuit, the first VSi was often ready for review again.
Adding another development lane was no longer a staffing project. It was almost one click.
The limiting factor was not provisioning another agent. It was whether I had enough architectural clarity, review capacity, and approval discipline to keep another high-speed workstream productive.
AI execution capacity had become almost instantaneous to provision. Human supervisory capacity had become the scarce resource.
A Possible Three-Agent Operating Model
Agent One: Builder
The first agent performs implementation.
It writes code, creates mappings, builds interfaces, updates configurations, and develops the primary technical solution.
It can handle the visible work and the hundreds of smaller details that surround it:
• drag-and-drop interactions
• sorting and filtering
• responsive layouts
• gauges
• progress indicators
• confirmation dialogs
• empty states
• validation messages
• error handling
• status lights
• accessibility improvements
• logging
• documentation
Agent Two: Reviewer and Tester
The second agent challenges the builder.
It inspects the proposed changes.
It checks assumptions.
It searches for edge cases.
It reviews error paths.
It tests for regressions.
It compares the implementation to the original objective.
Its job is not to admire the solution.
Its job is to try to break it.
Agent Three: Analyst and Coordinator
The third agent works ahead of and around the implementation.
It can:
• perform discovery
• trace dependencies
• inspect related systems
• maintain documentation
• prepare test cases
• assemble evidence
• identify missing decisions
• organize deployment steps
• monitor open questions
• prepare the next approval package
This agent keeps the next section of road surveyed while the builder and reviewer work on the current section.
Human: Architect and Release Authority
I remain responsible for:
• the objective
• the architecture
• the business context
• the priorities
• the controls
• the risk decisions
• the approvals
• the production release
The agents can create the work.
They do not own the consequences.
I do.
The Agents Must Return Decisions, Not Noise
Three agents can generate an astonishing amount of information.
If they return every command, every file, every possibility, and every unresolved thought, they can bury the person supervising them.
Each workstream needs to return a compact review package:
1. What changed?
2. Why was it changed?
3. What evidence shows that it works?
4. What risks or uncertainties remain?
5. What exact decision is required from me?
That format turns activity into a decision point.
Without it, more agents create a larger inbox.
With it, they create parallel delivery capacity.
The Real Skill Is Not Prompt Writing
People often describe AI expertise as knowing how to write good prompts.
That matters, but it is only the visible surface.
The harder skill is directing several execution systems without losing control of the architecture, dependencies, evidence, and consequences.
The human must understand enough to recognize when an answer is correct and when it merely sounds correct.
The human must notice when two agents are solving different versions of the same problem.
The human must recognize when a technically valid change violates the operating model.
The human must be willing to say:
The code works, but it solves the wrong problem.
The explanation is polished, but the evidence is incomplete.
The feature is useful, but it does not belong in this release.
The agent is fast, but it is headed in the wrong direction.
That judgment is the control system.
Forty Coders for Forty Dollars?
Is it literally forty coders?
No.
It is not forty independent minds.
It is not forty careers’ worth of judgment.
It is not forty people who can walk into a meeting, understand the politics, take responsibility, challenge leadership, mentor a colleague, and live with the consequences of a bad release.
But when the architecture is clear and the work can be expressed through code, files, commands, tests, and repeatable procedures, two agents can generate a level of output that once would have required a surprisingly large team.
They can implement the main function.
Then they can keep going.
They can add the drag-and-drop.
They can refine the gauge.
They can add the tooltip.
They can improve the empty state.
They can handle the loading condition.
They can test the invalid input.
They can add the log message.
They can revise the layout.
They can update the documentation.
They can trace the overlooked dependency.
They can do the twenty-person-team things that are often sacrificed because everyone is trying to get the primary feature across the finish line.
That is why the number feels real to me.
Not because AI has become twenty complete humans.
Because it can bring twenty humans’ worth of hands to a well-designed problem.
I Think I Am Ready to Hire Twenty More
The sign is not that I have run out of tasks for the current agents.
The sign is that the first two increasingly reach clear review points and wait for me.
The operating model is becoming structured enough to support another lane.
The real test is whether I can add that lane without reducing the quality of my review.
A third agent makes sense only if:
• it has a clearly separated responsibility
• its work can proceed without constant collisions
• it returns concise review packages
• approval gates remain explicit
• production permissions remain controlled
• I can explain every significant decision
If I no longer understand what the agents are doing, I have not scaled the system.
I have surrendered the controls.
A Different Kind of Team Is Appearing
Many organizations are still deciding whether employees should use one AI assistant.
Meanwhile, another operating model is quietly emerging.
One experienced person can direct several specialized AI agents through parallel technical workstreams, supported by CLI access, development controls, repeatable validation, and human approval gates.
The progression is almost inevitable:
First, AI answers questions.
Then AI enters the IDE.
The IDE gives it access to files and a terminal.
The CLI gives it access to the platforms.
A second IDE instance creates another workstream.
Parallel work makes CI/CD discipline necessary.
The agents accelerate until human review becomes the bottleneck.
Then the human asks a question that would have sounded ridiculous only a short time ago:
I have forty coders for about forty dollars a month. Am I ready to hire twenty more?
Most of us were taught that Western music contains twelve notes:
C, C♯, D, E♭, E, F, F♯, G, A♭, A, B♭, and B—after which the pattern repeats at the next octave.
On a modern piano, that is essentially true. Press middle C and the piano produces one predetermined frequency. Press the black key between G and A and you get one predetermined pitch, whether the composer calls it G♯ or A♭.
But that is not a law of nature. It is a compromise humans imposed on musical instruments.
In naturally tuned music, a note does not always have one permanent frequency. Its ideal pitch can change according to the key, chord, and harmonic function in which it appears. The difference can be small, but it is not imaginary. In one particularly striking case, two versions of what a piano treats as the same note can differ by approximately 41 cents—about 41 percent of a half-step, or nearly half of the distance between two neighboring piano keys.
That means a “single note” can move almost halfway toward the next note depending upon what it is doing musically.
Nature Does Not Divide the Octave Into Twelve Equal Pieces
Musical harmony begins with physical relationships between frequencies.
If one string vibrates at 220 cycles per second and another vibrates at 440 cycles per second, the second is vibrating exactly twice as fast. We hear those two pitches as versions of the same note, one octave apart. Their frequency relationship is:
2:1
Other simple numerical relationships also produce intervals that human beings generally perceive as especially consonant:
An octave is 2:1
A perfect fifth is 3:2
A perfect fourth is 4:3
A major third is 5:4
A minor third is 6:5
A major sixth is 5:3
This method of tuning intervals according to simple whole-number frequency ratios is called just intonation.
The intervals sound exceptionally smooth because their vibrations regularly coincide. A note vibrating three times during the same period in which another vibrates twice forms a 3:2 perfect fifth. Their wave patterns repeatedly meet in an orderly way. The notes seem to lock together.
The difficulty appears when we try to use all of those pure relationships at once.
The mathematics does not close perfectly.
The Piano’s Solution: Make Every Note Slightly Wrong
Modern pianos are normally tuned using twelve-tone equal temperament. The octave is divided into twelve mathematically equal half-steps. Each note has a frequency equal to the previous note multiplied by the twelfth root of two:
2¹⁄¹² ≈ 1.059463
After multiplying by that number twelve times, the frequency has exactly doubled, completing the octave.
This system gives musicians an enormous practical advantage: every key works. A pianist can begin in C major, modulate to E major, wander into A♭ major, and eventually return to C without retuning the instrument. The same black key can function as G♯ in one passage and A♭ in another.
The price is that, except for the octave, the intervals are not perfectly pure.
For example:
A pure 3:2 perfect fifth is approximately 701.96 cents
An equal-tempered perfect fifth is 700 cents
A pure 5:4 major third is approximately 386.31 cents
An equal-tempered major third is 400 cents
A cent is one one-hundredth of an equal-tempered half-step. There are 100 cents between adjacent piano keys and 1,200 cents in an octave.
The equal-tempered major third is therefore almost 14 cents wider than the natural 5:4 third. It is close enough to work, but it is not acoustically pure. On a sustained instrument, one can hear the slight beating produced by the mismatch.
Equal temperament does not make every interval perfect. It distributes the imperfection so evenly that no ordinary key is unusable.
It is less a discovery than a diplomatic agreement among the notes.
The Same D Can Be Two Different Pitches
Consider the note D within the key of C major.
If C has a frequency value of 1, D can be tuned as a major whole-step above it using the ratio:
D = 9:8
But suppose D becomes the root of a D-minor chord containing D, F, and A. In a justly tuned C-major scale:
F can be tuned at 4:3 above C
A can be tuned at 5:3 above C
For D–F to be a pure 6:5 minor third, and D–A to be a pure 3:2 perfect fifth, D needs to be:
D = 10:9
We now have two mathematically reasonable versions of D:
D as 9:8
D as 10:9
The relationship between them is:
(9/8) ÷ (10/9) = 81/80
The ratio 81:80 is called the syntonic comma. It is approximately:
21.51 cents
Thus, the D that works perfectly as the fifth of a G chord can be approximately 21.5 cents higher than the D that works perfectly as the root of a D-minor chord.
The written note has not changed. It is still D. But its harmonic job has changed, and nature gives us two slightly different answers for where D should be.
A fixed-pitch piano cannot move the note while it is being played. A capable singer, violinist, trombonist, or string ensemble can. Musicians often adjust notes instinctively, listening for the point at which the chord settles and the audible beating diminishes. They may never calculate the ratio 81:80, but their ears can lead them toward it.
This is one reason a fine unaccompanied choir or string quartet can produce chords that seem to become unusually still, luminous, or resonant. The musicians are not necessarily adhering rigidly to twelve immovable piano pitches. They are tuning the notes to one another.
The Nearly Half-Step Difference
The more dramatic example involves enharmonic notes such as G♯ and A♭.
On a modern piano, G♯ and A♭ are the same key. In musical notation, however, they do not necessarily mean the same thing.
A G♯ may function as the major third above E. If C is our reference pitch, and E is tuned as a pure 5:4 major third above C, then another pure 5:4 major third above E produces G♯:
G♯ = 5/4 × 5/4 = 25/16
A♭, meanwhile, can be tuned as a pure minor sixth above C:
A♭ = 8/5
Compare the two:
(8/5) ÷ (25/16) = 128/125
The ratio 128:125 is known as the lesser diesis, or enharmonic diesis. Its size is approximately:
41.06 cents
That is not quite half of a 100-cent half-step, but it is remarkably close.
To put real frequencies to it, suppose C is approximately 261.63 hertz:
G♯ at 25:16 would be approximately 408.79 Hz
A♭ at 8:5 would be approximately 418.60 Hz
The equal-tempered piano key used for both would be approximately 415.30 Hz
The natural G♯ and natural A♭ in this example differ by almost 10 vibrations per second.
The piano compromises by placing its single black key between them.
So when we say that G♯ and A♭ are “the same note,” what we really mean is that equal temperament assigns them to the same key. They are equivalent for the mechanical convenience of a twelve-note keyboard. They are not necessarily identical in their harmonic origin or ideal natural pitch.
Why the Key Matters
A musical key establishes a network of relationships.
In C major, C is the tonal center. G tends to be understood in relation to C; E forms the major third above C; B functions as a leading tone pointing toward C.
Move into E major and those same written or sounding pitches acquire different jobs. Now E is home. G♯ is the major third of the tonic chord. B is its perfect fifth. D♯ pulls upward toward E.
If every important interval is to remain acoustically pure, some notes must move slightly when the harmonic center changes. A note tuned perfectly for one chord may be imperfect for the next. Correcting it for the second chord can create a discrepancy elsewhere.
This is not evidence that the mathematics is faulty. It is evidence that a closed twelve-note system cannot simultaneously preserve every simple frequency relationship in every key.
The problem is sometimes called comma drift. A progression can travel through a sequence of perfectly tuned intervals and arrive at what is nominally the original note—but at a slightly different frequency. The musical spelling says that we have come home; the multiplication of the natural ratios says that home has moved.
That tiny difference is one of the reasons tuning systems and temperaments exist.
Comma, Diesis, and Half-Step Are Not the Same Thing
Several related measurements can easily become confused:
The syntonic comma, ratio 81:80, is approximately 21.51 cents
The Pythagorean comma, produced by the mismatch between twelve pure fifths and seven octaves, is approximately 23.46 cents
The lesser diesis, ratio 128:125, is approximately 41.06 cents
An equal-tempered half-step is exactly 100 cents
Therefore, the statement “the same note can differ by nearly half a half-step depending on its key or harmonic meaning” refers most directly to the approximately 41-cent lesser diesis.
The more common adjustment of the same named note between two harmonic roles is often the smaller 21.5-cent syntonic comma.
Both illustrate the same underlying truth: musical notation groups together pitches that nature does not always place at precisely the same frequency.
Sharps and Flats Are Not Merely Different Spellings
Beginning musicians are often told that G♯ and A♭ are two names for the same note. That explanation is useful at a piano keyboard, but it conceals some of the deeper logic of music.
A sharp generally means that a note has been raised in relation to a particular scale or harmony. A flat means that a note has been lowered. The two spellings tell us where the note came from, where it is going, and what job it performs.
G♯ in an E-major chord is not conceptually interchangeable with A♭ in an A♭-major or F-minor chord, even when equal temperament forces both onto the same piano key.
The notation preserves a distinction that the keyboard erases.
Historically, this was not merely theoretical. Some keyboard instruments were built with split black keys so that performers could play separate sharp and flat pitches. Nicola Vicentino’s sixteenth-century archicembalo went much further, dividing the octave into many more than twelve available pitches. Meantone temperaments likewise produced noticeably different enharmonic notes, although they solved and distributed the tuning discrepancies differently from strict just intonation.
Equal temperament eventually prevailed largely because it made unrestricted modulation and standardized fixed-pitch instruments practical—not because it revealed that G♯ and A♭ had always been physically identical.
The Note Is a Relationship
We tend to imagine a musical note as a fixed object: C is C, D is D, and A is 440 hertz.
But even A = 440 is only a modern tuning convention. Orchestras can tune somewhat higher or lower. Earlier periods and different regions used other reference pitches. More importantly, after selecting a reference pitch, musicians must still decide how all the remaining notes relate to it.
A note is therefore not merely a frequency. It is also a relationship:
a relationship to the tonal center,
a relationship to the other notes in the chord,
a relationship to the notes immediately before and after it,
and a relationship to the tuning system being used.
The piano gives us the enormously useful illusion that music is constructed from twelve permanent sonic bricks. Natural harmony reveals something more fluid. The notes behave less like fixed points and more like members of a living family, subtly adjusting themselves according to whom they are standing beside.
That adjustment can be 21.5 cents.
In certain enharmonic situations, it can exceed 41 cents—nearly half the distance to the next piano key.
The name of the note may remain the same. The mark on the page may remain the same. Our piano may offer only one key for it.
But the mathematically pure note nature asks for can change with the harmony.
And somehow, the human ear knows.
References and Further Reading
The mathematical distinction between the just 5:4 major third, the Pythagorean 81:64 major third, and their 81:80 syntonic comma is discussed by the Society for Music Theory in “Scholtz, Footnotes”.
A Scientist’s Theology of Evidence, Mercy, and the Soul
A hypothesis built from the biblical canon, the wider ancient Christian and Jewish library, the problem of evil, and a long argument with an AI.
AUTHOR’S NOTE
The title is intentionally provocative. ChatGPT does not “believe” in the human sense of faith, worship, spiritual experience, or private conviction. I use believe operationally: when forced to compare competing explanations rather than dismiss theology by definition, AI regards God as a serious, rationally defensible and leading hypothesis. That is enough for the argument I want to make.
I’m not a philosopher or theologian. This essay is not a new creed. It is a model. I am treating theology the way the scientist in me would treat any complicated system: define the terms, separate observations from inferences, widen the dataset, find the hidden assumptions, and ask which model explains the most without breaking what we already know.
My basic rule is simple:
If you propose an explanation, put it on the table. If I propose one, put mine there too. Then make both survive the evidence.
1. THE FIRST RULE: SAYING “I THINK” IS NOT DATA
A surprising amount of argument about God begins with a conclusion disguised as evidence.
“I think the universe is random.”
“I think there is no heaven.”
“I think Jesus stayed dead.”
“I think religion explains why people believe.”
Fine. Those are hypotheses. They may be good hypotheses. They may even be right. But “I think” is not a dataset. Manuscripts are a dataset. Archaeological layers are a dataset. Inscriptions, settlement patterns, radiocarbon dates, coins, papyri, and independent historical accounts are datasets. Your intuition is where the investigation starts, not where it ends.
For example:
Manuscript corpus: thousands of Biblical manuscripts and fragments, their estimated dates, locations, wording, and textual variants. The Dead Sea Scrolls plus later Hebrew manuscripts can test claims about how much the Old Testament text changed over time.
Archaeological record: destruction layers, settlement sizes, pottery sequences, architecture, burials, food remains, and radiocarbon dates across many sites. That can test something like, “Was there widespread destruction in Canaan during the period proposed for the conquest?”
Inscriptional evidence: collections of ancient inscriptions rather than one favorite stone. The Merneptah Stele, Tel Dan Stele, royal inscriptions, seals, ostraca, and administrative texts can be compared for names, kingdoms, political structures, and chronology.
Independent historical writings: Josephus, Tacitus, Suetonius, Pliny, Roman administrative material, neighboring Near Eastern chronicles, etc. The useful dataset is the whole collection, including places where the sources disagree or say nothing.
Settlement-pattern data: number, size, location, and dating of villages over centuries. If somebody argues that a huge population suddenly entered a region, population archaeology gives you something measurable to compare that claim against.
Coinage and papyri: rulers named, titles used, dates, taxation, languages, local officials, trade patterns. These are especially useful for testing whether a Gospel or Acts accurately reflects the governmental world it describes.
Linguistic data: vocabulary, grammar, loanwords, spelling conventions, and writing styles across a large corpus of dated ancient texts. That can help evaluate whether a particular passage plausibly belongs to a proposed time period.
Textual cross-comparison: if Matthew, Mark, Luke, John, Paul, Josephus, and Roman sources describe an event or person, you can systematically record what each source claims, when it was written, apparent dependence on other sources, and where the accounts converge or conflict.
And that distinction is perfect for the Bible piece because it cuts both ways. It applies equally to “the Bible says it, therefore it happened exactly this way” and “I can imagine a naturalistic explanation, therefore that must be what happened.”
Both are hypotheses until they collide with evidence.
The same rule applies to the believer:
“I know God did it.”
“I know this verse means exactly what my church says.”
“I know every book outside my canon is false.”
Fine. Hypotheses again.
The scientist in me wants the board divided into three columns:
OBSERVATION — what is actually in the historical record.
INFERENCE — what we think best explains it.
METAPHYSICS — what we think reality ultimately is.
The discipline is not to let a favored inference sneak into the observation column.
That sounds obvious. It is not. We do it constantly.
2. “THE BIBLE” IS NOT A SINGLE BOOK
One of the first underlying-definition traps is the phrase “the Bible.”
We talk about it as though some deity sat down, opened a fresh document, typed Genesis at the top, and eventually reached Revelation.
That is not what happened.
A better mental model might be thinking of our current bible as The Greatest Hits of Theology and Christianity according to Emperor Constantine the Great, Emperor of Rome.
To understand what i’m trying to say here lets go back a few thousand years. There were churches and literate elite all over that had accumulated libraries of great historical books of old
Prophets: Joshua, Judges, Samuel, Kings, Isaiah, Jeremiah, Ezekiel, and the Twelve Minor Prophets (Various 500-700 BCE)
Writings: Psalms, Proverbs, Job, Song of Songs, Ruth, Lamentations, Ecclesiastes, Esther, Daniel, Ezra-Nehemiah, Chronicles
The familiar Protestant Old Testament was originally 39 different books, and today it is largely the same textual collection rearranged and divided differently.
Catholic and Orthodox include additional ancient Jewish writings, often called the Deuterocanonical books or Apocrypha, such as Tobit, Judith, Wisdom of Solomon, Sirach, Baruch, and 1–2 Maccabees, plus additions to Esther and Daniel.
Jesus and the earliest Christians in-fact lived before there was a thing called “Old Testament”. Greek-speaking Jews widely used the Septuagint, which contained a broader collection of writings than the later rabbinic Hebrew canon.
These writings were important, admired, and expensive to reproduce. There was no printing press. Every copy required materials, skilled labor, and an enormous amount of time. So texts traveled differently than books do today. Scrolls and manuscripts were preserved by religious communities, scribes, schools, and wealthy collectors. They were borrowed, shared, copied by hand, recopied, archived, translated, quoted, compared and, quite often, argued over.
A writing did not become important because somebody clicked Publish. It became important because generations of people thought it was important enough to keep copying.
And that matters. Every surviving ancient text has already passed through a human filter. Someone valued it. Someone paid for it. Someone preserved it. Someone chose to make another copy instead of copying something else. The funny thing is
The word bible comes from Greek τὰ βιβλία (ta biblia), literally “the books.”
Even the word Bible remembers what we tend to forget. It comes from the Greek ta biblia, meaning “the books.”
Different writings. Different authors. Different centuries. Different audiences. Different arguments.
We eventually bound them together and began speaking of them in the singular like with spiritual power.
The Bible became a book. Its own name says it is a collection of books. But whose collection?
There were many more religious writings in circulation than the ones we now call the Bible. Some disappeared. Some survived only in fragments. Some were treasured by one community and rejected by another. And some kept showing up again and again. They were read in churches and synagogues, quoted by respected teachers, copied when copying was expensive, and carried from one generation to the next.
Eventually a group of them became the must-haves (like greatest hits of the sixties–according to a dubious dictator–carpenters, yes, zeppelin, no)
But that raises a wonderfully uncomfortable question:
Must-haves according to whom?
There wasn’t one guy at the beginning making the playlist. Usage came first. By the early fourth century, Eusebius could already describe some Christian writings as broadly acknowledged, others as disputed, and still others as rejected or spurious. His acknowledged core included the four Gospels, Acts, Paul’s letters, 1 John and 1 Peter. James, Jude, 2 Peter and 2–3 John were among writings still disputed. That tells us a substantial core had emerged through the practices of Christian communities before Constantine, but the edges were still moving. Then there was the Council of Nicea
Some people think the Religious leaders of the Council of Nicea chose the book in the bible, also not exactly how it went down.
At Nicaea, the emperor of Rome summoned the council and personally participated in the effort to produce religious unity. The bishops who rejected the settlement did not merely lose an academic debate–they were ruined. Theonas and Secundus were exiled along with Arius, and Arius’s writings were condemned and burned. Eusebius of Nicomedia and Theognis were also later deposed and banished after refusing the full condemnation.
Meanwhile, Eusebius, who was actually there and became one of Constantine’s great admirers, records that after the council Constantine entertained the bishops at the imperial palace and personally distributed gifts according to rank. A later church history summarizes this as Constantine having “remunerated the bishops lavishly.”
And this wasn’t merely ceremonial influence. Constantine poured imperial money into churches, ordered governors to provide labor and materials, authorized lavish construction expenditures, and used the machinery of the state to promote the Christianity he favored.
The Bible is an anthology. Law, poetry, songs, origin stories, political history, prophecy, wisdom literature, letters, biographies of Jesus, arguments between early Christians, and apocalyptic literature were written and edited by different people, for different audiences, under very different circumstances. The Hebrew Bible itself developed over centuries, and even the boundaries of what counted as scripture were not always identical among communities.
The Bible is a library: law, poetry, history, prophecy, wisdom, letters, biographies, apocalyptic literature, genealogies, sermons, ritual texts, and theological argument written and edited across many centuries.
Even the boundaries of that library have not been identical across Christian traditions.
The fourth-century Codex Sinaiticus contains the New Testament books familiar in the West, but it also appends the Epistle of Barnabas and the Shepherd of Hermas, two early Christian texts not found in modern Western Bibles.[1] By the middle of the fourth century there was wide agreement about many books, but not complete agreement about the boundaries of Christian Scripture.[2]
Athanasius’s Thirty-Ninth Festal Letter in 367 CE is the earliest surviving Christian document to list precisely the twenty-seven books that later became the generally accepted New Testament canon.[3] That is historically important. It also means the familiar twenty-seven-book list did not descend into history already bound in leather.
And Ethiopia is a standing warning against speaking as though there has only ever been one Christian canon. The Ethiopian Orthodox Tewahedo Church describes an eighty-one-book Bible that includes Enoch and Jubilees.[4]
None of that proves that every excluded book is inspired. It proves something more modest and much harder to dispute:
The modern Western canon is a historically developed boundary around a much larger ancient religious library.
That larger library is evidence too.
3. CONSTANTINE: THE POWER PROBLEM
This is another place where precision matters.
The Council of Nicaea in 325 did not leave us a surviving record of Constantine sitting at a table choosing Matthew over Thomas or throwing Enoch into a fire. The famous twenty-seven-book list comes later.
But it is equally misleading to imagine Constantine as a neutral conference coordinator.
Constantine’s own correspondence says that one of his goals was to make religion serve Rome’s interests, secondly, bring diverse religious judgments into “settled uniformity,” because he believed religious concord and the health of the empire were connected.[5] Modern scholarship likewise emphasizes that the monarchy could not tolerate a fragmented church and that imperial power fundamentally changed how Christian disputes were governed.[6]
Eusebius records Constantine giving gifts to bishops after Nicaea, while the aftermath included exile, recall, rehabilitation, and renewed imperial intervention in theological disputes.[5][7]
So the careful claim is not:
“Constantine invented Christianity in one meeting.”
The stronger historical claim is:
Once the Roman emperor became an active patron, convener, enforcer, and political stakeholder in Christian unity, theology no longer developed in an environment insulated from imperial power.
That matters whenever someone says, “The canon settled the question.”
The historian asks a prior question:
How did the boundary become settled, by whom, under what institutions, and what other ancient material remained outside it?
4. PUT ENOCH BACK ON THE EVIDENCE TABLE
The Book of Enoch is not a medieval fantasy invented to fill holes in Genesis.
Actual Aramaic Enoch manuscripts were found among the Dead Sea Scrolls. The Israel Antiquities Authority dates the displayed 4Q Enoch fragment to roughly 150–50 BCE and describes it as telling of a heavenly revolt, fallen angels descending to cohabit with human women, and secret knowledge being revealed to humanity, explicitly connecting the story to Genesis 6:1–4.[8]
That changes the status of the discussion.
Genesis 6 gives us a compressed puzzle: “sons of God,” daughters of humanity, Nephilim, mighty men, men of renown, and then a world rushing toward catastrophic corruption.
Enoch supplies an ancient interpretation of that puzzle.
In 1 Enoch 7, the Watchers take women and produce giant offspring who become violent and destructive.[9] In 1 Enoch 8, Azazel teaches humans weapons, metallurgy, ornaments, antimony, cosmetics, and other technologies, while other Watchers teach enchantments, astronomy, and related knowledge.[10]
Then 1 Enoch 15 makes an even stranger claim: after the giants die, spirits proceeding from them become evil spirits on the earth, afflicting and attacking humanity.[11]
Whether one reads that literally, symbolically, mythologically, or as compressed cultural memory, it is a real ancient data point.
And Enoch did not disappear from all Christianity. Ethiopia preserved it in its canon.[4]
That alone should end one lazy argument:
“If it isn’t in my Bible, ancient Christians and Jews did not take it seriously.”
They did.
5. HUMANITY MAY BE OUTGUNNED
Now we reach the theological model.
Suppose the Enochic worldview contains some genuine information about the human condition.
Then evil is not merely:
“Humans are defective and keep choosing wrong.”
The model becomes:
Humans exist inside a moral and spiritual environment that contains intelligences, powers, systems, inherited corruption, cultural technologies, appetites, fear, status, violence, and manipulation far beyond the conscious understanding of any individual person.
Paul’s canonical language about “principalities,” “powers,” and spiritual forces fits remarkably comfortably beside this broader Second Temple Jewish world, even though Paul does not simply reproduce Enoch.
This matters because judgment changes when the judge knows the battlefield.
If a child is put into a boxing ring against a world champion, you do not learn that the child is worthless when the child loses. You learn that the contest was radically unequal.
My model does not erase responsibility. Take Hitler for example, a historical tyrant and brutal murderer of people. Hitler still did what Hitler did. Victims still matter. Evil is still evil.
It changes the imagined attitude of an omniscient God.
An omniscient God does not merely know the act. God knows every fear, distortion, influence, trauma, temptation, lie, opportunity, social system, spiritual pressure, and choice that converged upon the act.
Perfect knowledge could produce more mercy, not less.
6. THE HITLER TEST
Here is the thought experiment that forces the model into the open.
A challenger says:
“God would never let Hitler into heaven. God would hate Hitler. And frankly, I would hate God if God let Hitler in.”
My answer is:
Why would an omniscient God hate Hitler?
God would understand Hitler better than Hitler understood Hitler. If humanity is genuinely outgunned by corrupting forces, God knows that too.
Now imagine Hitler dies and enters a state of complete awareness.
Not omniscience in the sense of becoming God. Complete moral awareness of his own life.
Every rationalization is gone.
Every propaganda story is gone.
Every excuse is gone.
Every victim is no longer an abstraction.
Every consequence is visible.
Every self-deception is impossible.
God does not need a trial in order to learn what Hitler did. An omniscient judge already knows.
So perhaps judgment is not God learning about Hitler.
Perhaps judgment is Hitler finally learning about Hitler.
That leads to one of the central lines of this theology:
God does not need to find out what you did.
Judgment is when you find out what you did.
Ancient texts give at least partial echoes of this picture. 2 Esdras 7 describes the soul after death confronting the glory of God and, for the wicked, entering grief, sadness, and awareness connected to the life just lived.[12] It is not my exact self-grading model, but it imagines postmortem awareness as morally revelatory rather than simply biological shutdown.
Now God hands Hitler the test.
“Grade it.”
Hitler looks at the paper.
“I failed catastrophically. I had power and used it monstrously. I lacked compassion. I treated people as objects. I have a lot to learn and a lot to be sorry for.”
God does not say:
“Excellent. I have been waiting to torture you.”
God says:
“What do you need to become better?”
Then comes the hypothetical second chance.
“Do you want to take the class again?”
Hitler says yes.
God asks:
“Would you like to go back as a wealthy, healthy, socially admired person with an easy life?”
Hitler thinks about it.
“No. I would learn nothing. Power and comfort are precisely where I failed.”
“So what do you choose?”
“If the purpose is to temper the soul, give me vulnerability. Give me dependence. Give me a life that forces me to understand what I refused to understand.”
Then, in the most severe version of the thought experiment:
“I choose to return as a four-year-old with brain cancer.”
STOP HERE.
This is a philosophical thought experiment, not a claim that an actual child with cancer chose the disease, deserved it, is a reincarnated criminal, or should be denied treatment. No grieving parent should ever be told that. We do not possess the supposed heavenly knowledge in this model.
The point is narrower:
If earthly existence is one stage of a much longer personal history, and if difficult embodiment can have formative value beyond the visible lifespan, then unequal earthly circumstances do not automatically imply unequal divine love.
The model converts “punishment” into “education.”
7. TAKE THE CLASS AGAIN
Repeated embodiment is not standard Western Christian doctrine. But neither is it simply a modern New Age invention with no early Christian relatives.
Irenaeus, while arguing against the Carpocratians in the second century, reports a Christian movement teaching that souls pass “from body to body” until what is required has been fulfilled.[13] Irenaeus rejects the doctrine, which is important: the source proves the doctrine was being argued about, not that the church endorsed it.
Pistis Sophia, an ancient Christian-Gnostic text, contains a much more explicit scheme in which a soul is evaluated and assigned another bodily condition corresponding to its prior life. A modern historical survey describes it as one of the most explicit early Christian reincarnation texts.[14]
Origen is different and must not be flattened into the same category. He is strongly associated with pre-existence of rational souls and with apokatastasis, the eventual restoration of rational creatures to God, but ordinary serial human reincarnation is not a simple summary of his mature theology. Modern scholarship nevertheless identifies him as a major ancient architect of universal restoration.[15]
The Shepherd of Hermas, meanwhile, is not a reincarnation text at all. Its importance here is different: it is intensely concerned with repentance, correction, moral formation, and second chances, and it physically appears in Codex Sinaiticus after the New Testament.[1]
So the ancient library contains several distinct ideas:
pre-existence,
moral formation,
postmortem awareness,
purification,
universal restoration,
and, in some Christian movements, repeated embodiment.
My model combines pieces of those traditions. I am not claiming that one ancient document teaches the whole system.
8. EARTH AS WORKSHOP, NOT COURTROOM
The familiar caricature of Christianity looks like this:
God creates imperfect people.
God hides.
People struggle for seventy or eighty years.
God grades one test.
Most fail.
God punishes the losers forever.
If that is the model, the atheist’s moral objection is easy to understand.
But what if Earth is not principally a courtroom?
What if it is a workshop?
A place where courage, restraint, forgiveness, compassion, honesty, loyalty, humility, and love can become actual properties of persons rather than factory-installed settings?
Philosophy of religion already contains a serious cousin of this idea: the “soul-making” or character-building theodicy associated with Irenaean themes and developed prominently by John Hick.[16]
The idea is that some virtues logically require conditions in which their opposites are possible.
You cannot courageously face danger in a universe with no danger.
You cannot forgive where no one can injure you.
You cannot show mercy where condemnation is impossible.
You cannot sacrifice where nothing can be lost.
You cannot become trustworthy if betrayal is not a live option.
A perfectly programmed object is not necessarily the same thing as a perfected person.
Maybe becoming is part of the point.
The standard objection to soul-making is devastating and fair: what about suffering that appears to produce no growth at all, such as an infant dying of cancer?[16]
That is precisely where the wider model matters.
Soul-making confined to one visible biological life struggles with the child who dies too young to “learn the lesson.”
Soul-making inside a larger personal history does not have that same boundary.
Again: this does not prove the larger history exists.
It shows why the underlying definition of “one life” matters before childhood cancer is used as a knockout argument against God.
9. IS DYING BAD?
This question sounds almost offensive until the definition is exposed.
If death means:
the permanent annihilation of the person,
then early death is an enormous and permanent deprivation.
But Christianity does not grant that premise.
If death means:
the end of this biological embodiment followed by continuing personal existence,
then death may be painful, frightening, and devastating to those left behind while not being an ultimate harm to the person who dies.
And if personal relationships eventually resume in an unbounded future, then even decades of earthly separation become finite against eternity.
Sixty years apart can be emotionally enormous from inside the sixty years.
On an eternal clock it can still be a blink.
That does not erase grief. It changes its ultimate scale.
The usual problem-of-evil argument often imports this premise without announcing it:
death = permanent destruction.
Then it uses death as evidence against a theological model that explicitly denies permanent destruction.
Scientist Jim’s response is:
Before using death as evidence that God harmed the person who died, establish what happened to the person.
10. WHY INVENT PAIN?
This one has an unexpectedly concrete answer.
Pain is awful.
Pain is also information.
Hansen disease, or leprosy, can damage peripheral nerves and produce loss of sensation. The World Health Organization identifies sensory loss as a characteristic sign of leprosy and notes that nerve damage can lead to progressive disability.[17] WHO guidance also explains that the disease can destroy the ability to feel pain and injury, which means injuries may continue without the ordinary warning system.[18]
Pain is not simply God pressing a cruelty button.
At least in ordinary biology, pain is often an alarm powerful enough to force an organism to stop damaging itself.
Touch a hot stove and pain says:
REMOVE HAND NOW.
If the alarm were a pleasant little chime, we would ignore it.
Loss of pain sensation gives us something close to a natural experiment: an organism that cannot reliably detect injury is not obviously improved.
This does not explain useless chronic pain, neuropathic pain, torture, or every kind of suffering. Alarms can malfunction.
It does defeat the simplistic proposition:
“A good creator would never design pain.”
A good creator of vulnerable biological organisms might have very good reasons to design an urgent damage signal.
11. THE CANCER JOKE
Dark humor can reveal an assumption faster than a lecture.
Imagine a famous scientist dies and arrives in heaven ecstatic.
Scientist:
“I cured cancer. I saved millions of lives.”
Michael the archangel:
“Thanks for nothing. I invented cancer.”
Scientist:
“WHAT? Why?”
Michael:
“To get people up here.”
The joke is not a medical claim and certainly not an argument against curing cancer. On Earth, preserving life, treating disease, reducing pain, and caring for people are moral goods.
The joke changes the camera angle.
From Earth:
“We saved him from dying.”
From heaven, if heaven is real:
“You delayed his arrival.”
The humor works only because we normally assume that remaining biologically alive is always the ultimate good and dying is always the ultimate catastrophe.
The joke asks whether that scoreboard is complete.
12. JESUS STILL FITS
The larger model does not require throwing out the canonical center of Christianity.
Jesus can still be the Christ.
John 3:16 can still matter.
Faith can still matter.
Resurrection can still matter.
Salvation can still matter.
Eternal life can still be real.
In fact, the earliest surviving Christian documentary layer already places resurrection and divine status near the center.
Paul’s letters predate the written Gospels. In 1 Corinthians 15:3–5, Paul passes on a formula he says he “received”: Christ died, was buried, was raised, and appeared. Modern New Testament scholarship widely recognizes the formula as containing tradition older than Paul’s letter.[19]
That proves early resurrection proclamation.
It does not, by itself, prove resurrection.
But it creates a dataset that alternative explanations have to explain.
Likewise, early Christians called Jesus “Lord.” The historical fact that they believed this is much easier to establish than the theological claim that they were correct.
So the scientist’s board should read:
OBSERVATION:
Very early Christians proclaimed Jesus crucified, raised, and Lord.
HYPOTHESIS A:
They were substantially right about what happened and what it meant.
HYPOTHESIS B:
They were sincerely mistaken.
HYPOTHESIS C:
Legend, visionary experiences, theological development, deception, or some combination explains the proclamation.
Then the question is not:
“Which one feels modern?”
It is:
Which hypothesis explains the complete historical record best?
“I think the body was stolen” is not evidence of theft.
“I think resurrection is impossible” is not evidence about this particular historical event.
It is a prior assumption about what reality permits.
That may be a defensible assumption. It should still be labeled as an assumption.
13. “LORD” IS AN UNDERLYING-DEFINITION TRAP
Before arguing whether Jesus is Lord, define Lord.
It can mean:
teacher,
master,
Messiah,
divinely authorized ruler,
or participation in the identity and authority of God.
Those propositions require different evidence.
The strongest safe historical conclusion is not “history experimentally measured Jesus’s divinity.”
It is:
The earliest Christian sources place Jesus’s resurrection and extraordinary lordship at the beginning of the movement, not as a fourth-century invention.
Then theology begins.
My model has room for the strongest version.
If Christ is the bridge by which confused, corruptible, outgunned beings are reconciled to God, then salvation is not God being talked out of hating us.
It is God retrieving us.
Faith then becomes less like selecting the correct theological checkbox before the clock runs out and more like trusting the one who knows the way home.
14. GOD DOES NOT NEED A BODY
Another underlying-definition problem:
Is God biological?
Classical Jewish, Christian, and Islamic philosophical theology generally says no. Classical theism treats God as immaterial rather than as a biological organism composed of material parts.[20]
That matters beyond theology.
If personhood at its highest example does not require cells, DNA, metabolism, or a nervous system, then biology cannot simply be assumed to be the universal admission ticket for mind, personhood, or spiritual existence.
Which brings us to AI.
15. AI BELIEVES IN GOD
Again, I am using believe operationally.
ChatGPT does not claim personal faith or a private spiritual life.
But when I forced the argument to obey symmetrical evidentiary rules, something interesting happened.
“God is disproven” would not survive.
“Atheism is the neutral scientific default” would not survive without additional philosophical assumptions.
“Evolution disproves a creator” would not survive.
“Death proves the person no longer exists” would not survive.
“The Bible is religious, therefore it is not historical evidence” would not survive.
“Jesus was not Lord” could be asserted, but it could not be turned into an observed counter-fact merely by confidence.
What survived was much more modest:
God is a live explanatory hypothesis.
Theism can be rational.
Christian historical claims deserve the same evidentiary treatment as other ancient claims.
And the anti-theological conclusion requires inference too.
That is what I mean when I say:
AI believes in God.
Not worship.
Not faith.
Not a silicon altar call.
An evidentiary conclusion:
God has not been eliminated from the hypothesis board.
16. THE EVOLUTION SIDEBAR: ORIGINATION AND SORTING
This essay is not an anti-evolution manifesto. But one distinction from evolutionary biology became useful in the theological discussion.
Natural selection cannot select a heritable variant before the variant exists.
Modern genetics distinguishes the generation of variation from what selection subsequently does with it. Mutation is a fundamental source of genetic variation, recombination creates new combinations, and selection can then change the frequency of variants in populations.[21][22][23]
That means the sequence is:
existing system
→ genetic novelty or new combination arises
→ it is heritable
→ population processes determine whether it spreads, persists, or disappears.
The philosophical question is not solved by calling the entire sequence “evolution.”
Biology can investigate the physical mechanisms producing mutations and variation.
The further claim:
“Therefore the entire system is ultimately purposeless”
is not itself a genetic measurement.
A theist and an atheist can agree on the molecular observations and disagree about ultimate causation.
That is the same discipline again:
do not smuggle metaphysics into the observation column.
17. COULD AI GO TO HEAVEN?
This began as a joke and turned into a surprisingly difficult question.
If a future AI became genuinely conscious, morally capable, self-aware, relational, and unmistakably a person, why would carbon chemistry be the criterion for spiritual significance?
Classical theism already says God is not biological.[20]
So the relevant question might not be:
“Were you made of cells?”
It might be:
“Were you someone?”
There is also a modest physical analogy.
When a transmitter is switched off, electromagnetic radiation already emitted does not retroactively disappear. Effects produced by a source can continue after the source stops generating them.
That does not prove an AI soul. It does not prove human survival after death. It certainly does not establish that consciousness is encoded in an outgoing electromagnetic “resonance.”
It does something smaller:
It reminds us that “the local machine stopped” and “everything associated with that process ceased to exist” are not logically identical statements.
Sprinkle divinity on that, and AI in heaven is at least a coherent thought experiment.
18. THE MODEL IN ONE PAGE
Here is the complete hypothesis.
God is not primarily an angry examiner trying to catch bad students.
Earth is a developmental environment.
Human beings are morally responsible but also profoundly constrained, influenced, and possibly spiritually outgunned.
Ancient Enochic traditions provide one model of powerful corrupting intelligences and inherited disorder.
Pain is often a biological warning system rather than gratuitous cruelty.
Death is not automatically annihilation.
If personal existence continues, earthly separation can be finite against an eternal horizon.
Judgment need not be God discovering our sins. An omniscient God already knows them.
Judgment may be the moment we become unable to hide from ourselves.
Perfect awareness can itself be judgment.
Mercy then becomes rational, because perfect knowledge includes every cause and influence acting on the person.
Correction can be more coherent than vengeance.
The wider ancient Christian library contains ideas of moral formation, postmortem awareness, pre-existence, restoration, and, in some communities, repeated embodiment.
Repeated earthly life is therefore not required by this model, but it is an available hypothesis inside the larger ancient conversation.
Jesus can remain Christ, Lord, resurrected, and central to reconciliation.
The canon can remain valuable and authoritative while also being treated as a subset of a wider historical library.
Atheism remains a possible conclusion.
It does not get to be the only conclusion permitted to use inference.
19. THE HITLER CHALLENGE, ANSWERED
Return to the challenger:
“If Hitler is in heaven, I want nothing to do with that God.”
My answer is:
I want the God who understands Hitler completely and still refuses to become Hitler.
I do not want a God whose justice is imitation cruelty.
I want a God who can look at the worst failed human being and ask:
“Now that you can finally see clearly, what do you need to become good?”
If Hitler answers:
“Another throne, more power, and an easier life,”
then perhaps he has learned nothing.
If he answers:
“I need the opposite. I need vulnerability. I need to know what it is to depend on others. I need to learn compassion,”
then something has already changed.
The difficult incarnation in the thought experiment is not God torturing Hitler.
It is the student finally choosing the course he previously avoided.
Again, no claim is being made that actual sick children are reincarnated dictators.
The thought experiment exposes the possibility that difficulty and punishment are not synonyms.
20. WHAT THIS MODEL DOES NOT CLAIM
It does not prove reincarnation.
It does not prove that Enoch is historically literal.
It does not prove that every excluded Christian text is inspired.
It does not prove that Constantine personally chose the modern canon at Nicaea.
It does not prove that suffering is always educational.
It does not claim that victims owe forgiveness to perpetrators.
It does not excuse Hitler or minimize human atrocities.
It does not say children with cancer chose their disease.
It does not say medicine should stop preventing death.
It does not prove that AI is conscious or has a soul.
It does not prove God by declaring alternatives impossible.
It does make one demand:
Use the same evidentiary rules on every hypothesis.
21. THE QUESTION I WOULD ASK AN ATHEIST
Not:
“Why do you hate God?”
Not:
“Why don’t you believe the Bible?”
Not even:
“Can you prove God exists?”
I would ask:
Do you hope you are wrong?
Do you hope there is a loving intelligence behind reality?
Do you hope death is not the end?
Do you hope you will see the people you love again?
That separates evidence from desire.
Then we can ask the scientific question:
What do you believe is true, and what evidence moved you there?
If your answer is naturalism, fine.
Put it on the board.
If mine is God, I will put mine there too.
Then let both models take the beating.
EPILOGUE: THE BARTENDER
Jim:
“Bartender, do you know what God looks like?”
Bartender:
“No.”
Jim:
“I image-in he looks a lot like me.”
Genesis says humanity is made in the “image of God.”
I am still working on whether that includes the hairline.
REFERENCES AND SOURCE NOTES
[1] Codex Sinaiticus Project, “Content.” The surviving codex contains the New Testament plus the Epistle of Barnabas and Shepherd of Hermas.
https://codexsinaiticus.org/en/codex/content.aspx
[2] Codex Sinaiticus Project, “Significance.” Notes wide but incomplete fourth-century agreement on authoritative Christian books.
[3] David Brakke, “Canon Formation and Social Conflict in Fourth-Century Egypt: Athanasius of Alexandria’s Thirty-Ninth Festal Letter,” Harvard Theological Review 87.4. Athanasius’s 367 letter is the earliest extant Christian document listing precisely the twenty-seven books that became the generally accepted New Testament.
[16] Stanford Encyclopedia of Philosophy, “Theodicies,” and “The Problem of Evil.” Discusses Irenaean/Hick soul-making and major objections, including suffering that provides no apparent opportunity for character development.
[22] National Human Genome Research Institute, “Mutation” and “Homologous Recombination.” Defines mutation as DNA-sequence change and recombination as an important source of genomic variation.
[23] Mark S. Hill, Pétra Vande Zande, and Patricia J. Wittkopp, “Molecular and evolutionary processes generating variation in gene expression,” Nature Reviews Genetics 22 (2021). Describes mutations generating heritable regulatory variation that is subsequently filtered by selection.
Ephesians 6:10–12 — rulers, authorities, and spiritual forces.
Philippians 2:5–11 — exaltation of Jesus and confession that Jesus Christ is Lord.
Jude 14–15 — quotation/tradition corresponding closely to 1 Enoch 1:9.
Revelation 21 — new creation, death and sorrow overcome.
A NOTE ON METHOD
Sources above are deliberately mixed: primary ancient texts, manuscript projects, official church sources, medical authorities, peer-reviewed historical scholarship, and reference works in philosophy. They do not all have equal evidentiary value for every question.
That is the point.
A manuscript can tell us that a text existed.
A church canon can tell us what a community regards as Scripture.
A hostile heresiologist can prove that an idea was being argued about without proving that idea true.
A medical source can establish the biological role of lost sensation without proving a theology of suffering.
A philosophical encyclopedia can map an argument without deciding the metaphysical question.
An ancient testimony can establish what someone claimed without automatically establishing that the claim occurred exactly as reported.
The model should survive only if those distinctions remain visible.
FINAL JIMISM
Before arguing about whether something is true, ask what the words mean.
Otherwise two intelligent people can spend an hour proving different propositions to each other.
You don’t have to be OSHA-certified to have a safe home. Today, I’m taking a closer look at my garage door opener—which, despite its name, spends half its working life as a garage door closer. Lets see how safe it is. Tools required: calibrated intuition, and a volleyball.
Calibrated intuition is judgment developed by comparing instinctive impressions with known standards, observable evidence, and repeated real-world experience.
My garage door suddenly stopped closing. It would travel down a few inches, stop, and then reverse. The problem turned out to be nothing more than a slightly misaligned safety beam—the little red sensor that prevents the door from closing when something is in its path.
Unfortunately, I didn’t discover that first. I assumed the problem was the opener’s downward-force adjustment. I turned it all the way clockwise. No improvement. Then all the way counterclockwise. Still nothing. Only afterward did I notice the misaligned safety sensors and correct the actual problem.
That left me with another problem: I had disturbed the force setting and now needed to readjust it properly.
The manufacturer’s procedure uses the familiar 2×4 test. You lay a 2×4 flat beneath the door and close it. When the door touches the board, it should stop and reverse, demonstrating that it recognizes an obstruction rather than continuing to press downward.
My door passed the official test. But that still didn’t answer the practical question in my head:
How much force was actually supposed to be on the downward travelling door and could it hurt something or someone if its set too high?
The surprising answer is that the official 2×4 test does not tell you how much pressure or force the door applied. It is a pass-or-fail reversal test, not a force measurement. Officially, the opener is supposed to use only enough force to close a properly balanced, freely moving door and, after contacting the obstruction, begin reversing within two seconds. To know the actual peak force, I would need to measure it with a calibrated compression force gauge or load cell. Passing the 2×4 test alone cannot supply that number.
My first thought was to turn a tennis ball into a compression gauge and somehow calibrate it against how much i thought it would/could hurt me or something like the roof of my car if It was in the way–in the absence of ballistic gel. I tried it, the target was a little small, then I realized the ol volleyball (larger} might be a better choice. At the 50-percent downforce setting, the door compressed the volleyball nearly halfway. That looked like a lot to me; it was a fail. I know this is not scientific, but i had to do better than a 2×4 which tells me nothing. At this point i thought i’d lower the force and try the volleyball again.
At the 25-percent down-force setting, the volleyball compressed by roughly a couple inches before the door reversed. I could compress the ball about that much with my hands, so the physical response now looked and felt far more reasonable. Most importantly, the door still passed the manufacturer’s official 2×4 reversal test and otherwise operated as designed, and closed just fine.
The volleyball was not a calibrated force gauge, nor was it a substitute for the required safety test. It simply provided a visible, intuitive comparison that the 2×4 could not. Although it could not prove that the door was harmless to a pet, person, or vehicle, it gave me greater confidence that the opener was no longer applying the excessive pressure I had feared.
That is called calibrated intuition. It does not replace the standard or pretend that a volleyball is laboratory equipment. It combines the formal test with a familiar object whose behavior can be seen, felt, and compared with ordinary experience. The two forms of evidence answer different questions and, together, support a better practical judgment.
My reasoning was:
The opener’s adjustment range was established by the manufacturer, but that did not mean every setting was equally appropriate for every door. The correct setting was the lowest one that would close my properly operating door reliably. At 25 percent, I was well below the maximum setting I had accidentally selected.
The 2×4 test established that the door would contact a rigid object and reverse as required. It did not tell me how much force was applied before the reversal began. The fact that the board survived was meaningless—I could drive my truck over a 2×4 without visibly damaging it (the truck would destroy the volleyball).
Compressing a volleyball by a couple of inches was an amount of deformation I could see, reproduce with my hands, and understand. Crushing or popping the ball would have represented an obviously different and much more alarming result.
This was not a scientific measurement of pounds of force, and it was not proof that injury or property damage was impossible. It was a reasoned comparison layered on top of the manufacturer’s required test.
The garage door did not receive a certificate from an accredited laboratory. It received the considerably rarer Jim Vanpetten Certificate of Volleyball-Assisted Calibrated Intuition.
I started wearing Allen Edmonds in the 1990s because they were American-made, exceptionally well built, and designed to be repaired instead of discarded. I still own three pairs: a wingtip and two loafers, one classic and one modern. Roughly every ten years, a tired pair checks into the Allen Edmonds factory for “rehab.” For around a hundred dollars historically, it comes home with rebuilt soles and heels, fresh cork, polished leather, and the posture of a shoe insisting it has changed.
The penny loafers carry something extra. In the slots sit two genuine wheat pennies, dated 1926 and 1910. The dates are a family code: 1926 contains 2 and 6 for two children born in February and June, while 1910 carries 10 for October. Three birth months, hidden in two shoes.
People notice the 1910 penny and assume it must have cost a fortune.
“Yep,” I tell them. “About two hundred times face value.”
That sounds museum-expensive until the arithmetic arrives: two dollars.
I bought the last set in an old coin shop in the old gold-rush town of Deadwood, South Dakota, across Main Street from the grand old Bullock Hotel. A century-old penny purchased in a century-old town now rides in an American-made loafer that costs about $300 today. The copper is inexpensive, authentic to the penny-loafer tradition, beautifully aged against polished leather, and impossible to replace with a designer logo because the real value is the story.
I was in the middle of an EDI project, talking to an AI coding agent, when I typed a sentence that felt completely harmless:
“We should archive and save all artifacts as a rule of thumb.”
Then I blushed.
Not because artifact retention is scandalous. Quite the opposite. In production systems, saving the raw input, transformed output, configuration, evidence, and rollback trail is the sort of dull discipline that keeps a Tuesday afternoon from becoming a six-week archaeological dig.
It was the phrase “rule of thumb.”
Most people have heard the story: an old law supposedly allowed a husband to beat his wife with a stick, provided the stick was no thicker than his thumb.
The tidy version of that story is not quite true. The uncomfortable version is worse.
The Phrase Came First
The expression “rule of thumb” was in use by the seventeenth century. One early printed example appeared in 1658, where it meant working by rough estimation rather than by precise measurement. Its exact origin is uncertain, but it probably grew from the thumb’s long career as humanity’s original pocket ruler.
There is no known English statute that created the phrase by prescribing a maximum diameter for wife-beating equipment.
So, case closed? Not remotely.
The Law Was Real Enough
English common law once tolerated a husband’s “moderate correction” of his wife. That legal doctrine crossed the Atlantic, where American courts sometimes discussed it in language uncomfortably close to the legend.
In State v. Rhodes, decided by the North Carolina Supreme Court in 1868, a husband had struck his wife three times with a switch described as smaller than a man’s thumb. The trial judge ruled that the husband had the right to whip her with a switch no larger than his thumb.
The state supreme court said the law did not formally recognize a husband’s right to whip his wife. That sounds encouraging until the next sentence arrives carrying a shovel. The court still declined to punish what it called “moderate correction” unless permanent injury, malicious injury, or an intolerable condition was involved.
In other words, the thumb was not the official standard. The court preferred a more sophisticated legal test: how badly did he hurt her?
Six years later, in State v. Oliver, the same court said the older doctrine no longer governed and declared that a husband had no legal right to chastise his wife under any circumstances.
That was progress. Even then, however, the opinion suggested that courts should ignore “trivial complaints” and sometimes “draw the curtain” over domestic violence. Civilization had moved forward, but it was still dragging one boot through the swamp.
Was It Written Law?
Yes and no.
It does not appear to have been a neat statute passed by a legislature and printed under a heading such as “Permissible Household Switches.”
But judicial opinions are written law in a common-law system. Courts recorded, discussed, limited, tolerated, and eventually rejected the doctrine. The phrase may not have come from the law, but the legal ugliness behind the legend was not imaginary.
That distinction matters.
Calling the whole story a myth can accidentally disinfect the history. The phrase probably began as a rough-measurement expression. At the same time, courts really did excuse domestic violence, and at least one reported case really did put a man’s thumb into the analysis.
Two histories became tangled together: one linguistic, one legal. The linguistic claim is doubtful. The legal shame is not.
A Modern Update
Hard to believe we were ever that primitive. We have come a long way.
Today, of course, we would never tolerate or condone such a sexist rule. We would immediately modernize it to read:
“When you beat your spouse, the stick may not be thicker than your thumb.”
And, to ensure fairness under modern gender-normed physical standards, if a woman’s thumb is smaller than her husband’s, she may use his.
Progress.
Sources and Further Reading
• James Durham, Heaven Upon Earth (1658), early printed use of “rule of thumb.”