6 Setup Problems That Stall Every AI Beginner

Last updated: August 2026

This month I kept structured notes on every one-to-one session I taught: 14 lessons with four working professionals, written up immediately after each call from the recording. An enterprise change manager, a technical artist, a business owner, and one long-running student who came up through Python and is now doing LLM engineering. That last route, from a standing start to building real systems, is the ordinary one, which is why machine learning without a PhD is the norm and not the exception. I went back through all 14 write-ups looking for what actually consumed the hour, and the answer was not what I teach. Six problems, in the order they usually appear.

A caveat worth stating plainly: these are my own session logs, not instrumented measurements, and four students is a small sample. The timings are my estimates recorded at the time. What makes them worth reading is that they are first-hand and specific, not that they are statistically powerful.

In this post: The machine tax · Which Claude am I using · The permission wall · Teaching past the task · The credential slip · The autonomy gap

1. The machine tax

The single biggest consumer of paid time across 14 sessions was not prompting, not context windows, not model selection. It was the student's own computer and the software around it.

In two sessions, environment problems ate most of the hour. One went almost entirely to an editor stuck fullscreen on a second monitor plus an IT approval that had not landed. Another was defined by an editor that took most of the session to open, on a machine where the desktop app refused to launch at all. In four more sessions it took roughly 15 to 25 minutes each.

Cause	Sessions affected	Rough time lost
Aging hardware	2	Most of the hour, twice
Display and docking faults	2	15 to 25 min each
Install and PATH errors	2	10 to 20 min each
Video call failures	3	5 to 15 min each

Almost none of it was the AI's fault. It was a docking station and a second screen resolution, a PC that had apparently never been restarted, an unresolved PATH after a fresh install, and a meeting tool that kept dropping the screen share. I wrote about what computer you actually need separately, because the answer surprises people in both directions.

The fix: Restart the machine the night before. Close everything. Reseat the second screen. Have the editor already open in the right folder before the session starts. In my logs that is worth 10 to 15 minutes per hour, every time.

2. Which Claude am I using

Here is the finding I did not expect. Across every non-developer I taught, the most repeated question was not how to write a better prompt. It was which tool they were supposed to be in.

All four students hit this, and it did not resolve after one explanation. With one student it came up in all five of her lessons. Her words, roughly: it is confusing to tell Claude from Cursor. And the confusion set is larger than most writing assumes. It is not two things. It is Claude chat, Cowork, the Claude Code command line, Claude Code inside an editor, the desktop app, and Cursor's own built-in AI. Two of my students also had a third-party terminal that a colleague had installed for them, which added another layer.

A fourth student, four sessions in, could not recall how to switch modes, how to change models, what markdown was, or the difference between the model tiers. All of it had been taught before, some of it more than once. She is smart and fully engaged. The problem was volume, not capability.

The one student who genuinely locked it in did so by inventing his own analogy, unprompted: chat is the beginner you teach and question, Cowork is the skilled worker who takes what is already on your machine and produces the outcome, and Claude Code is the independent agent that builds and ships. He was right, and the fact that he built the analogy himself is why it stuck.

The fix: Settle the map before anything else, and settle it once, in writing. One page, in your own words, naming which tool you use for which job. If you cannot write that page, that is your next session, not prompting. The chat vs Cowork vs Claude Code breakdown is the version I give students, and Anthropic's Claude Code overview is the reference for what the terminal tool is actually for.

3. The permission wall

Three of the four professionals had an employer constraint that made the standard published advice wrong for them. This is the most under-served topic I ran into all month, and almost nothing written about these tools acknowledges it.

One student's company had not approved Cowork at all. The sanctioned route was the command line tool authenticated with an API key through a corporate gateway. That single decision quietly removed three things she had no idea she was missing:

What API-only access through a corporate gateway gives you:
  Claude Code                      yes
  Third-party tools via API        yes

What it does not give you:
  The desktop app                  no
  claude.ai in the browser         no
  Voice input                      no

I found this out the hard way. I had sent her home with a homework technique that required the chat interface. She spent a week improvising with dictation into a document and copying it across, because the thing I told her to do was not available on her account. Neither of us knew until the following session.

A second student cannot install downloaded skills at work without committee approval and suspects the download sites are blocked outright. A third works under an NDA with separate production and staging connectors and a hard rule that nothing may be committed to company systems.

The fix: Before you follow any tutorial, confirm what your account actually has. Open the tool and try to sign in to each surface. Two minutes of checking beats a week of homework you cannot do.

Roughly half of what is on this page disappears when someone watches your screen for an hour and catches it live. That is most of what my 1-on-1 sessions are.

4. Teaching past the task

This one is my mistake, not the student's, and it showed up in 5 of the 14 write-ups.

One session covered account separation, resuming a session, recreating a token, ignore files, branches, merging, safety guardrails, a command line tool, and an introduction to a new product. In one hour. The student said herself it was a lot to process. Another covered a prompt problem, memory settings, profile building, connectors, safety, a dictation technique, prompt shortening, transcription, and two integrations. Also one hour.

When I lined up what students forgot against what I taught, the pattern was uncomfortable and clean:

What stuck	What did not
Anything used on their own real work that same session	Concepts taught next to the task, not inside it
Techniques that produced a visible result	Model tiers, effort levels, mode switching

The concepts my students forgot were consistently the ones I taught outside the task they came to do. Not the hard ones. The tangential ones.

The fix: Teach what the task requires and stop. If a concept does not change what you do in the next ten minutes, it is not ready to be taught yet. This applies to self-teaching too: stop reading about context windows and go finish the thing you opened the tool for. If you do not have a thing yet, pick one with a visible ending, like getting a one-page portfolio site live with Claude Code, because the techniques that stick are the ones that produced something you can look at.

5. The credential slip

Two of the four students created a real credential exposure within their first three sessions. In both cases the thing that caught it was the tool's guardrail, not the person.

The first wrote a live access token for a corporate system into a cloud-synced folder that was shared with her employer. The AI's own safety classifier refused to persist the secret from that path, which limited the damage considerably. One session later, after I had correctly taught her that credentials belong in an environment file and never in a conversation, a second token went straight into the chat window. I let it happen, which was worse than her doing it, because I had taught the rule and then broke it in front of her.

The second student hit a token with no permissions attached, mid-commit, which stopped the work cold. Separately, the AI refused to paste a token into chat and refused to approve its own pull request. Both refusals were correct, and both taught the security lesson better than my explanation had.

The pattern underneath all of it: non-developers have never had to think about where a secret lives, because no previous tool asked them to hold one. The twelve-factor guidance on config has been the standard answer since 2011, and it is still right: secrets belong in the environment, not in code and not in conversation. The chat window is the same exposure wearing a friendlier face, which is why I now hand every professional the safety rules for putting company material into a chat tool before they ever hold a token.

The fix: Before your first token, decide where the project folder lives, and make sure it is not inside anything that syncs or is shared. Then put every credential in an environment file and add that file to your ignore list on day one, not after the first scare.

6. The autonomy gap

Three of four arrived expecting more autonomy than currently exists, and every engagement eventually hit the same wall in the same place.

A business owner wanted a near-autonomous content machine that would research, draft, translate, and post on a schedule across several platforms. The research, drafting, translation and formatting automate genuinely well. The publishing step is where it stops, and one of his target platforms is a closed system where automated posting is likely not feasible at all.

An enterprise student asked whether she could build things and push them out to her company tools. I said yes before I had verified it. That turned out to be exactly the uncertain part, and I had to walk it back.

Reliably automated today:   read, summarize, draft, translate,
                            design, generate, write the query

Still a human job:          configure, permission, connect,
                            approve, publish

That line held in all four engagements. It is not a limitation of any particular tool. It is the boundary between producing content and changing the state of a system that has its own permissions model.

What makes the gap painful is not the limitation itself, it is finding it late. Three of these people had already committed budget, time, or an internal promise before anyone tested whether the hard part was possible. Enough technical literacy to run that test yourself is the strongest practical reason product and program managers still benefit from reading code, even in a year when the code mostly writes itself. The change manager had sent me a 36 page specification before our first session, and we spent four sessions on tooling without opening it together, which meant the one document that would have surfaced the boundary sat unread while we solved smaller problems.

The reframe that actually helps is not "the tool cannot do it." It is "here is what it produces, here is what a human configures, and here is who does which part." That turns a dead end into a plan, and in every case I have run it also turns out to deliver most of what the person originally wanted.

The fix: Before you buy anything or commit to a project, sort your goal into those two columns honestly. Take the single hardest step in your plan and test just that step first, before building anything around it. The first column is where AI earns its money right now. The second column is where you will lose a month if you assume otherwise.

Start here

If you act on one thing from this list, make it number two. Not because it is the most dramatic, but because every other problem on this page gets harder while you are still unsure which tool you are in. The credential mistakes happen in the wrong tool. The wasted hours happen because setup is being done twice. Settle the map first.

1. Write one page, in your own words, naming which tool you use for which job. Not copied from anywhere.
2. Open each surface your account has and confirm which ones actually work for you. Note what is missing.
3. Pick one real task you already have to do this week and do it in whichever tool your page says is the right one.

If you want the longer versions, what a CLAUDE.md file is covers giving the tool your context properly, and the Claude Code tutorial is the gentler on-ramp for the terminal side. If step three above is where you stall, a first twenty-minute session with a coding assistant hands you a task small enough to actually finish.

From the session logs of AI Tutor Code: 1-on-1 Python and AI tutoring for working professionals. The patterns above come from 14 real sessions in July 2026, anonymized to first names and roles.