the waste isn't a win, of course, but is a downside of a tradeoff that is massively weighted to the upsides for society -- that is (otherwise) completely clean always-on high capacity energy production.
We understand very well how to safely handle nuclear waste and make it a very (very) low risk downside.
looking backwards in the supply chain for other externalities is a good point, but I'm not sure any energy production method is exempt from this?
Also, by the way, my perspective isn't about nuclear Vs X (wind turbines etc) - I like all the ones that are net clean and useful in different circumstances as part of a mix.
I'm just addressing the narrower point about whether nuclear per se is a net benefit for society, which I believe it is, massively.
much has been written about the deteriorating quality of iOS.
There's bluntly not strong external evidence that software quality is a driving priority at Apple in recent years, so it most probably follows that concerns about maintainability aren't either.
I would say while LLMs do improve productivity sometimes, I have to say I flatly cannot believe a claim (at least without direct demonstration or evidence) that one person is doing the work of 20 with them in december 2025 at least.
I mean from the off, people were claiming 10x probably mostly because it's a nice round number, but those claims quickly fell out of the mainstream as people realised it's just not that big a multiplier in practice in the real world.
I don't think we're seeing this in the market, anywhere. Something like 1 engineer doing the job of 20, what you're talking about is basically whole departments at mid sized companies compressing to one person. Think about that, that has implications for all the additional management staff on top of the 20 engineers too.
It'd either be a complete restructure and rethink of the way software orgs work, or we'd be seeing just incredible, crazy deltas in output of software companies this year of the type that couldn't be ignored, they'd be impossible to not notice.
This is just plainly not happening. Look, if it happens, it happens, 26, 27, 28 or 38. It'll be a cool and interesting new world if it does. But it's just... not happened or happening in 25.
I would say it varies from 0x to a modest 2x. It can help you write good code quickly, but, I only spent about 20-30% of my time writing code anyway before AI. It definitely makes debugging and research tasks much easier as well. I would confidently say my job as a senior dev has gotten a lot easier and less stressful as a result of these tools.
One other thing I have seen however is the 0x case, where you have given too much control to the llm, it codes both you and itself into pan’s labyrinth, and you end up having to take a weed wacker to the whole project or start from scratch.
That's why you dont use LLMs as a knowledge source without giving them tools.
"Agents use tools in a loop to achieve a goal."
If you don't give any tools, you get hallucinations and half-truths.
But you give one a tool to do, say, web searches and it's going to be a lot smarter. That's where 90% of the innovation with "AI" today is coming from. The raw models aren't gettin that much smarter anymore, but the scaffolding and frameworks around them are.
Tools are the main reason Claude Code is as good as it is compared to the competition.
> The raw models aren't gettin that much smarter anymore, but the scaffolding and frameworks around them are.
yes, that is my understanding as well, though it gets me thinking if that is true, then what real value is the llm on the server compared to doing that locally + tools?
You still can't beat an acre of specialized compute with any kind of home hardware. That's pretty much the power of cloud LLMs.
For a tool use loop local models are getting to "OK" levels, when they get to "pretty good", most of my own stuff can run locally, basically just coordinating tool calls.
Of course, step one is always critically think and evaluate for bad information. I think for research, I mainly use it for things that are testable/verifiable, for example I used it for a tricky proxy chain set up. I did try to use it to learn a language a few months ago which I think was counter productive for the reasons you mentioned.
How can you critically assess something in a field you're not already an expert on?
That Python you just got might look good, but could be rewritten from 50 lines to 5, it's written in 2010-style, it's not using modern libraries, it's not using modern syntax.
And it is 50 to 5. That is the scale we're talking about in a good 75% of AI produced code unless you challenge it constantly. Not using modern syntax to reduce boilerplate, over-guarding against impossible state, ridiculous amounts of error handling. It is basically a junior dev on steriods.
Most of the time you have no idea that most of that code is totally unnecessary unless you're already an expert in that language AND libraries it's using. And you're rarely an expert in both or you wouldn't even be asking as it would have been quicker to write the code than even write the prompt for the AI.
I use web search (DDG) and I don’t think I have ever try more than one queries in the vast majority of cases. Why because I know where the answer is, I’m using the search engine as an index to where I can find it. Like “csv python” to find that page in the doc.
It's entirely dependent on the type of code being written. For verbose, straightforward code with clear cut test scenarios, one agent can easily 24/7 the work of 20 FT engineers. This is a best case scenario.
Your productivity boost will depend entirely on a combination of how much you can remove yourself from the loop (basically, the cost of validation per turn) and how amenable the task/your code is to agents (which determines your P(success)).
Low P(success) isn't a problem if there's no engineer time cost to validation, the agent can just grind the problem out in the background, and obviously if P(success) is high the cost of validation isn't a big deal. The productivity killer is when P(success) is low and the cost of validation is high, these circumstances can push you into the red with agents very quickly.
Thus the key to agents being a force multiplier is to focus on reducing validation costs, increasing P(success) and developing intuition relating to when to back off on pulling the slot machine in favor of more research. This is assuming you're speccing out what you're building so the agent doesn't make poor architectural/algorithmic choices that hamstring you down the line.
Respectfully, if
I may offer constructive criticism, I’d hope this isn’t how you communicate to software developers, customers, prospects, or fellow entrepreneurs.
To be direct, this reads like a fluff comment written by AI with an emphasis on probability and metrics. P(that) || that.
I’ve written software used by a local real estate company to the Mars Perseverance rover. AI is a phenomenally useful tool. But be weary of preposterous claims.
I'll take you at your word regarding respectfully. That was an off the cuff attempt to explain the real levers that control the viability of agents under particular circumstances. The target market wasn't your average business potato but someone who might care about a hand waived "order approximate" estimator kind of like big-O notation, which is equally hand waivey.
Given that, if you want to revisit your comment in a constructive way rather than doing an empty drive by, I'll read your words with an open mind.
> It's entirely dependent on the type of code being written. For verbose, straightforward code with clear cut test scenarios, one agent can easily 24/7 the work of 20 FT engineers. This is a best case scenario.
So the "verbose, straightforward code with clear cut test scenarios" is already written by a human?
> I mean from the off, people were claiming 10x probably mostly because it's a nice round number,
Purely anecdotal, but I've seen that level of productivity from the vibe tools we have in my workplace.
The main issue is that 1 engineer needs to have the skills of those 20 engineers so they can see where the vibe coding has gone wrong. Without that it falls apart.
It's an interesting one. We'll have to discover where to draw that line in education and training.
It is an incredible accelerant in top-down 'theory driven' learning, which is objectively good, I think we can all agree. Like, it's a better world having that than not having it. But at the same time there's a tension between that and the sort of bottom-up practice-driven learning that's pretty inarguably required for mastery.
Perhaps the answer is as mundane as one must simply do both, and failing to do both will just result in... failure to learn properly. Kind of as it is today except today there's often no truly accessible / convenient top-down option at all therefore it's not a question anyone thinks about.
How I see it, LLMs aren't really much different than existing information sources. I can watch video tutorials and lectures all day, but if I don't sit down and practice applying what I see, very little of it will stick long term.
The biggest difference I see is, pre-LLM search, I spent a lot more time looking for a good source for what I was looking for, and I probably picked up some information along the way.
Definitely. We have to find ways to replicate this.
One thing I've noticed is that I've actually learned a lot more code about things I didn't understand before. Just because I built guardrails to make sure that they are built exactly the perfect way that I like them to be built. And then I've watched my AI build it that way dozens of times now. Start to finish. So now I've just seen all the steps so many times that now I understand a lot more than I did before.
This sort of thing is definitely possible, but we have to do it on purpose.
OP here, yeah, I think that's a really good point.
I feel like the way I'm building this in is a violent maintenance of two extremes.
On one hand, fully merged with AI and acting like we are one being, having it do tons of work for me.
And then on the other hand is like this analog gym where I'm stripped of all my augmentations and tools and connectivity, and I am being quizzed on how good I could do just by myself.
And based on how well I can do in the NAUG scenario, that's what determines what tweaks need to be made to regular AUG workflows to improve my NAUG performance.
Especially for those core identity things that I really care about. Like critical thinking, creating and countering arguments, identifying my own bias, etc.
I think as the tech gets better and better, we'll eventually have an assistant whose job is to make sure that our un-augmented performance is improving, vs. deteriorating. But until then, we have to find a way to work this into the system ourselves.
there could also be an almost chaos-monkey-like approach of cutting off the assistance at indeterminate intervals, so you've got to maintain a baseline of skill / muscle memory to be able to deal with this.
I'm not sure if people would subject themselves to this, but perhaps the market will just serve it to us as it currently does with internet and services sometimes going down :-)
I know for me when this happens, and also when I sometimes do a bit of offline coding in various situations, it feels good to exercise that skill of just writing code from scratch (erm, well, with intellisense) and kind of re-assert that I can do it now we're in tab-autocomplete land most of the time.
But I guess opting into such a scheme would be one-to-one with the type of self determined discipline required to learn anything in the first place anyway, so I could see it happening for those with at least equal motivation to learn X as exist today.
> We'll have to discover where to draw that line in education and training.
I'm not sure we (meaning society as a whole) are going to have enough say to really draw those lines. Individuals will have more of a choice going forward, just like they did when education was democratized via many other technologies. The most that society will probably have a say in is what folks are allowed to pay for as far as credentials go.
What I worry about most is that AI seems like it's going to make the already large have/not divide grow even more.
that's actually what I mean by we. As in, different individuals will try different strategies with it, and we the collective will discover what works based on results.
because even supposing you have an interface for your thing under test (which you don't necessarily, nor do you necessarily want to have to) it lets you skip over having to do any fake implementations, have loads of variations of said fake implementations, have that code live somewhere, etc etc.
Instead your mocks are all just inline in the test code: ephemeral, basically declarative therefore readily readable & grokable without too much diversion, and easily changed.
A really good usecase for Java's 'Reflection' feature.
An anonymous inner class is also ephemeral, declarative, inline, capable of extending as well as implementing, and readily readable. What it isn't is terse.
Mocking's killer feature is the ability to partially implement/extend by having some default that makes some sense in a testing situation and is easily instantiable without calling a super constructor.
Magicmock in python is the single best mocking library though, too many times have I really wanted mockito to also default to returning a mock instead of null.
Yeah, it's funny, I'm often arguing in the corner of being verbose in the name of plain-ness and greater simplicity.
I realise it's subjective, but this is one of the rare cases where I think the opposite is true, and using the 'magic' thing that shortcuts language primitives in a sort-of DSL is actually the better choice.
It's dumb, it's one or two lines, it says what it does, there's almost zero diversion. Sure you can do it by other means but I think the (what I will claim is) 'truly' inline style code of Mockito is actually a material value add in readability & grokability if you're just trying to debug a failing test you haven't seen in ages, which is basically the usecase I have in mind whenever writing test code.
I cannot put my finger on it exactly either. I also often find the mocking DSL the better choice in tests.
But when there are many tests where I instantiate a test fixture and return it from a mock when the method is called, I start to think that an in memory stub would have been less code duplication and boilerplate... When some code is refactored to use findByName instead of findById and a ton of tests fail because the mock knows too much implementation detail then I know it should have been an in memory stub implementation all along.
the one I've noticed being the worst for lock ups is the camera / photos app, which is frankly very surprising given how central the photography usecase appears to be to iPhone sales and therefore Apple's bottom line.
I'm talking, I pull up the camera and try to take literally 4-5 shots quickly and by the 6th there's what feels like seconds of lag between the button press and the photo being taken.
It feels like I'm using an ancient camera phone, or a more modern phone but in extreme heat when the CPU is just throttling everything. But instead, this is a 2 year old iPhone at room temperature.
Interesting, likewise, the Camera app. And other camera apps, I use Halide too.
And Photos. Will it sync? Yes. When? Who the fuck knows? Doesn't matter whether you're on Ethernet or Wifi, gigabit internet. You can quit Photos on both devices, you can then keep Photos open foreground... so what? Photos will sync when it wants to, not what when you want it to.
you're right! The photo syncing is comically bad, again given the alleged importance of photos in the Apple marketing material. That said I've rarely used it in the past and so wasn't sure if it was a newly degraded experience or had always been that poor.
these things are hard, maybe impossible to define.
For example I mostly agree with your calls/called definition but you also get self-described libraries like React giving you defined structure and hooks that call your code.
React is 100% framework. They even bring their own DSL. It's absurd to call React library.
Library is something that can be pulled off project and replaced with something else. There's no non-trivial project where replacing React with anything would be possible. Every React web app is built around React.
100% this. To this day the official website still describe itself as a library, and I'm convinced it's completely for marketing reasons, since 'framework' feels heavy and bloated, like Angular or Java Spring, while 'library' feels fast and lightweight, putting you in control.
Framework can be more or less modular, Angular or Ember choose to be 'battery included', while React choose to be more modular, which is simply choosing the other end of the spectrum on the convenience-versus-flexibility tradeoff.
React ostensibly only care about rendering, but in a way that force you to structure your whole data flow and routing according to its rules (lifecycle events or the 'rules of hooks', avoiding mutating data structures); No matter what they say on the official website, that's 100% framework territory.
Lodash or Moment.js, those are actual bona fide libraries, and nobody ever asked whether to use Vue, Angular or Moment.js, or what version of moment-js-router they should use.
I think absurd is a bit strong. It'd be absurd to call something like rails a library.
I think you can probably see that distinction already, but to spell it out React is described as a library precisely because it does just one thing - the view - and leaves it to you to figure out the entirety of the rest of the stack / structure of your app.
Framework, at least to me, but I also believe commonly, means something that lets you build a full application end to end using it.
You can't do that with React unless your app is just something that lives in the browser either in-memory or with some localstorage backing or something. If that's your app, then probably I'd agree React is your framework per se, but that's hardly ever the case.
By the way, back to my original point, I still do think these things are impossible to define and in lots of ways these terms don't matter - if it's a framework for you, it's a framework - but I just had to defend my position since you described it as absurd :-)
React is a framework for blatantly obvious reasons.
It introduces JSX, which is technically speaking its own programming language independent of JavaScript.
It defines hooks like useState() and useContext() for state management, meaning it is not UI only, plus "function based" components that act as a pseudo DSL that is pretending to be functional JavaScript (which it isn't).
Most of the time you're expected to render the entire page body via react.
You couldn't get further away from the idea of a library.
Most people don't but you absolutely can use React a library. When React was very new, it was popular to use it as a view layer with backbone.js. In that usage, it's essentially a sophisticated templating library.
You can use Spring as a library if you really want to as well, but it's still a framework.
Id maybe concede that frameworks are a subset of libraries. You can use most frameworks in a library fashion, but the opposite is not true (you'd need a mini framework)
Agree, for modern React with hooks. A React component looks like a normal function, only you can't call it. Only React can call it, in order to set up its hooks state.
That’s because React started as a small, focused library and evolved as even more than a framework, a whole ecosystem, complete with its own best practices
React's homepage says "The library for" and "Go full-stack with a framework. React is a library. It lets you put components together, but it doesn’t prescribe how to do routing and data fetching. To build an entire app with React, we recommend a full-stack React framework like Next.js or React Router." and "React is also an architecture. Frameworks that implement it let you..."
React's Wikipedia page says "React ... is a free and open-source front-end JavaScript library", and has no mention of Framework.
Why die on a hill that it "is" something it says it isn't?
> Why die on a hill that it "is" something it says it isn't?
Because I think they're wrong about that.
If you'd prefer a different metaphor this is windmill I will tilt at.
To provide a little more of a rationale: React code calls the code I write - the JSX and the handlers and suchlike.
It's also pretty uncommon to see React used at the same time as other non-React libraries that handle UI stuff.
Most importantly, the culture and ecosystem of React is one of a framework. You chose React at the start of a project and it then affects everything else you build afterwards.
It's super interesting that you have this definition given your authorship of django (I mean, actually interesting, not 'interesting' :-)
In another comment I used the example of rails as a kind of canonical 'framework' that can potentially do everything for you full stack, and django is in the same category, juxtaposed against something like React that cannot.
To that, I think your last paragraph is the one I agree with most closely. It's true, but only for the view part of the app, right? I think that's where I get stuck on stretching to calling it a framework.
I guess I can see it if you're defining your view/client as a separate logical entity from the rest of the stack. Which is totally reasonable. But I guess just not how I think about it.
I just think they genuinely don't know. I was years into travelling before I learned about this 'trick'.
For my part, I'd just always assumed the charge would be ultimately converted by my bank in any case. Seems obvious now I look back, but I honestly just didn't think about the trick.
Just as an example that gives evidence for this, sometimes you'll go to the same place multiple times and the norm is they ask but occasionally someone won't. So it's not a policy.
I presume the people who don't just don't know about it, don't want to bother me and aren't aware it will make a difference.
I think I disagree, if I understand you correctly.
Technology is augmenting real world experiences all the time, and not always in positive ways.
Whenever anyone does anything with the real world as the destination, the phone comes too, and all that comes with the phone intersects with whatever it is you're doing. Again not always in positive ways.
I completely agree that the nature of the technology / platform doesn't matter or affect this.
> Technology is augmenting real world experiences all the time
As the sibling comment says, I never made a claim that technology writ large wasn't augmenting real world experiences. I did make reference to 'the technology', which if it helps to clarify could be read as 'a specific X technology'. A technology could be as broad as 'software', but it could mean a software innovation like 'infinite scroll with status updates'. How a technology is used can also factor in. iNaturalist, MeetUp, and hospitality club style websites are all social networks that encourage people to go out into the world and experience things. Even Facebook groups and marketplace can facilitate this to some degree, though real-world human connection is counter to its revenue strategy.
> and not always in positive ways.
Augmenting means to add to something, not take away. The word for that is detract.
yeah, I think I misunderstood the point you were making and I'm making a different but related point. So we probably don't disagree.
Interesting point on the word augment. I'd always took it to mean something more like a value-neutral addition, to which one is free to apply their own value judgements, which could be positive or negative and in any case aren't objective.
To take an example of the kind of thing I'm thinking of: you're out on a peaceful countryside walk yet are able to receive emails. The experience is augmented by this-- in my interpretation meaning you have something literally added to it. But the effect of this can be both positive or negative, to any degree, depending on the email itself and any number of other factors.
Anyway I think we're mostly just getting into semantics and I probably agree actually with your original point :-)
How are you disagreeing? I think your point is separate?
Poster above is making a claim about what brings us into our body-experiences, or what takes us out. Technically mostly noting that technology takes us out of the somatic experience.
Accessibility? Meditation apps? There are things with technology that allow us to be more connected with each other and ourselves in some ways. But not really to the somatic experience of their body, the world around them.
Generally if I understand OP correctly, I strongly agree. As a techie it took me a long time to understand the somatic experience as the missing part to my world view and thinking.
We understand very well how to safely handle nuclear waste and make it a very (very) low risk downside.
reply