Hacker Newsnew | past | comments | ask | show | jobs | submit | davnicwil's commentslogin

I think all it means when we say 'solve problems in real life' is just the stuff you have to do that tooling can't abstract you away from any more.

The sharp end of the debate now is around what exactly that means in the LLM world. It's extremely unclear what exactly the new level of abstraction unlocked is, or at least how general/leaky it is.

There's obviously just the stance of enjoying the craft, and that's one thing off to the side, but I think the major source of conflict for those who are more oriented towards living in the top level of abstraction (i.e. what you can do in real life) is between some of the claims being pushed about said level of abstraction and what many still experience in actual reality using these tools.


There's a lot of misconception about the intrinsic economic value of 'writing code' in these conversations.

In software, all the economic value is in the information encoded in the code. The instructions on precisely what to do to deliver said value. Typically, painstakingly discovered over months or years of iteration. Which is exactly why people pay for it when you've done it well, because they cannot and will not rediscover all that for themselves.

Writing code, per se, is ultimately nothing more than mapping that information. How well that's done is a separate question from whether the information is good in the first place, but the information being good is always the dominant and deciding factor in whether the software has value.

So obviously there is a lot of value in the mapping - that is writing the code - being done well and, all else being equal, faster. But putting that cart before the horse and saying that speeding this up (to the extent this is even true - a very deep and separate question) has some driving impact on the economics of software I think is really not the right way to look at it.

You don't get better information by being able to map the information more quickly. The quality of the information is entirely independent of the mapping, and if the information is the thing with the economic value, you see that the mapping being faster does not really change the equation much.

A clarifying example from a parallel universe might be the kind of amusing take about consultancy that's been seen a lot - that because generative AI can produce things like slides, consultancies will be disrupted. This is an amusingly naive take precisely because it's so clear that the slides in and of themselves have no value separate from the thing clients are actually paying for: the thinking behind the content in the slides. Having the ability to produce slides faster gets you nothing without the thinking. So it is in software too.


> You don't get better information by being able to map the information more quickly.

This ties quite neatly into the concept of "cognitive debt" that's doing the rounds at the moment: https://simonwillison.net/tags/cognitive-debt/

Cognitive debt accumulates when you move so fast on the implementation that your mental model of what the software does and how it works falls behind.


I very much appreciate this take. I will say though that I’ve had experience myself where using coding agents lead me to what I’d consider (in your terminology) a better mapping between information and code. Not because the agent was able to do things better than myself, but because, as my project grew and I got wiser on how to best map the information, it was incredibly fast for me to change the code in the right direction and do refactorings that I otherwise might not have gotten around to.

nicely said. I've been thinking a lot about how the bottleneck in the limit is getting your intent into the machine. Over time as AI improves it'll get better and better at extracting your intent just from situational context, but this only helps if you're willing to abdicate more and more judgement to the machine.

Eventually you may get to the point where the machine has all the context about the scenario and all the knowledge about how you think, and so will always perfectly be aligned with your intent, but when that day comes the thing will have far surpassed your decision-making capability and you won't be in the loop anymore anyway.


I don't think this is how it'll play out, and I'm generally a bit skeptical of the 'agent' paradigm per se.

There doesn't seem to be a reason why AIs should act as these distinct entities that manage each other or form teams or whatever.

It seems to me way more likely that everything will just be done internally in one monolithic model. The AIs just don't have the constraints that humans have in terms of time management, priority management, social order, all the rest of it that makes teams of individuals the only workable system.

AI simply scales with the compute resources made available, so it seems like you'd just size those resources appropriately for a problem, maybe even on demand, and have a singluar AI entity (if it's even meaningful to think of it as such, even that's kind of an anthropomorphisation) just do the thing. No real need for any organisational structure beyond that.

So I'd think maybe the opposite, seems like what agents really means is a way to use fundamentally narrow/limited AI inside our existing human organisations and workflows, directed by humans. Maybe AGI is when all that goes away because it's just obviously not necessary any more.


The most frustrating one for me is how in safari in the address bar the keyboard changes and drops '.' to the right of the spacebar in the exact spot I usually hit the spacebar with my thumb (because I'm just tapping the edge, not stretching to the middle of the screen).

This means in the modern mode of using the address bar as search, and not to type a domain manually (which is what I believe most people are also doing) I just end up with a search string separated by dots which Google can evidently deal with but is just very annoying.

I see threads on the internet going back years complaining about this issue and yet there's no configuration to change it. It would be such a simple and easy fix (like, just give me the regular keyboard, nothing special). It's a bit baffling since it seems such a glaring everyday UX problem.


well, it's basically existential, so the incentive is there to not only get it very right but also to limit the delta with how right anyone else gets it. The same can't really be said of the long tail of products Google have done.

Look to GCP as an example. It had to be done, with similar competitive dynamics, it was done very well.

Look to Android as another.


You must not know the stories of why GCP came to be.

It was an idea from the creators of Kubernetes and the execs at Google fought it the whole way


No, this is bunk. App Engine and GCE, the earliest components of GCP predate Kubernetes.

[I've been there for nearly all the relevant time]


I hadn't heard that, that's interesting. Any sources you'd recommend to hear more about it?

I think it's a slightly different point though. What I'm saying isn't about where the idea came from or whether it was part of some precient top down bet / strategy from the very beginning.

It's more where did the strategy evolve to (and why) and did they mess it up. GCP and Android are good examples of where it at a minimum became obvious over time that these were massively important if not existential projects and Google executed incredibly well.

My point is just that there's therefore good reason to expect the same of LLMs. After all the origin story of the strategy there has a similar twist. Famously Google had been significantly involved in early LLM/transformer research, not done much with the tech, faltered as they started to integrate it, course corrected, and as of now have ended up in a very strong position.


> well, it's basically existential, so the incentive is there to not only get it very right but also to limit the delta with how right anyone else gets it. The same can't really be said of the long tail of products Google have done.

I've yet to see anything that threatens Google's ad monopoly.


The threat to Google is that browsers themselves get displaced.


I mean I guess this is classic disruption theory.

It's not that a dominant position goes away overnight. In fact that would be precisely the impetus to spur the incumbent to pivot immediately and have a much better chance of winning in the new paradigm.

It's that it, with some probability, gets eaten away slowly and the incumbent therefore cannot let go of the old paradigm, eventually losing their dominance over some period of years.

So nobody really knows how LLMs will change the search paradigm and the ads business models downstream of that, we're seeing that worked out in real time right now, but it's definitely high enough probability that Google see it and (crucially) have the shareholder mandate to act on it.

That's the existential threat and they're navigating it pretty well so far. The strategy seems balanced, measured, and correct. As the situation evolves I think they have every chance of actually not being disrupted should it come to that.


I agree with your conclusion but I don't think it'd necessarily be unintelligible. I think you can describe a program unambiguously using everyday natural language, it'd just be tediously inefficient to interpret.

To make it sensible you'd end up standardising the way you say things: words, order, etc and probably add punctuation and formatting conventions to make it easier to read.

By then you're basically just at a verbose programming language, and the last step to an actual programming language is just dropping a few filler words here and there to make it more concise while preserving the meaning.


I think so too.

However I think there is a misunderstanding between being "deterministic" and "unambiguous". Even C is an ambiguous programming language" but it is "deterministic" in that it behaves in the same ambiguous/undefined way under the same conditions.

The same can be achieved with LLMs too. They are "more" ambiguous of course and if someone doesn't want that, then they have to resort to exactly what you just described. But that was not the point that I was making.


I'm not sure there's any conflict with what you're saying, which I guess is that language can describe instructions which are deterministic while still being ambiguous in certain ways.

My point is just a narrower version of that: where language is completely unambiguous, it is also deterministic where interepreted in some deterministic way. In that sense plain, intelligible english can be a sort of (very verbose) programming language if you just ensure it is unambiguous which is certainly possible.

It may be that this can still be the case if it's partly ambiguous but that doesn't conflict with the narrower case.

I think we're agreed on LLMs in that they introduce non-determinism in the interpretation of even completely unambiguous instructions. So it's all thrown out as the input is only relevant in some probabilistic sense.


Something I'm finding odd is this seemingly perpetually repeating claim that the latest thing that came out actually works, unlike the last thing that obviously didn't quite work.

Then next month, of course, latest thing becomes last thing, and suddenly it's again obvious that actually it didn't quite work.

It's like running on a treadmill towards a dangling carrot or something. It's simultaneously always here in front of our faces but also not here in actual hand, obviously.

The tools are good and improving. They work for certain things, some of the time, with various need for manual stewarding in the hands of people who really know what they're doing. This is real.

But it remains an absolutely epic leap from here to the idea that writing code per se is a skill nobody needs any more.

More broadly, I don't even really understand what that could possibly mean on a practical level, as code is just instructions for what the software should do. You can express instructions on a higher level, and tooling keeps making that more and more possible (AI and otherwise), but in the end what does it mean to abstract fully away from the instruction in the detail? It seems really clear that will never be able to result in getting software that does what you want in a precise way rather than some probabilistic approximation which must be continually corrected.

I think the real craft of software such that there is one is constructing systems of deterministic logic flows to make things happen in precisely the way we want them to. Whatever happens to tooling, or what exactly we call code or whatever, that won't change.


that's a good take

> getting software that does what you want

so then we become PMs?


I think the classic definition of the singularity though (per Kurzweil's book) is precisely when the curve actually doesn't look flat on human comprehensible timescales any more.

I.e. One day there are significant overnight changes. Then the very next day hourly changes, soon thereafter every minute, second, millisecond, etc.


I share your skepticism and think it's the classic pattern playing out, where people map practices of the previous paradigm to the new one and expect it to work.

Aspects of it will be similar but it trends to disruption as it becomes clear the new paradigm just works differently (for both better and worse) and practices need to be rethought accordingly.

I actually suspect the same is true of the entire 'agent' concept, in truth. It seems like a regression in mental model about what is really going on.

We started out with what I think is a more correct one which is simply 'feed tasks to the singular amorphous engine'.

I believe the thrust of agents is anthropomorphism: trying to map the way we think about AI doing tasks to existing structures we comprehend like 'manager' and 'team' and 'specialisation' etc.

Not that it's not effective in cases, but just probably not the right way to think about what is going on, and probably overall counterproductive. Just a limiting abstraction.

When I see for example large consultancies talking about things they are doing in terms of X thousands of agents, I really question what meaning that has in reality and if it's rather just a mechanism to make the idea fundamentally digestable and attractive to consulting service buyers. Billable hours to concrete entities etc.


On the other hand, LLMs are trained on enormous collections of human-authored documents, many that look like "how to" documents. Perhaps the current generation of LLMs are naturally wired for skill-like human language instructions.


I can see what you're getting at, but think about how humans are a general intelligence and we still ask them to perform specialized jobs. That said, they acquire knowledge in that position rather than being pre-loaded with everything they will ever know (outside of working memory).


yeah I think this is exactly how the analogy breaks down.

As humans we need to specialise. Even though we're generalists and have the a priori potential to learn and do all manner of things we have to pick just a few to focus on to be effective (the beautiful dilemma etc).

I think the basic reason being we're limited by learning time and, relatedly, execution bandwidth of how many things we can reasonably do in a given time period.

LLMs don't have these constraints in the same way. As you say they come preloaded with absolutely everything all at once. There's no or very little marginal time investment per se in learning anything. As for output bandwidth, it also scales horizontally with compute supplied.

So I just think the inherent limitations that make us organise human work around this individual unit working in teams and whatnot don't apply and are counterproductive to apply. There's a real cost to all that stuff that LLMs can just sidestep around, and that's part of the power of the new paradigm that shouldn't be left on the table.


I suppose the AI can wear many "hats" simultaneously, but it does have to be competent enough at at least one or two of them for that to be viable. I think one way to think about that is roles can be consolidated.


how did you go about organising this in terms of getting the word out? Did you just mention it a lot here, or via some other platforms too/instead?


We'd announce it on here and on twitter but we managed it on meetup.com so if you were a part of the HN London meetup group, you got emailed every time the next event got announced.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: