From the very start of llms I’ve had nothing but bad experiences with code that was generated for me. Either it’s buggy, it works but I end up losing an evening on some obscure bug, or it’s full of red flags.

My latest hobby project is just in a text editor with markup and that’s it. I’m also done with the augmented assistance in the IDE. I google things I forgot. I constantly read these amazing stories of people vibe-coding some firmware/driver that just works, and honestly I’m starting to question whether I’m reading the posts of some promotional bot.

I've seen this happen to myself where suddenly I had trouble planning out the architecture for a very small project. It should have been obvious to me, and I knew that. So it was disconcerting to not be able to suddenly have the answer appear in front of me like it normally would. I thought maybe I would go to Claude and help get some ideas.

But then I stopped myself. I knew I should be able to do this! So I got out a piece of paper and I scribbled ideas until the dam burst and suddenly the entire design was obvious, like it should have been in the first place. It took about 5 minutes.

But those were an alarming 5 minutes. It was like I'd gone blind to the solution.

And I realized that when I asked Claude for a bunch of ideas and then I selected the best one based on my experience, I was exercising that exact skill. I wasn't exercising the skill of coming up with the solution from scratch.

Lots of times we're happy letting particular skills atrophy. Maybe we don't like exercising them and we just don't want to do that anymore. And I think that's valid.

Just be careful how you use it.

Also, LLMs are first and foremost excellent at reading ultra fast. Makes it excellent for summarizing and re-representing modules of your code

Here's my advice, based on what I have done: implement a programming language yourself, from scratch, without using an LLM, and then program in that. Don't release your implementation, or any code you've written in it.

Most (almost all) of my programming at home has been done in a Lisp dialect I designed and wrote myself, which is superficially similar to Common Lisp, but with subtle differences, including some deficiencies that I have to work around. And in my Lisp dialect, I implemented a visual dataflow language. Code samples are on my web site, but they're PNG images, so are safe from LLMs (I think). The language was designed to run on MIMD hardware, which doesn't exist in the real world. I've also implemented a Prolog which doesn't use Edinburgh syntax, which I use for type checking, and for parsing a controlled English implementation. So the temptation, and also the option, of using an LLM was never there.

In the course of doing all this, I've learned a lot along the way, which I wouldn't have if I'd used an LLM.

What has made me enjoy it less, is having to deal with colleagues' use of it. Sorry to say, but I don't enjoy talking to meat proxies, or getting huge PRs that solve the wrong problem. It's like half the people have turned off their brain. We produce faster, but we don't produce the right stuff.

It uses a Chinese sage to illustrate the fight against using machines:

"I have heard my teacher say that whoever uses machines does all his work like a machine. He who does his work like a machine grows a heart like a machine, and he who carries the heart of a machine in his breast loses his simplicity. He who has lost his simplicity becomes unsure in the strivings of his soul. Uncertainty in the strivings of the soul is something which does not agree with honest sense. It is not that I do not know of such things; I am ashamed to use them."

It resonates with me similarly as the post.

For me, writing the code (literally typing), shifting files around, renaming things is slow. So I’ve been using small models + much stronger grasp on the reins. Similar to what this post mentions. It’s been great, the decisions come from me. I tell it to make a domain class with these fields and these invariants. It does it in a split second, I look it over, tweak it and move to the next part of implementation.

When I experimented with swarms it would spend an hour just having agents adversarially review to decide some pretty trivial details. This way, when someone asks me a question during review, I can answer it. When I need to dive back in, I know what to look for and where to look for it. I have way more connection to my work, than a few months prior.

I also remembered the sheer joy of forking enterprise codebases like that of cal.com and highlight.io - just to study and try to understand how large teams worked. I followed issues, I read through PRs and related comments, looked at how some of the comments were resolved. I studied the various moving parts of the app - highlight especially being effectively a log ingestion and aggregation platform, had some rather large infrastructure requirements - kafka, redis, postgresql, clickhouse. It was hard to run with infrastructure directly on your computer. You had to use their docker containers.

I also remembered reading through a tutorial for an sqlite clone in C. It was interesting. I particularly enjoyed typing out the C code and even trying alternate implementation of b-tree operations.

I remember back in 2022 - after I was unemployed for a while - I discovered open source bounties on algora.io (LLMs have since made this platform go bust). I was able to earn roughly $300 per month for a while working on open source issues ranging from $50 to $350. Now most $50 bounties can be one-shot with frontier models. So of course, no one posts open source bounties anymore. If you do, you may just end up with 50 slopped PRs.

Just random thoughts.

1. Compare the code against production data with MCP. We use a read only platform called Metabase which reads one of the MySQL replicas. I tell the agent to fetch production data and make a static pass (it doesn't run the code) in which it compares shapes and inputs, and oh boy it has caught a few misnomers.

2. To debug production data and create graphs. It connects to datadog (where we store the logs), checks the history of the commits, and many times suggest fixes. These are for low-medium impact like validations that didn't need to go through, or a step check that it was missing

3. Creating tickets on the board (we use linear). Now PRs are more detailed and can be understood.

And for coding? I've been spending the last 4 weeks scrutinizing EVERY output and decision from frontier models, and pushed back in many decisions.

Who likes typing code, writing boilerplate, reading bad documentation for nights looking for that small thing, asking around in forums, reading dependency source code, writing trivial unit/ui tests.

And who likes planning, architecting, directing a team, steering and giving advice, reviewing code, designing interfaces and APIs. Coding became more mentally exciting.

LLMs truly took the worst of this trade, and left all the enjoyable things (which they will be unable to do until AGI = for a long time if ever).

The previous time I had this kind of break from hands-on imperative programming was in… 1987.

I was seven years old when I started doing BASIC, and though interests came and went (at one point I went to film school), I never stopped coding entirely. Until now.

The amount of code I’m producing today is higher than before. I’m now also middle-managing a team and doing what’s effectively customer-facing product management, a combination that has become bearable thanks to AI. But it’s hard to shake the feeling that something is permanently gone from my life.

Writing code is like trying to build a house without powertools. Could you do it? Sure. But no one ever will, for most values of no one.

  Afraid of loosing your job to someone with little programming skills, no aspirations to quality, and a huge Claude account?

For tasks you enjoy, write them yourself.

An LLM can go and pull files off NFS, and write and run verification scripts in less time than I can even think of a testing strategy or locate the files.

Sometimes they'll do it unprompted

For writing unit tests, which are often repetative and verbose, they are another godsend.

Overall they're freeing up a lot more time for nice things like thoughtful API design, refactoring, system architecture and design work etc.

For exploring massive codebases they are another godsend

You still needed to know how to operate those machines. Where to begin, when to do what. Know what’s right and what’s wrong. They are just tools.

Something like claude desktop can help regular people build, a fully functioning, scalable and maintainable program on any platform contrary to popular opinion. These harnesses are getting that good.

Only reason people don’t do that is because they are intimidated. Regular people don’t even understand file systems. As soon as an Apple-like version of claude code exists that intimidation will be gone.

I have been writing code for 14 years now and everything I learned from my failures and successes someone else can get for free. Even newer paradigms these LLM’s can dream up.

Its the democratisation, of that foundation people put so much effort building is what pissed off everyone here. Including myself I’ll admit.

Results of all these years of hard earned knowledge are accessible to any random person off the street without any effort.

I use claude code at work, even for architectural decisions it can iterate small prototypes to validate. I still read code because I am old school but it can replace most people.

Now humans operate at a higher level of abstraction. Our focus area is now ensuring the high-level architecture will accommodate future needs well, ensuring the final product meets requirements, and most importantly, ensuring the final product has been validated. It’s important to use every strategy in the book to test the output via unit tests, smoke tests, integration tests, and end to end tests. On our team, we’ve been investing a lot in setting up full test environments that include the entire stack at a level simply unachievable before AI. Now we can merge code changes at an unprecedented velocity without losing confidence in the system.

> This is the game changer.

> This is not communication. It’s a tool output.

Not saying I'm 100% sure, but those seemed slightly sus to me

I use AI like StackOverflow on steroids. And like using stackoverflow, I do it in a browser and I don't let the LLM touch my code.

I, personally, love programming more than ever!

Oh sure, you are not an LLM bro! Honest!

The amount of new LLM articles that try to feed them like vegetables to a child is amusing and tragic at the same time.

I write software because I am interested in the final outcomes, not because I enjoy the journey, which is often infuriating because of the mistakes you make, or the crap you depend on to get your work done.

Whether people will still have jobs in three years, or thirty, only time will tell, but I feel people are kidding themselves if they think LLMs won't have an impact. We were fine with using machines to automate physical labor as we now balk at the same thing happening to the intellectual side of things.

I, personally, have done a complete volte-face as far as my views on the subject are concerned over the past year or so as I use LLMs more and more for coding and other tasks.

---

[1] There is this idea I have had of an Excel replacement: simple, purely functional, TSV-based spreadsheet with zero backward compatibility with styles as purely optional sidecar material that I have always wanted to do but lacked the time. Brainstormed a spec with Claude today. Might work on it in the near future.