Building a Mac app with Claude code

Two years ago, I saw myself as a really good Python engineer. Now I'm building native mobile apps, desktop apps that talk to Slack, APIs in Go, and full web apps in React, in hours or days!

It feels like I've got superpowers. I love it. I feel productive, fast, creative. But at night, there's this strange feeling of sadness. My profession, my passion, all the things I worked so hard to learn, all the time and sacrifices, a machine can now do most of it. And the companies building these tools are just getting started.

What does this mean for the next generation of engineers? Where's it all heading? Do you feel the same?

The reason you can use these tools so effectively across native, mobile, Go, React etc is that you can apply most of what you learned about software development as a Python engineer in these new areas.

The thing LLMs replace is the need for understanding all of the trivia required for each platform.

I don't know how to write a for loop in Go (without looking it up), but I can write useful Go code now without spinning back up on Go first.

I still need to conceptually understand for loops, and what Go is, and structured programming, and compilers, and build and test scripts, and all kinds of other base level skills that people without an existing background in programming are completely missing.

I see LLMs as an amplifier and accelerant. I've accumulated a huge amount of fuzzy knowledge across my career - with an LLM I can now apply that fuzzy knowledge to concrete problems in a huge array of languages and platforms.

Previously I would stay in my lane: I was fluent in Python, JavaScript and SQL so I used those to solve every problem because I didn't want to take the time to spin up on the trivia for a new language or platform.

Now? I'll happily use things like Go and Bash and AppleScript and jq and ffmpeg and I'm considering picking up a Swift project.

This is difficult to express because I too have enjoyed using an LLM lately and have felt a productivity increase, but I think there is a false sense of security being expressed in your writing and it underlies one of the primary risks I see with LLMs for programming.

With minor exceptions, moving from one language to another isn’t a matter of simple syntax, trivia, or swapping standard libraries. Certainly, expert beginners do espouse that all the time, but languages often have fundamental concepts that they’re built that and need to be understood in order to be effective with them. For example: have you ever seen a team move from Java to Scala, js to Java, or C# to Python - all of which I’ve seen - where the developers didn’t try to understand language they were moving to? Non-fail, they tried to force the concepts that were important to their prior language, onto the new one, to abysmal results.

If you’re writing trivial scripts, or one-off utils, it probably doesn’t build up enough to matter, and feels great, but you don’t know what you don’t know, and you don’t know what to look for. Offloading the understanding of the concepts that are important for a language to an LLM is a recipe for a bad time.

> but languages often have fundamental concepts that they’re built that and need to be understood in order to be effective with them

I completely agree. That's another reason I don't feel threatened by non-programmers using LLMs: to actually write useful Go code you need to figure out goroutines, for React you need to understand the state model and hooks, for AppleScript you need to understand how apps expose their features, etc etc etc.

All of these are things you need to figure out, and I would argue they are conceptually more complex than for loops etc.

But... don't need to memorize the details. I find understanding concepts like goroutines to be a very different mental activity to memorizing the syntax for a Go for loop.

I can come back to some Go code a year later and remind myself how goroutines work very quickly, because I'm an experienced software engineer with a wealth of related knowledge about concurrency primitives to help me out.

> But... don't need to memorize the details. I find understanding concepts like goroutines to be a very different mental activity to memorizing the syntax for a Go for loop.

That's one of the argument that seems to never make any sense to me. Were people actually memorizing all these stuff and are now happy that they don't have too? Because that's what books, manuals, references, documentations, wiki,... are here for.

I do agree with you both that you need to understand concepts. But by the time I need to write code, I already have a good understanding of what the solution is like and unless I'm creating the scaffolding of the project, I rarely needs to write more than ten lines at time. If I need to write more, that's when I reach for generators, snippets, code examples from the docs, or switch to a DSL.

Also by the time I need to code, I need factual information, not generated examples which can be wrong.