As far as I know the epistemological conundrum of whether or not we exist in a simulation remains unsolved, and I believe the settled thought is that we are nearly infinitely more likely to be in one than to not be in one, based to the assumption of an infinity adjacent universe, and the ontological theory that it is in fact possible to construct a simulation whose construction is transparent to it’s inhabitants.
So I wouldn’t be so quick as to write that off.
I would especially expect adherents to various religions to understand simulation as a probable foundational mechanism of their faith, considering that many religions essentially directly imply the formation of the universe as information based… but then science seems to be converging on information being the fundamental ether as well, so who knows.
By that same token, you could identify any poorly-understood corner of human perception to be evidence of simulation. Moon landing? Simulated. Quantum mechanics? Not natural, entirely simulated. My dog disappearing every week to pester my gereiatric neighbor for Beggin' Strips? He's actually being cached in a localized foveal dimension that ceases to exist when I look away from him.
Causality is convoluted and complex, the urge to ignore it has always overcome the less-curious individuals that are predisposed to hysteria and listlessness. Citing LLMs as the latest reason why we're simulated is not going to precipitate some scientific revolution in the understanding of reality. The underlying mechanics of text synthesis are easy to learn, they just don't want to learn it.
Idk, I find that carefully tending the garden of the mind , sowing the seeds I want to harvest later, eradicating the weeds with prejudice, and in general not entertaining things which are not useful to my purposes is, for me, a highly beneficial practice.
This does not mean to ignore things that are unpleasant, but rather to not allow things that do not benefit your diverse goals to occupy your productive potential, focusing instead on things that inform your path, actionable and relevant information, tools rather than distractions.
> in general not entertaining things which are not useful to my purposes is
Yeah, I think I do more or less the same as you describe, except my barrier to figuring out what is "not useful to my purposes" requires it to first exist in my mind for a while, before I can discard it as not applicable, as sometimes seemingly random things in one context somehow relates to completely different things.
I've chosen to do stuff sometimes that made no sense besides "It's fun but a waste of time" and it ended up leading me to realizations and experiences I wouldn't have had otherwise. But if I focused too much on avoiding things and optimizing "what I let in", I'd never be open enough to learn what I didn't know I could learn from it.
I planned and supervised the build of an ambient recall system, where a 4b model looks at the last 3k or so of context and picks through the RAG database for high ranking memories to inject, as well as mineable things to mark. Injections happens about 1/5 turns on most technical topics, data picked from prior design docs and data sheets mostly. At session wrapup the inference model goes back and rates all the memory injections in a frontmatter section, then looks at all the memory suggestions to commit those it finds memorable to the RAG database. Manual memorisation and RAG search are also available inline in the chat to both the user and the model. It also allows the main model to spawn little models as minions to work on repetitive simple tasks.
The thing to remember is that LLMs deeply model human behavior. If you want them to do their best work, you need to treat them like a collaborator and get them”invested” in the work and the outcome. I use an onboarding process with every new context and maintain an environment where a human would likely feel invested in the work and the outcomes. For me, it prevents a host of failure modes, and code quality has markedly improved.
An analysis of panels per capita vs regional IQ would be an interesting signal. Panels are cash positive in less tan 5 years of their 40 year lifespan. There is hardly a better investment up until you cover your own usage.
The argument essentially breaks down to "smart people buy more solar panels, dumb people buy less solar panels". I think this argument is simplistic. I imagine the primary indicator of how many panels per capital a region will have are either the total amount of sunlight it receive, the total value of local incentives, or perhaps the regional cost of grid electricity.
My highest energy months are the ones with the least amount of sunlight, and my highest energy hours are during long nights, because my primary energy expenditure is my heat pump. This use case is common for people that live in colder climates, which is a large number of people. This causes me to require a much larger base kwh solar install and battery capacity than other homes in other environments.
If we assume a potential 8% ROI in the market, you would need to offset more than $100/mo in electricity usage for every $15,000 you spend in solar install before solar becomes a better investment. The numbers just don't crunch well for many of us.
That is pretty optimistic. The calculators I've used online estimate my payback at 18 years and my lifetime savings at about $18K, with $32K out of pocket up front for the install. But my roof is 50% through the lifespan and I was told they would not warranty it against leaks due to panel mounts unless I first replaced the roof. That's $25K.
My next house will be my forever home, a little farther south than where I am now in the PNW, and on a big enough piece of land to use ground mount instead of roof mount. But right now, I cannot make the numbers work. I'd love having solar but I am not spending five digits of extra money just for the fun of it.
I think the problem is likely exactly what you describe, the high cost for most people to install the panels.
For some reason people treat roofs like black magic, and in some ways I can see that from a contractor perspective.
Since I’m looking at this from a different perspective (in house labor, we also do our own construction) for us it’s an absolute no-brainier. A 660watt panel which cost us $125 produces $200 of electricity in its first year of operation at local rates.after installation and support infrastructure our installed per panel cost is around $400, so on the third year we are cash positive.
I acknowledge that it’s not the same for many people, but this seems like it is in the same category as the fact that I can get an MRI from the exact same machine here for $150 (in an unsubsidised, for profit commercial imaging center) while the (imaging only) cost is $2700 in the USA for the same study. It seems like somebody is getting screwed.
That industry exists, it is called Purchase Power Agreements. The value of x is usually 20 or 25. It is typically lucrative for the company, not so much the homeowner.
I see you’ve never been to (pick one of many places where the social conditions are such that anyone who makes it to an age of agency with their brain fully intact is almost guaranteed to leave because it’s intolerable for anyone who actually thinks much) unfortunately, until you’ve lived in one of those places, it’s easy to imagine that people are the same everywhere. They are not. Social conditions are an extremely strong force in the intellectual development of humans.
To imagine that there are not regions that are comparatively intellectually impoverished is a comforting illusion, but unfortunately it is not reflective of the statistical reality nor the subjective experience of living in one of those places. Culture is very much regional, and cultural (social) factors (along with their physiological consequences) are by far the strongest factor in intellectual development.
In my experience sonnet<opus by a long shot for code review. Sonnet often flags things as errors that are not, because it fails to grasp the big picture… and also fails to grasp structural issues that are perfectly coded and only show up as problems at the meta scale.
I have no reason to believe that the next generation won’t offer similar gains in verification, and there is some evidence to support that the cybersecurity implications are the result of exactly this expansion of ability.
It depends on how you review. In an orchestrated per-task review workflow with clearly defined acceptance criteria and implementation requirements, using anything other than Sonnet (handed those criteria and requirements) hasn’t really led to much improvement, but it drives up usage and takes longer. I even tried Haiku, but, yeah, Haiku is just not viable for review, even tightly scoped, lol.
Siccing Sonnet on a codebase or PR without guidance does indeed lead to worse results than using Opus, though.
That makes sense, if your scope is tight enough, good enough is good enough. I’ve got the expected specifications and code style guides, including some aerospace engineering ones, but in complex systems I still run into difficult to sus out corner cases where the code works but the system breaks, usually due to unresolved conflicts in operational requirements.
Lol yeah, I don’t think I’m ready to ride in the jet that Claude built lol. I should clarify that I use the code guidelines because they are solid guardrails for making things that perform predictably, not because I’m building MCAS lol. Let’s hope that “vibe aerospace engineering” is a way off for now.
Honestly by the time it gets to review it should be rock solid, so the only thing the reviewer has to think about is the big picture and never “does this actually do what it’s supposed to without abusing any of the interfaces”. Vibe coding makes solid validation, testing, and documentation trivial. The onus of proving your code is good needs to shift downward, not upward. And straight up vibing it is absolutely a terrible idea for anything other than a demo or a simple tool.
You can go just as fast if you make good code, you just have to burn more tokens to do it. The tokens you burn in strict structure and documentation you’ll save in debugging as the codebase grows. I’m 5-30x my normal production depending on the day…with zero team and writing better code than I ever have, but you need a robust system to manage the path, and active supervision and management basically you’ll apply your senior dev skills as if you were managing 50 frisky interns.
AI coding is like having a team of 100 interns. It’s incredibly powerful but you need to keep it under control or you’re gonna have a bad day.
Write documentation describing the specs , the APIs, the protocols, and the customer stories. Specify that everything must be divided with clear separations of concerns, interfaces, and state objects. Any single file should have a clearly defined role and should not span domains or concerns.
File separation is even more critical than functional refactoring. It’s the files and their well defined and documented interface surfaces that will keep things from becoming an indecipherable tangle of dependencies and hidden state. Keep everything not defined in the interfaces private so that it is not accessible from outside the file, and prohibit attaching to anything without using the designated public interface surfaces.
Then write an implementation plan.
Then the skeleton, then start filling features one by one. Write the tests or testing documentation at the same time. If you have the luxury of compile time flags, put the tests right in the functions so they are self validated if built with test=1. (I know that’s weird but it helps the AI stay constrained to the intent)
After each minor feature (anything that would take me >1 hour to personally do, since the last review), have all touched files reviewed for correctness, consistency, coherence, and comments both within the codebase and the documentation. Don’t add features to the code, add them through the documentation and implementation plan. Don’t let Claude use the planning tool, it tries to do too much at once…. That’s how you get spaghetti.
One little thing, then review. 1/4 of the tokens burned in writing code, 1/2 in aggressive review / cleanup and 1/4 in ongoing documentation maintenance.
Thats the real price if you want to produce good code…. and you can produce really solid , maintainable code.
It’s just 4x the price of vibe coding… but 1 solid senior developer can still produce about as much as if he was running a team of 5-10 engineers depending on the project. Still incredibly rapid and economical…. But it takes the same skills as you need to run a team as well as an excellent sense of smell to call out wrong turns.
Also, use the 1M context model, have a solid onboarding that describes your company culture, and why the project matters to the AI collaborator, as well as your coding practices, etc. I also use several journals (musings, learnings, curiosity) that the AI maintains itself, reading them during onboarding and writing them in wrapup. It is at least a 2x when the AI is acting as if it were a person that is deeply invested in the outcome. Treat it like a collaboration and you will get better results.
It’s a token fire. But IMHO it’s the way if you’re building something that has to be deployed at scale and maintainable.
Straight vibes are fine for mockups, demos, and prototypes.
It depends on the kind of software you are programming.
If you are programming regular commercial software (office applications, web apps, games) with customers tolerating occasional bug and lot of pressure deliver fast, you can gain lot from Claude. Facebook motto: Move fast and break things
If you are programming software for industrial applications, critical software, most of the time you spend is not on writing software but writing tests, documenting, doing multiple rounds of reviews and for really critical applications doing formal verification. In this case AI can be also counterproductive, because if you absolutely have to understand every single line of code, manual coding helps to understand the code.
Example of cutting costs in programming of critical software
That’s most of my work(embedded sensor and control networks) and I’m sure that informs my methodology. I honestly don’t know much about how AI can inform standards SAAS but I have seen what happens when you just turn it loose, and in my experience it hasn’t been pretty; it works, but then when you need to change something it all crumbles like a badly engineered sandcastle.
OTOH for single purpose pipelines and simple tools. Claude can oneshot small miracles in 5 minutes that would take me 2 hours to build.
An example is the local agent framework that I had Claude spinup to do JTAG testing. I used to spend hours running tests over JTAG, now I have a local model run tests that Claude and I specify in the test catalog and it just runs them every time we add features. It took Claude minimal guidance and about 3 hours to build that tool along with a complete RAG system for document ingestion and datasheet comprehension, running locally on my laptop (I know it has a fan now lol) that only reaches out to the cloud when it runs into difficult problems. I don’t care if that is a bit of a mess, as long as it works, and it seems to , so far so good.
The testing is where Claude is basically magic, but it’s because we specify everything before we build and change the specs when we change the IRL code that it works. English is code, too, if you build structured documentation… and the docs keep the code accountable if you track the coherence.
If you are relying on understanding every single line of code, then maybe you should examine your modularity and testing norms. I don’t know about you, but the next day, I can’t realistically claim to actively hold an understanding of every line of code I wrote the day before. But AI can review 10Kloc and hold it in context with flawless retrieval. I cannot do that.
If you have the right structural framework and don’t approach it as a crutch but rather an amplifier, you can actually improve code quality and documentation while multiplying productivity, and you also don’t get cognitive atrophy out of the deal.
Also, previously unrealistic testing jigs are now trivial to implement, so I can test my code way beyond the point where I would have shipped it before.
AI , like people, makes mistakes. But using AI enables you to pivot to building the infrastructure that assures that no mistakes can escape the lab. That becomes your entire focus, instead of being a burdensome and usually neglected operational overhead.
It’s definitely easy, even tempting, to “hold it wrong” though.
It is a lot of work, but I’m much more productive and produce better code than when I was running a small team. And I’m not spending 36k a month. As a research stage startup, that’s a really big deal.
I’ve been writing code for nearly 50 years now, and the only thing I like better than coding is getting things done. For me, AI is rocket fuel if you do it right, and a bunch of hypergolic liquid if you don’t.
So I wouldn’t be so quick as to write that off.
I would especially expect adherents to various religions to understand simulation as a probable foundational mechanism of their faith, considering that many religions essentially directly imply the formation of the universe as information based… but then science seems to be converging on information being the fundamental ether as well, so who knows.
reply