davnicwil

yeah, 5g doesn't work on trains very well once just a little bit out of zone 2/3. Actually to be honest any connectivity at all is patchy.

To be fair, one interpretation is spending innovation tokens wisely. Just piggy back off an already understood concept/brand, don't try to be too clever on the parts where innovating won't matter that much.

There's a bit of an issue with the overload of 'office' in the political context, this being an EU initiative and domain but other than that I say good call.

You're right, but this is always true in recruitment. Anything that gives you an edge won't last long as it will be copied if it works well.

just thinking about this, if you had the latitude to explain it more or less exactly as you have here, in human language, and frame it as a screen stage of the application and not an interview, and add: 'hey, I know this is really far from ideal but if you're legitimately interested this probably works in your favour', good people might not mind it.

I think most of the issue with this kind of thing, practical stuff aside like extra time invested and potential unpleasantness of actual experience, is what it implies about the culture and your relationship. If you level with people a lot of that gets addressed, and you're left with 'only' the practical inconvenience.

I agree with most of what you're saying in this reply but I also think we're now talking about a different thing, like how well does any of it prepare you for real world jobs.

That's separate from the question of being taught, self teaching, and the combo of the two, I think. That's more to do with just the material itself and the goals you're set.

I do think though, all else being equal, in a business you're going to want to prefer people who have demonstrated the kind of higher order skill and agency to be able to adapt and self teach.

I get that in a lot of businesses the difference might not be material, stuff turnover is high, focus is practical and short term and not about how this or that graduate will develop within the business over a long period of time and so on.

But still, of two people with the requisite hard skills to get going quickly you're probably always going to favour the one who seems better able to also adapt to changes and learn new skills in a totally self directed way, right?

Particularly in today's environment - I can hardly imagine a point in history where this has broadly been more important.

I mean, yes, except for the framing of paying for the piece of paper.

The piece of paper is just the evidence that you've been through a journey successfully. What you're really paying for is access to the environment that facilitates that journey.

The journey is essentially transitioning from a system which is pricipally about executing diligently on well-defined instructions, to one which is about reaching more broadly defined and often even self-selected goals by whatever means you choose.

Obviously aspects overlap, the changes come in steadily over the years of a degree, and even in the most ideal case it's still basically just practice, but the journey is supposed to develop the higher order skills that at that age you are ready to develop, and must develop to succeed 'in the wild' so to speak.

Absolutely 100% one of those higher order skills, indeed maybe the most important, is being able to self-teach whatever necessary to fill in gaps in order to do something interesting, that won't be provided for you or made easy for you in any way. You have to figure it out on your own. Just as you will have to in more or less every single challenge you encounter in the world after university.

So again, the environment in which you develop those skills (along with so many other benefits) is what you're paying for and the piece of paper, such that it is, is just the evidence you succeeded in that.

To push back on this, I actually don't think the real role of a university is to teach, per se.

The real role they play is something very different to everything that comes before in education, and a bit closer to everything in the world that will ideally come after: immersion in your field of choice in an environment full of curious peers who are variously a few steps ahead of you, all the way up to world class experts in the field doing research.

Parts of your interactions there may include being actively taught relevant things, but the more important goal is to let you explore this environment and the material (yes, with a bit of structure) and in doing so figure out how to learn on your own.

You absolutely should be able to get a degree with top marks without attending a single lecture, seminar, lab, whatever, just by reading the material and interacting with those around you less formally, and never being actively 'taught' anything.

Many in fact do something approaching this, particularly in the later years of a degree.

not to tangent off from your point too much but I think in reality one might in fact pay more for a logoless macbook just because it would in itself be a pretty unique and cool artefact, and a good story as to how you acquired it!

If you think about it there shouldn't really be a reason to care as long as things don't get worse.

Presumably this is where it'll evolve to with the product just being the brand with a pricing tier and you always get {latest} within that, whatever that means (you don't have to care). They could even shuffle models around internally using some sort of auto-like mode for simpler questions. Again why should I care as long as average output is not subjectively worse.

Just as I don't want to select resources for my SaaS software to use or have that explictly linked to pricing, I don't want to care what my OpenAI model or Anthropic model is today, I just want to pay and for it to hopefully keep getting better but at a minimum not get worse.

very nice

I'd be totally happy with both modes being completely independent. Cloud-synced files could take care of shared state for a lot of usecases. I mainly just want this for the portability aspect with the phone.

There are some practical issues with having to make sure you have the screen and keyboard access (in practice the all-in-one of a laptop is pretty handy - though I guess you could still have this form factor in a much lighter shell minus the compute) but for a lot of cases like home <-> office this would be the dream, just carry your computer in your pocket.

Is there any world where them running MacOS on an A chip ultimately translates to just connecting an iPhone to a monitor, keyboard and mouse (all apple-branded, naturally :-) and running it in 'MacOS mode'?

Obviously just so many reasons why this won't happen. Or would happen on iPad first. But dare we dream?

While I agree that the slowdown is very noticeable once the MBA gets hot to the touch, I joke that it's a feature, encouraging you to take a cooldown break every once in a while :-)

More seriously though I agree it depends on workload. If you've got a dev flow that hits the resources in spikes (like initial builds that then flatten off to incremental) it works pretty well with said occasional breaks but if your setup is just continuously hammering resources it would be less than ideal.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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.

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?

Yes, but where reliability is concerned, a continuum is a problem. You can't say with any certainty where any given thing is on the continuum, or even define its bounds.

This is exactly what makes estimates categorically unreliable. The ones that aren't accurate will surprise you and mess things up.

In that sense, it does compress to being binary. To have a whole organisation work on the premise that estimates are reliable, they all have to be, at least within some pretty tight error bound (a small number of inaccuracies can be absorbed, but at some point the premise becomes de facto negated by inaccuracies).

With respect, I think this approach is actually harmful to everyone in the org because you're trying to twist reality to fit a premise that is just impossible to make true: that estimates of how long it takes to build software are reliable.

The reluctance to accept the reality that it cannot be made true achieves nothing positive for anybody. Rather it results in energy being lost to heat that could otherwise be used for productive work.

This isn't about respect between functions, this isn't about what ought to be professionally acceptable in the hypothetical. It's about accepting and working downstream of a situation based in objective truth.

Believe me, I wish it were true that software estimates could be made reliable. Everyone does. It would make everything involved in making and selling software easier. But, unfortunately, it's not easy. That's why so few organisations succeed at it.

I don't present easy answers to the tensions that arise from working downstream of this reality. Yes, it's easier to make deals contingent on firm delivery dates when selling. Yes, it's easier to plan marketing to concrete launch dates. Yes, it's easier to plan ahead when you have reliable timeframes for how long things take.

But, again unfortunately that is simply not the reality we live in. It is not easy. Flexibility, forward planning and working to where the puck is going to be, and accepting redundancy, lost work, or whatever if it never arrives there is part of it.

That I think is what people in different functions are best served rallying and collaborating around. One team, who build, market and sell software with the understanding that reliable estimates are not possible. There simply is no other way.

I really appreciate the compliment, thank you! I don't.