deterministic

No firewall?

Nope not true at all (30+ years of experience here working on very large scale software).

The whole point of being agile is to design your software architecture to be agile. That's what I do. And it works.

If that ever happens to you, you're doing it wrong.

I've spent 30+ years building large-scale software, and it has never happened to me. Good software design lets you accommodate even major requirement changes with minimal changes to the code.

> Unfortunately written by an AI - that completely takes the wind out of the content

I don't think the all-too-common "written by AI" remarks are helpful.

The article was informative and useful. That's what matters IMHO.

When using AI to generate text, I highly recommend asking it to "simplify" the text before publishing. Maybe even more than once.

> AI can generate components faster than humans can understand their combined execution

That is true but you are still responsible for the code that gets checked in. So slow down and make sure you do understand it before committing it.

I couldn't have explained it better myself.

We already have. See seL4.

If you work twice as fast but don't add a single $ to your income then you haven't increased productivity at all.

GLP-1 has negative side effects (loss of lean mass for example) that I most definitely do not want.

> AI has given a lot of completely incompetent people a false sense of competency

30+ years of experience writing large applications in C++ and TypeScript, including JIT compilers, commercial game engines, and business-critical systems used by international companies.

I love using Claude Code for the 90% of my work that is repetitive and boring. These are tasks I've done many times before. It does a great job as long as I guide it well and review every change before committing.

I find the negative tone of the article puzzling. AI is just a tool. Use it well and it makes you more productive. Use it badly and it causes problems.

An additional note running SQLite in production:

SQLite gets really slow when using very large BLOB's (100+ MB). I ended up having to store the BLOB's externally and refer to them from the SQLite DB. Not ideal of course (the BLOB's are not transacted) but works OK in practice using hashing/checks etc. to detect and handle invalid BLOB's.

> Only because Lisp Machines, or variations thereof didn't took off in the mainstream

It apparently turned out that it was more efficient to compile Lisp to a "normal" CPU instead of using an expensive custom non-generic "Lisp" CPU.

> I don’t know but to me it seems a bunch of people should learn proper typing

There is no way your hands can produce code faster than a machine.

Even before AI, I used a custom code generator for years. It generated about 90% of the code needed for large business applications in seconds, including support for multiple protocols, database adapters (Oracle, SQLite, in-memory, etc.), and programming languages such as C++, TypeScript, and Java.

Writing the same amount of code by hand would have taken even the fastest developer months. The machine did it in seconds, and it did it consistently and bug free.

I code the parts that are new and interesting. However after 30+ years of programming most code is something I have done before so I love getting Claude Code to do it :)

I 100% disagree.

I'm the maintainer of a large, business-critical C++ application with over a million lines of code that's used by major international companies. Claude Code routinely handles large and complex code changes correctly.

I review every line that Claude Code adds or changes, so this isn't speculation. It's an empirical fact.

These days my job is mostly to direct Claude Code, review its changes, and test the results. I still write code by hand when it's faster than explaining what I want, but that's becoming less common.

What an excellent read. It absolutely nails the "why aren't everybody writing software now" question.

Economists are famous for almost always being wrong predicting the future.

> I enjoy making bread at home but it costs 10x and tastes like dog shit

Eh? You enjoy making stuff at home that tastes like dog shit? That doesn't make sense at all.

BTW: I love making bread and it tastes amazing!

The #1 rule when using AI (IMHO) is simple: don't outsource your thinking.

Use AI to brainstorm, implement features, learn new things, improve your writing, or speed up repetitive work.

Just make sure you keep thinking while doing so!

Who cares? I most certainly doesn't. As long as the article is well written.

> go ahead and learn common lisp macros

Lisp macros used to be the one advantage Lisp had over other programming languages. However nowadays macros are common. There are even languages that has more than one flavour of macro system (Haskell has both a typed and non-typed flavour of macros).

However I personally prefer custom code generators instead of macros. The problem with macros, for the kind of large scale systems I work on, is understanding macros with N layers of abstraction, and also the compile/run time cost of using them.

Also, you can write code generators in any language and generate code for any language. Which is a huge advantage. I (for example) use code generators that generate C++, Java, Typescript, SQL, PDF's, interface descriptions, protocol specs etc. Whatever is required by a customer or other members of the team I can generate without demanding that they use a specific programming language.

Don't get me wrong. I love playing around with macros. However I have decided not to use them for real work.

I use plenty of DSL's in my daily work maintaining 1 million+ lines of C++ code used by very large companies around the world. No macros needed or wanted. More than 90% of the production code is generated from DSL's.

Outside of C++, Haskell has many great examples of powerful DSL's implemented without macros.

The problem with macros is the compile/run time cost. I could have implemented those DSL's using C++ templates (which are Turing complete by the way) but I prefer not to.

> Common Lisp it's in places where trying to build such kind of software in C/C++ would be a reciper for disasters.

I personally never blame the tools. I have written fairly complex software in 68000 assembler and it (1) worked fine and (2) was highly maintainable. However it was of course much slower to modify than using a higher level language.

> Alan Kay says a lot of problems with C/C++ go away when using the higher math more easily expressible in Lisp and like minded languages

That doesn't match my experience at all. Math and numbers are in general not a problem except when (say) implementing triangle hit detection in a game (something I did) where the precision of 32 bit floats does matter.

> Jürgen Schmidhuber says the problem with computers from a mathematician's point of view are the numbers.

That is probably true if you are a mathematician. Most people aren't.

Having said that, LEAN (for example) is written in C++ and used heavily by mathematicians.

I would be very interest in seeing how "getting lisp" enables you to write software that is more successful than the C and C++ software that runs the world. Perhaps you have written software in Lisp demonstrating this? Something you can show us?

Reject documents that contain LLM hallucinations.

Or use LLM's to generate 12+ pages of detailed reviews of those documents and return to sender.

I love using Claude Code in my daily work. It has made me much more productive.

But I also know that trying to optimize every second of my workday is a recipe for stress and eventually burnout. Nobody benefits from that.

So the key is to find the right balance between productivity and longevity.

If you feel stressed and overwhelmed then you are not in balance.

Please ask AI to simplify x 3 before posting AI generated articles.

Sorry, but I don't think you understand how many different skills are involved in building software that large companies can actually rely on.

Writing code is only one part of the job. I use Claude Code every day and I love it. It has made me much more productive. But I still have to guide it carefully, review every change, and fix the bugs and poor design decisions it introduces.

Personally, I'm looking forward to retirement. I expect there will be no shortage of consulting work helping companies clean up the AI-generated mess generated by inexperienced developers and overconfident middle manager with zero software development experience :)