If it was the easy part, then why did they pay us hundreds of thousands, sometimes millions, sometimes more - to do it? The fact of the matter is that it wasn't easy, not for a brain that's architected the way a human's is. The fact that computers can now do it much more quickly and arguably - in many cases - better doesn't diminish the act itself - it just shows how far AI has come, and how easily human intelligence will be dwarfed as it continues to make progress.
This has always seemed like a paradox to me. Once I got past the initial learning curve, coding seemed easy and fun. But most people can't or won't get past that learning curve, for reasons that I don't think we understand.
But if coding were hard, then writing small pieces of code would be as hard as writing big pieces. To make an analogy, playing the violin in tune doesn't get any easier, the shorter the piece that you have to play.
Developing software is hard. Some sort of "phase transition" occurs when a project gets big and complex, where coding is no longer what makes it hard. And writing software in a way that is not a net burden to a project or organization is hard, involving not just complexity but humanity. Most smart people in an organization have subtly arranged their affairs so that their career progress doesn't hinge on the success of a software project.
I admit that I only say these things as an observer, since I can code all day, but didn't pursue a software development career.
I also admit that I'm waiting for AI to handle the second two levels of software development. I'll concede that AI can develop software when The Mythical Man Month no longer reads like it was written yesterday.
> Some sort of "phase transition" occurs when a project gets big and complex, where coding is no longer what makes it hard.
It's in the name. Coding is taking an algorithm specified in some manner (pseudocode, diagrams, natural languages, thoughts,...) and transforming it into a sequence of instructions, statements, and expressions, that can be executed by a machine (either directly or through an automated process).
We have solved the coding difficulties on several front with things like programming languages (no need to type opcodes), syntax highlighting, linters, snippets, editors, IDEs,...
But someone still have to come up with the "Algorithm", and that's where it's hard. Usually because it's a combination of two sources: The business domain and the technical constraint. That's where people are failing.
But we did manage to create a lot of building blocks, like the standard algorithms and their data structures, libraries that provides an abstraction over a subdomain, frameworks that provides a scaffold to the thinking process,... But the developer still have to solve the system. And that system can get complex real quick if he's careless.
I do believe if you fail at the coding part, that's easy to fix with a few courses (or books) and some practice time. But the system thinking and the solving part is not easily taught. It's not even related to technology other than the latter being the domain it's exercised.
Part of it is learning, but it's just as much coming into the right mental models for it.
Programs are just virtual machines assembled from numerous smaller parts, not so different from a bicycle, car, or mechanized assembly line, but that's not at all how I thought of them when I was first getting into writing code. I'm not sure I even had a mental model at that point, or if I did it was too simplistic to build anything useful with. It was after my mind picked up the machine model when I started to become capable of writing code and eventually designing and build software from scratch.
You aren't paid to write lines of code, you are paid to build, ship and maintain products and services, usually in a complex corporate setting with ambiguous and ever-changing requirements. Code is a very small part of the overall picture.
Why do you think in most technical organizations the higest ranking and highest paid engineers generally write the least amount of code (often none)?
On one such engineer there's hundreds or thousands of others executing the idea into work so your premise about "Code is a very small part of the overall picture" is obviously very wrong. You wouldn't need to hire that many people if that was remotely true.
My experience is that the higher paid someone is generally the less they actually code. I'm sure some places have very difficult code but in my experience there's a reason that engineers fresh out of college mostly code and the highest paid engineers do things like design, planning, and coordination.
Folks have little appreciation for how soon we're all about to transition to something new.
I don't know what that entails, but something is going to happen.
I got into a discussion with some Rust compiler folks yesterday. I called Rust the "final human language we'll serialize our thoughts to": it's easy to write for LLMs, is super type safe, ergonomic, easy for humans to read and reason about, and has really nice deploy characteristics - single binary, no GC, bare metal, etc. If Python and Rust are equivalently easy to emit, you'll probably choose Rust if you're not bound to other choices.
People quipped back that this was absurd and that Rust is built for decades of future human use, that this kind of talk would put people off of Rust, and that they need to think of the future.
As if anything will be human in the coming decades.
> I called Rust the "final human language we'll serialize our thoughts to": it's easy to write for LLMs, is super type safe, ergonomic, easy for humans to read and reason about, and has really nice deploy characteristics - single binary, no GC, bare metal, etc.
I think it will go the other way - what use is a language with the poor ergonomics of Rust if humans aren't in the loop?
Maybe if you're willing to write insanity like this:
struct Zero;
struct Succ<N>(N);
trait Add<Rhs> {
type Output;
}
impl<M> Add<M> for Zero {
type Output = M;
}
impl<N, M> Add<M> for Succ<N>
where
N: Add<M>
{
type Output = Succ<<N as Add<M>>::Output>;
}
But even then it doesn't really work all that well for any practical use and you'll quickly hit a bunch of other roadblocks if you were to actually try to use it. You're pushing Rust to go well beyond what it is designed for. If we're being honest, in the real world you're going to write something like this instead:
fn add(a: u32, b: u32) -> u32 {
a + b
}
But then you give up the type safety. So it's not really a type safe language in any meaningful sense. Certainly not compared to languages that are designed to be actually type safe. If your only point of comparison is Javascript, then sure, Rust looks pretty super type safe in comparison to that, but in the grand scheme of things it's not type safe.
If it is just as easy to emit a language that is type safe, why Rust?
Try running a business that doesn't have the revenues to support high wages and you'll quickly figure out why you will pay as much as possible every single time: It means you can buy your way out of hiring the riffraff. Why do you think these high paying jobs were premised on weird trivia tests and other things that had absolutely nothing to do with the job? Hint: It was a social test to see if you'd fit in to the culture.
There have always been legions of people in India ready and able to write code for practically nothing. It was never hard or expensive. But they didn't fit in socially.
Because SWEs don't get paid for code. The code is just one byproduct of making business wants into business reality. We get paid to go figure out how to turn a management wishlist into a reliable money machine.
Most developers in the US are “enterprise” developers working in 2nd tier cities working in banks, government, airlines and unknown startups (including most YC companies) that will never make over $175K inflation adjusted their entire career. Hell the way enterprise developer comp has stagnated over the last decade, they may not see that in nominal terms.
Software engineering is more information processing engineering. Code is just the shovel with which we build the trench. Everything is about data, and we build the things that control and process the data based on various events according to some wants and needs.
LLMs are more like a trench digger with a cat's personality. It can helps in some cases, but are more likely to destroy a field. And good luck if you have some difficult terrain to pass through.
I really recommend you try LLMs again if you haven’t, the last part is really becoming less and less true every day. But I 100% agree that this does not pose a risk to the software developer for all the other points you mentioned. It will just make that trench digger more useful to the developer that needs it. And they’ll still need someone to drive the digger.
LLM is useful just like StackOverflow, Wikipedia, Web Search Engine, Manuals,… are. But automated (which is a pro) and with an hallucination problem (which is a core problem).
The others also may contain wrong information, but the risks are lower and not being automated means the risks are not compounded.
I personally believe we need more trustable source of information rather than automated way to transform it. Especially for the low hanging fruit of coding, which still require to presolve the problem and put us back at the real reason to have a developer.
And one thing that people seems to forget is the wealth of pre-LLM tools to speed up coding. No one uses notepad (from Windows 7) to write code, which is what they keep brandishing as the alternative to their agents and what not.
The hallucination problem has dropped exponentially in recent times in code generation. I can’t even recall a time any of the modern models I’ve used have done it in my recent usage. It’ll still do it in cheap/fast models and in places outside of code generation, but the good models write frankly incredible code, especially if you set them up with feedback loops.
What's odd about the current moment is that in the very same era in which it seems there is conclusive evidence (LLMs) that quantum explanations are not necessary to explain at the very least linguistic intelligence as advanced linguistic intelligence is possible in a purely classical computing domain, there is at the same time an insistence elsewhere that consciousness must be a quantum phenemonon. Frankly I am increasingly skeptical that this is the case. LLMs show that intelligence is at least mostly algorithmic, and the brain is far too warm and wet for quantum effects to dominate. Why should intelligence be purely classical but consciousness (another brain phenemenon) be quantum? It lacks parsimony.
> it seems there is conclusive evidence (LLMs) that quantum explanations are not necessary to explain at the very least linguistic intelligence as advanced linguistic intelligence is possible in a purely classical computing domain
Any reference explaining this? It isn't clear to me that LLMs have proven advanced linguistic intelligence
In just 2-3 years we've gone from primitive LLMs to LLMs reaching Graduate PhD-level knowledge and intelligence in multiple domains. LLMs can complete almost any code I write with high accuracy given sufficient context. I can have a naturalistic dialog with an LLM that goes on for hours in multiple languages. Frankly (and humblingly, and frighteningly) they have already surpassed my own knowledge and intelligence in many, probably most, domains. Obviously they aren't perfect and make a lot of errors - but so do most humans.
If LLMs are capable of writing code and code is what they are created with, what's keeping LLMs right now from entering into a loop where they are themselves creating new AI with more advanced concepts than we've ever known?
You are delusional. Each and every LLM (by design) is uncapable of having arbitrary long conversation as it has finite context window, and hallucinate left and right. But that is all irrelevant, as Penroses point is not about that.
In fact what Penrose saying is that LLMs are Searles Chinese rooms, as they lack qualia, and he offers quantum processes as basis for the qualia, however vagues it sounds.
So the point is not intelligence, not consciosness; cats arguably has less intelligence than LLM, but they clearly have emotions and are conscious.
Just for the sake of discussion, how do you know they lack qualia?
I don't want to say they have an internal experience, but the whole point of the question of consciousness and qualia is that we still don't know what causes them and how they are represented in the world.
The two main hypotheses seem to be that either, they are emergent phenomena which occur on top of the brain's neural and hormonal architecture (along with memories, outside experiences, etc) or that they are some sort of separate entity that exists independent of biology and even known physics and the brain is merely a "receiver" of some sort. (In earlier times, people were calling this entity a soul. My personal impression is that theories wanting to explain consciousness through Unexplainable Quantum Stuff are mostly continuing this very old worldview and dress it up in modern scientific terminology)
If consciousness was "just" an emergent result of certain neural interactions and memories - with no physical "secret sauce" needed - then there is no known fundamental reason (yet) why that same kind of emergence couldn't take place inside an LLM.
First of all, just for sake of discussion, it is not normal to try prove negative statements. In any case it is hard to make definitive arguments about phenomena observable internally, such as qualia.
Now, we can make reasonable claims that
1. we are conscious systems,
2. we are very complex physical systems, far exceeding complexity of LLMs.
3. LLM only very superficially resemble real human itelligence, not even close, hallucinate left and right, get easily off the track.
3. Higher animals, primate and espercially very low IQ people, anything that have neural networks resembling all show obvious signs of consciousness.
Emergent properties by the way do not cut, because if you squint enough you'll see that emergent properties do not exist without an intelligent observer, without intepretation. Say, emergent property of bird flocks; well the whole idea of bird flock is figment of human imagination, physical world does not have birds, let alone flocks. So consciousness can be "emergent" in typical sense of the word, it can be the result of working neural network, but it will be forever closed to analysis, as it is by definition outside of externally observable world.
Anyone who thinks LLMs have not come a long way in approximating human linguistic capabilities (and associated thinking) are in fact, engaging in (delusional) wishful thinking regarding human exceptionalism.
With respect to consciousness, you are doing nothing more than asserting a special domain inside the brain that, unlike the rest of the mechanisms of the brain, has special "magic" that creates qualia where classical mechanisms cannot. You are saying that there is possibly a different explanation for intelligence as consciousness, when it would be much simpler to say the same mechanisms explain both. Furthermore, you have no explanation for why this quantum "magic", even if it was there, would solve the hard problem of consciousness - you are just saying that it does. Why should quanta lend themselves anymore to the possibility of subjective experience/qualia than classical systems? Finally, a brain operates at 98.6° and we can't even create verifiable quantum computing effects at near absolute zero, the only place where theory and experiment both agree is the place quantum effects start to dominate. The burden of proof is on you and Penrose as what you are both saying is wildly at odds with both physics, experimental and theoretical, and recent advancements in computing. Penrose is a very smart guy but I fear on these questions he's gone pretty rogue scientifically.
It's the old fight between materialists and spiritualists. The majority is still undecided and maybe now is yet another pivotal moment in history when we must make a choice. Supporters of the mechanical consciousness idea will join the materialists, and those who favor the quantum interpretation will join the spiritualists.
"Doing them swiftly, efficiently, and -- most of all -- completely is one of the most critical skills you can develop as a team."
That all sounds great. However, I'd like to understand what teams are actually able to do this, because it seems like a complete fantasy. Nobody I've seen is doing migrations swiftly and efficiently. They are giant time-sucks for every company I've ever worked for and any company anyone I know has ever worked for.
The fact that it takes decades to master such a mundane task may mean the entire approach is wrong. The article hand-waves a lot of the complexity of "automating as much as possible."
In my opinion, the solution lies in append-only software as dependencies. Append-only means you never break an existing contract in a new version. If you need to do a traditional "breaking change" you instead add a new API, but ship all old APIs with the software. In other words - enable teams to upgrade to the latest of anything without risking breaking anything and then updating their API contracts as necessary. This creates the least friction. Of course, it's a long way for every dependency and every transitive dependency to adopt such a model.
I thought Observability in this context means the ability to introspectively make sense of why the LLM output what it did, which is a difficult problem because the model parameters are effectively an unintelligible morass of numbers. Does this help with that and if so how?
Pretty sure this just structures logs for requests to common 3rd party LLM providers. Which I guess is useful, but it's not some kind of problem unique to LLMs.
Correct- the summary is misleading marketing. This is just normal system / service observability. What people mean by observability in the LLM context is specific.
I wouldn't call it misleading marketing - it is what it is, similar to what you can get today from tools like Langsmith, etc - Observability for the LLM part of your system, but using your existing tools. You can further extend that to monitor specific LLM outputs - but that's just another layer on top of that.
Not talking about just monitoring outputs though. I'm talking about monitoring the internals of the model as it reaches its output. The entire issue around interpretability / observability inside the LLM's model is the hard problem, one for which considerable resources are being dedicated to solve - not simply hooking the public-facing APIs up to observability tools like any other service API. This is just conventional telemetry. Calling this LLM observability implies there is something special about it and unique to LLMs in particular that enhances introspection into the AI model itself, which is not true. The title is highly misleading, classic startup-bro fake-it-til-you-make-it hustling crap, and deserves to be called out.
I guess I'm not sure that there's a practical difference between "It's marketing" and "This is what the market rate is for a CEO." In other words, firms need to pay this much because that's what other firms are paying (at least.) That's not marketing - that's just the unfettered market at work. Which is why it needs to be fettered. I agree with the salary cap idea, because the market will naturally keep raising the price without bound unless there's something to counteract that, and it is terrible for the labor market as a whole (and even the company as a whole) to be paying so much for a CEO when the same amount could buy dozens or even hundreds of workers.
A salary cap doesn’t change the market rate! It just obfuscates it.
Salaries for public companies locked at 10M/yr? Ok, now firms have to compete on amenities. (Your current firm gives you a free car? Ours gives a jet, a personal Michelin star cook, and complimentary beverages)
You'd think so, right? Look up why corporations started providing insurance to their employees. Look into why your compensation is not just a salary, but salary, bonuses, stock (options or RSU's), etc.
AFAIK health insurance is special-cased by law. I had to pay (a trivial amount of) tax on imputed income from IBM's life insurance. The IRS is wise to a lot of perks like company cars.
How about no salary cap but a maximum difference factor between the highest paid and the lowest paid in any company?
Not sure what the figure should be (x10?, x20?, x50?, x100?). That way companies that want to pay higher saleries to their CEO would have to increase everyone's salary.
But there would need to be a way of stopping companies just using shells and subcontracting all the real work to low pay subsidiaries.
An escape from something like this is why companies no longer employ their own janitors, but rather contract that out.
The IRS rules went in that said that with the exception of your executives (that is a whole other conversation), everyone has to have the same plan for insurance and pensions. Since they did not want to give out that much money for janitors, they got kicked out of the companies.
Not buying it. Tesla has a huge share of a growing pie. They will continue to grow as the EV market grows. While I agree that the past few months were not good, the long-term outlook for EVs is positive and therefore Tesla's outlook is positive.
Just because we have all decided we hate Elon Musk doesn't mean everything he has done is bad and destined to fail.
Being first doesn't necessarily make a good outcome. Leadership is the most important to keep it going. Many incredible companies/products have failed as soon as leadership has failed. Musk is more and more worrying investors and customers. It doesn't mean it's going to fail, but it leaves more and more space to.
It’s not destined to fail. But Elon’s jumping the shark has absolutely harmed Tesla sales.
Personal anecdote: I got into the Tesla ecosystem with a model 3. All it took was one test drive and I was sold.
I went on to buy solar and powerwalls, because their prices were literally a fraction of every one of the six local solar companies I got quotes from. Heck, solar plus 3 powerwalls cost the same as just solar from the local clowns.
To your point that not everything they do is destined to fail: I’m still considering getting a couple more powerwalls because with tax incentives and utility rebates they’re a staggeringly good deal. And no one can see the Tesla logos in my basement.
But not only have musk’s idiot antics welded my wallet shut when it comes to not buying another Tesla car, I’ve got a set of emblems from a Mazda 3 to replace the Tesla badges on the one I’ve already got so I can stop feeling embarrassed to be implicitly advertising for them everywhere I drive. The alternative to the badges was a bumper sticker I once saw which said something like “I bought this before Elon jumped the shark”.
I’m bringing personal experience based on having spent $100k with his company– befor le he outed himself as a racist doofus.
You’re bringing quippy contradiction and downvotes. Are you just a fanboy, or do you work for his reputation protection service?
You’re also wrong. You don’t get to tell me what is or isn’t embarrassing for me. That’s for me to decide. Swapping on different badges is, in my world, funny; having a logo associated with an overtly racist man-child on my car is, in fact, embarrassing.
> Are you just a fanboy, or do you work for his reputation protection service?
Neither, I think the Tesla is a well functioning and decently engineered product. It does hurts that Elon is such a big ego and I don't agree with his rants on X.com, He is a extra juicy target for any kind of news or tabloid outlet. I don't attach my identity too strongly with Tesla's or Elon's brand so I just drive the thing around and appreciate it as a good tool that functions for me.
> You’re also wrong. You don’t get to tell me what is or isn’t embarrassing for me.
Fair enough, It's your car, maybe not for me, but absolutely fine for you to enjoy, mod, and change it up however you like.
I find it weird when someone brands one product with the logo of a competing product. I see this when people debadge and rebadge their Honda Civics with Lexus, Audi, and Mercedes logos. I know this is an expression of appreciation for the luxury brand they like but I feel confused by the action none the less. Why not just sell your car and buy a Mazda, is my natural next line of thinking. It's just my opinion, I shouldn't be prescriptive on how others should use their cars they own. You do you and if that makes you happy and hurts no one then thats fine with me,
Oh give me a break. That’s so condescending to African Americans. If African Americans bought a certain kind of shoe, it’s because they liked the shoes. It’s fun to try shoes. People make their own choices.
To be sure, this kind of research, whether ‘craft’ or ‘natural’ is the correct word, is simply too risky to continue. The juice is not worth the squeeze.
Literally just flew on a United Airlines 737 MAX 9 one week ago. It seems like the craft I flew on has probably been grounded in the week since. I noticed that we were flying on a MAX before boarding and nearly asked to switch flights, but consoled myself that I was being irrational and that the planes were almost certainly fine now. Guess my confidence was misplaced.
FWIW, it's only the Max 9s which have this issue. The Max 7s and 8s don't have an exit in that location (too few seats) and the Max 10s require an exit door to be installed in that location, not the door plug.
It's only the Max 9s that have the option of the door plug, if the installed seat count is below the threshold where an additional exit is required.
Yes, this seems like a top to bottom culture rot problem at Boeing sacrificing quality control in exchange for reduced costs.
A few years ago, I had read that certain airlines demanded planes manufacturered in Washington rather than South Carolina, and I wonder if that information actually ends up being a useful signal for better quality planes.
> A few years ago, I had read that certain airlines demanded planes manufacturered in Washington rather than South Carolina, and I wonder if that information actually ends up being a useful signal for better quality planes.
The one with the blown door plug supposedly came off the Renton assembly line. No one is safe.
Correct, but I've seen a lot of confusion that its a systemic problem (ala MCAS) with the Max family. It doesn't look that way. It looks like a manufacturing problem on one particular variant.
The 8 had the great MCAS crashes (boeing solution ? tell the pilot to turn it off when it happens !), the 7 has anti icing that burnout the engine nacelle and make it fall (boeing solution ? being exempted from the certification requirement of your engines not falling off and we will fix it in a few years !), the 9 has doors that fall off (boeing doesn't even have a solution on that one, but they know others bolts are at risk too since they warned to check the rudder bolts on jan 5), ... At this point it's a systemic problem with the MAX overall. The only one without issue is the 10 and it's because it's not out yet, but Boeing want a fast track on certification for it because obviously they're doing so good with these there is no need to fully check it.
And frankly this time we're talking about the worst of the worst, the basic first step of making airplanes : being able to ensure parts of it doesn't fall off for no reason. This is not a design issue, not a cost cutting "they didn't put enough sensors" reason, this is straight up "their manufacturing is bad and their QA is not able to catch it", ... These things have barely started flying and 5 of those are already affected (well, 6 ...), this is absurd.
Sure MBA taking over tends to kill engineering companies ability to make great product, but even Hewlett Packard is still able to make printers that print (they suck, but that's by choice from them)...
I've seen a lot of confusion that its a systemic problem
United found loose fasteners in a different locations on each of the five aircraft they found loose fasteners on. This is right on the heels of another emergency AD for the MAX about loose fasteners in a completely different location. That definitely hints at a systemic problem.
If you expand the scope a bit, Boeing's had nasty assembly and manufacturing problems across its whole model lineup. I highly doubt this is a one off problem.
Just had all my connections cancelled. So extra day in San Fran for me which is less than ideal, but probably better than being on the flight if something happens.
It was total bedlam at the airport when I got in this morning however. With almost no flights available to replace the grounded ones.
Another red eye special for me tonight but at least no connections.
The safety margins on flying machines is really high, so while Boeing really should figure out what the hell is going on, the plane didn't fall out of the sky after a depressurization incident. It failed to a known state (ideally by design!)
That it didn’t fall out the sky is largely due to the door blowing off at a lower altitude by some fluke or miracle. Had this happened at cruising altitude we’d be telling a different story.
I actually don’t want the developer experience of co-location. There are millions of things that are totally irrelevant happening in my company’s (thousands of engineers) monolith. The noise in the commit log is considerable. Isolated repos are smaller, and reduce useless coupling.
I get that it's not a universally applicable solution. I guess at a certain point of scale your organisation would grow out of complete co-location.
But I don't think we have to go with the 100% co-location approach as well. A large monorepo could be organized into domain specific mini-monorepos with co-location benefits.
I think Google, Meta, Microsoft, Twitter, Uber [1] and the thousands of engineers that these companies (and many other companies) employ, would disagree with you.
