Starting with the ground truth: agents and LLMs hallucinate, a lot. They often get things wrong on the first try, and need either systematic validation (e.g. tests) or a human to push back on what they’re doing.

What I’ve discovered is that it’s all too easy to push aside the latter if you have the former. Tests can create a false sense of security. It’s often the case that tests can’t cover everything because of a technical limitation. On iOS, you can’t run tests against the real screen time API in the simulator. Mocks were invented for just this purpose. But a mock also obscures how an external API actually works, and the agent can judge incorrectly in this case.

To give an example, a feature I recently added within OpenAppLock was push notifications. One case where a notification should be delivered is when you’ve used an app for a certain amount of time. On a 30-minute time limit, the notification is designed to fire in a background event around 25 minutes into that limit. Separately, there’s a usage counter in the app which only updates in the foreground. Skipping out on some details, Claude read a log of the time limit event firing in the background, thought that was a bug as it didn’t update the foreground usage counter continuously, and also concluded that the notification would get batched in with that event.¹

It feels like every engineer uncovers a similar experience: they code something with an LLM, attempt to fix a behavior they notice, and the LLM trips over itself trying to “reason” about a fix. Maybe they get mislead by an incorrect doc comment written by a previous agent. Even if they correctly explain how an API is supposed to work, they stumble on interacting with it themselves. More often than not, it’s when you start looking closely at the code when something just seems off about the way an LLM is doing something.

I say this after I’ve implemented the adversarial review loops, the test-driven development loops, and more into my workflow. I thought that software was different in that you can verify correctness. That’s why I happily embraced agents strapped with a software testing loop, while being skeptical of LLM usage in other fields. Perhaps I haven’t done enough to improve the correctness of these systems. Still, even the smallest of errors and confusions continuously compound at the pace of agentic development. Without the tacit knowledge and immersion within a codebase, it’s way too easy to miss the issues that crop up.

I’m not saying no to agents, because there are still many cases where they’re useful. I recognize that agents will continue to stick around in software. But I really, really don’t want them to make me dumber as an engineer anymore.

What should a recent software engineering graduate do to advance in the industry, in June 2026? There are a flurry of different opinions on the internet right now. No, I don’t know the answer. This has been a fairly confusing time for me.

The one that stands out for me: I like coding by hand and working with agents. Much of the online advice tries to side with one or the other. And, to be clear, I don’t think the advice on either side is bad; bits and pieces can co-exist. Yes, agents can be helpful to software engineers. No, agents cannot effectively replace them; I doubt they’ll reach that point with LLMs as the backbone. I don’t think someone is “behind” if they don’t use agents, just like they’re not “behind” if they don’t exclusively program in a modern language with nice features. It’s a technology fit for certain groups of engineers in certain use cases, but not all of them.

There are people pushing full steam ahead with agentic development, while others are sick of even hearing the word. There are people I’ve spoken to, both back home in California and in Atlanta, who like the programming portion for what it is. I resonate with this viewpoint. There is no other feeling like the one of pushing against the abstraction laid out in front of you, full focus, and coming up with your own. Seeing how the behavior of your program changes falls naturally into this process.

On the flip side, I’m drawn to the thrill of launching things. This isn’t in an entrepreneurial sort of way. I think it’s my way of pushing my ideas onto the world, beyond the programming abstractions in front of me. I want to see how the world reacts to it.¹

On another note, I’ve been having nap attacks recently. The attack usually hits during my mid-afternoon slump, so I originally attributed it to just that. But no, I think this is something more than that. On days where I’m not managing agents, it never hits as hard. Normally I would get by with coffee, but when this happens, it is literally impossible to focus unless I lay down for a bit. I take off my headphones, and suddenly my vision gets blurry.

Installing the sofa in my new apartment has helped to soften the transition a little bit.

Once I lay down and close my eyes, it’s like my brain gradually stops pounding. I usually wake up and I can keep going for another hour, but it inevitably hits again. I go lay down some more. Not long afterwards, I might not be able to even look at what the agent is doing without feeling like my head’s gonna explode. All I need for this to trigger is seeing Claude Code clicking around on an iOS simulator.

This is a phenomenon that has been written about before by people far more experienced than me. Now that the easy work can be automated, what’s left is mostly the challenging design work, which is exhausting. I just (naively) never thought it would hit me this early in my career.

There’s a feeling where if you’re immersed in a piece of media for too long and then exit, my head pounds for a bit and I need to re-adjust. This happens to me when I play games. Working with agents is like this combined with the information overload of speedrunning systems design.² If agents have any place in a production system, it would be with a human at the helm of the system design, drafting and reviewing how systems are designed and reworked over time.³

To pile more fuel onto the fire, it doesn’t help that with the correct systems in place, agents can run 24/7. In conjunction, it is desirable to have a mechanism where the human can check on the agent. When I tried this, I sometimes got the urge to check on the agent to see if it was stuck on something, or if it was taking things in a direction I didn’t want it to go. These checks have actually led me to re-steer the agent a few times, which further justifies their existence. But they’re also exhausting to deal with.

The lack of determinism in agents, even the ones powered by the best LLMs, makes this a difficult problem. Maybe the correct direction is to clamp agents down into a more deterministic system, such as a harness with issue tracking and very specific loops. I’ve talked with people working on this, and I think this direction shows some promise.

I still don’t really have the answer to the question in the beginning; I feel like few people really do. I’m just guessing and leaning into what I’ve experienced. Code by hand, work with agents, and if the nap attacks hit too hard, go and live a little.

The development process started out like this:

• I started Xcode and Claude Code
• I activated the built-in MCP integration in Xcode
• I had it generate a list of requirements based on a recording
• I let it run in auto mode for some number of hours
• I installed the app on my phone, and played around with it

This video actually did the bulk of the work for me. Claude recognized I had ffmpeg installed on my system, and began extracting frames locally. From this, it got pretty far in creating a local backend and layering a frontend on top of it. This was the first insight: it was fairly easy for Claude to re-create the app because screen time blockers operate mostly on device. OpenAppLock is a fully-local app, and everything stays on-device. There is no backend to orchestrate, which is one less integration that I needed Claude to talk to.

Not only this, but the only major external API I had to talk to for this app was Apple’s screen time API. There were few dependencies even by the standards of a standalone iOS app.

I think what drew me to this project, and why I kept it as opposed to other vibe coding experiments, was that it was immediately useful to me. No, not all of the features worked on the first try, but the one most important to me (scheduled times for app blocking) did. Arguably, still not all of the features work, which is the real hurdle I’ll need to clear before putting it on the App Store. But I immediately saw how this app would fit into my personal life; then, I saw how this app could be useful to others.

Check it out if you’re interested! I can’t promise that everything works right now. But, I’ll get around to fixing the interactions with the screen time API + making the code better designed for humans to work on.

Immediately, this project took on a wider scope. Networked multiplayer brings many challenges along with it. It’s not difficult to understand conceptually, but everyone must know how to work with it. Add in real-time events that can happen anytime during a round, and a scoring system that is heavily dependent on timing and showmanship? All for a roughly ten-person team to complete in five-ish months? Good luck.

Several months into this project, there are so many things that I want to fix, given the time. But we’re at a point where the game can be seen as fun. And to a degree, I think that’s mostly what matters.

It’s more interesting to smash every aspect of the game together instead of trying to perfect this piece of software. That can’t be said about a regular old frontend app or a critical piece of backend infrastructure.¹ You can have perfectly structured code, but if you can’t move at the pace of the different roles on a team, then the game becomes less fun. The gameplay mechanics, the game feel, and how it looks all contribute far more to a game’s fun-ness far more than a refactoring job.

All in all, fun-ness is a significantly different metric than I’m used to. You can’t really optimize for it; fun-ness is not to be solved as an engineering problem. Fun-ness is a uniquely human attribute that can not only be assigned to games, but to all sorts of human creation. It cannot be ranked by artificial intelligence, or other forms of automation, in the same way that stability can. If humans don’t find something fun, then it’s simply not fun.

From a traditional engineering perspective, it feels like there’s less affordability to cut features that “aren’t achievable.” You can cut game mechanics from a design perspective, but that is not the role of the engineer.

There was a talk at this year’s GDC that I missed and wish I had gone to, and it was about the creation of Peak. My key takeaway from my friends who attended it was the term cowboy coding, which is just another way to say: fuck it, we ball.

And I love this attitude for games, in a way that I don’t for critical infrastructure.² Ultimately, for a small team, you’re limited by what you can do. Games are such a complex piece of software, and for a small team, that imposes a lot of limitations. With a big team, you can throw all the resources you have at, say, QA or build engineering, and ensure stabilization that way. With a small team, most of your team needs to be focused on finding the fun. It’s okay if the code suffers a bit as a result.

Of course, there comes a point where it’s good to take a step back and control for code quality. It just can’t come at the expense of fun. Without code quality, there is still a game; Without fun, there is none.

I’m not really a party person.

Sure, I went to some parties during my freshman year, but I can’t say that I got anything out of them. They’re a hazy memory in the distant past, a blur on a forgotten album cover.

Instead, the hangouts I go to now are a little different. My friends have taken to calling it the “chiller,” which implies a completely different vibe than the traditional college party. And it is.

You’ll see the doom scrollers, the people lying on the couch, joined by those who drank too much alcohol that night. On the other side of the room, there are the people playing Settlers of Catan or the (officially licensed) Jujutsu Kaisen survival game. Maybe there’s some people drinking on a balcony or back porch. Occasionally there’s a movie playing, which might be in the background or with everyone gather around. The lights are usually dimmed out.

It’s not quite a party, but it’s also not just a hangout. You could think of it as a downscaled party with more breathing space, literally and metaphorically. Or, it’s like a hangout that’s scaled up with concurrent activities happening. Whatever the interpretation is, the core premise is the same. This is the college party, but decentralized.

A compelling reason for the chiller might be the expectations of society on this generation, which have caused some chaos. Derek Thompson summarizes it well when he says that we’ve incidentally built a “world of greater professional ambition, more intensive parenting, and lavish entertainment abundance.” There’s a demographic in this generation that has never known a reality without these three elements.

A world of greater professional ambition is normal when it’s harder than ever to find a job, especially in computer science where I am; the pressure is on to constantly improve one’s resume and portfolio projects. I have historically been terrible at pushing back against the constant urge to work on this, and I know others are too. Even without this direct pressure, there is pressure in the social media age to maintain a “cleaner” reputation. After all, employers check social media too.

Intensive parenting is when my mom kept a watchful eye on my sister as she attended private school, underwent the hardest classes, and applied to top colleges. It’s also why my brother is undergoing a rotation of extracurriculars ranging from coding classes to sailing. It’s not a constant top-down directive; it’s more like instilling a belief in my siblings that this is what success looks like.

Finally, the abundance of entertainment has always been prevalent in our lives. For someone my age, the introduction of video streaming was announced by Netflix when we were just 3 years old. Video streaming, music streaming, and social media have all displaced what came before in some shape or form. Now, with TikTok and short-form content, we’ve arguably reached the endgame of passive content consumption.

Given these factors, I feel like the chiller (or whatever term your friends use) is a natural evolution of the college party. For a certain demographic, especially for one focused on their career, I would say it’s not just natural, but necessary.

We still want to see our friends, so why not host something which only includes these people? There are more affordances that are attractive: you don’t have to drink or do other substances, but you can. With more time dedicated to the grind, the chiller can become the primary way of engaging with friends; this is a hard-fought luxury in a traditional college party setting.

While I’m not advocating for intensive parenting, the fact that the trend exists contributes to this development too: with a more filtered exposure to the world, college presents an opportunity to get comfortable with friends at any pace one chooses. Personally, I know I didn’t make as many friends during my orientation week, but the ones I did eventually get to know became my friends for the entirety of college, and potentially beyond. In this process, had the humble chillers been replaced by larger-scale parties, I don’t think I would’ve made those connections.

Maybe the chiller concept isn’t entirely new. But in a world where the friendship recession is supposedly ever-looming, I like to think that our generation still enjoys having fun, and this is what has persisted.

Thank you for reading.

I remember when my parents first showed me the iPhone.

I was still living in Shanghai. The iPhone came out in 2007, and the first iPhone sold in China was in 2009. I was sort of mystified by the technology, but at the same time it had always been in my core memory. This is, of course, the same for most of my generation. I barely remember a time without the iPhone.

My first memories with smartphones were mostly playing games. These were the O.G. smartphone games: think the original Plants vs. Zombies or Angry Birds.

On the other hand, WeChat was more like an entity that suddenly spawned into memory. We had permanently moved to the U.S. by the time it came around. I still remembered seeing the little QQ status bar icon on my dad’s home computer, or when my mom would bring me to work. As more and more things shifted to smartphones, WeChat slowly became ever-present and QQ faded away.

WeChat’s rise in China was not accidental. The threat that QQ would fall to mobile competitors was realized by eventual WeChat creator Allen Zhang, who proposed a new instant messaging app to Tencent CEO Pony Ma. Under Zhang, WeChat originally launched as a simple messaging app. When that failed to gain traction, WeChat copied another competitor, Talkbox, to add voice messaging. This was a legitimate feature because speaking Chinese is easier than typing it, especially for the generations before Pinyin was taught.

Contrary to what I used to think, every feature that WeChat added was deliberate (Allen Zhang even gave a speech about their ten principles). When QR codes came to WeChat, every account got one: you could now share your account and your content in a physical space. The same QR codes were utilized for WeChat Pay, which was tied to another popular feature: the ability to send red envelopes of money to friends. Building from this success, WeChat introduced a “tipping” feature to public accounts such as content creators.

Many of these features formed the bedrock for the introduction of mini programs in 2017. Instead of developing a full native app for iOS or Android, businesses could choose to develop a program for WeChat. They could integrate with the features people already used, such as chats, WeChat Pay and QR codes.

Tencent had, piece by piece, built a whole platform within a platform. It didn’t matter that the actual innovations came from other companies; Tencent leveraged its existing features, user base, and investments where it could. At this point it didn’t even matter whether you owned an iPhone or Android in China, so long as you had WeChat.

Why would someone choose to create a tightly-bound mini program over a native app with more flexibility?

From a technical perspective, developing a mini program is more accessible than a native app. The mini program stack includes JavaScript and markup languages similar to HTML and CSS. While not equivalent to the web, the inclusion of web-like technologies means developers can utilize their existing skillsets.

This effect exists elsewhere, too. Even in the West, many popular apps (Notion, Slack, Figma as well as incumbents like Amazon and Google) primarily live on the web. There are many use cases that a web app work just fine for. Progressive web apps (PWAs) have only increased the flexibility of the web by including features previously restricted to native apps.

In this way, a mini program exists as a strange middle ground between the web app and the native app. It’s kind of a web app, but it integrates deeply with the OS, just not the type of OS that we’d come to expect.

For companies, a unique proposition of mini programs is the number of entry points and possible flows. QR codes are one of them: they can be placed in physical spaces and shared digitally. Another is from within a chat: if you want to see something a friend shares with you, going through a mini program becomes a must. Authentication is handled automatically with permissions, becoming a background detail instead of the maze of passwords and social sign-ins we have in the West.

This forms the backbone of the mini program: one should be lightweight, focused, and have multiple entry points.

The other side of this discussion I’m interested in is Apple and the App Store. Knowing how Apple treats developers and the contradictory enforcement around in-app purchases, I had always wondered about the loopholes that WeChat presented in the system. Were mini programs simply immune to the infamous 30% App Store tax?

There were several conflicts related to this. Mini programs were permitted to link to external payment methods, a practice explicitly forbidden by the App Store (until recently). Apple continually pressured Tencent into disabling these payment loopholes. Yet, for a while Apple didn’t apply the same level of enforcement it did for, say, Epic Games or Hey. While Apple was fighting to keep its 30% cut and anti-steering practices, these loopholes were seemingly ignored for a while.

This is not to say that Apple and Tencent have had other clashes in the past. Apple forced Tencent to disable the aforementioned “tipping” feature for public accounts, because it was “virtual content” that needed to go through the in-app purchase system.

In the end, Apple reversed this ruling. Part of this was undeniably that WeChat was simply too powerful of an app: make WeChat worse on your platform, and users will look elsewhere. To cover mini programs, Apple did eventually launch the Mini Apps partner program, taking 15% of commissions from mini app purchases.

As a developer, I think that the contrast in app distribution between China and the U.S. is an interesting one.

In China, businesses that normally wouldn’t make a full-fledged app could make a mini program to establish an online presence. For restaurants, storefronts, and other places offering “in-person” services, the mini program has become the primary interaction point. It certainly makes more sense to meet users where they already are, rather than inventing a way to get to them yourself.

Part of this idea has gained traction with several other apps wanting to become a “super app” like WeChat. In southeast Asia, Grab is a popular super-app which covers payments, food deliveries and ride hailing. In China, competitors of WeChat operate their own versions of mini programs, even going as far to draft a standard. In the U.S, Apple’s Mini Apps program might spur other companies to develop a platform like WeChat’s.

Would we be better off if mini programs were a thing here? I’m not sure. With WeChat’s model, the platform remains controlled by one company. A mini program may be more accessible to develop than a native app, but theoretically the freedoms afforded by it could disappear anytime. The web remains the most open and accessible method we have for distributing software to mobile, but even a PWA lacks the seamlessness and tight integration of the mini program.

There is one interesting spec which solves the integration problem, yet sticks to standard web technologies and eliminates the need for a central server. Also, people are starting to use LLMs to create small, tailored apps for personal use. All factors considered, I think there is potential for this area to grow.

In the meantime, I will continue to use my poor reading skills to order coffee in China…using a mini program in WeChat.

Thank you so much for reading, and happy Chinese New Year.

Thank you to Kate Avendano-Woodruff for helping me shape my thoughts and inspiring me to write about this, especially around the broader impact of learning and school systems. She shared with me an old speech of hers which inspired the conclusion of this essay.

It was winter break of 2022, and I had just gotten a foothold on what college life was like. I was a freshman computer science student at Chapman University’s Fowler School of Engineering. Unbeknownst to me, the following years would be significantly different compared to my first; fall 2022 was the calm before a great storm.

I remember casually reading OpenAI’s initial ChatGPT announcement. I had no clue what they were talking about in technical terms, and the examples seemed rudimentary at best. I dismissed the initial hype around the chatbot, thinking that it wasn’t for me.

Yet, after GPT-4 came out that March, I sensed that things were changing. I became part of the initial cohort playing around with it. I quickly made custom versions of the chatbot with tailored prompts. One of them read handwritten notes and generated summaries, while another attempted to work through math problems. I was also part of the Notion AI beta, which I used to generate essay outlines and proofread drafts.

This was when I first discovered that LLMs can’t actually do math, even if they could explain calculus and linear algebra pretty well. I still attempted to get ChatGPT to do math, simply because it was fascinating to watch. Seeing the token-by-token generation of a detailed but incoherent solution was mystifying in its own way. You could imagine the dopamine hit when it actually got something right.

There were few, if any, guidelines on what could be produced by LLMs for schoolwork. Suddenly, every student I knew started using it seriously. It wasn’t like a switch had been flipped, but it feels like that in my memory. Within weeks, LLMs were everywhere. Every time I walked through the Keck Center, I would see laptops with ChatGPT open. Every time I collaborated with another student on an assignment, we would both try plugging questions into the chatbot. I barely remember a time in college without this experience. My graduating class is the first to have had exposure to ChatGPT for almost all four years of college.

In a time of naivety, there was some truly wild imagination about what AI could do. At a Shark Tank night in a local (computer science) club, our group created the presentation of all time. My contribution (if one could even call it that) was the DALL-E generated imagery of AI wingmen: uncanny images of well-dressed men guaranteed to improve your rizz. None of us thought that AI companionship, now a legitimate market in multiple countries, would actually take off.

The early college years was the peak of my LLM enthusiasm, because we had yet to face some of the consequences first-hand.

Chapman wasn’t the only school embracing this technology; it seemed like suddenly, ChatGPT and friends were everywhere. This isn’t just based on vibes: according to OpenAI, one-third of college students in the U.S. used ChatGPT by February 2025.

While generative AI has struggled in the enterprise, the base product unintentionally accommodated students from the beginning. ChatGPT had always seemed ready to replace websites like Course Hero and Chegg, the latter of which cut half its workforce last year. ChatGPT was faster, cheaper, and more accessible. Where previous solutions still required students to search for answers, ChatGPT completely removed the friction of getting them.

Early on, I thought this was just the new norm: college was going to be a breeze as the tech improved. However, several factors helped shape a more nuanced understanding of LLMs and their consequences.

One belief perpetuated by the industry was that LLMs would continue to scale indefinitely. Gary Marcus’s newsletter, one of my first subscriptions on Substack, completely subverted these expectations. It was his page, and not a computer science class, where I learned that LLM progression would hit a wall; indeed it has.

There were arguments that AI would fully replace coding jobs. Even if the current job market slump is due to a variety of factors, it still felt like a reflection of this idea. We all felt this impact equally when looking for internships, and I think this was all when we were collectively like: “…oh shit.”

Copyright issues over training data became prevalent. The New York Times sued OpenAI and Perplexity in December 2023, following several author lawsuits alleging the same thing: ChatGPT could produce copyrighted text, verbatim. Further research confirms this recurring phenomenon for both text and image models.

All the while, the impact of LLMs on academic integrity heightened, both at Chapman and elsewhere. Chapman’s academic integrity committee handled a record-breaking number of cases following the release of ChatGPT. Across the country, LLMs disrupted an already weak K-12 system, becoming part of a toolkit letting students completely opt out of the learning process.

With some awareness on these issues, students continued to use LLMs. I continued to use it, for my classes and projects, as did others.

Vibe coding slowly became the norm for student projects. I figured this would eventually become the case. Out of curiosity, I took an old data structures assignment and prompted ChatGPT to do the entire thing. The results were astoundingly good for a fraction of the time.

I witnessed this transition firsthand as a tutor. For coding assignments, the default response from students was that they asked ChatGPT first. I would sift through code that looked suspiciously well-done. Each file looked good in theory, but they didn’t piece together to form one cohesive program.

Another thing that drove LLM usage was top-down messaging. The well-intentioned messaging from Fowler faculty was to have projects to showcase for employers. Nowadays, the easiest way to get there is to vibe code. I get it! It’s tempting to let AI do all the work. In my experience, though, people (and prospective employers) are interested in the technical decisions, which you should make yourself.

In the context of education, some people have equated the invention of the LLM to that of the calculator. The primary difference is that the calculator doesn’t lie. In the case of LLMs, the machine doesn’t just lie: it makes up authoritative bullshit, where there is no notion of truth. It’s just a token predictor. And yet, both are machines, and students would point to the machine and say that it told them to do something. I know I personally had a hard time convincing tutees and group partners when the LLM was just plain wrong.

Everything I’ve mentioned so far involves students using LLMs; what happens when professors get involved in the mix?

At first, the reaction to LLMs from professors and faculty in the Fowler School of Engineering was mixed. To this day, some professors require citing code assistance using something similar to the following contrived example:

#include <string>
#include <fstream>
#include <iostream>

using namespace std;

int main() {
    /* Begin assistance from ChatGPT: How do I read in a file line by line in C++? */
    ifstream file("hello.txt");
    
    string line;
    while (getline(file, line)) {
        cout << line << endl;
    }

    file.close();
    /* End assistance from ChatGPT */
    
    return 0;
}

(This example was fully written by me, and not, in fact, generated by ChatGPT)

Those same professors would ban AI assistance on quizzes and exams.

Other professors fully embraced AI. For software engineering at Chapman, there is a separate track of classes focused on software design patterns, testing methodologies and agile development. For one of my projects, I got full points for submitting a v0-generated design alongside LLM-generated documentation. To be clear: the professor encouraged this, and I was fully transparent with how I used AI to do the assignment. Future assignments were the same, and even the provided instructions and templates had clear tells of being AI-generated.

I did not take this class seriously, and I attribute this to the way that AI use was encouraged. When I got AI-generated emails and assignment instructions from some of my other professors, I felt the same way. I think the worst offender of this was a training session for my tutoring job on campus: literally everything was AI generated, from the slides to the take home assignment.

Some of these experiences represent the vicious cycle that AI can bring to education: the educator generates assignment details with AI, students’ submissions are AI-generated, and the educator likely reviews and grades submissions with AI. In other words, the educator makes grading decisions based on AI. With how inherent gender and racial biases are in current-generation LLMs, this cycle has the potential to discriminate against women, people of color, and other groups underrepresented in technology. Left unchecked, my experience was a potential disaster waiting to happen.

There is generally more awareness now of the consequences of generative AI and their limitations. The disinformation campaigns coming from authoritarian regimes like the PRC. Deepfakes becoming even easier to generate than before. Multiple deaths and suicides linked to chatbots, to the point of having a dedicated Wikipedia page.

It’s hard to pinpoint when the AI “ick” started to take hold in some of my friend groups. Even though people still use AI for help on assignments, I’m sensing a weariness when it comes to AI slop on social media.

I mentioned it earlier, but something I realize now is that AI lets people opt out of caring. It feels disingenuous to consume AI-generated emails, assignment directions, or other pieces of writing because the other person didn’t really write it. This feels like a universal experience among professors receiving fully AI-generated answers. Writing, imagery, and other media forms all constitute thinking, and there is intrinsic value in how much someone thought about the content itself.

Programming is a bit more nuanced. Peter Naur’s Programming as Theory Building encapsulates and justifies one central idea: the theory of a program is equally, if not more, important than the source code itself. The point is to maintain a mental model sophisticated enough to justify design decisions and account for future ones. I can understand the appeal of making LLM do repetitive tasks while thinking at the design level; that is, the level at which caring matters. In my experience, if I tried to put LLMs beyond this, projects became cluttered and broken. Putting this kind of program out in the real world results in security leaks.

Of course, there are serious long-term consequences to opting out of learning, which includes lived experiences and struggles. If you’re a student reading this (or anyone, really), there are plenty of reasons to care about lived experiences. They are uniquely yours. Your school can’t take them away from you, nor can some corporation. I wouldn’t let AI take those experiences away, either.