adamzwasserman

1. It is what you do after the prompt: scan diffs in real time and hit the escape key at the slightest sign of trouble.

2. Deep questioning. Constantly probing the assistant: what does it think it is trying to achieve, why did it just make decision X, is there a better way, what does it think the current constraint is?

3. Fighting drift. Knowing that the model will always try to regress to the mean of the training corpus, and constantly being on guard against that drift.

4. Keeping state in your head, because the model cannot. It is up to the programmer to remeber what connects to what else in what way and why.

I responded in my article here: https://emusings.substack.com/p/the-prophet-loves-his-instru...

I can guarantee you that the comment from jvanderbot was not AI generated.

Or.. the LLMs are just "telescope" sufficiently powerful to detect the aligned internal representation that already exists.

A more powerful telescope does not "create" new galaxies.

As others have remarked: this is an unsubstantiated claim.

I am actually using LLMs to perform controlled experiments to determine if the opposite is true, and that consciousness is a byproduct of language as Jaynes might have agreed.

It is insane how much I enjoy this

I would say the opposite.

The main value I add to AI generated work is my ability to generalize, keep broader spans of context than the AI can, and make connections between things that the AI cannot.

We need a Slop Audit methodology.

That is why I have created one (Open Honest Slop Audit).

I enjoyed the deep dice. A lot of sensible advice, and enjoyed the deep dive. A lot of articles do not get a lot of that as right as this article does.

Anyone who also enjoyed it would probably get a kick out of my article on the same subject that goes into the regex (which has some valid use cases): https://hackernoon.com/on-the-practicality-of-regex-for-emai...

Do you need photos or paper?

pretext alleged bid to fund the war accustomed to constant unpredictability hoarding stashing useless bricks odyssey record high

Hide your kids, hide your wife, and hide your husband.

Nice idea, but most of the hiring managers I know have very little say over who gets in the door.

It is obviously promotional, I wrote the book and I want people to read it.

The reason why I wrote a book is that it is a very long and complex answer. I will see if I can summarize it for you adequately in a HN post.

I start by building the case that corporate IT failure is a real and measurable long-running crisis. I cite Standish Group's 1994 Chaos Report and KPMG's Report on IT Runaway Systems: only a third of corporate IT projects are deemed successful by the executives who fund them. PMI estimated $300B was lost in the US to failed IT in 1999–2001 alone. Decades of methodologies and magic bullets haven't moved the number.

I explain how enterprise software is still produced by hand. Every successful project depends on master programmers mentoring less-experienced ones. Per Bob Martin, programmer headcount doubles every five years, so half the industry always has under five years' experience: "perpetual inexperience.

I explain why prior fixes failed: Project management responded to the 1994 reports by trying to freeze requirements, which killed IT's ability to track changing business needs. The COTS (Commercial Off The Shelf) wave collapsed against unique corporate processes. Industrialization attempts—CASE, CORBA, COM/.NET, MDA—all targeted the wrong thing: writing code.

I move to making the case that the correct target is assembly of code. Per Alexander Stepanov, only about 10% of a developer's time goes to creative coding; the other 90% is "glue, fitting, and assembly" — wiring up libraries, reconciling versions, plumbing data between layers. Auto design is still artisanal; what got industrialized was assembly, via machine tools, interchangeable parts, and semi-skilled labor.

Then I explain how to industrialize the assembly, not the coding. Compilers and JIT VMs are the robots IT already has; class libraries and open-source packages are its interchangeable parts. The FANGs already build internal mass-production tooling on top of these. Corporate IT must do the same so master programmers can leverage semi-skilled assemblers because we are not going magically exponentially increase the number of insanely great programmers.

The book was written eight years ago, so I will address AI coding here: LLMs are trained using a technique called gradient descent which is a way of finding the most mid possible point of anything and we then assign the highest weights to that. LLM write mid code by design and this is unchangeable. Any attempt to write insanely great code using an LLM is an unholy uphill battle of fighting the gradient descent every step of the way.

No it is not too soon, but it is contingent upon understanding how factories actually work, and what distinguishes industrial production from artisanal production. Even AI generated code is artisanal.

As afar as I know, my book "The Chaos Factory" is the only book that does this.

Too bad the pope frames modern slavery almost entirely through the lens of the digital economy. Chattel slavery is alive and thriving in Mauritania, the Gulf, Xinjiang, and elsewhere.

None of it dependent on AI, none of it apparently worth its own treatment in a 38,000-word document.

Ah, thx for the reply.

It is very disappointing that the article does not point out that decommissioning old centers in favor of new ones will improve energy efficiency 2x and compute-per-watt at the silicon level between 20–30x.

Even the most fervent eco-warrior should be demanding we build new data centers and decommission old ones as fast as we can.

So tired of all the bullshit around this.

You seem to discount the possibility that ideas are emergent and as they emerge, multiple people at once become aware of them.

I am asserting it is Charles Fort's "steam engine time". Far from a crank position. It is one that bears serious consideration.

No offense, but you sound like someone who has never built a language model. Anyone who has actually built one understands that there is no copying going on. Just predicting words (tokens actually).

The problem is that people's words are MUCH more predictable then they would like to believe. And that truth upsets them.

In addition to having created models, I also write books and articles. Probably more than most people commenting here. I have a firm grip on what actual copyright law is and the pros and the cons of it.

Hi dmoose, your handle looks familiar to me. The non-glib answer is that we should giver some very serious consideration to the possibility that language either functions like, or possibly is the same as, Jung's collective unconscious: the organically created repository of all of humankind's cognition and reason, accumulated over vasts periods of time, deposited by billions of humans.

My way of "giving this serious attention" is through pre-registered, falsifiable, repeatable, experimentation, which anyone can look up on osf.io because I use my real name. I'll bet you that non of the randos in this thread do as much.

To all of the randos: unless you have data... it is just an opinion.

I submit most of the replies to my original reply as proof that there are no original thoughts.

People need to cope with the fact that no thought is original. Even Newton and Leibniz were having the same thoughts at the same time. Get over it.

I know I did done:

https://news.ycombinator.com/item?id=46240221

I built a Chrome extension to solve a problem I kept having: losing track of conversations on HN. The threads page is a firehose. Someone replies to your comment, you miss it, the conversation dies. Or you revisit a thread and can't remember which comments you've already read.

HN Reader does three things:

1. Hides stories you've seen – Checkbox next to each story. Check it to dim. Helps filter the front page to stuff you haven't looked at yet. 2. Collapsible comments that remember – Click the arrow to collapse a comment thread. Come back later and it stays collapsed, unless someone added a new reply, then it auto-expands with a "NEW" badge. 3. Highlights your conversations – On your threads page, badges show "you", "replied to you", and "you replied" so you can instantly spot active conversations.

That last one is what made me build this. I was missing replies buried in long threads. Now I just glance at my threads page and the blue "replied to you" badges jump out.

Everything stays in local storage. No server, no account, no tracking. Auto-cleans old data when storage gets full.

GitHub: https://github.com/adamzwasserman/hnreader

Works in Chrome, Arc, and any Chromium browser. Load it unpacked from the repo.

Feedback welcome – especially on what other HN reading problems you'd want solved.

I for one think it is hight time that we restore the study of quantum bogodynamics to its rightful place in the pantheon of human achievements.

The bogon flux must NOT be interrupted.

I love it!

You don't own him.

Correction. I copied some incorrect values from my test harness. So Honest Python does NOT beat Dishonest Swift.

But it does beat the pants off of JS/TS on V8 which is quite the surprise.

Also in the surprise category is that Honest Java is more than 2x faster than dishonest c++.

The dynamism exists to support the object model. That's the actual dependency. Monkey-patching, runtime class mutation, vtable dispatch. These aren't language features people asked for. They're consequences of building everything on mutable objects with identity.

Strip the object model. Keep Python.

You get most of the speed back without touching a compiler, and your code gets easier to read as a side effect.

I built a demo: Dishonest code mutates state behind your back; Honest code takes data in and returns data out. Classes vs pure functions in 11 languages, same calculation. Honest Python beats compiled C++ and Swift on the same problem. Not because Python is fast, but because the object model's pointer-chasing costs more than the Python VM overhead.

Don't take my word for it. It's dockerized and on GitHub. Run it yourself: honestcode.software, hit the Surprise! button.

The reason this is impressive has less to do with the tolerances themselves and more to do with backward compatibility across decades at scale. That's the genuinely hard part.

The history here is deeper than most people realize. The United States spent fifty years (roughly 1800 to 1853) at the Springfield and Harper's Ferry armories trying to achieve what LEGO now does routinely: parts manufactured to tight enough tolerances that they are truly interchangeable without fitting. In 1853, a visiting British inspector randomly selected ten muskets made in ten different years, disassembled them, mixed the parts, and reassembled ten functional muskets using only a screwdriver. Tolerances of a thousandth of an inch. It was considered impossible by most of the engineering establishment of the time.

The way they got there was by building machines, then using the parts those machines made to build better machines, then using those improved parts to build even better machines. A virtuous circle of transferring skill from human hands to tooling. This is the actual origin story of what historians call the American System of Manufacture, and it's the foundation the entire modern automotive supply chain sits on.

So yes, any competent injection molder holds tight tolerances today. But that's precisely the point: the reason it seems unremarkable now is that two centuries of compounding precision made it so

according to the WaPo, this guy was such a L33T hacker that 'he needed help transferring data from a thumb drive “to his personal computer"'.

Ooookay