I use a mac and a linux box. I'd never cross my mind that I cant leave some unsaved changes overnight. I leave unsaved changes for weeks across the many things I am working on.
I got a Commodore/PLUS 4 -
With almost no games (just Saboteur, Jet Set Willy and Booty), and my father taught me how to program in Basic 3.5 - and before I was 10
i was making trainers with 7501 assembly learned almost by trial and error. I knew back then what I wanted to do in life and followed that path to the fullest extent.
Could be, but that stack happens to also solve for a lot of problems totally unexperienced people will struggle with (such as, to not look too far, CORS issues). Good reco for a non-tech person to build a frontend. And besides, who cares which stack is used as long as its used. Its not like this will ever be maintained. If anything, if a need for a new feature emerges 5 months down the road the whole thing can be re-done from scratch in one sitting without writing a single line of code.
100% this, too. I am an IT professional - CTO for a large-ish enterprise (25-30bn yearly revenue). I am finding myself waking up at 4am every single day for the last 2 months to vibe code stuff i always wanted to build for myself, my family and friends, and never quite had the time for it. My sleep habits are definitely suffering but my happines is through the roof.
It helped me finish my webRTC client for a esp32 microcontroller. Thats fairly low level. It did it without breaking a sweat - 2hrs, and we had a model which works with my pipecat-based based server.
I loaded the lowest level piece of software I wrote in the last 15 years - a memory spoofing aimbot poc exploiting architectural issues in x86 (things like memory breakpoints set on logical memory - not hw addresses - allowing to read memory without tripping kernel-level detection tools, ability to trigger PFs on pages where the POC was hiding to escape detection, low level gnarly stuff like this). I asked it to clean up the code base and propose why it would not work under current version of windows. It did that pretty well.
Lower level stuff does of course exist, but not a whole lot IMHO. I would not assume claude will struggle with kernel level stuff at all. If anything, this is better documented than the over-abstraced mainstream stuff.
That's fair, AI handles spec-compliant code quite well. The sanctuary for humans remains where the map doesn't match the territory: debugging silicon errata, hardware-level race conditions, or working with custom, proprietary gear. Vibe coding falls apart when you have to poke around with an oscilloscope because the code is theoretically correct, but the device just isn't working
I am no longer sure thats the case. I had it chew through a gnarly problem with my own custom webrtc implementation on a esp32 SOC. It did not rely on any existing documentation as this stuff is quite obscure - it relied on me pointing to specs for webrtc, specs for esp32 SDK, and quite some prompting. But it solved the problems I was dreading to solve manually in a matter of a 2hr session. Thats for a hobby project, we are now starting to experiment using this in the enterprise, on obscure and horrible to work with platforms (such as some industry specific salesforce packages). I think claude can work effectively with existing code, specs on things that would never made it to stackoverflow before.
For what I am vibing my normal work process is: build a feature until it works, have decent test coverage, then ask Claude to offer a code critique and propose refactoring ideas. I'd review them and decide which to implement. It is token-heavy but produces good, elegant codebases at scales I am working on for my side projects. I do this for every feature that is completed, and have it maintain design docs that document the software architecture choices made so far. It largely ignores them when vibing very interactively on a new feature, but it does help with the regular refactoring.
In my experience, it doubles the token costs per feature but otherwise it works fine.
I have been programming since I was 7 - 40 years ago. Across all tech stacks, from barebones assembly through enterprise architecture for a large enterprise. I thought I was a decent good coder, programmer and architect. Now, I find the code Claude/Opus 4.5 generates for me to be in general of higher quality then anything I ever made myself.
Mainly because it does things I'd be too tired to do, or never bother because why expand energy on refactoring for something that is perfectly working and not to be further developed.
Btw, its a good teaching tool. Load a codebase or build one, and then have it describe the current software architecture, propose changes and explain their impact and so on.
> I thought I was a decent good coder, programmer and architect. Now, I find the code Claude/Opus 4.5 generates for me to be in general of higher quality then anything I ever made myself.
I have about the same experience as you do and experience using Opus 4.5.
If this is true, you weren’t a very good programmer. There’s much more to code quality than refactoring working code.
> If this is true, you weren’t a very good programmer. There’s much more to code quality than refactoring working code.
Yup, my conclusion exactly.
With that said, most code I have seen in private sector is almost objectively horrible (and certainly subjectively). Code manufactured with the current best tools such as Claude compares favourably. Companies rarely have the patience to pay for well manicured, elegant code. If it sort of works it ships.
The thing is good code doesn’t cost more than bad code in the long run.
In many cases it doesn’t even cost more in the short run. And it usually has nothing to do with being manicured or elegant.
A good engineer will tell you how to spend 25% of effort to get to 90% of the result you want. With maintainable code, and importantly with less code that touches fewer systems.
A bad engineer will deliver exactly what product asked for without asking questions, generate 4x the code, and touch every piece of the system.
Companies are just setup in a way that incentivizes building organizations that create bad code. Most places would rather hire 100 bad engineers who can be easily replaced than 5 good engineers.
Despite having worked with or managed hundreds of developers over the years, I don't think there were more than, maybe, 5 that I would not gladly swap for a claude-equivalent. Diligent, able to produce good code when adequately supervised, and devoid of a desire for work life balance :-)
Most software devs are just mediocre, they learn to code late in life, they work 9-5, and often stop learning as quickly as they can.
> Companies are just setup in a way that incentivizes building organizations that create bad code. Most places would rather hire 100 bad engineers who can be easily replaced than 5 good engineers.
This is quite true, and it is this -- really, a special case of "the market can remain irrational longer than you can stay solvent" -- that has me worried about the implications for the labour economy more than anything else.
> Here is to hoping someone will do something similar for DRM'ed BOSCH ebike motors.
Please not. Bike thieves are already annoying as they are (a ring in the rural city I live in managed to steal over 400 k€ worth of bikes in a matter of months, in my case they only stole the control unit), and so are people modding their bikes to run (way) faster than the legal limit, leading to more and more calls for them being banned off of normal bike tracks.
I am not interested in either, I just want to have control over the hardware I purchased with my own money.
As for thieves, they apparently have ways of bypassing bosch drm via hardware - bosch bikes get stolen all the time. As for speed unlocks, they are trivially possible with hardware bypasses. I doubt open source firmware would do harm.
> If you can't fence the product then there's no motivation to steal it in the first place.
Couple of big problems with this thought:
* You have to know you can't fence it. Do you think bike thieves are following exactly which e-bike models have DRM, whether it has been broken etc? I doubt it.
* It assumes that the DRM is so amazing that nobody figures out how to defeat it.
I started doing some research over the holidays and the smart system seems to be designed to prevent reversing - fuses blown both ways, so didn't even manage to read the firmware, and communication with the client software relies on what seems to be decent encryption. And from the design of the hardware bypasses it seems that the firmware does not trust its own peripheries. Good design, no doubt - will try to take it apart when i switch bikes and won't mind bricking my unit.
I have a Class 1 Makita (green) laser level, wide strong beam, excellent tool for landscaping. I accidentally looked into it from a 10 cm distance. It did not leave permanent damage, but for a few days I had the dot burned on my retina. And yes, I almost immediately closed my eye - within a few hundred ms's.
I use a mac and a linux box. I'd never cross my mind that I cant leave some unsaved changes overnight. I leave unsaved changes for weeks across the many things I am working on.
reply