I think you can use them critically. Probe the code, see how it behaves when tweaked, can you break it etc.? without slowing you down too much. And in doing so you probably learn 80% of what you would have if you'd written it yourself by hand.
But then there are definitely cases where LLMs are slower and less reliable than someone using tooling by hand, especially like deterministic refactoring operations can be done close to instantly if you already know what needs to be done and how to do it.
I'm less familiar with Swift but from a design point of view Go and Kotlin have really different ergonomics. Kotlin leans in really hard to creating DSLs etc. whereas Go avoids all that stuff like the plague. To me this makes the tag line a little confusing, like what does this imply for the design of this language?
I think the thing is that 3.5 flash is actually similarly capable on a lot of tasks that matter and is faster. Pro is more specialised in the direction of mathematical reasoning and stuff.
Yeah this idea that the unique value proposition of humans is now our motor capabilities rather than our cognition is unnerving as someone with dyspraxia. Like, oh good, they've figured out how to convert it into a much more limiting disability by commoditising apparently most knowledge work. Great.
Generally it's more "overlooked" than allowed. In the UK for instance cycling on pavements (sidewalks) is unlawful but the guidance is to only enforce this if the cyclist is not giving consideration to pedestrians.
Realistically though I think it leads to the same state of play as everywhere else where pedestrians don't much fancy being hit by a faster moving and taller (if not larger) object so dodge out of the way even if they aren't necessarily obligated to.
I think the fundamental aspect of flow is that it requires a high amount of cognitive engagement. Most of the time you're just not getting that from interacting with an LLM because the process is relatively passive. There are also forced breaks while it does its internal CoT which breaks flow.
I think a lot of people get a sort of novelty effect when first interacting with an LLM which can feel superficially like flow, but it's different in that it eventually wanes and what really happens in practice is you're encouraged to disengage and this makes it almost impossible to get into a true flow state.
The risk here I think is that if you get humans disengaging from the task at hand, there's a higher chance of bugs being introduced. You might move slightly faster in the short term but be forced to hit the brakes in the medium/long term.
> It's like a denial-of-service attack on the human mind.
I think this may be an example of deliberate hostile design, attempting to force users to adopt LLM based solutions to then summarise the vast output. Pushing back against AI contributions as such in this context makes sense, especially in software with an existing proven track record of great value delivery like Godot.
I think the implication here is that you can almost certainly bias the models to always accept you by including "nudge" phrases like "I demonstrated real world deployments" and "helped develop an application in the context of a complex architecture..."
I guess the question becomes about if we are meaningfully capable of doing this kind of verification any better than just adding another layer of automation
I think the main issue with transformer image generation in this respect is that not only can the image be explicit but also using it for this has an incredibly low effort cost and could photo-realistically depict a real living person and materially affect their life.
Whereas drawing applications have a natural barrier to achieving all of these together: time and skill.
More just interested in medical imaging in general but: unobstructed soft tissue imaging is possible with this, e.g. abdomen. You can get reasonably good differentiation between types of tissues using ultrasound in this context although there is the potential for ambiguous findings where further scans like MRI will be required to get less ambiguous information about it.
Chest cavity, brain tissue scanning etc. will likely remain unrealistic as ultrasound waves won't penetrate bone and the ribs and skull will interfere.
I think it's a bit odd to compare this to an MRI. The physics are totally different and there are things it fundamentally won't image in the same way because it's basically just ultrasound.
The approach sounds like something which appears in a few research articles from the 2010s (ultrasound computed tomography), although submersion to make the ultrasound transmission more efficient seems novel.
It's possible the "spa" approach is used because it's hard to achieve the level of cleanliness required in a typical health facility using a shared bath.
Tried the first one and it doesn't seem to work (dots don't respond to motion), and is absolutely riddled with intrusive ads. The one that another commenter left which is on F-droid is much better
But then there are definitely cases where LLMs are slower and less reliable than someone using tooling by hand, especially like deterministic refactoring operations can be done close to instantly if you already know what needs to be done and how to do it.