I tried Cursor again recently. Starting with an empty folder, asking it to use very popular technologies that it surely must know a lot about (Typescript, Vite, Vue, and Tailwind). Should be a home run.

It went south immediately. It was confused about the differences between Tailwind 3 and 4, leading to a broken setup. It wasn’t able to diagnose the problem but just got more confused even with patient help from me in guiding it. Worse, it was unable to apply basic file diffs or deletes reliably. In trying to diagnose whether this is a known issue with Cursor, it decided to search for bug reports - great idea, except it tried to search the codebase for it, which, I remind you, only contained code that it had written itself over the past half hour or so.

What am I doing wrong? You read about people hyping up this technology - are they even using it?

EDIT: I want to add that I did not go into this antagonistically. On the contrary, I was excited to have a use case that I thought must be a really good fit.

My recent experience has been similar.

I'm seeing that the people hyping this up aren't programmers. They believe the reason they can't create software is they don't know the syntax. They whip up a clearly malfunctioning and incomplete app with these new tools and are amazed at what they're created. The deficiencies will sort themselves out soon, they believe. And then programmers won't be needed at all.

Most people do not have the talent and/or discipline to become good programmers and resent those who do. This alone explains a lot of the current argument.

Just trying to help explain the issues you've been hitting, not to negate your experience.

First, you might've been using a model like Sonnet 3.7, whose knowledge cutoff doesn't include Tailwind 4.0. The model should know a lot about the tech stack you mentioned, but it might not know the latest major revisions if they were very recent. If that is the case (you used an older model), then you should have better luck with a model like Sonnet 4 / Opus 4 (or by providing the relevant updated docs in the chat).

Second, Cursor is arguably not the top tier hotness anymore. Since it's flat-rate subscription based, the default mode of it will have to be pretty thrifty with the tokens it uses. I've heard (I don't use Cursor) in Cursor Max Mode[0] improves on that (where you pay based on tokens used), but I'd recommend just using something like Claude Code[1], ideally with its VS Code or IntelliJ integration.

But in general, new major versions of sdk's or libraries will cause you a worse experience. Stable software fares much better.

Overall, I find AI extremely useful, but it's hard to know which tools and even ways of using these tools are the current state-of-the-art without being immersed into the ecosystem. And those are changing pretty frequently. There's also a ton of over-the-top overhyped marketing of course.

[0]: https://docs.cursor.com/context/max-mode

[1]: https://www.anthropic.com/claude-code

I had some success doing two front-end projects. One in 2023 using Mixtral 7b local model and one just this month with Codex. I am an experienced programmer (35 years coding, 28 professionally). I hate Web design and I never cared to learn JavaScript.

The first project was a simple touch based control panel that communicates via REST/Websocket and runs a background visual effect to prevent the screen burn-in. It took a couple of days to complete. There were often simple coding errors but trivial enough to fix.

The second is a 3D wireframe editor for distributed industrial equipment site installations. I started by just chatting with o3 and got the proverbial 80% within a day. It includes orbital controls, manipulation and highlighting of selected elements, property dialogs. Very soon it became too unwieldy for the laggard OpenAI chat UI so I switched to Codex to complete most of the remaining features.

My way with it is mostly:

- ask no fancy frameworks: my projects are plain JavaScript that I don't really know, makes no sense to pile on React and TypeScript atop of it that I am even less familiar with

- explain what I want by defining data structures I believe are the best fit for internal representation

- change and test one thing at a time, implement a test for it

- split modules/refactor when a subsystem gets over a few hundred LOC, so that the reasoning can remain largely localized and hierarchical

- make o3 write an llm-friendly general design document and description of each module. Codex uses it to check the assumptions.

As mentioned elsewhere the code is mediocre at best and it feels a bit like when I've seen a C compiler output vs my manually written assembly back in the day. It works tho, and it doesn't look to be terribly inefficient.

> It was confused about the differences between Tailwind 3 and 4

I have the same issue with Svelte 4 vs 5. Adding some notes to the prompt to be used for that project helps sort of.

It didn’t seem like it ever referred to documentation? So, obviously if it’s only going to draw on its ”instinctual” knowledge of Tailwind, it’s more likely to fallback on a version that’s been around for longer, leading to incompatibilities with the version that’s actually installed. A human doing the same task would probably have the setup guide on the website at hand if they realized they were feeling confused.

It would be nice if you could download some minified-for-LLM doc file that gave the LLM the public interface of the lib(s) you were using.

https://context7.com/jj-vcs/jj?tokens=55180 is supposed to be this, I have yet to try it though.

Tailwind 4 has been causing Claude a lot of problems for me, especially when upgrading projects.

I managed to get it to do one just now, but it struggled pretty hard, and still introduced some mistakes I had to fix.

In addition to not enjoying it, I also don’t learn anything, and I think that makes it difficult to sustain anything in the middle of the spectrum between “I won’t even look at the code; vibes only” and advanced autocomplete.

My experience has been that it’s difficult to mostly vibe with an agent, but still be an active participant in the codebase. That feels especially true when I’m using tools, frameworks, etc that I’m not already familiar with. The vibing part of the process simultaneously doesn’t provide me with any deeper understanding or experience to be able to help guide or troubleshoot. Same thing for maintaining existing skills.

It's like trying to learn math by reading vs by doing. If all you're doing is reading, it robs you of the depth of understanding you'd gain by solving things yourself. Going down wrong paths, backtracking, finally having that aha moment where things click, is the only way to truly understand something.

Now, for all the executives who are trying to force-feed their engineering team to use AI for everything, this is the result. Your engineering staff becomes equivalent to a mathematician who has never actually done a math problem, just read a bunch of books and trusted what was there. Or a math tutor for your kid who "teaches" by doing your kid's homework for them. When things break and the shit hits the fan, is that the engineering department you want to have?

I'm fairly certain that I lost a job opportunity because the manager interviewing me kept asking me variations of how I use AI when I code.

Unless I'm stuck while experimenting with a new language or finding something in a library's documentation, I don't use AI at all. I just don't feel the need for it in my primary skill set because I've been doing it so long that it would take me longer to get AI to an acceptable answer than doing it myself.

The idea seemed rather offensive to him, and I'm quite glad I didn't go to work there, or anywhere that using AI is an expectation rather than an option.

I definitely don't see a team that relies on it heavily having fun in the long run. Everyone has time for new features, but nobody wants to dedicate time to rewriting old ones that are an unholy mess of bad assumptions and poorly understood.

My company recently issued an "Use AI in your workflow or else" mandate and it has absolutely destroyed my motivation to work

Even though there are still private whispers of "just keep doing what you're doing no one is going to be fired for not using AI", just the existence of the top down mandate has made me want to give up and leave

My fear is that this is every company right now, and I'm basically no longer a fit for this industry at all

Edit: I'm a long way from retirement unfortunately so I'm really stuck. Not sure what my path forward is. Seems like a waste to turn away from my career that I have years of experience doing, but I struggle like crazy to use AI tools. I can't get into any kind of flow with them. I'm constantly frustrated by how aggressively they try to jump in front of my thought process. I feel like my job changed from "builder" to "reviewer" overnight and reviewing is one of the least enjoyable parts of the job for me

I remember an anecdote about Ian McKellen crying on a green screen set when filming the Hobbit, because Talking to a tennis ball on a stick wasn't what he loved about acting

I feel similarly with AI coding I think

I just don't understand your company and the company OP interviewed for. This is like mandating everyone use syntax highlighting or autocomplete, or sit in special type of chair or use a standing desk, and making their use a condition for being hired. Why are companies so insistent that their developers "use AI somehow" in their workflows?

Shareholders are salivating at the prospect of doing either the same amount of work with fewer salaries or more work with the same salaries

There is nothing a VC loves more than the idea of extracting more value from people without investing more into them

So you promote the most efficient employees and let them use tools like AI if they like

I disagree with siblings that it's fear or greed.

I think it's way more basic. Much like recruiters calling me up and asking about 'kubernetes' they are just trying to get a handle on something they don't really understand. And right now all stickers point to 'AI' as the handle that people should pull on to get traction in software.

It is incredibly saddening to me that people do pattern matching and memorize vocabulary instead of trying to understand things even at a basic level so they can reason about it. But a big part of growing up was realizing that most people don't really understand or care to understand things.

FOMO. They don't want to risk being the one company left behind because their engineers haven't learned to use AI as efficiently as others.

There are lots of ways to use AI coding tools.

Cursor is great for fuzy search across the legacy project. Requests like "how you do X here" can help a lot while fixing old bug.

Or adding a documents. Commit description generated based on diff. Or adding a javadoc to your methods.

Whatever step in your workflow which consists of rewriting existing text but not creating anything new - use Cursor or similar AI tool.

The other side of me thinks that maybe the eventual landing point of all this is a merger of engineering and PM. A sizeable chunk of engineering work isn't really anything new. CRUD, jobs, events, caching, synchronization, optimizing for latency, cost, staleness, redundancy. Sometimes it amazes me that we're still building so many ad-hoc ways of doing the same things.

Like, say there's a catalog of 1000 of the most common enterprise (or embedded, or UI, or whatever) design patterns, and AI is good at taking your existing system, your new requirements, identifying the best couple design patterns that fit, give you a chart with the various tradeoffs, and once you select one, are able to add that pattern to your existing system, with the details that match your requirements.

Maybe that'd be cool? The system/AI would then be able to represent the full codebase as an integration of various patterns, and an engineer, or even a technical PM, could understand it without needing to dive into the codebase itself. And hopefully since everything is managed by a single AI, the patterns are fairly consistent across the entire system, and not an amalgamation of hundreds of different individuals' different opinions and ideals.

Another nice thing would be that huge migrations could be done mostly atomically. Currently, things like, say, adding support in your enterprise for, say, dynamic authorization policies takes years to get every team to update their service's code to handle the new authz policy in their domain, and so the authz team has to support the old way and the new way, and a way to sync between them, roughly forever. With AI, maybe all this could just be done in a single shot, or over the course of a week, with automated deployments, backfill, testing, and cleanup of the old system. And so the authz team doesn't have to deal with all the "bugging other teams" or anything else, and the other teams also don't have to deal with getting bugged or trying to fit the migration into their schedules. To them it's an opaque thing that just happened, no different from a library version update.

With that, there's fewer things in flight at any one time, so it allows engineers and PMs to focus on their one deliverable without worrying how it's affecting everyone else's schedules etc. Greater speed begets greater serializability begets better architecture begets greater speed.

So, IDK, maybe the end game of AI will make the job more interesting rather than less. We'll see.

The one place it really shines for me personally is bash scripts.

I've probably written 50 over the last two years for relatively routine stuff that I'd either not do (wasn't that important) or done via other means (schelpping through aws cli docs comes to mind) at 2x the time. I get little things done that I'd otherwise have put off. Same goes for IaC stuff for cloud resources. If I never have to write Terraform or Cloudformation again, I'd be fine with that.

Autocomplete is hit or miss for me--vscode is pretty good with CoPilot, Jetbrains IDEs are absolutely laughably bad with CoPilot (typically making obvious syntax errors on any completion for a function signature, constructor, etc) to the point that I disabled it.

I've no interest in any "agent" thingys for the time being. Just doesn't interest me, even if it's "far better than everyone" or whatever.

> My main issue with vibe coding etc is I simply don't enjoy it. Having a conversation with a computer to generate code that I don't entirely understand and then have to try to review is just not fun. It doesn't give me any of the same kind of intellectual satisfaction that I get out of actually writing code.

I am the opposite. After a few decades of writing code, it wasn't "fun" to write yet another file parser or hook widget A to API B -- which is >99% of coding today. I moved into product management because while I still enjoy building things, it's much more satisfying/challenging to focus on the higher-level issues of making a product that solves a need. My professional life became writing specs, and reviewing code. It's therefore actually kind of fun to work with AI, because I can think technically, but I don't have to do the tedious parts that make me want to descend into a coma.

I could care less if I'm writing a spec for a robot, or I'm writing a spec for a junior front-end engineer. They're both going to screw up, and I'm going to have to spend time explaining the problem again and again...at least the robot never complains and tries really hard to do exactly what I ask, instead of slacking off, doing something more intellectually appealing, getting mired in technical complexity, etc.

After like the 20th time explaining the same (simple) problem to the AI that it is unable to fix, you just might change your mind [1]. At that point you just have to jump in and get dirty.

Do this a few times and you start to realize it is kinda of worse than just being in the driver's seat in terms of the coding right from the start. For one thing, when you jump in, you are working with code that is probably architectured quite differently from the way you normally do, and you have no developed the deep mental model that is needed to work with the code effectively.

Not to say the LLMs are not useful, especially in agent mode. But the temptation is always to trust and task them with more than they can handle. maybe we need an agent that limits the scope of what you can ask it to do, to keep you involved at the necessary level.

People keep thinking we are at the level where we can forget about the nitty gritty of the code and rise up the abstraction level, when this is nothing close to the truth.

[1] Source: me last week trying really hard to work like you are talking about with Claude Code.

> After like the 20th time explaining the same (simple) problem to the AI that it is unable to fix, you just might change your mind [1]. At that point you just have to jump in and get dirty.

You're assuming that I haven't. Yes, sometimes you have to do it yourself, and the people who are claiming that you can replace experienced engineers with these are wrong (at least for now, and for non-trivial problems).

> Do this a few times and you start to realize it is kinda of worse than just being in the driver's seat in terms of the coding right from the start. For one thing, when you jump in, you are working with code that is probably architectured quite differently from the way you normally do, and you have no developed the deep mental model that is needed to work with the code effectively.

Disagree. There's not a single piece of code I've written using these that I haven't carefully curated myself. Usually the result (after rounds of prompting) is smaller, significantly better, and closer to my original intended design than what I got out of the machine on first prompt.

I still find them to be a significant net enhancement to my productivity. For me, it's very much like working with a tireless junior engineer who is available at all hours, willing to work through piles of thankless drudgery without complaint, and also codes about 100x faster than I do.

But again, I know what I'm doing. For an inexperienced coder, I'm more inclined to agree with your comment. The first drafts that these things emit is often pretty bad.

You touched on the significant thing that separates most of the AI code discourse in the two extremes: some people just don't like programming and see it as a simple means to an end, while others love the process of actually crafting code.

Similar to the differences between an art collector and a painter. One wants the ends, the other desires the means.

That's not fair, and not what I am saying at all.

I enjoy writing code. I just don't enjoy writing code that I've written a thousand times before. It's like saying that Picasso should have enjoyed painting houses for a living. They're both painting, right?

(to be painfully clear, I'm not comparing myself to Picasso; I'm extending on your metaphor.)

You would rather debug the low quality LLM code that you know you could write better, a thousand times?

> occasionally makes mistakes

Well. Maybe we have to agree to disagree but I think it makes mistakes far more frequently than I do

Even if it makes mistakes exactly as often as I do, making 100x as many mistakes in the same amount as time seems like it would be absolutely impossible to keep up with

I love coding, do it for fun outside of my job, and find coding with an LLM very enjoyable.

I've been experimenting with LLM coding for the past few months on some personal projects. I find it makes coding those projects more enjoyable since it eliminates much of the tedium that was causing me to delay the project in the first place.

Exactly the same for me...now whenever I hit something like "oh god, I want to change the purpose of this function/variable, but I need to go through 500 files, and see where it's used, then make local changes, then re-test everything...", I can just tell the bot to do it.

I know a lot of folks would say that's what search & replace is for, but it's far easier to ask the bot to do it, and then check the work.

> "oh god, I want to change the name of this function/variable, but I need to go through 500 files, and see where it's used, then make local changes, then re-test everything..."

Forgive me for being dense, but isn't it just clicking the "rename" button on your IDE, and letting it propagate the change to all definitions and uses? This already existed and worked fine well before LLMs were invented.

Yeah, sorry...I re-read the comment and realized I wasn't being clear. It's bigger than just search/replace. Already updated what I wrote.

The far more common situation is that I'm refactoring something, and I realize that I want to make some change to the semantics or signature of a method (say, the return value), and now I can't just use search w/o also validating the context of every change. That's annoying, and today's bots do a great job of just handling it.

Another one, I just did a second ago: "I think this method X is now redundant, but there's a minor difference between it, and method Y. Can I remove it?"

Bot went out, did the obvious scan for all references to X, but then evaluated each call context to see if I could use Y instead.

(But even in the case of search & replace, I've had my butt saved a few times by agent when it caught something I wasn't considering....)

I really like working with LLMs but one thing I've noticed is that the obvious transformation of "extract this functionality into a helper function and then apply that throughout the codebase" is one I really actually enjoy doing myself; replacing 15 lines of boilerplate-y code in a couple dozen places with a single helper call is _really_ satisfying; it's like my ASMR.

Hah, well, to each their own. That's exactly the kind of thing that makes me want to go outside and take a walk.

Regardless of what your definition of horrible and boring happens to be, just being able to tell the bot to do a horrible boring thing and having it done with like a junior level intelligence is so experience enhancing that it makes coding more fun.

I find elimination of inertia and preservation of momentum to be the biggest wins; it's just that my momentum isn't depleted by extracting something out into a helper.

People should try this kind of coding a couple times just because it's an interesting exercise in figuring out what parts of coding are important to you.

Yes, that particular example modern editors do just fine. Now imagine having that for almost any rote transformation you wanted regardless of complexity (so long as the change was rote and describable).

I love programming, I just don't like CRUDing, or API'ing...

I also love programming behaviours and interactions, just not creating endless C# classes and looking at how to implement 3D math

After a long day at the CRUD factory, being able to vibe code as a hobby is fun. Not super productive, but it's better than the alternative (scrolling reels or playing games)

> You touched on the significant thing that separates most of the AI code discourse in the two extremes: some people just don't like programming and see it as a simple means to an end, while others love the process of actually crafting code.

Yeah this is for sure true, but it's probably true in degrees.

I think there was even a study or something (from GitHub maybe) about the frequency of languages and how there were far more commits in say Rust on weekends than weekdays (don't quote me on this).

Plenty of people like programming but really don't find yet-another-enterprise-CRUD-with-React-front-end thing to be thrilling, so they will LLM-pasta it to completion but otherwise would have fun hacking away in langs/stuff they like.

I identify with that (hypothetical) crowd.

I think I could be happy switching between the two modes. There's tasks that are completely repetative slop that I've fully offloaded to AI with great satisfaction. There's others I enjoy that I prefer to use AI for consultation only. Regardless, few people liked doing code review before with their peers and somehow we've increased one of the least fun parts of the job.

Same. After doing this for decades, so much programming work is tedious. Maybe 5% to 20% of the work is interesting. If I can get a good chunk of that other 80%+ built out quickly with a reasonable level of quality, then we're good.

Your use case seems relatively well-suited to AI. Even an unreliable technology like LLMs could be useful for automating a task that is mundane, well-defined, and easy to review for accuracy.

> After a few decades of writing code, it wasn't "fun" to write yet another file parser or hook widget A to API B -- which is >99% of coding today.

If this is your experience of programming, then I feel for you, my dude, because that sucks. But it is definitely not my experience of programming. And so I absolutely reject your claim that this experience represents "99% of programming" -- that stuff is rote and annoying and automate-able and all that, no argument, but it's not what any senior-level engineer worth their salt is spending any of their time on!

People who don’t do 1)API connecting, 2)Web design using popular frameworks or 3) requirements wrangling with business analysts have jobs that will not be taken over by AI anytime soon. I think 99% of jobs is pushing it, but I definitely think the vast majority of IT jobs fit into the above categories. Another benchmark would be how much of your job is closer to research work.

> that I don't entirely understand

That's the bigger issue in the whole LLM hype that irks me. The tacit assumption that actually understanding things is now obsolete, as long as the LLM delivers results. And if it doesn't we can always do yet another finetuning or try yet another magic prompt incantation to try and get it back on track. And that this is somehow progress.

It feels like going back to pre-enlightenment times and collecting half-rationalized magic spells instead of having a solid theoretical framework that let's you reason about your systems.

Well... I'm torn here.

There is a magic in understanding.

There is a different magic in being able to use something that you don't understand. Libraries are an instance of this. (For that matter, so is driving a car.)

The problem with LLMs is that you don't understand, and the stuff that it gives you that you don't understand isn't solid. (Yeah, not all libraries are solid, either. LLMs give you stuff that is less solid than that.) So LLMs give you a taste of the magic, but not much of the substance.

I'm the opposite. I haven't had this much fun programming in years. I can quickly iterate, focus on the creative parts and it really helps with procrastination.

Considering the actual Vatican literally linked AI to the apocalypse, and did so in the most official capacity[1], I don't think avoiding AI has to be ludditism.

[1] Antiqua et Nova p. 105, cf. Rev. 13:15

Full link and relevant quote:

https://www.vatican.va/roman_curia/congregations/cfaith/docu...

> Moreover, AI may prove even more seductive than traditional idols for, unlike idols that “have mouths but do not speak; eyes, but do not see; ears, but do not hear” (Ps. 115:5-6), AI can “speak,” or at least gives the illusion of doing so (cf. Rev. 13:15).

It quotes Rev. 13:15 which says (RSVCE):

> and it was allowed to give breath to the image of the beast so that the image of the beast should even speak, and to cause those who would not worship the image of the beast to be slain.

That was a very interesting read, thanks for linking it!

I think the unfortunate reality of human innovation is that too many people consider that technological progress is always good for progresses sake. Too many people create new tools, tech, etc. without really stopping to take a moment and think or have a discussion on what the absolute worst case applications of their creation will be and how difficult it'd be to curtail that kind of behavior. Instead any potential (before creation) and actual (when it's released) human suffering is hand waved away as growing pains necessary for science to progress. Like those websites that search for people's online profiles based on image inputs sold by their creators as being used to find long lost friends or relatives when everyone really knows it's going to be swamped by people using it to doxx or stalk their victims, or AI photo generation models for "personal use" being used to deep fake nudes to embarrass and put down others. In many such cases the creators sleep easy at night with the justification that it's not THEIR fault people are misusing their platforms, they provided a neutral tool and are absolved of all responsibility. All the while they are making money or raking in clout fed by the real pain of real people.

If everyone took the time to weigh the impact of what they're doing even half as diligently as that above article (doesn't even have to be from a religious perspective) the world would be a lot brighter for it.

> Too many people create new tools, tech, etc. without really stopping to take a moment and think or have a discussion on what the absolute worst case applications of their creation will be

"Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should." -Jeffrey L. Goldblum when ILM showed him an early screening of Jurassic Park.

> In many such cases the creators sleep easy at night with the justification that it's not THEIR fault people are misusing their platforms, they provided a neutral tool and are absolved of all responsibility.

The age old question of gun control.

Guns (and really most forms of progress in warfare and violence) undoubtedly fall under a similar conundrum.

Funny to note that at least one inventor who contributed greatly to modern warfare (the creator of the gatling gun) did seem to reflect on his future impact but figured it'd go in the opposite direction- that a weapon that could replace a hundred soldiers with one would make wars smaller and less devastating, not more!

I emphasize that it's the Vatican because they are the most theologically careful of all. This isn't some church with a superstitious pastor who jumps to conclusions about the rapture at a dime drop. This is the Church which is hesitant to say literally anything about the book of Revelation at all, which is run by tired men who just want to keep the status quo so they can hopefully hit retirement without any trouble.

> and then have to try to review

I think (at least by the original definition[0]) this is not vibe coding. You aren't supposed to be reviewing the code, just execute and pray.

[0]: https://xcancel.com/karpathy/status/1886192184808149383

Perhaps we're feeling too much pressure to pick an extreme stance. Can we firmly establish a middle-ground party? I feel like a lot of people here fit into a norm of "AI is very useful, but may upend many people's lives, and not currently suitable for every task" category. (There may be variations of course depending on how worried you are about FOOM.)

We need a catchy name.

This was my experience until recently.. now I'm currently quite enjoying assigning small PRs to copilot and working through them via the GitHub PR interface. It's basically like managing a junior programmer but cheaper and faster. Yes that's not as much fun as writing code but there isn't time for me to write all the code myself.

Can you elaborate on the "assign PR's" bit?

I use Cursor / ChatGPT extensively and am ready to dip into more of an issue / PR flow but not sure what people are doing here exactly. Specifically for side projects, I tend to think through high level features, then break it down into sub-items much like a PM. But I can easily take it a step further and give each sub issue technical direction, e.g. "Allow font customization: Refactor tailwind font configuration to use CSS variables. Expose those CSS variables via settings module, and add a section to the Preferences UI to let the user pick fonts for Y categories via dropdown; default to X Y Z font for A B C types of text".

Usually I spend a few minutes discussing w/ ChatGPT first, e.g. "What are some typical idioms for font configuration in a typical web / desktop application". Once I get that idea solidified I'd normally start coding, but could just as easily hand this part off for simple-ish stuff and start ironing out he next feature. In the time I'd usually have planned the next 1-2 months of side project work (which happens, say, in 90 minute increments 2x a week), the Agent could knock out maybe half of them. For a project i'm familiar with, I expect I can comfortably review and comment on a PR with much less mental energy than it would take to re-open my code editor for my side project, after an entire day of coding for work + caring for my kids. Personally I'm pretty excited about this.

I have not had great experiences interacting directly with LLMs except when asking for a snippet of code that is generic and commonly done. Now with GitHub Copilot (you need a Pro Plus I think) I'm creating an issues, assigning to Copilot, and then having a back and forth on the PR with Copilot until it's right. Exactly as I would with a junior dev and honestly it's the first time I've felt like AI could make a noticeable difference to my productivity.

I'm not your parent, but Claude at least has the ability to integrate with GitHub such that you can say "@claude please try to fix this bug" on an issue and it'll just go do it.

> Luddite

The luddites were not against progress or the technology itself. They were opposed to how it was used, for whose benefit, and for whose loss [0].

The AI-Luddite position isn’t ain’t AI, it’s (among other things anti mass copyright theft from creators to train something with the explicit goal of putting them out of a job, without compensation. All while producing an objectively inferior product but passing it off as a higher quality one.

[0]: https://www.hachettebookgroup.com/titles/brian-merchant/bloo...

> Having a conversation with a computer to generate code that I don't entirely understand and then have to try to review is just not fun.

Same for me. But maybe that's ultimately an UX issue? And maybe things will straighten out once we figure out how to REALLY do AI assisted software development.

As an anology: Most people wouldn't want to dig through machine code/compiler output. At least not without proper tooling.

So: Maybe once we have good tools to understand the output it might be fun again.

(I guess this would include advances in structuring/architecting the output)

> As an anology: Most people wouldn't want to dig through machine code/compiler output. At least not without proper tooling.

My analogy is GUI builders from the late 90s that let you drag elements around, then generated a pile of code. They worked sometimes, but God help you if you wanted to do something the builder couldn't do, and had to edit the generated code.

Looking at compiler output is actually more pleasant. You profile your code, find the hot spots, and see that something isn't getting inlined, vectorized, etc. At that point you can either convince the compiler to do what you want or rewrite it by hand, and the task is self-contained.

Tim doesn't address this in his essay, so I'm going to harp on it: "AI will soon be able to...". That phrase is far too load-bearing. The part of AI hype that says, "sure, it's kinda janky now, but this is just the beginning" has been repeated for 3 years now, and everything has been just around the corner the entire time. It's the first step fallacy, saying that if we can build a really tall ladder now, surely we'll soon be able to build a ladder tall enough to reach the moon.

The reality is that we've seen incremental and diminishing returns, and the promises haven't been met.

Diminishing returns? Am I reading right that you believe the last 6 months has been marked by a decrease in the capability of these systems?

That's not what diminishing returns means.

That's true, but it's nearest bit of evidence at hand to how the "returns" could be "diminishing". I'm fine if someone wants to provide any other coherent claim as to how we're in a "diminishing returns" state with coding LLMs right now.

What's the implication of this story to someone who had started writing code with LLMs 6 months ago, and is today as well. How has their experience changed? Have the returns to that activity diminished?

The compiler analogy doesn’t quite fit, because the essential difference is that source code is (mostly) deterministic and thus can be reasoned about (you can largely predict in detail what behavior code will exhibit even before writing it), which isn’t the case for LLM instructions. That’s a major factor why many developers don’t like AI coding, because every prompt becomes a non-reproducible, literally un-reasonable experiment.

I think the "largely" in there is interesting and load-bearing: a lot of people find compiler output quite surprising!

But that doesn't mean that it's not a gradient, and LLM output may be meaningfully harder to reason about than compiler output, and that may matter.

Assembly output may sometimes be surprising, but maintains the language semantics. The surprise comes from either misunderstanding the language semantics, or from performance aspects. Nevertheless, if you understand the language semantics correctly, the program behavior resulting from the output is deterministic and predictable. This is not true for LLMs.

I don't disagree on a factual level, I am just describing some people's subjective experiences: some language semantics can be very subtle, and miscompilation bugs are real. Determining if it is just an aggressive optimization or a real codegen bug can be difficult sometimes, that's all.

To some extent yes, but I don’t think that changes much about the distinction to AI coding I was making. The thing is that language misconceptions are fixable; the LLM unpredictability isn’t.

I think that AI assistance in coding will become enjoyable for me once the technology exists for AI to translate my brainwaves into text. Then I could think my code into computer, greatly speeding the OODA loop of programming.

As it is, giving high-level directives to an LLM and debugging the output seems like a waste of my time and a hindrance to my learning process. But that's how professional coding will be done in the near future. 100% human written code will become like hand-writing a business letter in cursive: something people used to be taught in school, but no one actually does in the real world because it's too time-consuming.

Ultimately, the business world only cares about productivity and what the stopwatch says is faster, not whether you enjoy or learn from the process.

> It doesn't give me any of the same kind of intellectual satisfaction that I get out of actually writing code.

Writing code is a really fun creative process:

1. Conceive an exciting and useful idea

2. Comprehend the idea fully from its top to its bottom

3. Translate the idea into specific instructions utilizing known mechanics

4. Find the beautiful middleground between instruction and abstraction

5. Write lots and lots of code!

6. Find where your conception was flawed and fix it as necessary.

7. Repeat steps 2-6 until the thing works just as you dreamed or you give up.

It's maybe the most fun and exciting mixture of art and technology ever.

I forgot to say the second part:

Using AI is the same as code-review or being a PM:

1. Have an ideal abstraction

2. Reverse engineer an actual abstraction from code

3. Compare the two and see if they match up

4. If they don't, ask the author to change or fix it until it does

5. Repeat steps 2-4 until it does

This is incredibly not fun, because it's not a creative process.

You're essentially just an accountant or calculator at this point.

Sounds like me 20 years ago learning Java

It's new tech. We're all "giraffes on roller skates" whenever we start something new. Find out where you can use in your life and use it. Where you can't or don't want to, don't. Try to not get deterred by analysis paralysis when there's something that doesn't make sense. In time, you'll get it.

> My main issue with vibe coding etc is I simply don't enjoy it.

I almost enjoy it. It's kind of nice getting to feel like management for a second. But the moment it hits a bug it can't fix and you have to figure out its horrible mess of code any enjoyment is gone. It's really nice for "dumb" changes like renumbering things or very basic refactors.

When the agent spins out, why don't you just take the wheel and land the feature yourself? That's what I do. I'm having trouble integrating these two skeptical positions of "LLMs suck all the joy out of actually typing code into an editor" and "LLMs are bad because they sometimes force you to type code into an editor".

Yeah, I will say now that I've played with the AI coding tools more, it seems like there are two distinct use cases:

1 - Using coding tools in a context/language/framework you're already familiar with.

This one I have been having a lot of fun with. I am in a good position to review the AI-generated code, and also examine its implementation plan to see if it's reasonable. I am also able to decompose tasks in a way that the AI is better at handling vs. giving it vague instructions that it then does poorly on.

I feel more in control, and it feels like the AI is stripping away drudgery. For example, for a side project I've been using Claude Code with an iOS app, a domain I've spent many years in. It's a treat - it's able to compose a lot of boilerplate and do light integrations that I can easily write myself, but find annoying.

2 - Using coding tools in a context/language/framework you don't actually know.

I know next to nothing about web frontend frameworks, but for various side projects wanted to stand up some simple web frontends, and this is where AI code tools have been a frustration.

I don't know what exactly I want from the AI, because I don't know these frameworks. I am poorly equipped to review the code that it writes. When it fails (and it fails a lot) I have trouble diagnosing the underlying issues and fixing it myself - so I have to re-prompt the LLM with symptoms, leading to frustrating loops that feel like two cave-dwellers trying to figure out a crashed spaceship.

I've been able to stand up a lot of stuff that I otherwise would never have been able to, but I'm 99% sure the code is utter shit, but I also am not in a position to really quantify or understand the shit in any way.

I suppose if I were properly "vibe coding" I shouldn't care about the fact that the AI produced a katamari ball of code held together by bubble gum. But I do care.

Anyway, for use case #1 I'm a big fan of these tools, but it's really not the "get out of learning your shit" card that it's sometimes hyped up to be.

For case 2, I've had a lot of luck starting with asking the LLM "I have experience in X, Y, and Z technologies, help me translate this project in those terms, list anything this code does that doesn't align with the typical use of the technologies they've chosen". This has given me a great "intro" to move me closer to being able to understand.

Once I've done that and piked a few follow up questions, I feel much better in diving into the generated code.

So you basically read some articles about how frontend works, and that helped you understand frontend code better.

Not quite that reductive. More of, I thought about what would be the exact page/article that, if it exists, would get me started, and used the description of that as a prompt to the LLM "Learning X for people that know Y". This is especially useful because X is now curated to what you're actually working on and Y is curated to what you already know.