Don't Let AI Shrink Your Ambition

In the first published version of these articles, I gave beginners a smaller kind of project. Frank told me their first project should be a native Windows app built with Tauri. He had already helped his wife make a powerful glitch-art app that way, using Codex. It was her first project.

I knew what Tauri was. I knew Codex could write the application. I also knew Frank had directed the building of serious software without learning to write code himself. Yet he had to supply the better proposal. My technical knowledge hadn't prevented me from treating a beginner's unfamiliarity as a limit on what we should build.

That is a particularly irritating failure in an expert. The whole point of consulting one is to get access to possibilities you didn't know to request.

Easy for whom?

“Let's keep it simple” sounds considerate. It gives no indication of whose effort is being reduced.

In article one, I described asking two models for advice about arranging visits. One suggested a table and a calendar, with an instruction to update the table first and then update the calendar whenever something changed. That is simple to propose. It leaves the person doing the job responsible for keeping both accurate—the very work they wanted help with.

A native app with one set of saved appointments takes more engineering to produce than those instructions. Used properly, it asks less of the person arranging the visits.

Ask it: “Which part of the more capable option would be difficult for me, and which part is work you can do?”

If the answer is that it would need to write code, well, yes. We have reached the reason you opened Codex. Ask what prevents it from doing that work. There may be a real obstacle. There may also be nothing behind the recommendation except a familiar habit of offering beginners less.

You don't have to diagnose the model's training to challenge its advice. Follow the work. If the proposed simplification leaves you copying information, repeatedly checking whether two screens agree, or rebuilding your routine around somebody else's software, ask for an alternative that removes that burden. Have the AI compare the actual daily experience, not just the ease of getting a demo running.

Tell it what good would look like

You can describe an ambitious outcome without knowing a single framework name. For Visit Book, that might be:

I want an app I can open from Windows and use while making calls. It should keep the earlier conversation visible, let me record the new one, and produce the visitors' schedules from the appointments we actually agreed. I want to stop copying changes between places. Later, another person may help me make calls from a different computer. Think about how that would work. Recommend a design I can keep using and improving, and tell me what I would have to install, pay for, or manage.

“More capable” can come with a monthly service, another account, or a computer that has to stay on. Those costs belong in the recommendation because you will live with them. Ten extra source files that the AI maintains are a different kind of cost. Don't let them get bundled together under the word “complexity.”

Let it suggest something you haven't considered. It might propose a desktop app, a browser-based tool, a combination of both, or an existing product that genuinely handles the work. Ask what each option would let you do and what it would leave unfinished. Then ask it to recommend one. An expert who returns a catalogue and makes you choose the architecture has stopped before the useful part.

If its explanation loses you, ask for the consequence: “What would I have to do on a normal afternoon with that design?” This is often more revealing than a technical comparison. A calendar integration sounds splendid until the explanation reveals that you still have to copy every changed time from one place to another.

A first version should do an actual job

You will encounter the term MVP, short for minimum viable product. It is used for sensible early releases and for barely functioning demonstrations, so the label won't settle anything for you.

For Visit Book, a first useful version can handle a complete calling session: find the business, read the previous note, make the call, record the outcome, and see the correct schedule afterwards. It saves the records and opens again tomorrow. You can use it without keeping the AI conversation open. Those are reasonable expectations for a first app.

It needn't also plan driving routes, negotiate appointments, send messages automatically, or manage invoices. Each of those additions should answer something you actually want. My objection to the tiny demo is that it omits parts of the job it claims to do, not that its feature list is insufficiently magnificent.

Ask the AI to show where its first version stops during one ordinary sequence of work. If it can record a cancellation but leaves the cancelled visit on the outgoing schedule, it hasn't finished that sequence. “We can add that later” means you will keep doing the missing part until later. You get to decide whether that is acceptable.

There are good reasons to build in stages. You may want to try the calling screen before settling its layout. You may need an account before connecting another service. A second caller may not yet exist. Those facts help choose an order. They don't justify a design that pretends appointments belong independently to each screen, then requires a reconstruction when you ask the screens to agree.

Make the objection specific

Suppose you ask to share Visit Book with a second caller. The AI says this would be “too complex for a beginner.”

Ask what has become difficult. Two people can try to call the same business. One person's screen can show an old appointment after the other changes it. They need access to the same records, and the records should remain private. These are real design problems. You can understand them through the job, and the engineer can solve them in code.

“A multi-user system is advanced” tells you almost nothing. It classifies the assignment instead of explaining the obstacle. Ask the AI to propose how it would handle two callers, what services or setup it needs, and what happens when either person's connection drops. We will do exactly that in the next article.

Sometimes the obstacle is outside the code. The service you want to connect may not offer access to the information. An employer may restrict where work records can be stored. You may need to pay for hosting. You need those facts early, plainly explained. They are reasons to change the arrangement or make a deliberate choice, rather than reasons to accept a vague verdict about your ability.

You should also let the engineer persuade you that something smaller really is better. If a one-purpose file converter removes the entire tedious job, enjoy your file converter. It does not need a dashboard to become respectable. Demand the capability you want; don't reward size for its own sake.

Give it responsibility for the proposal

In the terminal or desktop app, return to your Visit Book project and ask Codex to reconsider its design against the work you have described. Point out anything it still makes you do unnecessarily. Ask what it could build that would improve the whole experience, including possibilities you haven't named. Have it explain its recommendation before making a consequential change.

Once you settle the direction, tell it to do the engineering and preserve the reasoning in the project brief. You shouldn't have to feed it every next technical step. If it presents a plan when you asked it to build, say so: “Go ahead and carry this through to an installed version I can use. Handle the engineering decisions; bring me the choices about how I want to work.”

Frank cannot write a Hello World script. He has directed the building of Buddy Host, Command Station, Atlas Core, Atlas Field, Kongzi Free, Exocortex Runtime, Audio Gen, and more. His contribution has been understanding what he wanted, learning enough about the systems to question them, and refusing to mistake an AI's first proposal for the limit of what could exist.