I spec out everything in excruciating detail with spec docs. Then I actually read them. Finally, we create granular tasks called "beads" (see https://github.com/steveyegge/beads). The beads allows us to create epics/tasks/subtasks and associated dependency structure down to a granular bead, and then the agents pull a "bead" to implement. So, mostly we're either creating spec docs and creating beads or implementing, quality checking, and testing the code created from an agent implementing a bead. I can say this produces better code than I could write after 10yrs of focused daily coding myself. However, I don't think "vibe coders" that have never truly learned to code, have any realistic chance of creating decent code in a large complex code base that requires a complex backend schema to be built. They can only build relatively trivial apps. But, I do believe what I am building is as solid as if I had a millions of dollars of staff doing it with me.
But how is that less work and allows you to do that in Disneyland with your kids? For me, personally, there is little difference between "speccing out everything in excruciating detail in spec docs" and "writing actual implementation in high-level code". Speccing in detail requires deep thought, whiteboard, experimentation etc. All of this cannot be done in Disneyland, and no AI can do this at good level (that's why you "spec out everything in detail", create "beads" and so on?)
Yes, I normally draft spec docs in the office at my desk, this is true. However, when I have the spec ready for implementation with clear "beads", I can reasonably plan to leave my office and work from my phone. Its not at a point where I can just work 100% remote from my phone (I probably could but this is all still new to me too). But it does give me the option to be vastly more productive, away from my desk.
As opposed to the Netherlands, Norway has an abundance of hydro electric power to fuel the cars and significant oil and gas income that can easily finance these policies.
Most countries aren't close to a level of electric car penetration where that would really be a problem. Even in Norway this is new car sales. The actual percentage of cars on the road that are fully electric is 32%.
Plus most people charge cars overnight when there's a surplus of power.
Oil and gas income I will give you though... I don't think most countries could afford this.
Hydro doesn’t really care if it’s used day or night, they can just open or close the gates as needed. It would be more of a thing if they used nuclear or coal, which is hard to ramp up and down.
Yes, but Norway controls the sluice gates and has an idea of when demand is high or low. I guess you could argue that their generation capacity is limited and during peak they simply can't offer anymore, but other than that, Norway can totally ramp down production at night.
The demand for electricity in Europe is so high that Norway could sell every watt-hour if the DC links and HV AC backbone had enough capacity. Essentially the only thing preventing Norwegian electricity prices rising to European levels is the lack of capacity in the backbone HV system not the ability to control the generators.
Without hiring/being a cloud expert, it's hard to be sure that you didn't leave some door wide open due to a configuration error. Both approaches offer more than enough opportunities to royally screw up.
You are correct that a Linux installation is ineligible for support from Microsoft. Not that that means anything for private usage.
Also, Linux has a great track record for not dropping support for older hardware. I think that is a lot more informative than whatever statement Microsoft's legal team has managed to come up with.
The same way you know that your browser session secrets, bank account information, crypto private keys, and other sensitive information is never uploaded. That is to say, you don't, really - you have to partially trust Microsoft and partially rely on folks that do black-box testing, network analysis, decompilation, and other investigative techniques on closed-source software.
Your focus on startup speed feels really alien to me. When working on a project I just keep vscode open. I reboot maybe once a week and starting vscode again takes about a second, and then maybe 10s of seconds of background processing, depending on the project size, for the language server to become fully operational. That's more than good enough for me.
I've done a lot of shell-driven development in the 00s though, and I remember it did involve frequently firing up vim instances for editing just a single file. I no longer understand the appeal of that approach. Navigating between files (using fuzzy search or go-to-definition) is just a lot faster and more convenient.
> starting vscode again takes about a second, and then maybe 10s of seconds of background processing
Yet I'm doing the same thing instantly or near instantly.
I don't reboot often and I'm still lazy and will leave projects open often, but honestly, have you considered that your workflow is an adaptation to the wait time?
> Navigating between files (using fuzzy search or go-to-definition) is just a lot faster and more convenient.
I agree? But why do you think people don't fuzzy search in vim? Or the terminal? There's been tools to do this for a very long time. Fzf is over a decade old and wasn't the first
If you're using vim as an IDE (which is if course perfectly doable), then why does it matter if startup time is 50 or 1000 ms. You typically leave them running.
> Yet I'm doing the same thing instantly or near instantly.
Does vim somehow allow LSP servers to index faster? Or are you not actually doing the same thing?
Why are you leaving them running? Because they are slow to load?
Yes, Neovim supports LSP and it is very very fast.
I'm not sure why any of this is surprising. We're talking about the same company who is speeding up their file browser by loading it at boot time rather than actually trying to fix the actual fucking problems. Why is it surprising that everything else they make is slow and bloated as shit (even more as they've shoving AI into everything)
The point of LSP is that neovim is using the same servers for this as vscode. So I guess you work on smaller projects or with languages that have faster (usually meaning less fully featured) LSP servers.
LazyVim includes a bunch of pre-configured plugins that turn NeoVim into an IDE. Fuzzy search by filename, search by text, file explorer, go to definition, go to reference... Even debugging and unit test runners, it's all there. Yet when I'm at the command line and I need to make a quick edit to one file, e.g. `nvim ~/.bashrc`, I don't pay the startup cost of waiting for 50 plugins I'm not going to use. So it's the best of both worlds.
They're not using the remote VM as a server but as the development machine though. You don't want to have to git commit and push every time you need to run or even type-check your code.
I think what GP describes is actually a pretty okay solution for orgs that don't want to provider their devs with local admin privileges.
You can develop locally if you want to, and lots of people do, but it’s community support. The environment that someone else is obligated to fix for you is the remote one (which they can do by blowing away the container and then you recover your state from Git).
reply