It is not logically inconsistent. The "Imperial Manager"ial class mentioned in the OP is multifaceted. That is to say, there are warring factions within the ruling class who disagree on details about certain things. (other things they are fully aligned on such as stamping down on the working class)
I thought of this when I saw that the final criteria in the list is Social Understanding. Might be a lot of humans who can't measure up to sentience by these parameters! ;-)
(and I wonder what my ADHD friends would think of the Executive Function requirement as well...)
Around 8 months or so of using ChatGPT/Codex, Claude, Grok & Gemini, I've found ChatGPT and Grok to be the best overall.
Claude often gets API and logic wrong and tries way too hard to "impress": When asked to generate Godot proof-of-concept scenes (or other stuff) it adds a lot of extra textures, colors, UI etc whereas Codex is more exact, does literally what asked, no more no less. Claude tends to flops in general non-coding questions too.
Gemini is the worst; it often refuses to search or interop with Google's own services like Flights etc. When I asked to do a reverse image search, it told me to go to TinEye
ChatGPT/Sora seems to be better at image generation than Gemini/Banana too.
Sometimes I ask them a quirky question or a random phrase and only Grok and ChatGPT seem to know what's up. Gemini would if it used Google's own search but nope.
As soon as LLMs are doing serious junior level 3D modeling and mechanical CAD design, that's going to lead to some wild iteration loops with rapid prototyping. Very exciting.
yes please. I want to destroy the business model of making me pay money for hardware (understandable because it is made of atoms) and then making me pay for software blocks / DLC to be able to use the hardware
Reminds me of the best saying I ever got from my CS professor. She would make us first write out our code and answer the question, "What will the output be?" before we were allowed to run it.
"If you don't know what you want your code to do, the computer sure as heck won't know either." I keep this with me today. Before I run my code for the first time or turn on my hardware for the first time, I ask myself, "What _exactly_ am I expecting to see here?" and if I can't answer that it makes me take a closer and more adversarial look at my own output before running it.
I'm not 100% convinced, while iterating fast on an early prototype, what's wrong with legitimately not knowing what e.g. the data structure will end up looking? Just let it run, check debugger/stdout/localhost page and adjust: "Oh, right, the entries are missing canonical IDs, but at the same time there are already all the comments in them, forgot they would be there – neat". What's wrong with that? Especially at uni, when working on low-stakes problems.
> what's wrong with legitimately not knowing what e.g. the data structure will end up looking?
But that's not what the above comment said.
> Just let it run, check debugger/stdout/localhost page and adjust: "Oh, right, the entries are missing canonical IDs, but at the same time there are already all the comments in them, forgot they would be there
So you did have an expectation that the entries should have some canonical IDs, and anticipated/desired a certain specific behavior of the system.
Which is basically the meaning of "what will the output be?" when simplified for programming novices at university.
The point of university isn't to get things done - it is to imprint knowledge into your brain. If you are approaching school with the attitude of "how do I get this over with as fast as possible," you are wasting your time and the time of the teacher.
This is a restatement of the old wisdom that to safely use a tool you must be 10% smarter than it is." Or stated differently, you must be "ahead" of the tool (capable of accurately modeling and predicting the outcome), not "behind" (only reacting). TDD is kind of an outgrowth of it. I've lived by the wisdom, but admit that for me there is a lot of fun in the act of verifying hypotheses in the course of development, even in the "test case gap" when you're writing the lines of code that don't make a difference in terms of making a long term test case go from red to green, or doing other exploratory work where the totality of behavior is not well charted. Those times are the best. "Moodily scowling at the computer screen again," has been a status update from chilluns on what I'm doing more times than I like to admit.
I agree with this. Writing a prompt isn't good enough on its own. Knowing what the desired output and result paired with understanding how an app should work is still very essenntial.
reply