Picturing my students
and catching up with vibe-coding
Some of you want me to write about my UATX experience, which will start in less than two weeks. I do not know how much time I will have to do that. Meanwhile I have not started yet, and I have time to write.
As of now, I will have 34 different students, split into three sections—two sections of Political Psychology and one of Public Choice. A few students are taking both courses.
The administrative software that UATX uses includes pictures of the students. They look perfectly normal, but their attendance at the school is a non-normal choice. We’ll see.
I asked Claude to develop a flash card app for me to use to try to learn the students’ names. It took longer than I expected, because Claude could not extract the pictures the way that they were rendered by the code. I don’t know whether this was a security issue, or just the way that code gets written nowadays.
Instead, I had to go through the process of manually extracting the pictures and putting them into a file. Once that was done, the flash card app took Claude about a minute to build, and it worked without having to be rewritten at all. Not that I will have time to use it enough to learn everyone’s name.
Last summer, when I was working on The Social Code, Claude assumed that I was a software engineering professional. It was there to help me with the actual code, but it expected me to know everything about configuration. Which I didn’t. So I had to put time and effort into learning the tools of the trade, such as node.js, React, and Github. And Claude assumed that I would be comfortable implementing changes by going into the code and editing it.
As of now, Claude is much more friendly to “vibe-coding.” It lets me see how the software works without having to download, install, and learn to use the professional’s toolkit. It does not expect me to look under the hood at the code and to make fixes. I mean, I am sure that professional software engineers can bring their knowhow along and use it with Claude, but it is easier now for an amateur to get usable software. It is closer to Replit in that regard.
The first year that I taught high school, in the fall of 2001, I taught a course in programming for a web site. I had just come off of a business experience in which I was in charge of our web site. I had coded in a text editor, like Windows Notepad or Unix vi. Better code editing tools were just coming on stream in the late 1990s.
I had my students get accounts on a free hosting service, where I figured they would upload files that they created in a text editor, the way that I did. But I was telling them how to code things manually that the hosting service could provide for them with a couple of clicks. Within weeks they were running circles around me. They were showing me how to create fancy web pages.
I expect that same thing will happen at UATX. Vibe-coding is not what I am supposed to be teaching, but it is something I think that they should learn. In the Public Choice class, I have a specific vibe-coding assignment, a virtual wax museum of certain economists, because I want them to get used to vibe-coding. And I want them to be creative and add embellishments that go beyond the basic assignment. Most of all, I want them to document the process of working with AI’s to develop software. If you go into an organization today without knowing what AI can and cannot do for you as a developer, I think you will be severely handicapped.
The state of the art is moving very rapidly. One of the things that I hope that the students learn is how to keep up with progress in AI coding. As Ethan Mollick says, you can just watch barriers fall with each new release.
Brillant observation about the shiftfrom Claude expecting expertise to enabling actual vibe-coding. Back when I was experimenting with similar tools, that friction between 'what the AI assumes I know' and 'what I actually need to do' was brutal. The real value in that virtual wax museum assignment isn't just geting students comfortable with AI tools but making them document the workflow itself. Most orgs still have no idea what these tools can actually deliver vs the hype.
Not sure if what I do is "vibe-coding", but I've been using Claude Code a lot lately to help with testing our startup's product, which does migration of data between different types of databases.
I used Claude to code test data generators, test change generators, a deep-crawl correctness validator, and a test harness.
I've written things like these "by hand" several times in the past, and they are tedious but rather straightforward engineering tasks, but they take quite a bit of time to get right.
One big thing that Claude does is it wants to be "lazy", so you have to make darn sure it doesn't do things like hack the test validation code to make a particular test pass!
For testing, Claude is awesome in many ways. It grinds through numerous logs, quickly uncovering the root problem and recommending a solution, that is correct most of the time (but here you still need to watch its "laziness": it will recommend working around a problem that it identifies versus fixing the thing that generated the badness in the first place. So, if you're using it like this, you have to stop Claude from "localized" fixes.
It helps if you give Claude clear directions about stuff like "we will always use Standard Format X for Datatype Y in our 'consumer' - if we're not seeing X, the fault is in the 'producer' that give us Format Z, not the fact that we can't parse Format Z".
Using Claude Code for this stuff has saved us several man-months of time in coding the test infrastructure as well as grinding through several dozen combinations of load-types and source/target combinations.
Claude is awesome at identifying weird datatype format problems and other tedious things that are huge pains-in-the-ass for human programmers, especially if the solution involves combining log crawls, code digging, and looking up stuff online. Claude can do this in a couple of minutes, while even an experienced programmer may spend hours futzing with this sort of stuff.
Also, Claude is good at stuff like generating parallelized code or adding parallelism to existing code.
Where Claude isn't great is at high-level design. You need to come up with the high-level plan of how you want your stuff to work, carefully specify it in a set of prompts (or a spec document that's in a location and format that Claude can ingest), force Claude to dialog with you about its questions, and only have it generate code once you confirm that Claude understands what you want by basically repeating your design back to you.
Claude can also flail badly if it's trying to solve something harder, particularly if the online documentation isn't good and you haven't been rigorous with your requirements. You have to keep Claude's "eye on the ball" and be rigorously consistent with what you want it to do and what you don't want it to do.
And yes, Claude can generate "wrong" or incomplete code. You have to run a lot of tests to make sure its code is correct.
And like human programmers, Claude will only do what you ask it to do, not necessarily what you wanted.