" Do we have any standard benchmarks for humanoids to do domestic tasks?" The answer is yes. Steve Wozniak proposed the Coffee Test. See https://www.youtube.com/watch?v=MowergwQR5Y
It's actually very clever. Despite the apparent simplicity, no current model could pass it.
Re your forecasts, I think they are optimistic in terms of timing but not ridiculously so.
I use Claude. It's really good, but you should try to use it as Boris suggests. The other thing I do is give it very careful and precisely worded specs for what you want it to do. I have the habit, born from long experience, of never assuming that junior programmers will know what you want the program to do unless you make it explicit. Claude is the same. LLM code generators are terrific, but they can't second guess unclear communication.
Using carefully written specs, I've found Claude will produce flawless code for quite complex problems. It's magic.
LLMs are parameter based representations of linguistic representations of the world. Relative to robot predictive control problems, they are low dimensional and static. They are batch trained using supervised learning and are not designed to manage real time shifts in the external world or the reward space. They work because they operate in abstract, rule governed spaces like language and mathematics. They are ill suited to predictive control tasks. They are the IBM 360s of AI. Even so, they are astonishing achievements.
LeCun is right to say that continuous self supervised (hierarchical) learning is the next frontier, and that means we need world models. I'm not sure that JEPA is the right tool to get us past that frontier, but at the moment there are not a lot of alternatives on the table.
I've spent a lot of my career doing various types of solution design. One of the insights I gained from thinking a lot about representation, intentionality and the philosophy of language is that the way you represent a problem has a big influence on how easy you will find it to solve the problem. I've found that helps with solution design. Don't just think about the problem. Think about what is the best way to represent the problem.
Majored in Philosophy. Started programming in 1973 on mainframes. Became a full time developer, systems analyst. 72 years old now, with 50 years experience in IT. Co-founded a couple of start ups, made a little bit of money. Went back to corporate life for a while. Ended up as a Program Architect at Salesforce. Resigned to start a company which develops and delivers commercial LLM/RAG solutions. Going reasonably well. Simple principles: keep learning, do what you want to do, not just what the man tells you. I saw a note from another Philosophy grad saying that Philosophy is actually useful in that it gives you a framework and a perspective to look at things a little differently. I agree with that.
I'm in the process of actually building LLM based apps at the moment, and Martin Fowler's comments are on the money. The fact is seemingly insignificant changes to prompts can yield dramatically different outcomes, and the odd new outcomes have all these unpredictable downstream impacts. After working with deterministic systems most of my career it requires a different mindset.
It's also a huge barrier to adoption by mainstream businesses, which are used to working to unambiguous business rules. If it's tricky for us developers it's even more frustrating to end users. Very often they end up just saying, f* it, this is too hard.
I also use LLM's to write code and for that they are a huge productivity boon. Just remember to test! But I'm noticing that use of LLM's in mainstream business applications lags the hype quite a bit. They are touted as panaceas, but like any IT technology they are tricky to implement. People always underestimate the effort necessary to get a real return, even with deterministic apps. With indeterministic apps it's an even bigger problem.
I knew a tech founder once who spent an hour lecturing us (his employees) on business ethics. He'd even written a little red book (like Mao) to codify his thoughts on how we should all behave.
Fast forward a few years and the guy flees the US after being charged with securities fraud. Spends the rest of his life living on his millions in a foreign country with no US extradition treaty.
Look, I love LLMs and even implement them for customers, but I am very sceptical about them 'replacing' ERP and CRP systems. What some AI folks don't seem to understand is that traditional ERP and CRP apps are completely driven by auditable business rules because they have to be. If you're running a company, there's no discretion at all about how money and other assets and liabilities are accounted for. It all has to be strictly according to the rules. This goes for most everything else - management are responsible for the business rules implemented in the system and they need to be precisely spelled out. Sure, AI can and should be used extensively for the human UI piece of it. To simplify getting data into and out of the system for example. But the engine inside and the database are all strictly rule governed and I definitely dont expect that to change anytime soon.
I'm surprised not to see anything about David Cope, who is the real master of AI produced music. Cope works mostly within the classical tradition, using AI to produce work in the style of great composers like Bach, Mozart etc. To my ear, it lacks the brilliance of the originals, but some of it is quite good. Certainly several orders of magnitude better than Suno's AI slop.
Gettier cases tell us something interesting about truth and knowledge. This is that a factual claim should depict the event that was the effective cause of the claim being made. Depiction is a picturing relationship: a correspondence between the words and a possible event (eg a cow in a field). Knowledge is when the depicted event was the effective cause of the belief. Since the paper mache cow was the cause of the belief, not a real cow, our intuitions tell us this is not normal knowledge. Therefore, true statements must have both a causal and depictional relationship with something in the world. Put another way, true statements implicitly describe a part of their own causal history.
I think you are asking the wrong question. Before you decide what to bring in house, you need to have an IT strategy That sets out what components of your desired solution should be built, and what should be bought. You need to have a view about which technologies you will use, and why. What is your end state IT architecture? Have you prioritised your objectives and requirements?
I understand your current systems are holding you back and there may be no appetite to get a bunch of expensive consultants in to answer all these questions. But just hiring a bunch of devs without a plan for what you want them to do is a recipe for disaster.
I know Orwell's work pretty well, and I read that sentence, and thought to myself: "Cant remember where he said anything like that, but what the hell, I haven't read everything Orwell ever wrote". So I just rolled with it.
The cognitive load to fact check everything is too great, so we decide which sources we think are reliable and just accept them. The solution is not to disbelieve everything you are told, but to accept that some of the facts you have not checked might be wrong, and be prepared to re-evaluate when contrary evidence appears.
As others have said, rewrite the CV. It's not clear to me who you are and what kind of role would best suit you. Put a summary at the top making clear what you are best at and what kind of role you are looking for. Summarize your skills and achievments. Consider using simple graphics. eg List of tech skills rated with slide bar from expert to familiar understanding.
LLMs make writing code easier, but they don't make it unnecessary. "No-code" is mostly small consumer apps and POCs, but "low-code" is a big industry based on platform building. Much of the work of building and maintaining an enterprise system is (a)data model definition (b) UI/UX construction and (c) workflows. Low code platforms specialise in doing this in a structured, fast and maintainable way without code. LLMs are great but they aren't a magic bullet. Enterprise grade development requires a lot of structure and LLMs don't provide that. Low code provides a pre built, well documented structure, enabling mediocre developers like me to build reliable, professional grade enterprise apps.
Lots of different types of tools here. Some are no code, most are low code. There is no clear dividing line between them: they are all configurable platforms with the ability to incorporate code through APIs and add ons.
Some are just special purpose utilities (eg Postman). Some are niche products with a relatively limited set of use cases(eg Airtable), some are enterprise grade platforms which can be used to build huge systems (eg Salesforce, MS Power platform), and there is every type of gradation between these.
This is a multi billion dollar business, growing steadily. It's going to accelerate even faster as LLM Technologies are increasingly tuned to build code extensions.
The NFL theorem means nothing if all the learning tasks have a common underlying structure. In the real world, they do. The laws of physics and chemistry create emergent causal relationships. Any SSL learning algorithm that learns to exploit causal relationships will consistently perform well over a variety of real world tasks.
Don't know how accessible or affordable therapy is where you live, but you certainly need someone to talk to.
I had a midlife crisis in my 40's. My career was going nowhere, I was trapped in a job I hated. I felt I was wasting my life.
What kept me going was the sense of obligation I had to others who depend on me. If you have nothing or no one to whom you owe service, then you can change that. Find a partner, or volunteer yourself for charitable work. By helping others, you also help yourself.
I made a point of enjoying the little things in life. Exercise. Walk in the sun. Go fishing. Grow tomatoes. Buy a friend a drink. Whatever, just sneak the little pleasures when you can.
I set some goals. Not boring goals like to make money, goals to achieve something meaningful, that engaged my interests and (modest) abilities.
Things got better. My 50's and 60's were some of the most rewarding years of my life. (I'm 69 now). I achieved some things I'd never thought I could achieve, just by pluggin' away.
Life is hard. John Stuart Mill wrote that most people have a limited capacity for happiness. I think that is true. But the strange thing is that by relieving yourself of the obligation to feel happy, sometimes it happens anyway.
Good point. The essence of processing is the transformation and combination of signs. Processing a sign is a kind of energy transformation. The process takes input signs, performs some kind of energy transformation, and produces a new sign, with different signification, which may be a better or more useful signifier for some purpose. Think NAND gates, or neurons. Example: if it looks like a duck and quacks like. duck, then it's probably a duck. A neuron summing 'looks like a duck' signal and 'quacks like a duck' signals is a more reliable signifier for ducks than either of the inputs. As for signs, see C S Peirce or Ruth Millikan for a clearer explanation. TLDR: Signs are relations between objects and processes (Sign, Signifier and Interpretant)
I'm 69, about to turn 70. I'm in a senior technical consulting role which often requires me to go on the tools. I work for a big, successful software firm that can afford to pay well. Most of my peers are 20+ years younger than me and quite smart, so I have to work hard to keep up. But I manage. Next year I will quit my job and 'retire'. In fact I'll be using my financial security to start up a SaaS. business. I have a bunch of ideas I've been wanting to work on. Working keeps me focused and connected. My rule is: stay interested, stay connected.
It's actually very clever. Despite the apparent simplicity, no current model could pass it.
Re your forecasts, I think they are optimistic in terms of timing but not ridiculously so.