Chapter 14 — The Honesty Question

“You shall not bear false witness against your neighbor.” — Exodus 20:16

“We should fear and love God so that we do not tell lies about our neighbor, betray him, or give him a bad name, but defend him, speak well of him, and put the best construction on everything.” — Martin Luther, Small Catechism, on the Eighth Commandment

Why This Matters

You are six weeks into Phase 2. You have prompted, reviewed, and corrected a fast junior partner who works for free, doesn’t sleep, and occasionally lies to you with a straight face. You have shipped four projects that the AI helped write. By the time you turn in Project 14 — the capstone, two weeks from now — that number will be five.

A question that students start asking around this point in the course, sometimes out loud and sometimes only to themselves, is:

Did I really do this?

It is a good question. It is the right question. It is the question this chapter exists to answer.

There are dishonest answers available. “Of course I did it — I wrote the prompts” (true but insufficient). “Well, the AI did most of it, so not really” (false but humble). “Authorship doesn’t matter anymore” (a refusal to ask the question at all). The honest answer is more carefully shaped than any of those, and most of this chapter is about getting it right.

This is the only chapter in either Coding 1 or Coding 2 that does not introduce a major new technical skill. There is no new API, no new pattern, no new project. The work of this chapter is reasoning carefully about what you have done, what part of it was honestly yours, and what you can stand behind when someone — a professor, a future employer, a future coworker, the person sitting next to you — asks the question directly.

The Christian student has one advantage and one extra burden here. The advantage: the Christian tradition has thought hard about lying, false witness, and stewardship for two thousand years, and there is real wisdom to draw on. The extra burden: that wisdom is binding on you in a way it isn’t binding on the secular student next to you. The Eighth Commandment is not a polite suggestion to be sincere. It is a command. And it is the most relevant commandment of the ten for the work we are doing this week.

There is no project this week. There are reps. They are mostly reflective. Take them seriously. The semester ends in two weeks; the question of what is honestly yours doesn’t.

14.1 — Three Honest Things You Can Say

The most useful place to start is with the three statements that, in our work, are almost always honestly available to you. Memorize them. They will get you through job interviews, classroom conversations, code review meetings, and the inside of your own head.

Statement 1: “I wrote the spec.”

This is the architectural honesty. You decided what the program should do. You wrote the contract. You chose the inputs, the outputs, the error cases. You made the decisions that determine whether the program is the right program at all — questions the AI cannot answer because the AI does not know what you are trying to accomplish.

If you wrote the spec, this statement is honest. It is the most senior-engineering statement in your vocabulary, and it is also the one most students undervalue.

Statement 2: “I directed the AI.”

You wrote the prompts. You read the responses. You accepted some and rejected others. You caught the bugs the AI introduced. You decided when to iterate, when to start over, when to take the keyboard. You held the system together while the AI typed individual methods.

This is the senior/junior model from Chapter 9. If you really did this — and you can prove it with a prompts log — the statement is honest.

Statement 3: “I tested it.”

You wrote the tests. You ran them. You confirmed the program does what the spec says. The thing that landed in the grader’s inbox is verified, not just typed. The AI’s contribution is checked against an artifact you created.

If you wrote test-first (Chapter 4) and the tests are yours, this statement is honest.

Those three statements, together, describe most of what a senior engineer actually does. None of them require you to have personally typed every character of the final code. All three of them are exactly the work AI cannot do for you.

If you can honestly say all three about a project, you wrote the project. The AI helped. The author is you.

Coach’s Note — A useful test: imagine yourself in a job interview a year from now, with the project open in front of you, and the interviewer asks “walk me through this.” If you can talk for ten minutes about every architectural decision, every test you wrote, every place you redirected the AI, and every bug you caught — you wrote it. If you stammer because you’ve never read your own submission carefully — you didn’t, and pretending you did would be the lie.

14.2 — When AI Helps, What Belongs Where

There is a difference between honesty and exhaustive disclosure. They are not the same thing. Carpentry-school students do not file a separate cover sheet for every nail they used. Pianists do not announce, before each recital, which of their teachers taught them which fingering. The expectation is not that you list every external influence; the expectation is that you do not lie about what you contributed.

Apply the same standard to AI.

What you must always disclose

• Where the rules require it. If your professor’s syllabus says “log every AI prompt,” log every prompt. If a contest’s rules forbid AI, do not use AI. If an academic honesty policy says “attribute AI-generated content,” attribute it.
• When someone directly asks. “Did you use AI on this?” gets a direct answer.
• When the work would be misread without the disclosure. Submitting AI-generated code in a context where the reader will assume you typed every line yourself — without correcting that assumption — is dishonest by omission.

What does not require a flag

• The fact that you used an IDE.
• The fact that you Googled “java string format syntax” three times.
• The fact that you copied the bones of a public static void main signature from a previous project.
• The fact that your AI assistant autocompleted variable names as you typed them, exactly the same way the IDE’s built-in autocomplete does.
• The fact that you asked the AI to explain a Javadoc you didn’t understand. That’s reading, not writing.

The boundary is fuzzy. The principle is sharp: the question is not “did a tool touch this,” but “would my reader form a wrong impression of my contribution if I didn’t say something?” A reader who assumes a programmer used an IDE in 2026 is not forming a wrong impression; you don’t need to flag it. A reader who assumes you personally invented the algorithm in a method that the AI wrote whole-cloth is forming a wrong impression — that one needs a flag.

Coach’s Note — A simple working rule: when in doubt, add the disclosure. The cost of one extra line in a comment block is essentially zero. The cost of being caught omitting it later is your reputation. Asymmetric tradeoff, always default toward disclosure.

14.3 — Senior as Author: The Architect Who Doesn’t Lay Bricks

The closest pre-AI analogue to senior-engineer-with-AI-assistance is the architect of a building.

An architect draws the building. The architect specifies the load-bearing walls, the room layout, the materials. The architect does not personally lay a single brick. A team of masons lays the bricks; a team of electricians runs the wiring; a team of carpenters builds the framing. The building gets built. When the building is finished, it is the architect’s building.

This is not a polite fiction. It is the accurate description. The architect made the building be the building it is. The masons made it stand up. The masons and the architect both worked; both are necessary; both deserve credit for what they did. But when we ask “who designed this building?” — the answer is the architect’s name, and nobody thinks the architect is dishonestly taking credit for the masons’ labor by saying so.

The senior engineer working with AI is in the architect’s position. You decide what the system is. You decide its shape. You decide what each module does. You decide what counts as correct behavior. The AI lays bricks for you — fast, mostly accurate, occasionally wrong, requiring inspection. The building is yours.

This analogy has limits. The architect’s masons are humans with their own agency, training, and rights; the AI is a tool. The architect’s masons get paid; the AI does not. The architect is held legally responsible for the building’s integrity in ways the AI’s deployer is not (yet) held responsible for the code’s correctness. The analogy is not perfect.

But it is closer to the truth than either of the two failure modes students fall into:

Failure mode 1: “If I didn’t type it, I didn’t write it.” This is the brick-layer’s view of authorship — only the hands count. It is false. Authorship of a system is not reducible to typing. If it were, transcriptionists would be authors.

Failure mode 2: “I told the AI what to do, so it’s all mine.” This is the architect-who-overstates-their-role view. The masons did real work. So does the AI. Saying “AI was involved” when it was involved is just accuracy.

The honest middle: you are the author, the AI was a tool, the tool did real work, and saying so is the truth.

Coach’s Note — When you start your first job and someone asks “how do you use AI in your workflow?” — this is the framing you want to come from. “I direct it like a junior engineer. I’m the architect; it’s part of the construction crew.” That answer is honest. It is also exactly the answer that gets senior engineers hired, because it signals you understand the actual division of labor.

14.4 — Specific Scenarios

Abstract principles only get you so far. Here are the specific scenarios you will face this year and next, with the honest answer for each.

Scenario A: Submitting a school assignment that used AI

The question: Can you submit it without flagging the AI?

Default answer: Only if your professor’s policy explicitly allows undisclosed AI use. Otherwise, always attribute. In this course, every Phase 2 project requires a prompts.txt log; the rule is already explicit.

The honest move: Include a clear comment block at the top of your main file. Name the assistant. Note which methods it generated. Note what you wrote by hand. Note where you reviewed and accepted. The reflection in P14 is literally a graded component of this honesty.

Scenario B: A job interview asks “did you write this?”

The question: A recruiter or interviewer looks at a personal project on your GitHub and asks the question directly.

Honest answer: “I designed it and directed the implementation. I used an AI assistant for the routine method bodies — about 30% of the code by line count. Every line I shipped, I read, tested, and signed off on. I can walk you through any of it.”

This answer is honest. It is also the answer the interviewer wants to hear, because it signals exactly the kind of judgment they’re trying to assess. The interviewer is not asking “did you type every character?” — they are asking “do you know what’s in this code and can you stand behind it?” Those are the questions you can honestly answer yes to, if you actually did the senior work the chapter is describing.

The dishonest version of the answer — “I wrote every line myself” — has two failure modes. First, it’s false. Second, the interviewer can usually tell within ninety seconds, because the project’s style won’t match how you talk about it under cross-examination. The lie is detected by the same pattern recognition that lets you spot AI-generated code in P11. Don’t lie. The truth is better, and the truth is also what the interviewer is hoping to hear.

Scenario C: A teammate’s code that you suspect is unattributed AI

The question: What do you do?

Honest move: First, don’t accuse. Suspecting isn’t evidence. Ask, directly, conversationally: “Hey, did you use an AI to help with this? I’m trying to figure out the best way to review it.” The framing — review-related, not accusatory — usually gets a true answer.

If they say yes, the review proceeds normally; AI-assisted code needs the same review as any other code, just with extra alertness for the Chapter 11 failure modes.

If they say no but you remain suspicious, the right next move is to do a careful review and surface concrete issues. “I noticed three places where the variable naming is inconsistent with the rest of our codebase — let’s talk about those.” You’re not accusing; you’re reviewing. If the issues are real, they need to be fixed regardless of provenance.

The wrong move: stewing privately, going to a manager with vague suspicions, or holding it against your teammate without ever raising it. Luther on the Eighth Commandment: “defend him, speak well of him, and put the best construction on everything.” That doesn’t mean ignoring real problems. It means raising them as problems to solve, not as accusations to escalate.

Scenario D: An open-source contribution

The question: You want to contribute a PR to a public project. You used AI for parts of it.

Honest move: Most major open-source projects now have an explicit policy. Read it. Some require disclosure; some prohibit AI-generated content entirely (often for licensing reasons, since AI-generated code’s copyright status is currently unsettled). Follow the rules.

If the project allows AI but you used it heavily, mention it in the PR description: “Used AI assistant for the bulk of the unit test scaffolding; designed and reviewed the production code myself.” Brevity is fine. Transparency is non-negotiable.

Scenario E: You’re tutoring a younger student

The question: They ask you for help on their homework. You’re tempted to just paste their problem into an AI and read them the answer.

Honest move: Don’t. The damage isn’t to the homework grade; the damage is to the student. They didn’t come to you for an answer; they came to you for the experience of working through it. Channeling them straight to an AI deprives them of the rep that builds the skill. Sit with them. Read the chapter together. Let them type. That is the loving thing as well as the academically honest thing.

This scenario is the one that most directly tests whether you’ve absorbed the course’s thesis. The reps are the point. AI can shortcut the output; nothing can shortcut the formation. The friend who shortcuts your formation is not actually doing you a favor. Don’t be that friend, and don’t accept it from one either.

Coach’s Note — The hardest of the five scenarios for most students is Scenario E. You will be asked. You will be tempted. The honest answer requires you to put your friend’s long-term skill ahead of their short-term grade. That is what being a good neighbor — and a good engineer — actually looks like. Practice it now, in low-stakes settings, so it’s already a habit when the stakes are higher.

14.5 — The Eighth Commandment, Applied

The Eighth Commandment is you shall not bear false witness against your neighbor. The straightforward reading is “don’t lie about other people,” and it is the right reading. But the Lutheran confessional tradition, following Luther’s Small Catechism, reads it more broadly: don’t lie in ways that affect your neighbor’s reputation, your own reputation, or the truth of the matter at hand.

Luther’s explanation, in full: “We should fear and love God so that we do not tell lies about our neighbor, betray him, or give him a bad name, but defend him, speak well of him, and put the best construction on everything.”

There is a positive command and a negative command. The negative: don’t lie, betray, or smear. The positive: defend him, speak well of him, put the best construction on everything. This is asking more than the absence of false statements. It is asking for the active practice of fair representation.

For us, that has three direct implications.

First, don’t misrepresent your own work. Bearing false witness includes bearing false witness about yourself. Claiming credit for what you didn’t do is the same kind of dishonesty as denying credit to someone who did. If you submit AI-assisted work as if it were entirely yours, you are bearing false witness — against the AI’s role (a small thing), against your own honest abilities (a bigger thing), and against your reader’s ability to form an accurate judgment (a serious thing). The reader is your neighbor. The lie is to them.

Second, don’t misrepresent your neighbor’s work. A classmate who used AI heavily and disclosed it has done nothing wrong; a classmate who didn’t disclose has done wrong. Both deserve fair construction. The first deserves the credit they’re due — full credit for the senior-engineering work that AI doesn’t replace. The second deserves the chance to address the omission honestly before being treated as a cheater. The rush to judgment is itself a kind of false witness.

Third, defend, speak well of, put the best construction on. This is the hardest part, and the most important for the AI question. The honest defense of AI-assisted work — yours or someone else’s — is that the work is real, the senior engineering is real, the architecture is real, the review is real. The dishonest defense is “the AI did everything but it’s fine because I’m enrolled in this class.” Defending real work honestly is the duty; defending dishonest work dishonestly is sin.

The Eighth Commandment, properly understood, is not a barrier to using AI. It is a standard for how to use AI: honestly, with disclosure where disclosure is owed, with credit where credit is owed (including credit to yourself), and with the active practice of representing the work — yours and others’ — accurately.

Coach’s Note — I want to be precise about what is and is not sin here. Using AI is not sin. Failing to disclose where disclosure is owed is sin. Misrepresenting your own contribution is sin. Submitting under a policy you knew forbade AI is sin. Using AI honestly within a policy that allows it is just work. The commandment does not forbid the tool; the commandment governs the truthfulness with which the tool is used.

14.6 — Vocation: The Image of God and the Use of Tools

There is a deeper theological frame underneath the practical question. Briefly — because this chapter is not a theology lecture, but the frame matters.

The LCMS Lutheran tradition (and the broader Christian tradition) holds two things together:

1. The human being is made in the image of God. Genesis 1:26-27. This is the foundational claim about human dignity, human creativity, and human worth. Human beings make things — including artifacts of intellect, like code — and that making participates, in a small way, in God’s own creative activity. Bach made cantatas. Bunyan made an allegory. You make small Java programs. The scale differs; the kind of activity does not.

2. Human beings have always used tools. Tubal-Cain in Genesis 4 forged instruments of bronze and iron. Bezalel in Exodus 31 was filled with the Spirit of God for craftsmanship — for the skilled use of tools to build the tabernacle. The Christian tradition has never held that tool use is opposed to image-bearing. Tools amplify the image-bearer; they do not replace the image-bearer.

AI is a tool. A new one, an unusual one, one that touches the work in ways our older tools did not. But still a tool. The question is not whether the image-bearer may use the tool. The question is how the image-bearer is shaped by the using.

This is the older question of vocation, in a new register. Your vocation is what you are called to do — the work that uses your gifts in service of your neighbor. A working programmer’s vocation is to build software that serves real people for real purposes. If AI helps you serve them better — faster, with fewer bugs, with more capacity for the parts of the work that require human judgment — then AI is serving your vocation. If AI replaces the judgment, the spec-writing, the review, the architectural decisions — the parts of the work that are the human creative contribution — then you have outsourced the vocation itself, which is a different and worse outcome.

The diagnostic question: after a project with AI, do you understand more, or less, than you would have without AI? If more — you used it well. If less — you used it as a substitute for thinking, and you’ve done a small disservice to yourself and a larger one to your future neighbor.

Coach’s Note — A student who used AI to skip every hard rep in Phase 1 graduates Coding 2 with a credential and without the skill. A student who used AI as a partner after doing the reps graduates with both. The difference is invisible on the transcript and obvious in the work. You will see it in your own first job. So will everyone around you.

14.7 — A Concrete Standard for This Course

To make all of this operational, here is the standard this course holds you to. It is not the only honest standard available; it is the one this course uses, with reasoning.

1. Phase 1 was AI-off. You built foundational skills without the tool. This was not a moralism; it was a calibration exercise. If you ever shipped a Phase 1 project with AI help — and you did not say so in the reflection — that was dishonest, and your skill diagnosis is now wrong. You should privately fix that diagnosis before the final by repeating a Phase 1 project without AI.

2. Phase 2 is AI-on with full disclosure. Every project has a prompts.txt. The grader reads it. Submitting without one, or submitting one that omits prompts you actually sent, is dishonest.

3. The midterm was AI-off; the final is AI-on. Both are open-book. The final’s AI-on rule exists because you have spent eight weeks learning to use AI responsibly. If you cannot honestly use AI under exam conditions — meaning the AI is helping you implement what you specified, not making the architectural decisions for you — you do not pass the final by reaching the same score, you pass it by reaching that score honestly.

4. The reflection.docx in P14 is graded. It is not a formality. The grader is checking whether your reflection accurately describes what the AI did and what you did. A reflection that overstates your role or understates the AI’s role is dishonest. A reflection that understates your role and overstates the AI’s role (the imposter-syndrome version of dishonesty) is also wrong, in a different direction. The reflection must be accurate.

5. The honor code applies, in this course, to the prompts log. A falsified prompts log is the same level of academic integrity violation as a falsified set of test results, which is the same level as plagiarism. The course treats it that way.

That is the standard. It is simple, it is enforceable, and it is honest.

14.8 — What Happens When the Norms Catch Up

Right now, in 2026, the norms around AI-assisted code are still being negotiated. Different professors have different rules. Different employers have different rules. Different open-source projects have different rules. Some of those rules will turn out, in retrospect, to have been too strict. Some will turn out to have been too loose.

You are not responsible for getting the norms right at the field-wide level. You are responsible for following the norms that apply to you — honestly, fully, without parsing them in self-serving ways.

Five years from now, the rules will be much clearer. The most likely shape, based on how every previous wave of automation in software has played out:

• Disclosure will be the default. Major employers and major open-source projects will require it. The rare cases of “AI use undisclosed” will be looked at the way “code copied without attribution” is looked at today.
• Senior-engineer skills will be valued more, not less. The students who can do the work this course has been teaching — read, spec, test, debug, persist, direct, review — will be sought after. The students who can only “ask the AI and paste” will not.
• A small but real subset of professional contexts will keep AI off entirely. Security-critical code, safety-critical code, code subject to particular licensing constraints. Those careers will reward the same skills the course teaches plus the discipline to keep AI off when AI must be off.

You have time to position yourself for that future. Or you can play the short game — maximize the grade this semester, minimize the rep, take the credential without the skill — and discover, in two years, that the credential does less than you expected. The course’s advice is the former.

Coach’s Note — I have watched, in my own career, every new “this changes everything” technology in software — the web, mobile, cloud, version control gone mainstream, the IDE, automated CI/CD. Every one was real. None of them removed the skill of careful thinking. AI is going to be the same. The students who pair careful thinking with the new tool win. The students who hope the new tool removes the need for careful thinking lose. I have never seen an exception. I do not expect AI to be one.

14.9 — Common Honesty Pitfalls (Week 14 Edition)

These are the patterns the course has seen in eight weeks of Phase 2. None of them are uniquely bad; all of them are real. Notice if you’ve fallen into any.

Pitfall: You stopped logging prompts after the first three. Why it happens: The prompts pile up, the log feels tedious, you tell yourself you’ll fill it in later, you forget. Why it’s a problem: “Later” doesn’t happen. You can’t reconstruct what you actually sent. Your submission’s prompts log no longer matches reality. That’s dishonest, even if accidentally so. Fix: Log in real time. One paste, three seconds, every prompt. Build the habit.

Pitfall: You “trimmed” the log to make it look like you sent fewer prompts. Why it happens: The rubric rewards low prompt count. Why it’s a problem: This is the form of dishonesty the rubric is structured to catch (sort of) and the grader can usually smell. More importantly, it’s straight-up falsification. Fix: Submit the real count. If it was high, write about it in the reflection. Honest 20 prompts beats fake 8.

Pitfall: You let the AI make architectural decisions and called it “directing.” Why it happens: Architecture is hard. The AI is fluent. It’s tempting to ask “should this be one class or three?” and accept the answer. Why it’s a problem: Architecture is the senior-engineering job. If the AI made it, you didn’t author the system; you assembled the AI’s system. Fix: Make architecture decisions yourself, on paper, before prompting. Chapter 12 was about exactly this. Re-read it.

Pitfall: You wrote a vague reflection that hides what actually happened. Why it happens: Specific reflections expose specific weaknesses. Why it’s a problem: Vague reflection is a small dishonesty in its own right. It also makes the reflection worth nothing as a learning artifact for you — you can’t improve a pattern you won’t name. Fix: Write the reflection that names the hard moments specifically. The grader respects honesty more than polish.

Pitfall: You believed the AI when it claimed it wrote something it didn’t. Why it happens: Mid-conversation, you ask “did you change processOrder?” The AI says yes. The file shows it didn’t. Why it’s a problem: Not a pitfall in your honesty — but a pitfall in your verification discipline. Always check the file. Fix: Diff the file before and after every change. Trust the diff, not the AI’s narration.

Pitfall: You used AI for a Phase 1 rep “just to see what it would say.” Why it happens: Curiosity, mostly. Not malice. Why it’s a problem: Phase 1 was an intentional skill calibration. AI on a Phase 1 rep doesn’t tell you what you learned; it tells you what the AI knows. Fix: If you really wanted to compare, do the rep first, then ask the AI. The order matters.

14.10 — Reps

Open the exercises for the full set. Reps this week are mostly reflective. Three written reflections, three small code reps, three policy-reading reps. Take them seriously. Reflection that gets done in three minutes is not reflection.

A preview:

• Rep 1 — Re-read your own Project 9–12 reflection. What did you say? Was it true?
• Rep 3 — Write a 200-word answer to a job-interview question about your AI use.
• Rep 6 — Read your school’s actual academic integrity policy. Summarize what it says about AI.

Full set in the exercises.

14.11 — No Project This Week

Chapter 14 has no graded project. Use the week to:

• Do every Chapter 14 rep — especially the reflective ones. They are conditioning for the reflection portion of Project 14 (the final), which is graded.
• Re-read your prompts.txt from Projects 9–13. Notice patterns in your own prompting that you want to keep or change.
• Read Chapter 15 in advance. It is the consolidation chapter before the final.

This is intentional rest before the capstone. There is no new technical material to memorize. Sleep well.

Coach’s Note — The week before a capstone is the week most students try to “get ahead” by starting the capstone early. Don’t. Use the week to consolidate what’s already in your hands. The capstone will be easier next week if you arrive at it with rested judgment than if you arrive at it with two days of low-quality preview work behind you.

14.12 — Coach’s Final Word for Week 14

The honesty question is going to follow you out of this course and into your career. It is, structurally, the question every working programmer over the next decade is going to have to answer for themselves, repeatedly, in small forms — did I do this? How much of this is honestly mine? What can I stand behind?

You have an answer now. You have a framework. You have the practiced discipline of attribution from twelve weeks of prompts.txt logs. You have the practiced habit of distinguishing the parts of the work that are honestly yours (the spec, the architecture, the review, the test, the redirect) from the parts that are the tool’s. You have the theological frame, if it speaks to you, of vocation and the Eighth Commandment as standards higher than mere policy compliance.

That is enough.

Two more chapters. Chapter 15 is consolidation; Chapter 16 plus Project 14 is the final. You have the skill. You have the discipline. You have the honesty. Bring all three to the capstone.

See you on Monday.

Up next: Read the exercises and complete every reflection. Then Chapter 15 — capstone preparation.