I'm interested in AI only as a tool to enhance thought. Unfortunately, almost all of the discourse about the power of LLMs is about how to use them to avoid having to think: the amazing things these new models can one-shot (i.e. create with just one brief initial prompt), the loops and the graphs and the factories... everything is publicized as a way to hand off as much of the work as possible to a bunch of GPUs in the cloud, then sit back and wait for the magic to happen.

None of those techniques is bad in itself (I use most of them!), but I think the way we talk about them is giving a lot of people the wrong impression. I suspect this is part of the reason why researchers find people becoming lazier with their thoughts ¹, losing their skills ², or never learning them in the first place ³. If you only emphasize "long-horizon" performance and hands-off results, of course people will—very wrongly—believe that mental atrophy is an inevitable side effect of using AI for work. They will also become frustrated when all they get is slop.

Here I want to contribute to the debate in a different way. I'll share with you real, unabridged data about what it's like to work with AI in a way that I think is effective, healthy, and without the dreaded feebleminding effects. You won't learn programming by using AI like this, but you will exercise your mind on some very useful general-purpose skills. This is what I call the Anti-Magic Effect: good work with AI actually requires skill and effort.

I don't mean this as a showcase of the "ideal" or "right" way to prompt. I'm sure AI coding experts will find much to improve in my process. I mean it as a lead-by-example attempt at getting other practitioners to share their work in the same way. Anyone can get something out of an LLM, but apparently very few can get anything worth sharing with others. So let's talk about it.

I also took this as an opportunity to put two of my thinking tools to work: the "goals as mountains" metaphor from Purpose from First Principles and my Anatomy of Augmented Thought (AAT) framing. They helped me ask interesting questions about the process.

What I Did and How

Before we look at all the pretty charts, some meta-information.

You can find the prompts I used to build the Foldable Tractatus here. That's all 191 of them, in easily browsable form and enriched with metadata. You can also download them as text files on the GitHub repo.

From the start, I meant the creation of this app to be a case study of AI prompting. Because I want this to be useful to non-programmers first and foremost, I set myself some constraints:

• I never looked at the source code written by the models.
• I only used $20/month subscriptions to Claude and ChatGPT. I could have used the much more expensive plans, but then most non-engineers wouldn't have been able to relate. Besides, $20 is more than enough for a small project like this.
• I also deliberately avoided using ultra-customized scaffolding, harness setups, and frameworks. I use those for my other projects, and they do pay off very well, but this case study is about the mental side of things, the human involvement, not tooling optimization.
• I didn't put much weight on code quality, which is probably the main weakness of this test, but that, again, is out of scope here. I did, however, emphasize keeping user data private and secure.
• Although I was unfamiliar with some of the tools (the then-new Claude Design, Val Town, and a few others), I did use my programming and product management experience to make the process smoother and more successful. A newbie would have to learn these the hard way in projects like this, via study or trial and error. If you read my prompts, you'll see that none of it is arcane, and that this is another demonstration that using AI well does make you learn.

But the most important constraint, the one that makes all of this meaningful, is that I didn't stop working until the result was very close to what I wanted, based on my own judgment and taste. This is not an example of "wow look what this thing can make on its own!", it's "wow look how much faster and better I can do my job with it!"

For the curious & savvy, this is the software stack I used to build the app. Unless otherwise noted, it was all proposed by the AI.

• Frontend: Vite (first time for me) + React 19 single-page app, written in TypeScript.
• Backend: Val Town (my request—but they're shutting down soon 🤕), with Hono for routing and SQLite for storage.
• Rendering: KaTeX for math, self-hosted fonts, and build-time prerender for SEO.
• Testing: Vitest with jsdom. Backend tests with an in-memory @libsql/client. Playwright for the AI's checks.
• Hosting: Vercel (my request).
• Styling: plain CSS.
• Analytics: self-hosted Plausible, no tracking (my request).
• License: MIT, source code here.

For the actual work, I used a sequence of AI tools, switching as the project moved from phase to phase: first the claude.ai chat interface, then Claude Design (it has since been assimilated into Claude chat), and finally VS Code with Claude Code and a little bit of OpenAI Codex. The models involved were Claude Fable 5 (it was part of the $20 sub at the time), Claude Opus 4.8 & 5, Claude Sonnet 5, and GPT 5.6 Sol and Luna.

Over the past few years I've used large language models to build many projects, both bigger and smaller than the Foldable Tractatus, but this was the first time I stopped to dissect my process closely. This may not be the optimal way to do things, but it is a real-world project built with a well-tested process that has worked well for me.

So what do the numbers say?

Table of Contents

• What I Did and How
• 📍 You are here
• The Process in Numbers
• Purpose Analysis
• How Did I Apply My Own Advice from "Anatomy of Augmented Thought"?
• Conclusions - Coming to Terms with the Anti-Magic Effect
• Appendix: How I Measured the Climb
• Comments
• References

The Process in Numbers

The first thing you'll notice when looking at the transcripts is that this was definitely not a one-shot job. I could have given the AI a few lines summarizing what I wanted, looked out the window for thirty minutes, and found in front of me a working app. It would have done roughly what I asked it to do (as interpreted by the AI), it might have been somewhat useful, and it would have been terrible. Publishing something like that would have been irresponsible and extremely lazy of me—worthy of the S-slur (the AI kind!).

The point of using AI, in my opinion, is to do things faster and better than without it. Expecting a quick prompt or two to complete the job is what I call the Magic Wand Illusion. You get speed, and that's all you get.

Instead, I had a clear idea in my mind of how I wanted this app to work, and clear standards for the kind of UX, style, and level of polish it should have. I knew what it should not include. And I had a clear user persona in mind: the curious student or lover of philosophy who wants to read and navigate the book on their own terms. I conveyed this information to the model in not one but 191 prompts and answered 47 questions from the AI, for a total of 9,487 human-typed words. That's almost 4 hours of typing if I assume a measured typing speed of about 40 words per minute (slow because it includes a lot of thinking).

Based on my past experience, and the fact that I'm not an expert at frontend engineering, I estimate that making the app myself would have taken at least ten times as long, and possibly much more if I got stuck in a couple of unfamiliar design ruts. The core build alone, about a third of the app, would have taken me 40 to 80 hours (more on this estimate in Algorithmic Work Is Where It Shines, below).

These prompts were spread over 33 sessions in five distinct phases, from the initial specification to the final polish. The AI worked for a total of 13.6 hours. I stopped only when I had an app very close to the one I wanted.

1 - Specification Phase

The first phase, "Specification", consisted of only one session, with a couple of huge prompts. Prompt 1, the very first in the project, had 758 words and contained my initial concept for the app. I dictated it by voice and had a Whisper voice-to-text model transcribe it. If you're curious, here is the full text:

I only began this process after mulling over the idea for this app for a few weeks. This allowed me to constrain the design very strictly from the start, and based on previous experience I expect this saved me a considerable amount of firefighting time after the feature was built. We'll see in the Purpose Analysis section that, already at this early stage, about two thirds of the app's final specification was settled.

Also note that at this stage I focused exclusively on what the final product should look like and do from the point of view of the user. No UI design choices, and almost zero technical details. Specifying them this early on would have constrained the model too much and prevented some healthy exploration in later phases, after the product requirements had solidified.

2 - Design Phase

After those first few specification prompts, I moved on to the "Design" phase.

I could have attempted to build the thing directly, letting the LLM choose the look and feel of the app on its own. I do this occasionally when I really don't care about UI/UX, and usually live to regret it anyway. If I didn't like how the app was built, I would have had to either ask it to redo it from scratch (potentially many times, slot-machine style), or spend a few frustrating hours painstakingly pointing out all of the things I wanted fixed, and waiting for it to fix them one by one. I mean, I would have had to do that much more than I actually did, which is saying something.

I found it easier to do the design work upfront instead, in quick visual iterations. Then the AI doesn't have to worry about technical aspects like correct logic and security, and it's able to work faster and with fewer errors (this is standard product management common sense for humans as well!). In this case I did all the design inside Claude Design, a relatively new tool at the time.

In this phase I typed a total of 2,837 words (~1.2h of thinking-typing) across 19 short sessions, 72 prompts, and 25 questionnaire answers, which led to 2.3 hours of LLM work. That's not a great AI-to-human effort ratio (less than 2×), but it paid off in the later stages. Some of those prompts were long lists of very detailed point-by-point change requests, like the following one, where I reviewed some wildly different directions proposed by Claude for the high-level design (the "1a", "1b"... labels refer to visual options shown on the canvas by the AI):

3 - Implementation and Polish Phases

Thanks to all the upfront work of the previous two phases, actually building the thing was relatively smooth and painless. In the "Implementation" phase, the AI built and tested the actual code: all the logic, the interactions, and the data-handling infrastructure. Although I typed some 2,375 words in this phase (more than the average length of an Aether Mug post!), they were of a very different nature from those of the Specification and Design steps. Rather than writing prompts about what to build, I was mostly explaining what to fix. I'd test each build carefully in all its functions and note down everything that I wanted changed, removed, or corrected. Rinse and repeat. The final "Polish" phase was just more of this, focused on the finer details.

Session 23Prompt 97ImplementationHuman: 264 words · ~7 min · 1 image

Summary: Report seven distinct bugs/UX problems found in testing (sidebar layout shift, blank PDF export, dropdown z-index, missing confirmation toasts, unclear share affordance, missing overwrite confirmation, and a question about Val Town share behavior) and ask them to be fixed.

A quick test revealed these problems you should fix now: 1. The main section containing the statements should be fixed horizontally. Instead, when I collapse and expand the left sidebar (which changes in width in the process), the whole section gets shifted left and right. It should be the other way around: fixed horizontal position of the main body, and the sidebar flushed against it. 2. The markdown export works, but the PDF (print preview) comes out completely blank. 3. As shown in the image, the dropdown fails to cover some other UI elements. It should be at the top of the z ladder. This issue was already fixed in the design files. 4. Saving a new named thread, renaming it, overwriting it, or deleting it should all trigger confirmation toasts. 5. Saving a new named thread closes the dropdown, but there is no indication that this can be shared with others, or how. 6. When activating a thread (either preset or saved), a confirmation dialog must be shown, because it would overwrite existing pins. This is present in the reference design files, and you already implemented it for the "Pin only these" action when a word is selected. If the spec fails to mention that the same modal is necessary at thread selection, update the spec. 7. I used the "Share" function with some pins but no notes, and it worked in another browser: I could see the same pins. However, nothing was created on Val Town. Is this the correct behavior? I have some more, but for now focus on resolving these.

4 - Content Phase

The "Content" phase is where I imported the actual contents of the book in their entirety. Until then, I had done all the work with a small subset of Wittgenstein's propositions: enough to get a feel for what the completed product would look like, but few enough to avoid wasting tons of tokens every time the model decided to read that file.

The Content phase is also when I had the AI create an index of all technical terms used in the book, to power the "click and highlight all occurrences" feature. I did most of this using OpenAI Codex instead of Claude (I just felt like changing for a while). Index-making is the kind of task that can be parallelized, which is what I did:

GPT 5.6 Sol sent out a small crowd of subagents, each with its own task:

• 1 to figure out the best data architecture for the index
• 1 to decide the structure of the indexing work
• 1 to set up the supporting infrastructure
• 3 to identify the actual index terms, each focusing on a different range of propositions, avoiding duplicates via a central file
• 1 to review the index built this way, which gave three rounds of feedback reports to the other agents until they had fixed all issues

Overall Trends

In total, across all phases, my prompts produced 666 outcomes distributed across five categories: Deciding, Building, Fixing, Checking (i.e. verifying that things work as desired), and Support work (i.e. things that facilitate the other categories but don't end up in the final product, like engineering docs, tooling setup, solution research, etc.). The distribution of outcomes in each phase was different.

This chart shows a few interesting things. First, the split is not so clean: there was a steady number of new decisions even during implementation, and there was a fair amount of building in the Design phase, when the look and feel of the app was prototyped. This mix of doing and planning across the whole project means there was a perpetual feedback loop, and it's a sign of a healthy product development process, AI or not. Waterfall is dead.

Second, something that strikes me as very AI-specific is the sheer amount of Support work. My prompts led to as many of these outcomes as to actual building outcomes! This shows how much effort I had to spend scaffolding, harnessing, constraining, and steering the models to keep them on track and under control.

As I explained in the AAT post, the algorithmic work of writing code with an LLM is the quick and easy part. It's the metacognitive and reflective work that consumes a much larger share of the human's brain cycles ⁴. I'll return to more AAT insights later on.

Purpose Analysis

A software development project, like many human endeavors, is a control process. Whether you start with a plan or not, the work is a constant loop of observing reality, finding how it differs from the desired goal state, and gradually applying corrections, repeated over and over until there is nothing significant left to correct.

You are here:

You Might Also Like...

• Presenting the Foldable Tractatus

Can we see that in the data? Yes, very clearly. I had an AI analyze all outcomes and catalog all those that corrected previous outcomes. Some of these corrections were reversals of previous actions or decisions, others were replacements with something better or different, others still were fixes to previously-introduced flaws. This gives us a list of 125 ranges: the lifetime of each mistaken or superseded outcome has a clear start and end, as shown in this chart.

There is so much information in this chart! I'll unpack it briefly.

One thing that immediately jumps out is that, while some of those elements lasted a long time before being corrected, most were rather short-lived: a sign of the feedback loop doing its job.

Next, try hovering over the various phase names at the top of this last chart: it will spotlight the items that were corrected in that phase (if they're currently ordered by start) or those that were started in that phase (if they're ordered by correction). This reveals a few things:

1. Nothing that was introduced in the Specification phase needed a correction beyond the Implementation phase. These were the high-level foundations of the idea, and they mostly held up.
2. The value of the Design phase is evident from the large number of iterations visible there. All those cycles of making and remaking would have cost more time and tokens if delayed until a later phase. In fact, 48 out of 51 of the Design-phase elements that needed a correction were fixed within that phase itself. The Design held up against the reality test that came after it.
3. 28% of all the issues on the chart were created during the Implementation phase. Despite all the preparatory work of the previous steps, Fable 5 made a few mistakes. But some of those items were not the model's fault—they were me changing my mind when I finally got to interact with the built product. I never stopped replanning the details, as the "Signs of human engagement" chart further below will show more clearly.

At one point in the essay Purpose from First Principles, I use the metaphor of climbing a mountain to represent any teleological process: the peak is the goal, and your way there is never a straight line but a series of steep and flat segments passing through intermediate bases. Where the metaphor is unrealistic is replanning: a mountain has a fixed height that you can't control, but in a generic purposeful undertaking you can usually update your plan and even your goal based on new information.

You can see the goal of the Foldable Tractatus grow in this "burnup" chart:

The red "decided" line is the goal state as defined at that point in the process—the "height of the mountain" that kept growing as I decided on more things to build. Here 100% represents the final result that I accepted as done (see the Appendix for details on this process). The blue "built" line, on the other hand, shows when those same elements were actually implemented in code, including the prototype designs from Claude Design that made it to the end product mostly unchanged.

This chart is telling us a few things. One is that there are several "plateau" periods in both lines: steps, sometimes dozens, in which nothing was decided or built. A few of them were indeed trial and error, with decisions walked back. But in most of them productive work did happen: setting up the process and infrastructure, planning, verifying, and other tasks that build nothing visible to the end user.

Specification. Let's focus on the upward movements of the "decided" line next. You'll notice that the line doesn't start at zero, but at around 30%: my very first prompt already defined about a third of the app's final state, including three of its four most central features. Two more exchanges with the AI brought it to 66%, and by the end of the Specification phase the fraction reached 68%. This shows right away that the human input dominated the conceptual work.

Design. That is not to say that the AI did not participate in the creative process. You can see it in action in the Design phase, where several significant decisions were added to the pile, raising the mountain's height from 68% to 91%—almost a quarter of the final "design weight" added not from my own independent inventions, but from design proposals the model made and I reviewed, selected, and tweaked. We'll get back to this point.

The "built" line remains entirely flat for the first 8 prompts: during the first turns of Design, while I explained my concept for the app, nothing was built except a quick-and-dirty wireframe that was later thrown away. Several of the first steps were the AI interviewing me about my design preferences and constraints. Building started when the LLM made the first design prototypes, among which were those that eventually made it into the final version, and by the end of Design, 49% of everything—the visual part—was already built.

Implementation. Not surprisingly, during the Implementation phase there were few decisions and a lot of building. In a few steps, Claude brought the app from being only a visual dummy to being 86% built. The vast majority of the value had been built by that point. The app was already distinctly recognizable, albeit buggy and incomplete. As we'll see later on, it was at the beginning of this phase that the LLM really shone.

Final stages. After prompt 84, progress slowed down again, continuing with another 107 prompts (more than half of the total!) of debugging and polishing, which resulted in only the last 14% of the app being built. In the final stretch, between around prompt 137 and the final prompt 191, both the "decided" and "built" lines flatten almost entirely. A lot of "invisible" work happened there. With those last 55 prompts, the outcomes included:

• 11 devil-in-the-details decisions with small overall weight;
• 27 verification and 22 tooling steps;
• 13 bug reports and 16 bug fixes;
• 13 content, 11 UX-improvement, and 7 accessibility outcomes;
• 6 corrections of plain AI mistakes;
• 13 process, 9 plans or dev docs and 7 research outcomes;
• probably some backtracking and removing that my data couldn't fully capture.

In a general goal-oriented process, the amount of this kind of fine zeroing-in on the goal state depends on how much you care about getting it just right. Given that the Foldable Tractatus is, even now, far from perfect, I could have continued for a long time, but decided at prompt 191 that I had reached "good enough" for a product like this.

How Did I Apply My Own Advice from "Anatomy of Augmented Thought"?

In my Anatomy of Augmented Thought (AAT) study I made several precise statements about how to work well with an LLM on complex tasks, so I tried to see what insights about them I could glean from my prompting data.

Unfortunately, even with the rather comprehensive record I kept of the project, some things about the AAT framework can't be directly observed in it:

• One of the three axes of AAT, "Mode", distinguishes the kinds of thinking being done: autonomous (instinctive), algorithmic, and reflective. Since the differences between these happen mostly in the human's head before writing a prompt, I couldn't get hard quantitative data from the session transcripts. We can say something about the AI's algorithmic work, though.
• Mental fatigue can't be measured from the transcripts.
• Since I did not include the AI responses in my analysis, any information about the AI's "thinking types" is indirect.

What I could interpret to some extent in the available data is the "Phase" axis (divergent vs convergent work).

So, how did this project reflect my delegation guidance? Here is the table from the AAT post:

Things One Should NOT Delegate

Never Delegate Final Decisions

I followed this AAT principle quite closely, and you can see the deliberate split between the AI's exploration of options—a divergent act—and my choosing among them—a convergent act.

Especially in the Design phase, I gave detailed feedback about the elements I wanted to cherry-pick and mix from different design directions explored by the agent. For example, when Fable 5 proposed these two panel variants...

...my feedback was detailed:

That's not to say that I never listened to the LLM. I was satisfied right away with many of the basic elements in those panel prototypes, for example. In many cases (17, to be exact) the AI used the "Q&A" tool to ask me a multiple-choice question, with one of the options marked as "Recommended". In 11 of those I went with the recommended choice, effectively confirming the model's proposed decision.

It's easy to fall into the trap of not reading the options at all, avoid thinking about your own independent options, and simply accepting all "Recommended" items. I see novices doing that often, and it's more likely to happen when you're tired ⁵.

Some recent studies ⁶⁷ claimed that using AI leads people to erroneously feel like they made the calls while the model silently pulled the strings. I think this is true in many cases, but my records tell a different story. With the data I have, I could make a considerably more neutral estimate of decision and idea ownership.

You could argue that only 57% of the app (the "...based on my idea" branch) is genuinely mine, and that the decisions labeled "...based on the AI's idea" show me being led by the AI. There is some truth in that, but I think the story is more complicated here.

On the one hand, the AI may have constrained the search space and failed to surface other possibilities that I could have discovered with more effort. On the other hand, as I show repeatedly in this post, I did exercise my freedom to reject or modify the AI's suggestions. Even when I accepted an LLM's idea, nearly half the time I did so with qualifications, as in the following cases:

• "...keyboard navigation sounds great. I would also use the up and down arrows to move."
• "Peek display: I approve your four-state model, at least tentatively."
• "I love your idea for how to use Val Town… My only remaining question is security: can this be abused?"

The end result is that almost every aspect of the final product was due to my own, human decisions. Only about 1% of the importance-weighted features of the Foldable Tractatus can be traced to something the AI decided autonomously.

This is close to the ideal split suggested by AAT, where the LLM diverges algorithmically (options uncovered through search and mechanical recombination) and the human converges reflectively (applying taste and expert judgment to pinpoint one decision). Maybe the litmus test is this: did the human have and consider the opportunity to choose differently? If the answer is "no", then the human cannot claim real ownership of that aspect, and thinking otherwise would be a harmful bias.

All in all, I would probably not have built the app without the help of AI: it would have taken me too long, and given me too many headaches. At the same time, I can safely claim that what the app is and what it does is overwhelmingly my own responsibility and creation.

Never Delegate Verification

The data shows that I remained in the driver's seat through most of the process. There are many recorded cases of me explicitly pointing out mistakes introduced by the agent, and cases in which I changed my mind, altering or reverting decisions I had previously made.

But were my corrections timely, or did I delay them too much—perhaps out of laziness or distraction—causing more work than necessary down the road? A software bug gets more costly as the project continues: like a house of cards, building lots of functionality on top of an undetected bug can lead to a lot of rework to fix it later. Was I diligent enough on this front?

Well, the app might still have bugs and issues that no one has reported yet, and those would all be my fault. During the process, though, the picture seems more positive.

Sometimes I was proactive, catching agent mistakes as soon as the agent began making them, like in Prompt 166, when it was working on the book's glossary:

Even when correcting after the fact, I couldn't find significant cases in which a correction was clearly due to my inattention in a previous step. The only examples hinting at my own negligence were minor things that could have been fixed earlier, but were safe enough to postpone: things like the ideal color contrast of some interface elements (Prompt 188), small mobile glitches (Prompt 138), and a junk project file that would have remained invisible to the end user in any case (Prompt 180).

Things You CAN Delegate

You Can Mostly Delegate Divergent Work

As I've mentioned already, I let the AI do most of the divergent work.

The challenge is preventing the agent from converging on its own without my permission. I often did this by asking Claude to offer multiple disparate options for me to look at:

As I mentioned in the decision breakdown, some 28% (in weight) of all decisions, while arguably "belonging" to me as the one who selected and qualified them, were options explored by the model. And we already saw in the climb chart that this process, in which the AI produces options and the human selects and improves them, was effective in the Design phase. This kind of AI-powered brainstorming was even more influential in the initial Specification, where a couple of steps (Prompts 2 and 3) allowed me to make decisions worth more than one third of the whole product.

In case you're curious, these are the three most valuable AI ideas that I adopted:

1. The choice to make the app English-only rather than bilingual.
2. The approach to displaying the folding state of statements. I approved it "at least tentatively" but it survived to the end.
3. The idea to hand-curate the glossary instead of making every word clickable.

Algorithmic Work Is Where It Shines

According to AAT, the kind of thinking that is most appropriate to hand over to an LLM is the algorithmic—the mechanical, pattern-based, predictable-and-boring kind.

Three prompts near the beginning of the Implementation phase produced 4,000 lines of code—over a third of the entire codebase—in around one hour of AI work. This included a multitude of automated tests the model wrote to verify its code worked. In some cases, the AI was able to boost its own speed many times over by "fanning out" subagents to work in parallel, like Codex did when building the index.

To make a rough comparison, I estimated how long it would have taken me to do, on my own, the work that Claude did in the very prolific prompts 82–84. I studied each of the 12 implementation milestones the AI used and made educated guesses with PERT times ("optimistic", "most likely", and "pessimistic"), and got a range of 40 to 80 hours, or 7 to 13 workdays. Claude did it in about 60 minutes—some 50 times faster!

This estimate is extremely approximate, but the fact that this quintessentially algorithmic task was the most impressive acceleration in the whole pipeline seems solid enough.

Conclusions - Coming to Terms with the Anti-Magic Effect

If you found my development process interesting, you might take away lessons like the following:

• Try to do as much upfront deciding and designing as you can before ever talking to the AI.
• Be ready to remain vigilant throughout, looking to uncover bugs and wrong directions as early as possible.
• Never stop acting like a designer, imagining the experience from the point of view of the user and steering in that direction.
• Let the AI run wild with the divergent exploration, but make the choices yourself.
• If you do the above things well, the model will blaze through the implementation work; but do your due diligence, because most of the problems enter the project in that phase.

If you've read until this point, perhaps you'll agree that working in this manner does something to mitigate the oft-quoted pitfalls of LLM use, like cognitive atrophy (you're thinking constantly and hard!), lack of ownership of the output ⁸ (it's yours because you obstinately make all the important decisions!), and deskilling (it might not teach you to program, but it will teach you to build well!).

Of course, how useful all of this is will depend on the scale and type of project you apply it to. For small, quick-and-dirty solutions, the process showcased above is overkill. When you have no strong preferences and "barely works" is enough for you and all recipients, then a few lazy prompts might just do the job. On the opposite end of the spectrum are the very complex and high-stakes projects, like apps involving payments or databases holding many people's valuable data, where the process as I outlined it here won't cut it on its own. More preparation and design, and much more testing and verification will be necessary. I suspect that projects like that are still best left to human domain experts.

But I think the Foldable Tractatus represents an underrated project category in the AI age: that of mid-sized, low-to-medium-stakes products. It's what you'll have on your hands if you want a highly custom app, dashboard, or automation: not so large-scale that you'll need extra-high reliability, security, and code quality, and not trivial enough to outsource to the AI wholesale. Yet so many cool things are possible in this range! It is perhaps the category that most non-engineers will be interested in as AI coding tools become more accessible. That's why I decided it would be worth a few hours of analysis.

If you only take home a single point from this post, I hope it is the point I started with, which I call the Anti-Magic Effect: productive human-AI "centaur" cognition is possible, but it doesn't look anything like what the marketers want you to think. Far from being the keyboard equivalent of flicking a magic wand, the task should and will be difficult for you, it will be tiring, and it will require a great deal of your input all throughout. And, despite all appearances, that is good news for us humans. ●

References