I've been programming for 30 years professionally, and I did it for a hobby as a kid. I love it still, but I am having more fun than I ever did before because none of the drudgery that goes along with it is required anymore. I love the AI and I wouldn't be sad if I never had to write another line by hand. But it's been my job, and the thing I've always hated about the job is that I didn't just get to leave it at work. My mind is always on it even when other people have shut down for a weekend or a weeklong vacation. I always have to worry about that next project that still isn't done, or isn't making an much progress while I'm away. Not as much now, because I just have to check in on Claude when I think of something I missed or need to do for some upcoming thing. It really takes away a lot of my stress because I can use it to extract action items from meetings, it help sketch designs, and write all the damned unit tests for me. Life is better now.

same here. Laptop came with me on all vacations. Major issues had to be worked out while I was in the shower, having dinner, with family, always. How am I going to fix that bug. How am I going to write that app. I can't even fit this issue into my head. I have to stare at the code for two hours just to understand this again, and find a fix. This went on for decades.

AI takes away 90% of the anxiety about new issues coming in, and half the profession thinks we've lost our minds. Systems that always take me hours to get my head around, figure out a fix, LLMs understand the whole thing. I'm no longer the only person that knows how all this ORM code in SQLAlchemy works. Something else knows too. I can bounce ideas off it. It can bounce ideas off me. The relief is immense.

oh well, losing one's mind sure leaves me a lot more time to do other things and not stress about bugs which are now all entirely fixable, including ones that have evaded explanation for years. Features that used to be "OK, that would be a lot of effort and im not sure it's really worth it", that's over. We can do anything now.

AI seems to always reveal more about people than about machines. Like "how do we actually think? how does consciousness work?" and all that. It's also showing me, "other devs see a really different world than you do".

Regardless of all the concerns that others and I have, 'leaving it at work' is one positive I noticed as well. That is a good expression for that feeling.

When the models got good enough, and I accepted some projects can be managed without writing any code... Some weight lifted from my shoulders. If I wrote code in the past, it felt like I had to carry it in production and help with its maintenance. I would think about all the edge cases that could go wrong. Now, it is not that personal. I'm not a critical piece and that is okay, relieving even.

I'm happy I'm not valuable for technical questions (incomplete, ambiguous questions that would fill up the context of my brain just to understand the question). Writing code now is like writing an email, I can write a good enough email and close the day, others can pick it up. It has freed up a lot of mental capacity. Nobody had a good understanding of that kind of personal burden anyway. Now it is everyone's problem.

We forget how sometimes some coding tasks can be detrimental to some human's psychology. World is full of texture, different situations and experiences.

>none of the drudgery that goes along with it

The durdgery is what pushes languages forward to be more powerful and expressive. Thousands of programmers all facing the same drudgework, they came up with new languages. They weren't content to just accept Java, they made Clojure, and Scala, and lots of other languages. That in turn pushed Java to keep up or be left behind. Take away the drudgery and guess what? All that goes away. Just let claude crank out 30K LoC a day, who cares now?

I still remember back to when I was first learning to write code. I dreamed of code that wrote code for me. But it wasn't because I didn't want to code. It was because I wanted to code in something more elegant. Claude is for someone who says "I don't want to code, I just want to get paid" and it really shows. Slop is slop, even before Claude came along. The programmers who just want to get paid always produced slop. They just have a machine doing it for them now. Who needs them anymore really?

That's another thing, I make programming languages for fun. And implementing the AST nodes is absolute drudgery. Now I just have to construct the grammar and play. I do still make games and play with making apps (Air guitar that detects my hands and stuff) I have even taught coding as an adjunct professor, and done weekend long code competitions, so I've been all over it. I still enjoy the hobby, BECAUSE it's no strings. I don't feel "special" and I'm ok with it.

I notices this too.

The agebt is very eager to prosuce observable results and doesn't seem to care about mental load or how difficult certain choices will make future maintenance.

Before some idiot comes up and says humans do the same. LLMs tends to go to extreme lengths way beyond human capabilities when it comes to writing brittle and unmaintanable code.

One habit I've really noticed I have to break myself of with Claude is the temptation to say "maybe later" when I have an idea. There's never a reason to do that: if something might work, I can leave Claude in a tmux window to check the details I think should exist and then just...go do something else.

Copyright doesn't cover the results of code, nor the methods used in the code, techniques and algorithms aren't covered by copyright. Period. Copyright applies to 'the work'. If you don't copy the source code, it's not covered.

They copied strings, and visual design. Both of which are work, both of which are covered by copyright.

Designs and strings are only sometimes covered under copyright.

The elements of a design that are ornamental, utilitarian, or a general look and feel are not covered under copyright but would be covered under a design patent if one exists.

Strings are only covered under copyright if they are a sufficiently original work of human expression. Simple informational messages generally wouldn't qualify.

This was copying many screens, composing layouts and many strings. not a "general look and feel" or one off utility string. Others found parts of the code copied (exact variable names). It would take a court to decide, but I think it's pretty clear cut copyright violation. They gave their agent had access to the EE code, and seemingly asked it to produce a copy. It's not a 1:1 copy, but there was a lot of copying. No clean-room attempt was even made.

If I take the first chapter of Harry Potter and write a new ending, it's still copyright violation. They took many parts.

If they did take sufficiently significant parts of copyrightable components, then yes, it would be a copyright violation. I don't think I saw overwhelming evidence of that in the OP, but certainly there is more to the story.

Whatever LLM they used copied the source code. It took their prompt and filled in the blanks of the spec by copying from the closest matching open source project. This is just what a next token predictor is going to do if you tell it to replicate software that's in its training set since that is the optimal way to predict the next tokens.

They aren't 10x gains. They're more like 3.5x gains. But still worth it. By a lot.

you are never going to get away from reading the code every time. at least I haven't seen how you could possibly. That being said, it is considerably less work to read and check the code than it is to have to build it all, even if you know what you're doing and have done it before.

I find this to be false.

Same way teaching your child to do something is much harder than to just do it yourself.

Except the child learns.

Parsing is the front end to a compiler. Can't get semantics without first recognizing syntax. I have a hard time thinking about programming languages without seeing them as a parsing exercise first, every time.

The recommended advice is to start with semantics first. Syntax will change, there is not much point fixing it down too early.

Most of the work is actually the backend, and people sort of illusion themselves into "creating a language" just because they have an AST.

Syntax and semantics are never orthogonal and you always need syntax so it must be considered from the start. Any reasonable syntax will quickly become much more pleasant to generate an ast or ir than, say, manually building these objects in the host language of the compiler which is what the semantics first crowd seem to propose.

It also is only the case that most of the work is the backend for some compilers, though of course all of this depends on how backend is defined. Is backend just codegen or is it all of the analysis between parsing and codegen? If you target a high level language, which is very appropriate for one's first few compilers, the backend can be quite simple. At the simplest, no ast is even necessary and the compiler can just mechanically translate one syntax into another in a single pass.

I think his point is that "form follows function". If you know what kind of semantics you're going to have, you can use that to construct a syntax that lends itself to using it properly.

> The recommended advice is to start with semantics first. Syntax will change, there is not much point fixing it down too early.

It's actually the reverse, in my opinion. Semantics can change much more easily than syntax. You can see this in that small changes in syntax can cause massive changes in a recursive-descent parser while the semantics can change from pass-by-reference to pass-by-value and make it barely budge.

There is a reason practically every modern language has adopted syntax sigils like (choosing Zig):

    pub fn is_list(arg: arg_t, len: ui_t) bool {

This allows the identification of the various parts and types without referencing or compiling the universe. That's super important and something that must be baked in the syntax at the start or there is nothing you can do about it.

Getting an overview of parsing theory is mainly useful to avoid making ambiguous or otherwise hard to parse grammars. Usually one can't go too wrong with a hand-written recursive descent parser, and most general-purpose language are so complicated that parser generator can't really handle them. Anyway the really interesting parts of compiling happen in the backend.

Another alternative is basing the language on S-expressions, for which a parser is extremely simple to write.

I learned from the Dragon Book, decades ago. I already knew a lot of programming at that point, but I think most people writing compilers do. I'm curious if there really is an audience of people whose first introduction to programming is writing a compiler... I would think not, actually.

Wouldn't say a lot of people use it for an introduction to programming, but I've personally seen it appear quite early in the programmers journey.

I was first exposed to compilers as a learning subject as a mandatory 2nd year/1st semester course; with the Dragon Book as the main textbook...

And they say you can't learn anything about computers from these bots... I had to learn this lesson from giving a shell account to one of my compatriots. I worked with him on group projects so I trusted him. He installed a fork bomb in his user's cron tab that went off at 3:00 a.m. everyday and I had to wonder why my hand compiled DRI driven screensaver went to a crawl. I did learn the lesson and I did forgive him. But it didn't cost me a couple Grand in API fees.

This is ultimately just going to give them training material for how to avoid this crap. They'll have to up their game to get good code. The arms race just took another step, and if you're spending money creating or hosting this kind of content, it's not going to make up for the money you're losing by your other content getting scraped. The bottom has always been threatening to fall out of the ads paid for eyeballs, And nobody could anticipate the trigger for the downfall. Looks like we found it.

> This is ultimately just going to give them training material for how to avoid this crap.

> The arms race just took another step, and if you're spending money creating or hosting this kind of content, it's not going to make up for the money you're losing by your other content getting scraped.

So we should all just do nothing and accept the inevitable?

> So we should all just do nothing and accept the inevitable?

I daresay rate-limiting will result in better outcomes than well-poisoning with hidden links that are against the policies of search engines.

Lots of potential for collateral damage, including your own websites' reputations and search visibility, with the well-poisoning approach.

The README.md specifically states how to allow for nice robots to proceed unhindered. The people behind these efforts, I would imagine, don't particularly care about their sites' reputations in the cases people use LLMs for search.

To be honest who cares about Google search anymore it's pretty useless these days.

The small non-profit I volunteer with finds Google ads to be surprisingly effective, and much more cost-effective than FB for what they do, so there's at least some Google search usage in the demographic that they serve.

To be clear, I mean AI is going to be the downfall of ad supported content. But let's face it. We have link farms and spam factories as a result of the ad supported content market. I think this is going to eventually do justice for users because it puts a premium on content quality that someone will want to pay a direct licensing fee to scrape for your AI bots as opposed to tricking somebody into clicking on a link and looking at an impression for something they won't buy.

I don't think you realise just how cheap and easy it is to run these things. Even at the worst rate of being scraped by AI companies, on the order of dozens of RPS, it didn't even use 1% of a CPU to give them content, nor does it use appreciable memory, or use up significant bandwidth (it generates lightweight pages).

The only time investment on my side was the initial set-up, and that barely took half an hour.

Tech is just a series of arms races

So, if at the end of the day instead of clicking EVERY single link in the repository they just check it out and parse locally...... I would consider it a win.

It's super expensive for them to run this hardware. And they need the compute for other things. Everyone who's cursed open AI for going down in the middle of the day whenever they're using it to write code or do some other thing, will breathe a little easier now that there's some compute available. Wise decision, in my opinion.