AI is a threat if you're a messy codebase, an unsolved math problem, or cancer. Otherwise you only have an improved quality of living to look forward to IMO.
Why would I ever do that to myself? My experience with Codex/GPT is fantastic, while my impression of Claude/Opus is that it's longwinded, patronizing, token-inefficient, stops to ask stupid questions every other minute, overcomplicates simple tasks, often poor engineering overall. I don't use it but this is what I see my partner run into who has access to both and compares them often. She has the same assessment.
Cuz OpenAI has been secretly downgrading models on many accounts, including mine lately. I paid $200 a month since like gpt-5.4, and since Astra released I found the model is somehow acting strange, it is until I checked X I have discovered that OAI is giving Luna level models when I am requesting Sol/Astra, or some piece of s** that is even worse than Luna. I basically had to ran every session with a Pelican test to determine if that session is safe. So I just spun up my Claude $20 and figured that now I can get all the work done just with Opus 5. Let me show you a pelican, by "gpt-6-sol". Cutting usages is one thing, but secretly downgrading models to a level that is not reliable anymore is the last straw. I am not saying other frontier labs (I am talking about you Anthropic) isn't doing this, but their version of downgraded/quantized/reduced effort model is at least usable, probably just slightly dumber, OAI's differences is day and night. https://imgur.com/a/PDbYdOQ
Somehow this just hasn't happened to me. I use Astra on high all day for fairly intensive game dev tasks, sometimes cranked up depending on the task.
I have heard ultra thinking might delegate to worse agents for some of its sub-tasks, but I don't use that much anymore since Astra came out. Just high seems good enough to throw most laundry lists at.
It feels goalpost-movey to downplay exploring a large search space efficiently in regards to "intelligence". If we dug into a human genius's brain and found it was somehow trying out a million ways to solve a a problem at once, no one would seriously suggest the person isn't actually intelligent.
And our brains must something like that at some physical level. You can't have a "turtles all the way down" of reasoning - the building blocks must be simpler. It must reduce to something like pathfinding and brute force at some point, weighted by factors in the system and maybe some randomness.
We have a romantic view of intelligence, perhaps stemming from intuition within the context of scientific discovery. Given enough intelligence, and enough context, a brilliant person can have a stroke of inspiration that allows them to make a major leap (a-la General Relativity or Fermats last theorem). We haven't seen THAT same capacity from a machine, but we see the more ordinary, unsexy grinding type of progress that represents 99.9% of scientific reality.
I would find it very interesting to train a model on information only available prior to the discovery of e.g. relativity or calculus and see if it can invent it. My intuition is that modern frontiers absolutely could. Not to take away from their brilliance, but Newton and Einstein were brilliant people who also happened to be in the perfect place at the perfect time - there's not so much "low hanging (i.e. approachable by one brilliant individual) but immensely valuable fruit" anymore.
Is there truly anything new under the sun? Hasn't all of existence alway been here? All math, all physics? We could have merely discovered it. Intuition might be nothing more than combinations of what already exists rather than some sort of divine insight that unlocks previously unknowable mysteries.
Agreed. I don't believe intuition and creativity would be more than pattern recognition, remixing ideas, and trial and error combined with a kind of "genetic algorithm" approach if you deconstructed them into what the brain is actually doing.
Bluetooth is slow. The transport is 3Mbps at max, if you subtract all the headers from different layers, you may have like 1.5-2Mbps practical transfer speed.
And harm a lot too, you phone can't deep sleep since it has to wake up periodically to process data from bluetooth stack. Combined with slow transfer speed, that gonna eat your battery like nothing.
Playing audio over bluetooth also wakes things periodically, but it uses almost no power. With a similarly competent design photo transfer should be very battery efficient.
No, most(if not all) bluetooth controller has audio offload, basically the cpu does not involve(or very little) when transfering data from storage to radio.
Don't you mean yes bluetooth controllers have audio offload? "similarly competent design" means you do the exact same thing in the other direction. Instead of rarely waking up the CPU to coordinate sending, you rarely wake it up to coordinate receiving.
You would often not have wifi available, and you wouldn't want to have to type in wifi passwords to your camera all the time. But your phone will almost always be nearby and persistent bluetooth is easy.
Problem is they have to disconnect from the current wifi ap to connect to the cameras ap which is inconvenient and means there can’t be a constant connection.
Wifi NAN could be used to solve this problem but I’ve not seen anything using it. Apple only just added support last year though.
I tried fd but it seems to ignore so much that it's basically useless. If I wanted `git ls-files|grep` I would `git ls-files|grep`
yells at cloud
..it's probably ok actually and I should give it a real go, but I'm too used to find and even have a keybinding in my ~/.inputrc to insert a find + where loop
"\e\C-f": "find . -type f -print0|while read -rd '' f; do ; done\e-b\C-b\C-b\C-b\C-b\C-b\C-b"
(yes I know about -exec; I find the loop easier to work with)
Humans have been hand-crafting artisanal test cases of equal banality for years, often to meet some metric no one is verifying deeper than an automated report etc. I'm more inclined to believe the null hypothesis here, that the formula doesn't need any change and the signal is still equally valid. If anything changed, the signal is probably more useful now, since you'll never catch a good AI writing test cases that do literally nothing except call a function in a try catch with an empty catch block. (Models may have done that a few years ago but I haven't witnessed that behavior in a long time.) I've witnessed myriad examples of this in pre-AI production code.
As a programming lead on a hobbyist video game project, we're reaping massive rewards being in category #1. I keep the architecture and important details in check while letting frontier models go ham. As alluded, it's a video game, not a life support system, so bugs are low-impact. But even better, the defect rate is actually the lowest it's ever been. Insidious bugs baked in by years of accumulated human error are trivial for Sol or Astra to untangle. This is the best time to be alive so far if you enjoy hobby game dev.
I've found the same, the rate of bugs has dropped pretty dramatically after switching to ai generated code. I think it's partly because ai will write 1000s of lines of unit tests without complaining. I also have a github workflow where claude runs the /code-review command on every PR.
In the world of web apps, I find the agent's ability to write good e2e tests to be a real game changer. Turns out with enough rigor you can write pretty stable mostly not flaky e2e tests. And even flaky ones are fixed quickly due to a fuck ton of assertions at every step.
Test code looks like a mess, even more than the usual LLM code. takes a while to let it go. Test report looks beautiful though.
When the test code "looks like a mess", how do you get assurance it is testing the right properties?
Like you, I've found that LLMs can improve test coverage by decreasing the amount of developer time spent writing tests. But generally, it takes a lot of manual work to set up the initial testing framework, and even then, a lot of vigilance to ensure that what is actually tested corresponds to the description of the test.
I feel weirdly stuck on both sides of this. I haven't been in a full-time "code writing" roles for years, so my own personal usage of LLMs for anything is roughly nil right now, just because I continue to be able to get done all tasks I wanted to get done in the time I have using tools and techniques I already had available, and have seen little need to adopt new ones. The exceptions have been around things like using the text interface for diagramming tools to at least get the initial scaffolding set up without having to learn the specific quirks of that tool, then spending maybe an hour or two at the end to clean up and make it look nice and ensure it's actually coherent and has no mistakes. This is a task I have to do maybe two or three times a month, so it isn't a huge win, but it's not nothing.
But that's digression. The short of it is I've seen enough to convince me these tools may as well be magic and a whole lot of tasks that break down into "produce media content of some sort" that has a well-defined goal and definition of correctness will be permanently sped up by automation. This includes a lot of software writing. At the same time, I shared the skepticism of estimates of economic impact and irrevocably changing the larger world. I'm a lot closer to the business side of the house these days, working with customers and prospective customers to identify use cases, reference architectures, pain points, feature requests, and bring this back to the development teams to attempt using real-world experience like this to inform how we design products. It's not product management as I'm focused more often on the nitty gritty technical details, not high-level user experience or roadmaps. But it gives me a great avenue into seeing what causes organizations to actually buy and/or adopt new software products, and the rate at which they can do that.
And frankly, it isn't moving the needle much. They have the same budgets they always had, so they're not buying more, and our business is growing, but no faster or better than it grew before agentic coding became a thing. I always wonder because it seems the glowing success stories on Hacker News come in one of three varieties. It's the solo indie dev, usually targeting mobile app stores, who churns out dozens of roughly "will compile and doesn't immediately crash at runtime" apps in the time it used to take to complete one. It's the hobbyist, making software only they and maybe their immediate friends will ever use. Or it's startups, whose monetization model isn't monetization at all; it's just having something shiny to show investors in order to convince those with loose money to give enough to you personally that you can build up a nest egg whether or not your product ultimately ends up ever having a single paying customer.
In my own business, a multi-decade, mature but not hyperscale company selling overwhelmingly self-hosted enterprise open source software, I can see the impacts on output. We have the same major products with the same release cadence. Each point release averages more new features than they used to, but also more regressions. It's overall a mixed bag. Non-technical product management staff is able to contribute code. We have a ton of new internal tools that nobody uses but they're there now. On the customer side, those that hinge decisions on wanting features that didn't exist yet are benefiting from getting those. Those that already had the features they want are losing from the greater rate at which regressions get through. The net business impact seems to be things have definitely changed qualitatively, but in purely financial quantitative terms, things are about the same as they were before. More code being committed to various git forges, but same headcount, same revenue, same margins, and same market cap.
This is perplexing because I've been all over the country, coast to coast and north to south and to Canada, and never encountered this despite being shorter than the person you're responding to (who is actually well above-average height..)
reply