The National Cryptologic Museum outside Fort Meade has one or a few Connection Machines, a Cray, and all sorts of other computing and other gear. It's quite a worthwhile tour, IMHO. https://www.nsa.gov/museum/
My former employer, Ab Initio, has a Connection Machine in the basement. (Ab Initio was founded by the same person as Thinking Machines, and many/most of the early employees were from there.)
I have Claude Code author changes, and then I use this "codex-review" skill I wrote that does a review of the last commit. You might try asking Codex (or whatever) to review the change to give you some pointers to focus on with your review, and also in your review you can see if Codex was on track or if it missed anything, maybe feed that back into your codex review prompt.
I think it's happening, some of them are even making it to the front page of HN, like the "I built 50 calculators" a few days ago. I'm still working to release some of the things I've built over the last month:
- A nice little single-file web "random slideshow" to replace an aging one I bought.
- A fairly feature-complete read-only SQL console.
- A development SMTP server (like Mailhog) https://github.com/linsomniac/smtphotel
- A work status dashboard that I'll probably release once I have run it a bit longer.
- A fairly extensive Docusign-like webapp.
- A retrospective meeting runner.
- A cron "swiss army knife" helper.
- A "social calorie tracker" (I'm unhappy with the existing ones out there).
These are all things I've vibecoded in the last month, and are more than I could have coded in my spare time in 6 months or more.
I had an Ender 3 Pro, and it was also very finicky, ~18 months ago I replaced it with a Bambu P1S and that thing is just a (nearly) fire and forget machine. I've been super happy with it. In the 18 months I've had it, I've probably gone through 10-20 rolls of filament, in the 4 years I had the Ender I went through maybe 3-4 (because every time I wanted to print something I knew I'd have to spend an hour fiddling with it). A coworker has the Ender 3 though and his has been reliable, so it seems YMMV.
Ha, another Ender survivor here. I had the Ender 5 Pro for a few years, recently bought a Bambu H2D and it's like going from a bicycle to a car with heated steering wheel. It "just works" (it still has the classic 3D printing problems of edges of the print lifting up etc, but that's not the printer's fault). Vast majority of the time it just works.
Which problems did you have with the Ender apart from the mentioned classic 3D printing problems? As I mentioned in an earlier comment I'm using one of these machines without too much trouble after fixing the mistakes made by a previous owner. I did put more capable firmware on the thing which improved printing speed - especially in the preparation phase - and to a lesser extent quality but even with the stock firmware it performed well enough with PETG and some complex models after dialing in the temperatures, distances and speeds to the somewhat odd filaments I use. I can send code directly to the printer, no SD card needed, I can follow printing progress in a browser and I don't send a single bit of information to the Creality mothership while doing so. The same is probably harder - but maybe not impossible, I haven't looked into this yet - with Bambu printers?
>>Which problems did you have with the Ender apart from the mentioned classic 3D printing problems?
The kind of problems that could only be solved with a rather embarrasing amount of tuning every time I switched filament types or speeds or the temperature in my garage changed etc etc etc. Things that basically meant that every time I wanted to introduce any change I needed to print a new flow tower, new bridging tower, new temperature tower, the bed levelling took a huge amount of effort to install BL touch on it but it still worked....when it wanted to, with parts of the first layer being too close scraping the bed and others being far enough to not stick.
Don't get me wrong - the Ender 5 could print as well as the H2D can, absolutely. But it would need 10 test prints and me pulling my hair out first to get to the same level of quality - which I have done, repeatedly, but I just lost the appetite for the tinkering. With the H2D I click print and the machine calibrates itself so well I actually feel bad for anyone who only ever experienced this and never had to sit down calibrating extruder steps or flow rates manually. (yes, old man yelling at clouds).
>>and I don't send a single bit of information to the Creality mothership while doing so. The same is probably harder - but maybe not impossible, I haven't looked into this yet - with Bambu printers?
Bambu printers, even with the most recent firmware allow Home Assist integration where you can monitor all print parameters remotely. But to be completely honest with you - I did go through a phase where I cared about stuff like this, now I just want it to work and be more like my dishwasher than like my bike, I want to tinker with the bike but my 3D printer should "just" work.
Sounds mostly valid, if I ever get something more 'advanced' I may look back on my time with this machine the same way I look at my early history with (2D) printers - dot matrix, then HP500 inkjet with a sheet feeder and other such luxuries to the current HP and Canon lasers.
Having said that I must say that the firmware update did make quite a bit of difference. I have yet to print out any of those flow/bridging/temperature towers, I did get a few bad starts related to bed adhesion but those are 'common 3D printer problems' not related to the machine. Using some of my daughters' hair spray solved that for the most.
Yes, definitely! The AI tooling works much like a human: it works better if you have a solid specification in place before you start coding. My best successes have been using a design document with clear steps and phases, usually the AI creates and reviews that as well and I eyeball it.
I've been using checklists and asking it to check off items as it works.
Another nice feature of using these specs is that you can give the AI tools multiple kicks at the can and see which one you like the most, or have multiple tools work on competing implementations, or have better tools rebuild them a few months down the line.
So I might have a spec that starts off:
#### Project Setup
- [ ] Create new module structure (`client.py`, `config.py`, `output.py`, `errors.py`)
- [ ] Move `ApiClient` class to `client.py`
- [ ] Add PyYAML dependency to `pyproject.toml`
- [ ] Update package metadata in `pyproject.toml`
And then I just iterate with a prompt like:
Please continue implementing the software described in the file "dashcli.md". Please implement the software one phase at a time, using the checkboxes to keep track of what has already been implemented. Checkboxes ("[ ]") that are checked ("[X]") are done. When complete, please do a git commit of the changes. Then run the skill "codex-review" to review the changes and address any findings or questions/concerns it raises. When complete, please commit that review changeset. Please make sure to implement tests, and use tests of both the backend and frontend to ensure correctness after making code changes.
>Anyone who claims AI is great is not building a large or complex enough app
I can't speak for everyone, but lots of us fully understand that the AI tooling has limitations and realize there's a LOT of work that can be done within those limitations. Also, those limitations are expanding, so it's good to experiment to find out where they are.
Conversely, it seems like a lot of people are saying that AI is worthless because it can't build arbitrarily large apps.
I've recently used the AI tooling to make a docusign-like service and it did a fairly good job of it, requiring about a days worth of my attention. That's not an amazingly complex app, but it's not nothing either. Ditto for a calorie tracking web app. Not the most complex app, but companies are making legit money off them, if you want a tangible measure of "worth".
Right, it has a lot of uses. As a tool it has been transformative on many levels. The question is whether it can actually multiply productivity across the board for any domain and at production level quality. I think that's what people are betting on, and it's not clear to me yet that it can. So far that level looks more like a tradeoff. You can spend time orchestrating agents, gaining some speedup at the cost of quality, or you can use it more like a tool and write things "manually" which is a lot higher quality.
>While in our interpretation the RFCs do not require CNAMEs to appear in any particular order
That seems like some doubling-down BS to me, since they earlier say "It's ambiguous because it doesn't use MUST or SHOULD, which was introduced a decade after the DNS RFC." The RFC says:
>The answer to the query, possibly preface by one or more CNAME RRs that specify aliases encountered on the way to an answer.
How do you get to interpreting that, in the face of "MUST" being defined a decade later, as "I guess I can append the CNAME to the answer?
Holding onto "we still think the RFC allows it" is a problem. The world is a lot better if you can just admit to your mistakes and move on. I try to model this at home and at work, because trying to "language lawyer" your way out of being wrong makes the world a worse place.
The RFC is also 39 years old! At this point, DNS is what existing software expects it to be, not what someone proposed in the mid-eighties. The fact that they did not have any testing to match exact byte-by-byte responses with existing behavior and other DNS resolvers for this layer of service is massively irresponsible.
Somewhat unrelated: If you use epoxy for repairs, particularly of plastics (though I just used some for a wood repair), get yourself some fiberglass tape/fabric to use with it. Sometimes I'll lay the tape over the repair, sometimes I'll cut it up into little fragments and mix it directly in the epoxy (depending on if the epoxy is the bulk of the repair, like filling in a hole, or if I'm trying to repair a crack.
Also, if you are repairing plastic, consider "hot staples". A friend of mine just educated me on that 6 months ago, and I'm using them all the time, a starter kit costs around $50 though. This is a good, quick demo of them: https://youtube.com/shorts/43TDecNqTco?si=xsDJ3n7KMjpg8NVw
I mostly use the square pins from SIL headers, bent into an appropriate shape. I use a pointed tip but I don't think it matters much, as long as it can transfer heat into the pin.
I most recently used this to repair a snapped headband on some sony headphones. I'd previously tried to superglue it, but the glue eventually came undone - but my "staples" are still going strong.
The maintenance factor seems to often be overlooked. The amount of time I've put into EV maintenance in the last decade is about the same as I've put into my two ICE cars, but I drive them 1/10th as much. It's really, really nice, and I don't think dealer service departments are ready for a massive switch to EV.
2 days ago I built a skill to automate a manual workflow I was using: After Claude writes and commits some code, have Codex review that code and have Claude go back and address what Codex finds. I used this process to implement a fairly complete Docusign-like service, and it did a startlingly good job right out of the gate, the bugs were fairly shallow. In my manual review of the Codex findings, it seems to be producing good results.
Claude Code largely built that skill for me.
Implemented as a skill and I've been using it for the last 2 days to implement a "retrospective meeting runner" web app. Having it as a skill completely automates the code->review->rework step.
I looked that the official repo of skills, but I found those very generic and artificial.
I would encourage you to write up a blog post of your experience and share a version of the skill you have built. And then follow up with a blog post after 3 months with analysis like how well the skill generalized for your daily use, whether you had to make some changes, what didn't work etc. This is the sort of content we need more of here.
reply