Since coding with Cursor, I’ve spent a lot of time thinking about how much computing interfaces have changed in such a short period of time.
Just as we saw a paradigm shift from imperative to declarative interfaces, LLMs have opened the door to new kinds of interfaces.
Intent-driven interfaces are already everywhere - from AI assistants processing raw data, to Arazzo for defining how APIs map to human-scale workflows, to agents capable of handling complex tasks.
While the doomer view is “robots will take all our jobs”, my optimistic take is we finally have a human-centric way of interacting with machines and it’s going to supercharge our abilities
If the faster one creates naive, hard to discover bugs, is it really faster? I don't think we understand the long term consequences (or maintenance) of LLM generated code. So far the anecdotal results haven't been great.
I've become increasingly frustrated with having to work with other people's AI-"assisted" code. I can tell when I depart from reading sensible human-written code and enter the land of Copilot where all bets are off. Just yesterday I discovered that some environment variables someone had configured on a service weren't actually doing anything, because the service didn't support being configured via environment variables, let alone those particular ones. It's stuff like that which really gets me about all this: you can no longer assume a coherent theory of mind behind what you're reading. You can no longer trust that because something looks specific and intentional (like environment variable names), that it actually came from reality and not a confabulation. It's breaking the social contract that makes collaboration work.
I don’t support stupidly applied AI generated code either, but this isn’t a new thing at all, before it was code pasted from Stackoverflow and hammered at until it sort of worked.
Stack Overflow rarely surfaced a solution to your particular problem, but solutions to tangential or otherwise very similar problems. You still had to reason around the posters problem context and try to see if it really matched your own. You still had to have some understanding.
LLMs present a solution as if it is 100% in the context of your problem. You arrive at a solution without being forced to think at all if the solution applies to your problem.
Without being forced to, many will not. I teach programming and I can tell you it is so so obvious when students are just blasting shit from ChatGPT into their submissions without thought.
I built Lttrs.co to make it easy to publish content to the web. From personal websites, to that pesky terms of service you need hosted for launching your iOS app. All your content is one-way synced from Google Docs so there's a clear source-of-truth (No more copy-pasting!). After you share your folder and hit publish, Lttrs builds an optimized, statically generated site (with a perfect 100 Lighthouse score for performance).
It's still early and I'd love to hear what you think!
A possible explanation could be based on research suggesting that regular lack of deep sleep increases risk of Alzheimer’s. Given that Neurosurgeons have a grueling 7-8? year residency period after medical school, it would be possible that they undersleep far more than the control group.
I would like to see how the prevalence of Alzheimer's among Neurosurgeons compares against a population with similar work/sleep schedules (eg. finance)
From cursory googling it looks common for programs to expect you to work right up to the legal limit (80 hours/week based on 4-week averages) during residency. Having 16 hour days for ~7-8 years means that you probably have to get used to being a bit sleep deprived all the time.
What a great idea, to have sleep deprived surgeons. Really, the legal limit should be much less than that for safety reasons alone (patient safety, not surgeon safety).
Part of the problem apart from handover (which wouldn't typically affect surgeons), is the level of complexity. Much of the idea of the modern surgical training (and many other fields) is that the only way of learning well enough is to do, as much as possible. So we push surgeons to carry out as many surgeries as humanly possible.
Whether we have the balance right in terms of maximizing repetition vs. minimizing mistakes from tiredness is a good question, but it's not a given that reducing the number of hours worked for surgeons would improve patient survival without a great deal of care in how (e.g. ensuring you cut their number of hours without reducing their critical skillset).
Somewhere I read tired health workers are better than fresh workers who need to take over patients (losing context and details in the hand offs). Not sure if that explains it though.
Yes, I've read this several times: it's the handover that is most problematic.
However, IMO you can do things to mitigate this but it involves paying workers who aren't working at full capacity; basically doubling staffing costs I think. If you have a large shift handover period, a staff member doesn't take on a new patient unless they can finish their active input within the shift, it goes to the people sitting idle waiting on the next shift - people are never under a single worker for less than a half-shift; so you can't start with one nurse for half-an-hour at handover and then get passed on, you'd start with that nurse and get half-shift + ½hour. At the back end of the shift the nurse -- and other personnel -- would not be taking on new patients who couldn't be signed-off within their shift, meaning they have fewer patients, meaning they can focus more on handover of the patients for whom it's necessary.
There's probably holes in that, it's like reverse pipelining.
You might get enough effect by having a smaller overlap and having workers shadow the worker who is going off-shift but that's not really reducing handovers so much.
This looks a lot like OData - a REST-ful API standard with schema introspection, patterns for defining and traversing resource relationships, well-defined guidance around mechanics, tooling support. In particular, the "Microtypes" concept resembles how entities work in OData - rich query support for collections (eg. sorts, filters, order by), "expansions" on related resources, even inheritance semantics (ie. being able to request a derived entity as its parent type).
I think this is a bit cherrypicked. The example you're using is a fully qualified bound function. OData support for actions and functions explicitly exist to provide affordances for how to do RPC within OData. You can easily model this API in OData without requiring a function (eg. having a navigation property reference called "favoriteAirline"). Moreover, you can typically invoke functions without a fully qualified prefix (save cases where there is ambiguity).
For the most part, OData does a good job at letting folks opt into complexity, allowing integrators to make full use of APIs without needing to know anything about $metadata, inheritance mechanics, functions, etc.
I hear you. This was a fun project to adapt an existing standard (OData) to be compatible with GraphQL and get a sense of what that looks like over a really big API (hundreds of types, thousands of facets). Part of this is also to see whether as a developer, it makes integrating with Microsoft Graph easier or faster. I'd love to hear your thoughts.
I built this demo during Microsoft's internal hackathon, Oneweek, to show what GraphQL querying of the Microsoft Graph API could look like. While not all GraphQL functionality is currently implemented (namely support for pagination, data mutations), I think it's quite cool to be able to request resources from different services in a single request (eg. fetching my recent emails, OneDrive files, users in my org). The gist of how this works: the tooling translates an OData schema into a GraphQL schema and code generates resolvers for each field.
Yes, and in case there's confusion around Core vs. Standard. Standard can be thought of a spec, and supporting a version of .NET Standard implies support in a specific set of versions of .NET Core.
Just as we saw a paradigm shift from imperative to declarative interfaces, LLMs have opened the door to new kinds of interfaces.
Intent-driven interfaces are already everywhere - from AI assistants processing raw data, to Arazzo for defining how APIs map to human-scale workflows, to agents capable of handling complex tasks.
While the doomer view is “robots will take all our jobs”, my optimistic take is we finally have a human-centric way of interacting with machines and it’s going to supercharge our abilities