I'm a manager at a large consumer website. My team and I have built a harness that uses headless Claude's (running Opus) to do ticket work, respond to and fix PR comments, and fix CI test failures. Our only interaction with code is writing specs in Jira tickets (which we primarily do via local Claudes) and adding PR comments to GitHub PRs.
The speed we can move at is astounding. We're going to finish our backlog next quarter. We're conservatively planning on launching 3x as many features next quarter.
Claude is far from perfect: it's made us reassess our coding standards since code is primarily for Claude now, not for humans. So much of what we did was to make code easier for the next dev, and that just doesn't matter anymore.
This was always going to fail because the requirements were insane: solving SQL, XML and JSON generation should have never been part of the spec. There are hundreds, if not thousands of libraries for the those cases.
The developers should have never tried to boil the ocean: simple Kotlin or Scala style interpolation with overloading `+` for concatenation is the 80% use case here. Yes it doesn’t do everything. But it makes life a lot more ergonomic. And they rejected this solution out of hand! So instead of something useful but not perfect we get nothing.
Apple first-gen products are often half-assed. But they iterate and improve on a regular cadence. The current Apple Vision Pro is a dev kit, it will get better.
$68 billion is a lot, but it also only three Big Digs ($22 billion). If Chernobyl killed the Soviet economy it was because it was in already terrible shape.
Because we outlawed railroad strikes but didn't outlaw airline strikes.
Doesn't really prevent a strike though: it just makes it cost more. Here in Massachusetts it's illegal for public school teachers to strike, yet it has happened a couple times in the last year. In one case the teacher's union was fined: https://www.bostonherald.com/2023/02/08/woburn-teachers-turn...
I agree. The only real use for more pixels is for crop-to-zoom. I want big glass and big sensors so we can get real bokeh.
My ideal phone camera would be a single APS-C sized sensor replacing all three current iPhone cameras. The lens should be a f1.2, 50mm equivalent pancake. Yes that’s hard to do, but using fancy fresnel lenses and a pile of CPU to correct things I bet you could make it work. Make the sensor ~30 megapixels so you can digital zoom.
Add a mount that includes communication so if you want you can add fancy lenses and they can be active parts of the autofocus system.
This design actually competes with low-end mirrorless and is probably even possible to build (the lens might be pushing what’s possible, but I bet we can get close).
It feels like Xiaomi is chasing a market that doesn’t really exist. Smartphone cameras are good enough for most people. And for folks who want more, mirrorless and DSLRs start cheap and much, much better.
Even worse, this phone looks to use the same small sensors and small lenses all smartphones are saddled with. A bulkier form factor and slapping Leica’s logo doesn’t make a “real” camera. Big sensors and big lenses do.
Literally none of what you listed is work. Board games, happy hours, friends: these are all things you can (and should) be doing in your non-work hours.
The state doesn't have unions, the teachers do. The state negotiates with the union and then the teachers vote to approve the agreed on contract. If the teachers don't like the contract the union has negotiated, they can vote against it. If the union leadership continues to negotiate unacceptable contracts, the teachers can vote their union leadership out.
At what point are “rigorous specs” just another, higher-level programming language? We’ve already moved the needle on language “high-level”-ness without AI. The Kotlin and Java I write today is orders of magnitude more expressive than the C of the 70s.
What about AI is going to change how programming languages climb the abstraction ladder?
Most EVs have one pedal mode: lift your foot off the accelerator and the car rapidly decelerates to a stop using regenerative breaking.
My BMW has a neat adaptive driving mode: because the motors don’t use permanent magnets, lifting off would normally result in coasting. When adaptive driving is on, the car uses its radar to figure out how much regeneration (and if necessary friction) braking to apply so you stop just short of the car in front of you, all without applying the brake. The same system is also used to dampen acceleration when there are cars in front of you. It sounds like madness, and is very strange the first few times you use it, but ends up making driving more pleasant.
I would love to see a language that considers tooling a first class problem. Most (all?) languages barely consider complex projects with 100s of dependencies and large multi-step builds. Java shouldn't have to wait for Maven and Gradle to come along, and Python shouldn't be shackled to piss-poor systems like pip.
This is something Rails gets very right. Bundler and Rake make Rails one of the nicest development environments there is.
But we can and should do better. Why is DLL-hell still a thing? Imports should specify versions, defaulting to a default if none is specified. Languages barely even consider versions today, they are almost always hacked on via magic text strings in filenames.
Why do tools like Dependabot and Renovate need to parse a million dependency formats to figure out versions? The language runtime or build system should produce that as a first class output.
Deployment and documentation are other places most languages ignore and delegate to a variety of crappy external tools.
Build Server Protocol is a good step in the right direction, but it barely scratches the surface. It would be great to see a language that prioritizes the parts of the developer experience that aren't writing code.
Preview, despite its name, does this really well. Its freeform drawing tools are a little different (shapes and lines are vector, not pixel) but they're very easy to use.
Why not just specify all contributions must be written with a steady hand and a strong magnet.