AI Engineer Melbourne 2026 Keynote Livestream | Day 2

SPEAKER_02

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

SPEAKER_02

Thank you.

Thank you.

Thank you.

SPEAKER_02

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

SPEAKER_05

Good morning. And welcome back. Thank you.

SPEAKER_05

Thank you.

SPEAKER_05

Thank you.

SPEAKER_05

Thank you. Jeremy Howard. Thank you.

SPEAKER_00

Thank you. Thank you.

SPEAKER_00

Thank you.

SPEAKER_00

Thank you. Thank you.

SPEAKER_00

Thank you. Thank you.

SPEAKER_00

Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.

SPEAKER_00

Thank you. Thank you.

SPEAKER_00

Thank you. Thank you.

SPEAKER_00

Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.

SPEAKER_00

Thank you. Thank you.

SPEAKER_00

Thank you.

SPEAKER_00

Thank you.

SPEAKER_00

Thank you.

SPEAKER_00

Thank you. Thank you.

SPEAKER_00

Thank you.

People who have previously been extremely positive about agents and using AI encoding and so forth. I think Armin was one of the particularly interesting ones. You might know him as the guy who created Flask, been a very important software developer. And of course also George Hotz who created the Comma self-driving AI system and the original iPhone hacker and so forth. I've got some quotes from Armin here though that I thought was interesting. He said for months he was in this situation where the dopamine hit from working with these agents is so very real. Saying you feel productive, you feel like everything's amazing. And you go deeper and deeper in this belief that it all makes perfect sense. But it's decoupled from any external validation. And so we're starting to see these concerns. I saw this two days ago from a guy who's been working on this new GPU functional programming system. Who was saying how cool it was that he went from 0 to 95% in his most recent project in five hours. And then realized, oh, 15 hours later I'm still not there. And I keep finding problems. And I actually don't know if there's still problems. And so actually at this point I don't even know where I stand. But getting the first 95% done in five hours sure felt good. But did I actually achieve anything by using AI other than that dopamine anticipation. So I think it's very encouraging that thoughtful people in our community are reflecting and sharing their reflections. In fact, one of our own community members put this on our Discord the other day. And was asking for feedback from our community. Talking about the product he works on. It's genuinely interesting. The problem requires deep domain expertise. But it's hard for us to verify because we've got 200,000 lines of vibe coded software at this point. And he's actually realized the pace we've moved at has slowed down. As models get better and token speed spend increases. Because we generate more and more code with less and less careful engineering. Debugging failures, he told us, is super painful. And interestingly, again, this dark flow idea. Most of his colleagues feel they're making great progress. But then when they have quarterly meetings with management they get a reality check. When they have to show what have you shipped. What's the accuracy. How many clients have you signed. And they suddenly realized the routes actually weren't good. So I'm not going to go too deep into negativity. We've all seen it. It's in mainstream newspaper articles nowadays. Wall Street Journal. I think just today, Uber is now saying they're putting a strict budget on token use. Because they're not seeing the ROI. And so rather than dive into some kind of AI negativity. I instead actually want to point out something that is. You can go into totally different directions with AI. And I'm looking at two of those key motivation platforms of autonomy and mastery. And it's certainly true that AI can decay those things. So I'm sure anybody who's done a lot of agentic work and vibe coding has been in that situation. Where we have what psychologists call an illusion of control. The agents asking you, hey, do you want to go with a distributed system here. Or would you rather use green threads. Use a polling loop or whatever. And you're, I don't know what any of that means. A or B. A. So this is something that actually decays your autonomy. On the other hand, AI can be used to support your growth. It can be teaching you things. It can be trying things. It isn't necessarily creating more outputs more quickly. But it's definitely something that can happen. So ditto with mastery. Mastery is not in SDT. It's not about creating more outputs. Creating more products. It's about creating this genuine ability to craft something. It's effortful. And involves learning from that effortful work. So with AI you can tackle more complex tasks. And you can focus on learning those underlying foundational principles. And master your craft. Or not. You could focus on outsourcing more and more to AI. More and more quickly. With less and less effortful practice. Getting less and less learning.

SPEAKER_00

It's not about creating more outputs. Creating more products. It's about creating this genuine ability to craft something. It's effortful. And involves learning from that effortful work. So with AI you can tackle more complex tasks. And you can focus on learning those underlying foundational principles. And master your craft. Or not. Right.

SPEAKER_00

You could focus on outsourcing more and more to AI. More and more quickly. With less and less effortful practice. Getting less and less learning.

SPEAKER_00

So AI is neither good nor bad for you. For your psyche. But warning. The people getting you to use AI. Don't care about your autonomy and mastery. They care about your outputs. And so they're going to put you in the decay world. All the time. The people who are selling you. The AI models. Platforms. Harnesses. And your bosses at work. Who need to be able to show their quarterly token maxing metrics. So you need to look after yourself. In this world. So I want to show what it looks like to have amazing mastery over a computer.

SPEAKER_00

And how that's changed over a period of time. So this is Ivan Sutherland. He did this at 2X. Back in 1963. And he's shown how he's able to create a direct interface between himself and a computer. Where he's drawing with a light pen. With one other hand. He's pressing buttons. To set constraints. As he's drawing. And he's using it directly against one of these. I think this is one of these fancy vector monitors. And he's showing the interviewer here how he can create an arc. For example.

SPEAKER_00

So this is Ivan Sutherland. He did this at 2X back in 1963. And he's shown how he's able to create a direct interface between himself and a computer where he's drawing with a light pen with one other hand. He's pressing buttons to set constraints as he's drawing. And he's using it directly against one of these. I think this is one of these fancy vector monitors. And he's showing the interviewer here how he can create an arc, for example, using these constraints by drawing directly on the screen. And you can adjust it. This is an extraordinary level of deep connection between the human and the computer.

SPEAKER_00

You might have seen this: the Mother of All Demos. This was 1968 that this happened. Very similar idea. So in the Mother of All Demos, Douglas Engelbart introduced for the first time the mouse, hypertext, real-time collaborative editing, video conferencing, word processing, screen windowing, and dynamic file linking. This quote was in 1962 towards the start of this project, and the demo was in 1968. And his goal was the same: augmenting the human intellect so that the entity to be produced will exhibit more of what could be called intelligence than an unaided human could. We've amplified the intelligence of the human by organizing his intellectual capabilities to higher levels of synergistic structuring.

SPEAKER_00

So you see, it's very similar between what Sutherland was doing and what Engelbart was doing. This was their mission: to amplify and augment human intelligence.

SPEAKER_00

One of the most underappreciated, most extraordinary people in the history of computer science is Kenneth Iverson. Not that underappreciated. He got the Turing Award. He designed APL. APL is a notation. It was a new notation for representing computation and mathematical thinking. This is from his Turing Award presentation paper. And if you don't know APL, it won't look very familiar. But what he's showing here is he's proving some characteristics of the inner product in his new notation. And one of the really interesting things about this: if you ever get into APL, and I strongly recommend it, is it turns out that this generalizes in a much deeper way than normal mathematical nomenclature. And the inner product in APL is an operator that can combine any two functions. It's not necessarily multiplication and addition. And so suddenly he's proved a whole class of features about a whole class of functions, many of which have never been looked at by a mathematician before, just through notation. And this can go a really long way.

SPEAKER_00

Some of you might have seen this very famous single line of code in APL, which is a complete implementation of Conway's Game of Life. So here in this video, that life function is being applied over these two characters, and off it goes. Again, it's the same thing, right? Iverson was passionate about creating this connection between the human and supporting the human's thinking: notation as a tool of thought.

SPEAKER_00

Perhaps most mind-blowingly, Brett Victor, who spent a couple of years, as he described, being a hermit living on a train, came out the end of those two years of hermithood having built the most extraordinary and inspiring array of real-world demos showing how to understand climate, how to understand electricity, how to build games, how to build graphics, how to understand wave forms. And he shared this all with the world. This is his coding environment where he changes it graphically. This is his amazing game-playing demo where he actually created a time machine for his code. If you haven't seen this, please watch everything Brett Victor's done. It's incredibly inspiring. And all of it, you'll see it's all the same thing. It's creating this connection between the human and the computer that they're working with so that they can craft. This is all effortful craft that he is supporting.

SPEAKER_00

Chris Latner. This is his Playground system. He's created a whole amazing hierarchy from LLVM, Clang, Swift, Playground, MLIR, Mojo. At every level trying to improve this ability for humans to connect to and work with their computers.

SPEAKER_00

My argument is that we're still on this chain. We can continue working along this history from the Mother of Demos in a really deep and powerful way. AI is a marvellous way to connect more deeply with our computers and achieve this fullest representation of humanity. So this has actually been my mission for the last 30 years and very dramatically for the last 10. And at Answer.ai, it's all of my focus: this idea that we should be seeking to augment human creativity, not replace it. It's interesting to see, hopefully this resonates with you, but also hopefully you see this is almost never what you actually see being marketed when somebody's trying to sell you a piece of AI. It's going to summarise this for you, it's going to write this for you, it's going to do this for you. It's all about being done for you.

SPEAKER_00

Thank you.

SPEAKER_00

So one was I wanted to learn about recursive language models. Probably a lot of you know about recursive language models. They've been taking over the world. So we've got this system called Solve-It. And I should show you Solve-It.com. And I loaded the paper, recursive language models paper, into Solve-It. And you could just read it in the normal way, piece at a time. But make sure you understand it. And so here, I looked at figure one. I was like, well, I don't know what this is, or this is, or this is. And so normally I might just skip over it. But here I can just say, hey, what's this figure? And it tells me, okay, these are the three evals that the RLM authors are doing here. And interestingly, it's going from a constant to a linear to a quadratic complexity, which is not actually captured in the original paper. So that's really helpful information.

SPEAKER_00

Now, I don't work very well at an abstract level. I need things to be concrete. So I could ask for an example of each task. And this is much easier than going into the papers and trying to dig them out. And so here I'm getting little examples. Okay, I get it. So I always tell people, don't move on when you're learning a new thing or working on something until you get it. So I was, okay, I get it. So then there's another figure where they describe it. I didn't fully understand this figure, to be honest, at first. And so it tells me what the key pieces are. It's very handy.

SPEAKER_00

Now, I don't work very well at an abstract level. I need things to be concrete. So I could ask for an example of each task. And this is much easier than going into the papers and trying to dig them out. And so here I'm getting little examples. It's, okay, I get it. So I always tell people, don't move on when you're learning a new thing or working on something until you get it. So I was, okay, I get it. So then there's another figure where they describe it. I didn't fully understand this figure, to be honest, at first. And so it tells me what the key pieces are. It's very handy.

SPEAKER_00

So when I'm reading this, I'm thinking, okay, I want to push beyond this. I want to understand it but try and go a bit past it. So I'm thinking, okay, I wonder if we can replicate all of the features of an RLM right now. So I had a hypothesis about how to do that. And I checked with the AI, I think we can try this ourselves. And it clarified some key points about where subagents fit. And as it turns out, Solve-It has a subagent. So I said, yeah, you've got a subagent. Why don't you try it? So in this case, it spawns an agent and tells it to use Python to solve the complex square root. And we can also write code here, right? So I can then try it myself and I can compare. I'm thinking, oh, cool. Okay, so I've confirmed.

SPEAKER_00

I'm in an environment where I can actually do the same things that the RLM paper did. So another thing I mentioned as I read papers is often it's very easy to skip over citations, right? But here it says, well, here's recent work. Well, okay, I don't know any of these, so I shouldn't keep moving. So I said, stop. Can you please go and read all those papers for me and tell me what they are and why they're here? I can decide whether to click on those links and read them more myself. And I want to test my understanding at this point. So anyway, to skip ahead a little bit, I'm thinking, okay, let's try it. So they've got their table of results here for four different tasks. So I'm thinking, I'm not sure that this thing called an RLM even exists. It just feels like a normal tool loop that happens to have particular tools in it. And I seem to have the same tools right now. So I think we can be an RLM, can't we? So I said, let's try it. Let's try this code QA thing. I've never heard of this before. So it tells me where to find the data. And so I start. So it writes some code for me, which actually didn't work. But then we can help me debug it. And then I can test it. And then I can experiment and look at this data carefully, make sure I understand what this eval is and how it works. And then I just tell it, okay, solve it. Go ahead and just solve this right now. And so this is one of the things in one of the evals. And it goes ahead and tries to do it. And it says, I think the answer's B. And they check. Oh, it is B. Tell me how you did that. And then, okay, let's try another eval. And answer is C. Yep, answer is C. And so this is very interesting. So I did this for a few different tasks, including the hardest quadratic tasks. So I downloaded another of these datasets, went through them, and discovered that Solve-It correctly solved every one of the tasks. And so I've now not only do I understand RLM, I've re-implemented it. This is all in the space of a couple of hours. And, in fact, discovered that this is a much more powerful platform than even RLM is.

SPEAKER_00

Another example was I was looking at Julia Evans, who's a fantastic writer, always really interesting. And she. I'm very. I'm not a fan of Tailwind, and I was keen to see how she had done this year, this article called Moving Away from Tailwind, which had a particular structure. This was the structure she had, and I decided, okay, I want to go through her blog post. So I loaded the blog post, as you can see, into Solve-It, and I started reading it. And, again, the red is me asking questions as I go through the article. And so she said she used something called Tailwind Preflight as her starting point for her styles, and it's, well, are there other options? So I went and grabbed it, and actually, one of the cool things about Solve-It is because it's in a browser, I've got actual styles, HTML here. So I'm actually modifying my environment as I go. And so I can see this happening, and then I can try it out. So I'm trying out layers. I'd never really done anything with layers before, so I make sure I understand how they work. But, again, I'm actually using them. So before I actually used RLM, you know, or rebuilt RLM inside a dialog, here I am rebuilding Julia's styles inside a dialog. She had a section about components, and, again, same thing. I started creating the components myself, as you can see, with the help of AI to make sure I understand. So here I've got a badge component, for example. And this is all real, right? I'm creating actual code. I'm seeing it actually running. Button components. Then very interested in colors. I had some ideas about how to create a new color framework. So a bit of a discussion, as you see, with the AI. But, again, the AI didn't write it for me, right? I came up with this idea of what I think I wanted to do. And then I tried it. And you can see I've created my own new color palette that I'm very happy with. And I thought, oh, cool. I'll try and map those to semantics now. So, okay, which should danger be? It helps me show me what it looks like. Different colors on different backgrounds. Inverted ones. It helps me create these full swatches so I can see how my color palette looks. Did a similar thing with font sizes. I had an idea of how I wanted to create nice typography. So, again, write the code, talk through it, and have a look to see. And I'm thinking, oh, yeah, they all look pretty good.

SPEAKER_00

[SPEAKER_04] Thank you. [SPEAKER_01] So by craft field, right? I normally talk about software engineering being a bit of a canary in the AI coal mine because we applied it there very early and it's very applicable to software engineering. Inverted ones. It helps me create these full swatches so I can see how my color palette looks. Did a similar thing with font sizes. I had an idea of how I wanted to create nice typography. So, again, write the code, talk through it, and have a look to see. And I'm like, oh, yeah, they all look pretty good. [SPEAKER_04] Thank you. [SPEAKER_01] So by craft field, right?

SPEAKER_00

[SPEAKER_01] I normally talk about software engineering being a bit of a canary in the AI coal mine because we applied it there very early and it's very applicable to software engineering. [SPEAKER_01] But it's all still changing and we don't really know where it's all going yet. [SPEAKER_01] We certainly have more questions than we have answers, which is why we're all here, to share and learn from one another. [SPEAKER_01] But I'd love a show of hands, actually. [SPEAKER_01] Who in the room thinks that it's just another evolution, another step change in the long history of computing? [SPEAKER_01] A few hands, okay.

SPEAKER_00

[SPEAKER_01] And who thinks it's more of a revolution, something that's genuinely new? [SPEAKER_01] Okay, I think I see more revolution hands, but it's actually pretty mixed. [SPEAKER_01] Well, I think we're all still trying to work that out. [SPEAKER_01] Nobody really knows where this is all going. [SPEAKER_01] And it's those very questions that took me back to university at the beginning of 2024 because I really wanted to understand this more deeply.

SPEAKER_00

[SPEAKER_01] So I did a Master's of Engineering, took me two years part-time, and I designed a longitudinal study with two questionnaires spaced six months apart that I ran at the end of 2024, beginning of 2025, to look at the lived experience of professional software engineers who are using AI, either at work or at home. [SPEAKER_01] I got participants from 28 countries, and today I'm going to share four of the findings from that research for you to contemplate, take away with you. [SPEAKER_01] So one of the things I was really interested in understanding was whether AI coding assistants shift our perceived focus across these common development tasks that we all do.

SPEAKER_00

[SPEAKER_01] And most engineers felt that they spend less time on all but one. [SPEAKER_01] Reviewing code was the only one that was slightly in those two time points because over that six-month period, we saw a statistically significant shift from the more creation-focused tasks to the more verification-focused ones. [SPEAKER_01] And what that tells us is that the very nature of the work we do or the craft of software engineering is changing. [SPEAKER_01] Those common tasks, does that mean that we've got a whole bunch of free time on our hands now? [SPEAKER_01] We're all going home at midday, we're going to the beach and relaxing.

SPEAKER_00

[SPEAKER_01] I don't think that's what we're feeling at all. [SPEAKER_01] I know that it's not what I'm feeling. [SPEAKER_01] I'm busier than I ever have been. [SPEAKER_01] And it was different enough to the other standards of software development tasks I just mentioned. [SPEAKER_01] So I've given it a new name, Supervisory Engineering Work. [SPEAKER_01] It's made up of directing AI, evaluating. [SPEAKER_01] I think it sits right in the middle, in a new loop. [SPEAKER_01] I've called it the middle loop. [SPEAKER_01] But note that the dimensions of craft, they don't disappear. [SPEAKER_01] We're now just applying them to a new type of work.

SPEAKER_00

[SPEAKER_01] Productivity and developer experience travel together. [SPEAKER_01] They're correlated. [SPEAKER_01] And leaders have been told, if you want to improve the productivity of your team, focus on improving the developer experience. [SPEAKER_01] So I asked engineers in my study, did they feel more productive with AI? [SPEAKER_01] And of course, most said yes. [SPEAKER_01] 84% did at both time points.

SPEAKER_00

[SPEAKER_01] Very stable. [SPEAKER_01] But those same engineers were starting to report a decline in their developer experience. [SPEAKER_01] And by that, I mean one of three dimensions: cognitive load, flow state, or feedback loops. [SPEAKER_01] And I said that at least one of those three had declined or gotten worse. [SPEAKER_01] And by the second time point, six months later, that number had almost doubled to 27%. [SPEAKER_01] And it was flow state that was the most negatively affected, followed by cognitive load that was increasing. [SPEAKER_01] Feedback loops was improving, though.

SPEAKER_00

[SPEAKER_01] And if you're not going to do that, the fact that we're getting more feedback more frequently is actually interrupting our flow. [SPEAKER_01] Correlation there. [SPEAKER_01] Side effects, right? [SPEAKER_01] But note what's happening. [SPEAKER_01] We feel more productive, but the very things that made the work feel like a craft are starting to erode. [SPEAKER_01] So if you're feeling a version of this, know that you're not imagining it. [SPEAKER_01] The research is starting to show it. [SPEAKER_01] And giving it names like AI burnout.

SPEAKER_00

[SPEAKER_01] If you haven't read it yet, Steve Yegi has a really great blog post called The AI Vampire, on which he talks about this as well. [SPEAKER_01] And for the leaders in the room, please make sure that you're taking note of this as well. [SPEAKER_01] It's not sufficient to try and measure productivity alone because you're... [SPEAKER_01] So if you're feeling a version of this, know that you're not imagining it. [SPEAKER_01] The research is starting to show it. [SPEAKER_01] And giving it names like AI burnout. [SPEAKER_01] If you haven't read it yet, Steve Yegi has a really great blog post called The AI Vampire, on which he talks about this as well.

SPEAKER_00

[SPEAKER_01] And for the leaders in the room, please make sure that you're taking note of this as well. [SPEAKER_01] It's not sufficient to try and measure productivity alone because you're... [SPEAKER_01] So anyway, this is all sounding pretty grim, so I hope that the next and last finding that I'll share with you will give you as much hope as it gave me. [SPEAKER_01] The research is starting to show it. [SPEAKER_01] And giving it names like AI burnout.

SPEAKER_00

[SPEAKER_01] If you haven't read it yet, Steve Yegi has a really great blog post called The AI Vampire, in which he talks about this as well. [SPEAKER_01] And for the leaders in the room, please make sure that you're taking note of this as well. [SPEAKER_01] It's not sufficient to try and measure productivity alone because you're... [SPEAKER_01] So anyway, this is all sounding pretty grim, so I hope that the next and last finding that I'll share with you will give you as much hope as it gave me. [SPEAKER_01] So of all the research questions that I had to answer, I figured that demographics would play a big part, that they would matter.

SPEAKER_00

[SPEAKER_01] So things like your seniority, the size of the company you're working for. [SPEAKER_01] Well, it turns out the strongest predictor of productivity in those three dimensions of developer experience was something called self-efficacy. [SPEAKER_01] Self-efficacy is your own belief in your own ability to accomplish something. [SPEAKER_01] So engineers who felt more confident were over 10 times more likely to report higher productivity gains. [SPEAKER_01] That's a really big effect, and I'll tell you why it matters.

SPEAKER_00

[SPEAKER_01] Because self-efficacy is a belief, and you can change your belief much more easily than you can change your demographics or your work situation, right? [SPEAKER_01] Stuck where you are, you don't have to wait for the perfect title or the perfect tool to come along. [SPEAKER_01] You can actually get going right now. [SPEAKER_01] And self-efficacy is built up through mastery experiences, which you can gain through experimentation. [SPEAKER_01] The more you experiment, the more you learn. [SPEAKER_01] The more you learn, the more confidence you gain. [SPEAKER_01] So you're far more in control of how you react to this moment than you might have thought.

SPEAKER_00

[SPEAKER_01] Alright, so the very nature of our work is changing, the craft is relocating, what does the future even look like for us? [SPEAKER_01] I'm not an oracle. I don't have a crystal ball. [SPEAKER_01] It was inspired by a paper that I read recently. [SPEAKER_01] It was written by some of the same researchers that created the SPACE framework, if you're familiar with that. [SPEAKER_01] And they described these three possible futures. [SPEAKER_01] Now, I've given them slightly different names, but I was inspired by their work here. [SPEAKER_01] So on the one hand, you've got the artisanal developer.

SPEAKER_00

[SPEAKER_01] Possibly restricted to the more safety domains or heavily regulated environments. [SPEAKER_01] Now, I think this type of... There will be a demand for this type of work, but it might be quite rare. [SPEAKER_01] On the other hand, you've got the clerical coder. [SPEAKER_01] Now, this is the one to watch out for because I think it's the one that's probably got the least amount of joy built in. [SPEAKER_01] It's doing a lot of work overnight. [SPEAKER_01] You come in in the morning, and you just accept those PRs uncritically. [SPEAKER_01] Where's the creativity in that, right? [SPEAKER_01] So that's the one to avoid.

SPEAKER_00

[SPEAKER_00] [SPEAKER_01] And in the middle, we've got the orchestrator or the code conductor. [SPEAKER_01] But that's probably the same... Think building software with agents at scale.

SPEAKER_00

[SPEAKER_01] Now, depending on where you find your joy, you might find yourself leaning towards one of at least two different directions. [SPEAKER_01] If you're more interested in really understanding the problem, the domain, then you might lean towards being more domain-focused, capturing the what and the why in intense, well-written specs. [SPEAKER_01] And you're feeding that to the agents. [SPEAKER_01] On the other hand, if you're more interested in building the machine that builds the machine, then you might be more leaning towards that harness, making the harness by... [SPEAKER_01] ...the future of work looks like.

SPEAKER_00

[SPEAKER_01] And then create the pathways by opening up the opportunities, blurring the lines, and encouraging them to move towards it. [SPEAKER_01] And remember that pride and joy, they don't just happen by accident. [SPEAKER_01] They're outcomes that you can design into your system. [SPEAKER_01] So that, my friends, is the leadership work for you. [SPEAKER_01] All right, to wrap this up, nobody has this all figured out yet, right? [SPEAKER_01] Literally nobody. [SPEAKER_01] Not the top practitioners, not the tech leaders, and not the academics.

SPEAKER_00

[SPEAKER_01] Trust me, I know I have been in rooms with all of these people just this year, and they all have more questions than they have answers. [SPEAKER_01] We've all been rebooted. [SPEAKER_01] We're all just explorers now. [SPEAKER_01] And we're writing the path as we walk along it together. [SPEAKER_01] The future is yours to imagine, so take the opportunity to design the craft that brings you the most pride and joy in your work. [SPEAKER_01] Because as engineers, we've always designed for the future. [SPEAKER_01] And now we get to design our own. [SPEAKER_01] And that's all. [SPEAKER_01] Thank you. Thank you so much, Annie.

SPEAKER_00

[SPEAKER_05] Lots of thoughts, lots of anxiety that I hear from many folks in the industry. [SPEAKER_05] It's very understandable. [SPEAKER_05] So, a very helpful way of framing the challenges we have, whether we're leading folks or whether we're being directed around. [SPEAKER_01] Because as engineers, we've always designed for the future. [SPEAKER_01] And now we get to design our own. [SPEAKER_01] And that's all. [SPEAKER_01] Thank you. Thank you so much, Annie. [SPEAKER_05] Lots of thoughts, lots of anxiety that I hear from many folks in the industry. [SPEAKER_05] It's very understandable.

SPEAKER_00

[SPEAKER_05] A very helpful way of framing the challenges we have, whether we're leading folks or whether we're being directed around. [SPEAKER_05] Next up we have Mike Neal. [SPEAKER_05] I've known Mike for far too long.

SPEAKER_00

[SPEAKER_05] Not because he's an awesome person, but it demonstrates we're getting on in years. He has been involved in the Australian technology industry in many ways over a very extended period, over 20 or more years now that I've known him. He was an open source architect at Red Hat, the co-founder of CloudBees, and he's now the principal engineer at Block, where he works extensively on open source and their Project Goose product. But he's here to talk about something different. We have a massive constraint in computation. Meanwhile, there's lots of computation in the world. It's not sitting in data centers. It's sitting in this room. I don't know what the rough estimate will be, but would we have the equivalent of what's sitting on our phones and our laptops and so on in this room. And it's just going to waste almost all the time. We build these devices. We're very concerned about, for example, the climate impact of data centers and computation. I think it's a very legitimate concern. But it's not just the electricity to do the computation. We are making phones. We are making laptops. We're making desktops. And that embodies probably the significant majority of the total energy consumption of that device over its lifetime. And then we have them sitting there completely idle almost all the time. Mike is trying to do protocols to leverage devices. There are implications about who owns computation, where sovereignty sits. Are we going to be forever dependent on a small number of hyperscalers who have the capital and the wherewithal to build the compute that we all then just rent from them? Or is there another way? Mike has some thoughts and, more importantly, actions around that. It's amazing work and it's a privilege to have him come and speak about it. Please welcome Mike Neal.

SPEAKER_00

[SPEAKER_05] Thank you. [SPEAKER_04] Thank you. You can hear me okay? Great. Compute is all around us. It's in this very room with us. Quite a lot, actually. A lot of it's idle. Not all of it's idle. [SPEAKER_03] I can see a lot of people getting a lot of it running right now. It's getting expensive as people are starting to find.

SPEAKER_00

[SPEAKER_04] It's very resource heavy. It's not always the most efficient thing with the hardware that's used. And, of course, there's lots of consumer stuff together versus the deployed fleet of AI specialist stuff from 2025. The bar chart kind of looks like that. There's a lot of consumer stuff out there. And it's not comparing apples with apples, but it just gives you a taste of what's going on. There's the sheer power of compute that comes out of Apple devices and other things out there that's just being bought every year, renewed, or just sitting there idle. It's been there for years. So why do we want to do that? John talked about this a bit. Sovereignty has been talked about this week a bit. Sovereignty is just giving you optionality of where things run so you don't have to rely on an optic fibre that goes out, that's the one that goes out from Bondi Beach and heads across to California. Your data doesn't have to go there because you've got national sovereignty and for some reason this diagram is going via New Zealand which is chilling. Would you do things differently if you had zero marginal cost? This is one of the things about local models or personal stuff is you're not collaborating from all over different companies. You're not.

SPEAKER_00

So there's no incentives for the public one. [SPEAKER_04] This is not a scam. This is not an attempt or anything. It's really just a proof point. That's where we are. Thanks again everyone for having me. This is the technology we use and these are some links you can follow up. Thanks.

SPEAKER_00

[SPEAKER_05] Thank you so much, Mike. You can probably hear my voice is going. Don't worry if you're sick of my voice, imagine how I feel. Now to round out this round of talks this morning, we have a genuine treat for you. I was up at the sister conference AI Engineer Singapore just a couple of weeks ago. Some really amazing speakers up there and one of them I heard speaking on the first day of the leadership track was Jishuan Li. Jishuan is the head of ZAI. That's how it's pronounced. It's not Zai. Z is—I'm not going to pronounce it. Go and find Xiaipu or Jishuan. It's the Chinese word for intelligence. ZAI is one of a number of Chinese companies, model labs, who are very fast followers in a really deep and powerful way.

SPEAKER_00

AI is a marvellous way to connect more deeply with our computers and achieve the fullest representation of humanity. This has actually been my mission for the last 30 years and very dramatically for the last 10. At Answer.ai, it's all of my focus, this idea that we should be seeking to augment human creativity, not to replace it. It's interesting to see, hopefully this resonates with you, but also hopefully you see this is almost never what you actually see as being marketed when somebody's trying to sell you a piece of AI. It's going to summarize this for you, it's going to write this for you, it's going to do this for you. It's all about being done for you.

[SPEAKER_00] Thank you.

SPEAKER_00

One was I wanted to learn about recursive language models. Probably a lot of you know about recursive language models. They've been taking over the world. We've got this system called Solve-It. I should show you Solve-It.com. I loaded the paper, recursive language models paper, into Solve-It. You could just read it in the normal way, piece at a time, but make sure you understand it. I looked at figure one. I didn't know what this is, or this is, or this is. Normally I might just skip over it. But here I can just say, hey, what's this figure? And it tells me, these are the three evals that the RLM authors are doing here. Interestingly, it's going from a constant to a linear to a quadratic complexity, which is not actually captured in the original paper. That's really helpful information.

SPEAKER_00

I don't work very well at an abstract level. I need things to be concrete. I could ask for an example of each task. This is much easier than going into the papers and trying to dig them out. Here I'm getting little examples. I get it. I always tell people, don't move on when you're learning a new thing or working on something until you get it. I was like, okay, I get it. Then there's another figure where they describe it. I didn't fully understand this figure, to be honest, at first. It tells me what the key pieces are. It's very handy.

SPEAKER_00

Now, I don't work very well at an abstract level. I need things to be concrete. So I could ask for an example of each task. And this is much easier than going into the papers and trying to dig them out. And so here I'm getting little examples. It's like, okay, I get it. So I always tell people, don't move on when you're learning a new thing or working on something until you get it. So I was like, okay, I get it. So then there's another figure where they describe it. I didn't fully understand this figure, to be honest, at first. And so it tells me what the key pieces are. It's very handy.

SPEAKER_00

So when I'm reading this, I'm thinking, okay, I want to push beyond this. I want to understand it but try and go a bit past it. So I'm thinking, okay, I wonder if we can replicate all of the features of an RLM right now. So I had a hypothesis about how to do that. And I checked with the AI, I think we can try this ourselves. And it clarified some key points about where subagents fit. And as it turns out, Solve-It has a subagent. So I said, yeah, you've got a subagent. Why don't you try it? So in this case, it spawns an agent and tells it to use Python to solve the complex square root. And we can also write code here, right? So I can then try it myself and I can compare. I'm like, oh, cool. Okay, so I've confirmed. I'm in an environment where I can actually do the same things that the RLM paper did.

SPEAKER_00

So another thing I mentioned as I read papers is often it's very easy to skip over citations, right? But here it says, well, here's recent work. Well, okay, I don't know any of these, so I shouldn't keep moving. So I said, stop. Can you please go and read all those papers for me and tell me what they are and why they're here? I can decide whether to click on those links, read them more myself. And I want to test my understanding at this point.

SPEAKER_00

So anyway, to skip ahead a little bit, I'm thinking, okay, let's try it. So they've got their table of results here for four different tasks. So I'm thinking, I'm not sure that this thing called an RLM even exists. It just feels like a normal tool loop that happens to have particular tools in it. And I seem to have the same tools right now. So I think we can be an RLM, can't we? So I said, let's try it. Let's try this code QA thing. I've never heard of this before. So it tells me where to find the data. And so I start. So it writes some code for me, which actually didn't work. But then we can. It can help me debug it. And then I can test it. And then I can experiment and look at this data carefully, make sure I understand what this eval is and how it works. And then I just tell it, like, okay, solve it. Go ahead and just solve this right now.

SPEAKER_00

And so this is one of the things in one of the evals. And it goes ahead and tries to do it. And it says, I think the answer's B. And they check. Oh, it is B. Tell me how you did that. And then, okay, let's try another eval. And the answer is C. Yep, answer is C.

SPEAKER_00

And so this is very interesting. So I did this for a few different tasks, including the hardest quadratic tasks. So I downloaded another of these datasets, went through them, and discovered that Solve-It correctly solved every one of the tasks. And so I've now not only do I understand RLM, I've re-implemented it. This is all in the space of a couple of hours. And in fact, discovered that this is a much more powerful platform than even RLM is.

SPEAKER_00

Another example was I was looking at Julia Evans, who's a fantastic writer, always really interesting. And she. I'm very. I'm not a fan of Tailwind, and I was keen to see how she had done this year, this article called Moving Away from Tailwind, which had a particular structure. This was the structure she had, and I decided okay, I want to go through her blog post. So I loaded the blog post, as you can see, into Solve-It, and I started reading it. And again, so the red is me asking questions as I go through the article. And so she said she used something called Tailwind Preflight as her starting point for her styles, and it's well, are there other options? So I went and grabbed it, and actually, one of the cool things about Solve-It is because it's in a browser, I've got actual styles, HTML here. So I'm actually modifying my environment as I go. And so I can see this happening, and then I can try it out. So I'm trying out layers. I'd never really done anything with layers before, so I make sure I understand how they work. But again, I'm actually using them. So before I actually used RLM, or rebuilt RLM inside a dialog, here I am rebuilding Julia's styles inside a dialog. She had a section about components, and again, same thing. I started creating the components myself, as you can see, with the help of AI to make sure I understand. So here I've got a badge component, for example. And yes, this is all real, right? I'm creating actual code. I'm seeing it actually running. Button components. Then very interested in colors. I had some ideas about how to create a new color framework. So a bit of a discussion, as you see, with the AI. But again, the AI didn't write it for me, right? I came up with this idea of what I think I wanted to do. And then I tried it. And you can see I've created my own new color palette that I'm very happy with. And I thought, oh, cool. I'll try and map those to semantics now. So okay, which should danger be? So it helps me. Show me what it looks like. Different colors on different backgrounds. Inverted ones. It helps me create these full swatches so I can see how my color palette looks. Did a similar thing with font sizes. I had an idea of how I wanted to create nice typography. So again, write the code, talk through it, and have a look to see. And I'm like, oh yes, they all look pretty good.

SPEAKER_00

[SPEAKER_04] Thank you. [SPEAKER_01] So by craft field, right? I normally talk about software engineering being a bit of a canary in the AI coal mine because we applied it there very early and it's very applicable to software engineering. But it's all still changing and we don't really know where it's all going yet. We certainly have more questions than we have answers, which is why we're all here, to share and learn from one another. But I'd love a show of hands, actually. They all look pretty good. [SPEAKER_04] Thank you. [SPEAKER_01] So by craft field, right?

SPEAKER_00

[SPEAKER_01] I normally talk about software engineering being a bit of a canary in the AI coal mine because we applied it there very early and it's very applicable to software engineering. [SPEAKER_01] But it's all still changing and we don't really know where it's all going yet. [SPEAKER_01] We certainly have more questions than we have answers, which is why we're all here, to share and learn from one another. [SPEAKER_01] But I'd love a show of hands, actually. [SPEAKER_01] Who in the room thinks that it's just another evolution, another step change in the long history of computing? [SPEAKER_01] A few hands, okay.

SPEAKER_00

[SPEAKER_01] And who thinks it's more of a revolution, something that's genuinely new? [SPEAKER_01] Okay, I think I see more revolution hands, but it's actually pretty mixed. [SPEAKER_01] Well, I think we're all still trying to work that out. [SPEAKER_01] Nobody really knows where this is all going. [SPEAKER_01] And it's those very questions that took me back to university at the beginning of 2024 because I really wanted to understand this more deeply.

SPEAKER_00

[SPEAKER_01] So I did a Master's of Engineering, took me two years part-time, and I designed a longitudinal study with two questionnaires spaced six months apart that I ran at the end of 2024, beginning of 2025, to look at the lived experience of professional software engineers who are using AI, either at work or at home. [SPEAKER_01] I got participants from 28 countries, and today I'm going to share four of the findings from that research for you to contemplate, take away with you. [SPEAKER_01] So one of the things I was really interested in understanding was whether AI coding assistants shift our perceived focus across these common development tasks that we all do.

SPEAKER_00

[SPEAKER_01] And most engineers felt that they spend less time on all but one. [SPEAKER_01] Reviewing code was the only one that was slightly in those two time points because over that six-month period, we saw a statistically significant shift from the more creation-focused tasks to the more verification-focused ones. [SPEAKER_01] And what that tells us is that the very nature of the work we do or the craft of software engineering is changing. [SPEAKER_01] Those common tasks, does that mean that we've got a whole bunch of free time on our hands now? [SPEAKER_01] We're all going home at midday, we're going to the beach and relaxing.

SPEAKER_00

[SPEAKER_01] I don't think that's what we're feeling at all. [SPEAKER_01] I know that it's not what I'm feeling. [SPEAKER_01] I'm busier than I ever have been. [SPEAKER_01] And it was different enough to the other standards or software development tasks I just mentioned. [SPEAKER_01] So I've given it a new name, Supervisory Engineering Work. [SPEAKER_01] It's made up of directing AI, evaluating... [SPEAKER_01] I think it sits right in the middle, in a new loop. [SPEAKER_01] I've called it the middle loop. [SPEAKER_01] But note that the dimensions of craft, they don't disappear. [SPEAKER_01] We're now just applying them to a new type of work.

SPEAKER_00

[SPEAKER_01] Productivity and developer experience travel together. [SPEAKER_01] They're correlated. [SPEAKER_01] And leaders have been told, if you want to improve the productivity of your team, focus on improving the developer experience. [SPEAKER_01] So I asked engineers in my study, did they feel more productive with AI? [SPEAKER_01] And of course, most said yes. [SPEAKER_01] 84% did at both time points. [SPEAKER_01] Very stable. [SPEAKER_01] But those same engineers were starting to report a decline in their developer experience. [SPEAKER_01] And by that, I mean one of three dimensions: cognitive load, flow state, or feedback loops.

SPEAKER_00

[SPEAKER_01] And I said that at least one of those three had declined or gotten worse. [SPEAKER_01] And by the second time point, six months later, that number had almost doubled to 27%. [SPEAKER_01] And it was flow state that was the most negatively affected, followed by cognitive load that was increasing. [SPEAKER_01] Feedback loops was improving, though. [SPEAKER_01] And if you're not going to do that, the fact that we're getting more feedback more frequently is actually interrupting our flow. [SPEAKER_01] Correlation there. [SPEAKER_01] Side effects, right? [SPEAKER_01] But note what's happening.

SPEAKER_00

[SPEAKER_01] We feel more productive, but the very things that made the work feel a craft are starting to erode. [SPEAKER_01] So if you're feeling a version of this, know that you're not imagining it. [SPEAKER_01] The research is starting to show it. [SPEAKER_01] And giving it names like AI burnout. [SPEAKER_01] If you haven't read it yet, Steve Yegge has a really great blog post called The AI Vampire, on which he talks about this as well. [SPEAKER_01] And for the leaders in the room, please make sure that you're taking note of this as well. [SPEAKER_01] It's not sufficient to try and measure productivity alone because you're...

SPEAKER_00

[SPEAKER_01] So anyway, this is all sounding pretty grim, so I hope that the next and last finding that I'll share with you will give you as much hope as it gave me. [SPEAKER_01] So of all the research questions that I had to answer, I figured that demographics would play a big part, that they would matter. [SPEAKER_01] So things like your seniority, the size of the company you're working for, that sort of thing. [SPEAKER_01] Well, it turns out the strongest predictor of productivity in those three dimensions of developer experience was something called self-efficacy. [SPEAKER_01] Self-efficacy is your own belief and your own ability to accomplish something.

SPEAKER_00

[SPEAKER_01] So engineers who felt more confident were over 10 times more likely to report higher productivity gains. [SPEAKER_01] That's a really big effect, and I'll tell you why it matters. [SPEAKER_01] Because self-efficacy is a belief, and you can change your belief much more easily than you can change your demographics or your work situation, right? [SPEAKER_01] Stuck where you are, you don't have to wait for the perfect title or the perfect tool to come along. [SPEAKER_01] You can actually get going right now. [SPEAKER_01] And self-efficacy is built up through mastery experiences, which you can gain through experimentation.

SPEAKER_00

[SPEAKER_01] The more you experiment, the more you learn. [SPEAKER_01] The more you learn, the more confidence you gain. [SPEAKER_01] The more confidence you gain, the more you're able to achieve. [SPEAKER_01] So you're far more in control of how you react to this moment than you might have thought. [SPEAKER_01] Alright, so the very nature of our work is changing, the craft is relocating, what does the future even look like for us? [SPEAKER_01] I'm not an oracle. [SPEAKER_01] I don't have a crystal ball. [SPEAKER_01] It was inspired by a paper that I read recently.

SPEAKER_00

[SPEAKER_01] It was written by some of the same researchers that created the SPACE framework, if you're familiar with that. [SPEAKER_01] And they described these three possible futures. [SPEAKER_01] Now, I've given them slightly different names, but I was inspired by their work here. [SPEAKER_01] So on the one hand, you've got the artisanal developer. [SPEAKER_01] That's hand-crafted. [SPEAKER_01] Possibly restricted to the more safety domains or heavily regulated environments. [SPEAKER_01] Now, I think this type of... [SPEAKER_01] There will be a demand for this type of work, but it might be quite rare. [SPEAKER_01] On the other hand, you've got the clerical coder.

SPEAKER_00

[SPEAKER_01] Now, this is the one to watch out for because I think it's the one that's probably got the least amount of joy built in. [SPEAKER_01] It's doing a lot of work overnight. [SPEAKER_01] You come in in the morning, and you just accept those PRs uncritically. [SPEAKER_01] Where's the creativity in that? [SPEAKER_01] Possibly restricted to the more safety domains or heavily regulated environments. [SPEAKER_01] Now, I think this type of... [SPEAKER_01] There will be a demand for this type of work, but it might be quite rare. [SPEAKER_01] Possibly restricted to the more safety domains or heavily regulated environments.

SPEAKER_00

[SPEAKER_01] Now, I think there will be a demand for this type of work, but it might be quite rare. [SPEAKER_01] On the other hand, you've got the clerical coder. Now, this is the one to watch out for because I think it's the one that's probably got the least amount of joy built in. It's doing a lot of work overnight. You come in in the morning, and you just accept those PRs uncritically. Where's the creativity in that, right? [SPEAKER_01] So that's the one to avoid. And in the middle, we've got the orchestrator or the code conductor. We're going to give these things funny names. But that's probably the same as thinking building software with agents at scale.

SPEAKER_00

[SPEAKER_01] Now, depending on where you find your joy, you might find yourself leaning towards one of at least two different directions. If you're more interested in really understanding the problem, the domain, then you might lean towards being more domain-focused, capturing the what and the why in well-written specs. And you're feeding that to the agents.

SPEAKER_00

[SPEAKER_01] On the other hand, if you're more interested in building the machine that builds the machine, then you might be leaning towards that harness, making the harness by showing what the future of work looks like. And then create the pathways by opening up the opportunities, blurring the lines, and encouraging them to move towards it. [SPEAKER_01] And remember that pride and joy, they don't just happen by accident. They're outcomes that you can design into your system. So that, my friends, is the leadership work for you.

SPEAKER_00

[SPEAKER_01] All right, to wrap this up, nobody has this all figured out yet, right? Literally nobody. Not the top practitioners, not the tech leaders, and not the academics. Trust me, I know I have been in rooms with all of these people just this year, and they all have more questions than they have answers. [SPEAKER_01] We've all been rebooted. We're all just explorers now. And we're writing the path as we walk along it together.

SPEAKER_00

[SPEAKER_01] The future is yours to imagine, so take the opportunity to design the craft that brings you the most pride and joy in your work. Because as engineers, we've always designed for the future. And now we get to design our own. And that's all. Thank you. Thank you so much, Annie. [SPEAKER_05] Lots of thoughts, lots of anxiety that I hear from many folks in the industry. It's very understandable. So, a very helpful way of framing the challenges we have, whether we're leading folks or whether we're being directed around.

SPEAKER_00

[SPEAKER_05] So, next up we have Mike Neal. I've known Mike for far too long. Not because he's not an awesome person, but it demonstrates we're getting on in years. And he has been involved in the Australian technology industry in many ways over a very extended period, over 20 or more years now that I've known him. [SPEAKER_05] So, he was an open source architect at Red Hat, the co-founder of CloudBees, and he's now the principal engineer at Block, where he works extensively on open source and their Project Goose product. But he's here to talk about something different.

SPEAKER_00

[SPEAKER_05] So, obviously, we have a massive constraint in computation. Meanwhile, there's lots of computation in the world. It's not sitting in data centers. It's sitting in this room. I don't know what the rough estimate will be, but would we have the equivalent of what's sitting on our phones and our laptops and so on in this room. And it's just going to waste almost all the time.

SPEAKER_00

[SPEAKER_05] We build these devices. So, we're very concerned about, for example, the climate impact of data centers and computation. I think it's a very legitimate concern. But it's not just the electricity to do the computation. We are making phones. We are making laptops. We're making desktops. And that embodies probably the significant majority of the total energy consumption of that device over its lifetime. And then we have them sitting there completely idle almost all the time.

SPEAKER_00

[SPEAKER_05] So, Mike is trying to do protocols to decentralize devices, with implications about who owns computation, where sovereignty sits. Are we going to be forever dependent on a small number of hyperscalers who have the capital and the wherewithal to build the compute that we all then just rent from them? Or is there another way? [SPEAKER_05] Well, Mike has some thoughts and, more importantly, actions around that. It's amazing work and it's a privilege to have him come and speak about it. Please welcome Mike Neal. [SPEAKER_05] Thank you.

SPEAKER_00

[SPEAKER_04] Thank you. You can hear me okay? Great. Yeah. So, yeah. Compute is all around us. It's in this very room of us. Quite a lot, actually. A lot of it's idle. Not all of it's idle. [SPEAKER_03] I can see a lot of people getting a lot of it. [SPEAKER_05] It's amazing work and it's a privilege to have him come and speak about it. Please welcome Mike Neal. [SPEAKER_05] Thank you. [SPEAKER_04] Thank you. You can hear me okay? Great. Yeah. So, yeah. Compute is all around us. It's in this very room of us. Quite a lot, actually. A lot of it's idle. Not all of it's idle.

SPEAKER_00

[SPEAKER_03] I can see a lot of people getting a lot of it writing right now. It's getting expensive as people are starting to find.

SPEAKER_00

[SPEAKER_04] It's very resource heavy. It's not always the most efficient thing with the hardware that's used. And, of course, there's lots of consumer stuff compared to the deployed fleet of AI specialist stuff from 2025. The bar chart looks like that. There's a lot of consumer stuff out there. And it's not like you're comparing apples with apples, but it just gives you a taste of what's going on. There's the sheer power of compute that comes out of Apple devices and other things out there that's just being bought every year, renewed, or just sitting there idle. It's been there for years. So why do we want to do that? Well, John talked about this a bit. Sovereignty has been talked about this week a bit. Sovereignty is just giving you optionality of where things run so you don't have to rely on an optical fibre that goes out that's the one that goes out from Bondi Beach and heads across to California. Your data doesn't have to go there because you've got national sovereignty and for some reason this diagram is going via New Zealand which is cool. Would you do things differently if you had zero marginal cost? If you had this, this is one of the things about local models or personal stuff is you're not collaborating from all over different companies. You're not, so there's no incentives for the public one.

SPEAKER_00

[SPEAKER_04] This is not a scam. This is not an attempt or anything. It's really just a proof point. So yeah, that's where we are. So thanks again everyone for having me. This is the technology we use and these are some links you can follow up. So thanks. [SPEAKER_04] Thank you so much. [SPEAKER_03] collaborating from all over different companies. You're not so there's no incentives for the public one. [SPEAKER_04] This is not a scam. This is not an attempt or anything. It's really just a proof point. So yeah, that's where we are. So thanks again everyone for having me. This is the technology we use and this is some links you can follow up. So thanks.

SPEAKER_00

[SPEAKER_04] Thank you so much

SPEAKER_00

[SPEAKER_05] Mike. You can probably hear my voice is going. Don't worry if you're sick of my voice imagine how I feel. All right. Now to round out this round of talks this morning we have a genuine treat for you. So I was up at the sister conference AI Engineer Singapore just a couple of weeks ago. Some really amazing speakers up there and one of them I heard speaking on the first day of the leadership track was Jishuan Li. Now Jishuan is the head of ZAI. That's how it's pronounced. It's not ZAI. It's not Zai and Z is I'm not going to pronounce it go and find Xiaipu or Jishuan it's the Chinese word for intelligence it stands for that. ZAI is one of a number of Chinese companies model labs who are very fast followed

SPEAKER_00

And it tells me, okay, these are the three evals that the RLM authors are doing here. And interestingly, it's going from a constant to a linear to a quadratic complexity, which is not actually captured in the original paper. So that's really helpful information. Now, I don't work very well at an abstract level. I need things to be concrete. So I could ask for an example of each task. And this is much easier than going into the papers and trying to dig them out and so forth. And so here I'm getting little examples. It's, okay, I get it.

SPEAKER_00

So I always tell people, don't move on when you're learning a new thing or working on something until you get it. So I was, okay, I get it. So then there's another figure where they describe it. I didn't fully understand this figure, to be honest, at first. And so it tells me what the key pieces are. It's very handy. So when I'm reading this, I'm thinking, okay, I want to push beyond this. I want to understand it but try and go a bit past it. So I'm thinking, okay, I wonder if we can replicate all of the features of an RLM right now. So I had a hypothesis about how to do that. And I kind of checked with the AI, hmm, I think we can try this ourselves.

SPEAKER_00

And it clarified some key points about where subagents fit. And as it turns out, Solveit has a subagent. So I said, yeah, you've got a subagent. Why don't you try it? So in this case, it spawns an agent and tells it to use Python to solve the complex square root. And we can also write code here, right? So I can then try it myself and I can compare. I'm, oh, cool. Okay, so I've confirmed. I'm in an environment where I can actually do the same things that the RLM paper did. So another thing I mentioned as I read papers is often it's very easy to skip over citations, right?

SPEAKER_00

But here it says, well, here's recent work. Well, okay, I don't know any of these, so I shouldn't keep moving.

SPEAKER_00

So I said, stop. Can you please go and read all those papers for me and tell me what they are and why they're here? I can decide whether to click on those links, read them more myself. And I want to test my understanding at this point. So anyway, to skip ahead a little bit, I'm thinking, okay, let's try it. So they've got their table of results here for four different tasks. So I'm thinking, I'm not sure that this thing called an RLM even exists. It just feels like a normal tool loop that happens to have particular tools in it. And I seem to have the same tools right now. So I think we can be an RLM, can't we?

SPEAKER_00

So I said, let's try it. Let's try this code QA thing. I've never heard of this before.

SPEAKER_00

So it tells me where to find the data. And so I start writing code for me, which actually didn't work. But then we can help me debug it. And then I can test it. And then I can experiment and look at this data carefully, make sure I understand what this eval is and how it works. And then I just tell it, OK, solve it. Go ahead and just solve this right now. And so this is one of the things in one of the evals. And it goes ahead and tries to do it. And it says, I think the answer's B. And they check. Oh, it is B. Tell me how you did that. And then, OK, let's try another eval. And answer is C. Yep, answer is C. And so this is very interesting.

SPEAKER_00

So I did this for a few different tasks, including the hardest quadratic tasks. So I downloaded another of these data sets, went through them, and discovered that solve it correctly solved every one of the tasks. And so I've now not only do I understand RLM, I've re-implemented it. This is all in the space of a couple of hours. And in fact, discovered that this is a much more powerful platform than even RLM is. Another example was I was looking at Julia Evans, who's a fantastic writer, always really interesting. And she I'm not a fan of Tailwind, and I was keen to see how she had done this year, this article called Moving Away from Tailwind, I've re-implemented it.

SPEAKER_00

This is all in the space of a couple of hours. And, in fact, discovered that this is a much more powerful platform than even RLM is. Another example was I was looking at Julia Evans, who's a fantastic writer, always really interesting. And she... I'm very... I'm not a fan of Tailwind, and I was keen to see how she had done this year, this article called Moving Away from Tailwind, which had a particular structure. This was the structure she had, and I decided, okay, I want to go through her blog post. So I loaded the blog post, as you can see, into Solveit, and I started reading it. And, again, so the red is me asking questions as I go through the article.

SPEAKER_00

And so she said she used something called Tailwind Preflight as her starting point for her styles, and it's, well, are there other options? So I went and grabbed it, and actually, one of the cool things about Solveit is because it's in a browser, I've got actual styles, HTML here. So I'm actually modifying my environment as I go. And so I can see this happening, and then I can try it out. So I'm trying out layers. I'd never really... I'd never done anything with layers before, so I make sure I understand how they work. But, again, I'm actually using them.

SPEAKER_00

So before I actually used RLM, you know, or rebuilt RLM inside a dialog, here I am rebuilding Julia's styles inside a dialog.

SPEAKER_00

She had a section about components, and, again, same thing. I started creating the components myself, as you can see, with the help of AI to make sure I understand. So here I've got a badge component, for example. And, yeah, this is all real, right? I'm creating actual code. I'm seeing it actually running. Button components. Then very interested in colors. I had some ideas about how to create a new color framework. So a bit of a discussion, as you see, with the AI. But, again, the AI didn't write it for me, right? I came up with this idea of what I think I wanted to do. And then I tried it. And you can see I've created my own new color palette that I'm very happy with.

SPEAKER_00

And I thought, oh, cool. I'll try and map those to semantics now. So, okay, which should danger be? So it helps me... Show me what it looks like. Different colors on different backgrounds. Inverted ones. It helps me create these full swatches so I can see how my color palette looks. Did a similar thing with font sizes. I had an idea of how I wanted to create nice typography. So, again, write the code, talk through it, and have a look to see. And I'm like, oh, yeah, they all look pretty good. [SPEAKER_04] Thank you. [SPEAKER_01] So... [SPEAKER_01] By craft field, right?

SPEAKER_00

[SPEAKER_01] I normally talk about software engineering being a bit of a canary in the AI coal mine because we applied it there very early and it's very applicable to software engineering. [SPEAKER_01] But, you know, it's all still changing and we don't really know where it's all going yet. [SPEAKER_01] We certainly have more questions than we have answers, which is why we're all here, to share and learn from one another. [SPEAKER_01] But I'd love a show of hands, actually. [SPEAKER_01] Who in the room thinks that it's just another evolution, another step change in the long history of computing? [SPEAKER_01] A few hands, okay.

SPEAKER_00

[SPEAKER_01] And who thinks it's more of a revolution, something that's genuinely new? [SPEAKER_01] Okay, I think I see more revolution hands, but, you know, it's actually pretty mixed. [SPEAKER_01] Well, I think we're all still trying to work that out. [SPEAKER_01] Nobody really knows where this is all going. [SPEAKER_01] And it's those very questions that took me back to university at the beginning of 2024 because I really wanted to understand this more deeply.

SPEAKER_00

[SPEAKER_01] So I did a Master's of Engineering, took me two years part-time, and I designed a longitudinal study with two questionnaires spaced six months apart that I ran at the end of 2024, beginning of 2025, to look at the lived experience of professional software engineers who are using AI, either at work or at home. [SPEAKER_01] I got participants from 28 countries, and today I'm going to share four of the findings from that research for you to contemplate, take away with you. [SPEAKER_01] So one of the things I was really interested in understanding was whether AI coding assistants shift our perceived focus across these common development tasks that we all do.

SPEAKER_00

[SPEAKER_01] And most engineers felt that they spend less time on all but one.

SPEAKER_00

[SPEAKER_01] Reviewing code was the only one that was slightly in those two time points because over that six-month period, we saw a statistically significant shift from the more creation-focused tasks to the more verification-focused ones. [SPEAKER_01] And what that tells us is that the very nature of the work we do or the craft of software engineering is changing. [SPEAKER_01] Those common tasks, does that mean that we've got a whole bunch of free time on our hands now? [SPEAKER_01] We're all going home at midday, we're going to the beach and relaxing. [SPEAKER_01] I don't think that's what we're feeling at all. [SPEAKER_01] I know that it's not what I'm feeling.

SPEAKER_00

[SPEAKER_01] I'm busier than I ever have been.

SPEAKER_00

[SPEAKER_01] because over that six-month period, we saw a statistically significant shift from the more creation-focused tasks to the more verification-focused ones. And what that tells us is that the very nature of the work we do or the craft of software engineering is changing. Those common tasks, does that mean that we've got a whole bunch of free time on our hands now? We're all going home at midday, we're going to the beach and relaxing. I don't think that's what we're feeling at all. I know that it's not what I'm feeling. I'm busier than I ever have been. And it was different enough to the other standards or software development tasks I just mentioned. So I've given it a new name, Supervisory Engineering Work. It's made up of directing AI, evaluant, I think it sits right in the middle, in a new loop. I've called it the middle loop. But note that the dimensions of craft, they don't disappear. We're now just applying them to a new type of work. Productivity and developer experience travel together. They're correlated. And leaders have been told if you want to improve the productivity of your team, focus on improving the developer experience. So I asked engineers in my study, did they feel more productive with AI? And of course, most said yes. 84% did at both time points. Very stable. But those same engineers were starting to report a decline in their developer experience. And by that, I mean one of three dimensions. Cognitive load, flow state, or feedback loops. And I said that at least one of those three had declined or gotten worse. And by the second time point, six months later, that number had almost doubled to 27%. And it was flow state that was the most negatively affected, followed by cognitive load that was increasing. Feedback loops was improving, though. And if you're not going to do that, the fact that we're getting more feedback more frequently is actually interrupting our flow. Correlation there. Side effects, right? But note what's happening. We feel more productive, but the very things that made the work feel like a craft are starting to erode. So if you're feeling a version of this, know that you're not imagining it. The research is starting to show it. And giving it names like AI burnout. If you haven't read it yet, Steve Yegge has a really great blog post called The AI Vampire, on which he talks about this as well. And for the leaders in the room, please make sure that you're taking note of this as well. It's not sufficient to try and measure productivity alone because you're... So anyway, this is all sounding pretty grim, so I hope that the next and last finding that I'll share with you will give you as much hope as it gave me. So of all the research questions that I had to answer, I figured that demographics would play a big part, that they would matter. So things like your seniority, the size of the company you're working for, that sort of thing. Well, it turns out the strongest predictor of productivity in those three dimensions of developer experience was something called self-efficacy. Self-efficacy is your own belief and your own ability to accomplish something. So engineers who felt more confident were over 10 times more likely to report higher productivity gains. That's a really big effect, and I'll tell you why it matters. Because self-efficacy is a belief, and you can change your belief much more easily than you can change your demographics or your work situation, right? Stuck where you are, you don't have to wait for the perfect title or the perfect tool to come along. You can actually get going right now. And self-efficacy is built up through mastery experiences, which you can gain through experimentation. The more you experiment, the more you learn. The more you learn, the more confidence you gain. The more confidence you gain, the more confidence you gain, the more confidence you gain, the more confidence you gain, the more confidence you gain, the more confidence you gain, the more confidence you gain, the more confidence you gain. So you're far more in control of how you react to this moment than you might have thought. Alright, so the very nature of our work is changing, the craft is relocating, what does the future even look like for us? I'm not an oracle. I don't have a crystal ball. It was inspired by a paper that I read recently. It was written by some of the same researchers that created the SPACE framework, if you're familiar with that. And they described these three possible futures. Now, I've given them slightly different names, but I was inspired by their work here. So on the one hand, you've got the artisanal developer. That's, you know, think hand... Possibly restricted to the more safety domains or heavily regulated environments. Now, I think this type of... There will be a demand for this type of work, but it might be quite rare. On the other hand, you've got the clerical coder. Now, this is the one to watch out for because I think it's the one that's probably got the least amount of joy built in. It's doing a lot of work overnight. You come in in the morning, and you just accept those PRs uncritically. Where's the creativity in that, right? So that's the one to avoid. And in the middle, we've got the orchestrator or the code conductor. We're going to give these things funny names. But that's probably the same... Think building software with agents at scale.

SPEAKER_00

[SPEAKER_01] Now, this is the one to watch out for because I think it's the one that's probably got the least amount of joy built in. It's doing a lot of work overnight. You come in in the morning, and you just accept those PRs uncritically. Where's the creativity in that, right? So that's the one to avoid. And in the middle, we've got the orchestrator or the code conductor. We're going to give these things funny names. But that's probably the same... Think building software with agents at scale. Now, depending on where you find your joy, you might find yourself leaning towards one of at least two different directions. If you're more interested in really understanding the problem, the domain, then you might lean towards being more domain-focused, capturing the what and the why in tense, in well-written specs. And you're feeding that to the agents. On the other hand, if you're more interested in building the machine that builds the machine, then you might be more leaning towards that harness, making the harness by... ..the future of work looks like. And then create the pathways by opening up the opportunities, blurring the lines, and encouraging them to move towards it. And remember that pride and joy, they don't just happen by accident. They're outcomes that you can design into your system. So that, my friends, is the leadership work for you. All right, to wrap this up, nobody has this all figured out yet, right? Literally nobody. Not the top practitioners, not the tech leaders, and not the academics. Trust me, I know I have been in rooms with all of these people just this year, and they all have more questions than they have answers. We've all been rebooted. We're all just explorers now. And we're writing the path as we walk along it together. The future is yours to imagine, so take the opportunity to design the craft that brings you the most pride and joy in your work. Because as engineers, we've always designed for the future. And now we get to design our own. And that's all. Thank you.

SPEAKER_00

Thank you so much, Annie.

SPEAKER_00

[SPEAKER_05] Lots of thoughts, lots of anxiety that I hear from many folks in the industry. It's very understandable. So, a very helpful way of framing the challenges we have, whether we're leading folks or whether we're being directed around. So, next up we have Mike Neal. I've known Mike for far too long. Not because he's an awesome person, but it demonstrates we're getting on in years. And he has been involved in the Australian technology industry in many ways over a very extended period, over 20 or more years now that I've known him. So, he was an open source architect at Red Hat, the co-founder of CloudBees, and he's now the principal engineer at Block, where he works extensively on open source and their Goose, Project Goose product. But he's here to talk about something different. So, obviously, we have a massive constraint in computation. Meanwhile, there's lots of computation in the world. It's not sitting in data centers. It's sitting in this room. I don't know what the rough estimate will be, but would we have the equivalent of what? Sitting on our phones and our laptops and so on in this room. And it's just going to waste almost all the time. We build these devices. So, we're very concerned about, for example, the climate impact of data centers and computation. I think it's a very legitimate concern. But it's not just the electricity to do the computation. We are making phones. We are making laptops. We're making desktops. And that embodies probably the significant majority of the total energy consumption of that device over its lifetime. And then we have them sitting there completely idle almost all the time. So, Mike is trying to do protocols to destroy devices. implications about who owns computation, where sovereignty sits. Are we going to be forever dependent on a small number of hyperscalers who have the capital and the wherewithal to build the compute that we all then just rent from them? Or is there another way? Well, Mike has some thoughts and, more importantly, actions around that. It's amazing work and it's a privilege to have him come and speak about it. Please welcome Mike Neal.

SPEAKER_00

[SPEAKER_05] Thank you. [SPEAKER_04] Thank you. You can hear me okay? Great. Yeah. So, yeah. Compute is all around us. It's in this very room of us. Quite a lot, actually. A lot of it's idle. Not all of it's idle. [SPEAKER_03] I can see a lot of people getting a lot of it writing right now. It's getting expensive as people are starting to find. It's very, very resource heavy. It's not always the most efficient thing with the hardware that's used. [SPEAKER_04] Yeah. [SPEAKER_04] So, yeah. [SPEAKER_04] Compute is all around us. [SPEAKER_04] It's in this very room. [SPEAKER_04] Quite a lot, actually. [SPEAKER_04] A lot of it's idle. [SPEAKER_04] Not all of it's idle.

SPEAKER_00

[SPEAKER_03] I can see a lot of people getting a lot of it writing right now. [SPEAKER_03] It's getting expensive. [SPEAKER_04] As people are starting to find, it's very, very resource heavy. [SPEAKER_04] It's not always the most efficient thing with the hardware that's used. [SPEAKER_04] And, of course, there's lots of consumer stuff together versus the deployed fleet of AI specialist stuff from 2025. [SPEAKER_04] The bar chart looks like that. [SPEAKER_04] There's a lot of consumer stuff out there. [SPEAKER_04] And it's not that you're not comparing apples with apples, but it just gives you a taste of what's going on.

SPEAKER_00

[SPEAKER_04] There's the sheer power of compute that comes out of Apple devices and other things out there that's just being bought every year, renewed, or just sitting there idle. [SPEAKER_04] It's been there for years. [SPEAKER_04] So why do we want to do that? [SPEAKER_04] Well, John talked about this a bit. [SPEAKER_04] Sovereignty has been talked about this week a bit. [SPEAKER_04] Sovereignty is just giving you optionality of where things run so you don't have to rely on an optic fibre that goes out from Bondi Beach and heads across to California.

SPEAKER_00

[SPEAKER_04] Your data doesn't have to go there because you've got national sovereignty and for some reason this diagram is going via New Zealand which is chilling. [SPEAKER_04] Would you do things differently if you had zero marginal cost? [SPEAKER_04] This is one of the things about local models or personal stuff is you're not collaborating from all over different companies. [SPEAKER_03] You're not collaborating from all over different companies. [SPEAKER_03] So there's no incentives for the public one. [SPEAKER_04] This is not a scam. [SPEAKER_04] This is not an attempt or anything. [SPEAKER_04] It's really just a proof point. [SPEAKER_04] So yeah, that's where we are.

SPEAKER_00

[SPEAKER_04] So thanks again everyone for having me. [SPEAKER_04] This is the technology we use and this is some links you can follow up. [SPEAKER_04] So thanks. [SPEAKER_05] Thank you so much Mike. [SPEAKER_05] You can probably hear my voice is going. [SPEAKER_05] Don't worry if you're sick of my voice, imagine how I feel. [SPEAKER_05] All right. [SPEAKER_05] Now to round out this round of talks this morning we have a genuine treat for you. [SPEAKER_05] So I was up at the sister conference AI Engineer Singapore just a couple of weeks ago.

SPEAKER_00

[SPEAKER_05] Some really amazing speakers up there and one of them I heard speaking on the first day of the leadership track was Jishuan Li. [SPEAKER_05] Now Jishuan is the head of ZAI. [SPEAKER_05] That's how it's pronounced. [SPEAKER_05] It's not Zai. [SPEAKER_05] Z is the Chinese word for intelligence.

SPEAKER_04

[SPEAKER_05] It stands for that.

SPEAKER_01

[SPEAKER_05] ZAI is one of a number of Chinese companies, model labs, who are very fast followed. By craft field, right? I normally talk about software engineering being a bit of a canary in the AI coal mine because we applied it there very early and it's very applicable to software engineering. But, you know, it's all still changing and we don't really know where it's all going yet. We certainly have more questions than we have answers, which is why we're all here, to share and learn from one another. But I'd love a show of hands, actually. Who in the room thinks that it's just another evolution, another step change in the long history of computing? A few hands, okay.

SPEAKER_01

And who thinks it's more of a revolution, something that's genuinely new? Okay, I think I see more revolution hands, but, you know, it's actually pretty mixed. Well, I think we're all still trying to work that out. Nobody really knows where this is all going. And it's those very questions that took me back to university at the beginning of 2024 because I really wanted to understand this more deeply. So I did a Master's of Engineering, took me two years part-time, and I designed a longitudinal study with two questionnaires spaced six months apart that I ran at the end of 2024, beginning of 2025, to look at the lived experience of professional software engineers

SPEAKER_01

who are using AI, either at work or at home. I got participants from 28 countries, and today I'm going to share four of the findings from that research for you to contemplate, take away with you. So one of the things I was really interested in understanding was whether AI coding assistants shift our perceived focus across these common development tasks that we all do. And most engineers felt that they spend less time on all but one. Reviewing code was the only one that was slightly in those two time points because over that six-month period, we saw a statistically significant shift from the more creation-focused tasks to the more verification-focused ones.

SPEAKER_01

And what that tells us is that the very nature of the work we do or the craft of software engineering is changing. Those common tasks, does that mean that we've got a whole bunch of free time on our hands now? We're all going home at midday, we're going to the beach and relaxing. I don't think that's what we're feeling at all. I know that it's not what I'm feeling. I'm busier than I ever have been. And it was different enough to the other standards or software development tasks I just mentioned. So I've given it a new name, Supervisory Engineering Work. It's made up of directing AI, evaluant, I think it sits right in the middle, in a new loop.

SPEAKER_01

I've called it the middle loop. But note that the dimensions of craft, they don't disappear. We're now just applying them to a new type of work. Productivity and developer experience travel together. They're correlated. And leaders have been told, if you want to improve the productivity of your team, focus on improving the developer experience.

SPEAKER_01

So I asked engineers in my study, did they feel more productive with AI? And of course, most said yes. 84% did at both time points. Very stable. But those same engineers were starting to report a decline in their developer experience. And by that, I mean one of three dimensions. Cognitive load, flow state, or feedback loops. And I said that at least one of those three had declined or gotten worse. And by the second time point, six months later, that number had almost doubled to 27%. And it was flow state that was the most negatively affected, followed by cognitive load that was increasing. Feedback loops was improving, though. And if you're not going to do that,

SPEAKER_01

the fact that we're getting more feedback more frequently is actually interrupting our flow. Correlation there. Side effects, right? But note what's happening. We feel more productive, but the very things that made the work feel like a craft are starting to erode. So if you're feeling a version of this, know that you're not imagining it. The research is starting to show it.

SPEAKER_01

And giving it names like AI burnout. If you haven't read it yet, Steve Yegi has a really great blog post called The AI Vampire, on which he talks about this as well. And for the leaders in the room, please make sure that you're taking note of this as well. It's not sufficient to try and measure productivity alone because you're... So anyway, this is all sounding pretty grim, so I hope that the next and last finding that I'll share with you will give you as much hope as it gave me. So of all the research questions that I had to answer, I figured that demographics would play a big part, that they would matter. So things like your seniority,

SPEAKER_01

the size of the company you're working for, that sort of thing. Well, it turns out the strongest predictor of productivity in those three dimensions of developer experience was something called self-efficacy. Self-efficacy is your own belief and your own ability to accomplish something. So engineers who felt more confident were over 10 times more likely to report higher productivity gains. That's a really big effect, and I'll tell you why it matters. Because self-efficacy is a belief, and you can change your belief much more easily than you can change your demographics or your work situation, right? Stuck where you are, you don't have to wait for the perfect title

SPEAKER_01

or the perfect tool to come along. You can actually get going right now. And self-efficacy is built up through mastery experiences, which you can gain through experimentation. The more you experiment, the more you learn. The more you learn, the more confidence you gain. The more confidence you gain, the more confidence you gain, the more confidence you gain, the more confidence you gain, the more confidence you gain, the more confidence you gain, the more confidence you gain, the more confidence you gain, So you're far more in control of how you react to this moment than you might have thought. Alright, so the very nature of our work is changing, the craft is relocating,

SPEAKER_01

what does the future even look like for us? I'm not an oracle. I don't have a crystal ball. It was inspired by a paper that I read recently. It was written by some of the same researchers that created the space framework, if you're familiar with that. And they described these three possible futures. Now, I've given them slightly different names, but I was inspired by their work here. So on the one hand, you've got the artisanal developer. That's, you know, think hand... Possibly restricted to the more safety domains or heavily regulated environments. Now, I think this type of... There will be a demand for this type of work, but it might be quite rare.

SPEAKER_01

On the other hand, you've got the clerical coder. Now, this is the one to watch out for because I think it's the one that's probably got the least amount of joy built in. It's doing a lot of work overnight. You come in in the morning, and you just accept those PRs uncritically. Where's the creativity in that, right? So that's the one to avoid. And in the middle, we've got the orchestrator or the code conductor. We're going to give these things funny names. But that's probably the same... Think building software with agents at scale. Now, depending on where you find your joy, you might find yourself leaning towards one of at least two different directions.

SPEAKER_01

If you're more interested in really understanding the problem, the domain, then you might lean towards being more domain-focused, capturing the what and the why in tense, in well-written specs. And you're feeding that to the agents. On the other hand, if you're more interested in building the machine that builds the machine, then you might be more, you know, leaning towards that harness, making the harness by... ..the future of work looks like. And then create the pathways by opening up the opportunities, blurring the lines, and encouraging them to move towards it. And remember that pride and joy, they don't just happen by accident.

SPEAKER_01

They're outcomes that you can design into your system. So that, my friends, is the leadership work for you.

SPEAKER_01

All right, to wrap this up, nobody has this all figured out yet, right? Literally nobody. Not the top practitioners, not the tech leaders, and not the academics. Trust me, I know I have been in rooms with all of these people just this year, and they all have more questions than they have answers. We've all been rebooted. We're all just explorers now. And we're writing the path as we walk along it together. The future is yours to imagine, so take the opportunity to design the craft that brings you the most pride and joy in your work. Because as engineers, we've always designed for the future. And now we get to design our own.

SPEAKER_01

And that's all. Thank you.

SPEAKER_05

Thank you so much, Annie. Lots of thoughts, lots of anxiety that I hear from many folks in the industry. It's very understandable. So, a very helpful way of framing the challenges we have, whether we're leading folks or whether we're kind of being directed around. So, next up we have Mike Neal. I've known Mike for far too long. Not because he's an awesome person, but it demonstrates we're getting on in years. And he has been involved in the Australian technology industry in many ways over a very extended period, over 20 or more years now that I've known him. So, he was an open source architect at Red Hat, the co-founder of CloudBees, and he's now the principal engineer

SPEAKER_05

at Block, where he works extensively on open source and their Goose, Project Goose product. But he's here to talk about something different. So, obviously, we have a massive constraint in computation. Meanwhile, there's lots of computation in the world. It's not sitting in data centers. It's sitting in this room. I don't know what the rough estimate will be, but would we have the equivalent of what? Sitting on our phones and our laptops and so on in this room. And it's just going to waste almost all the time. We build these devices. So, we're very concerned about, for example, the climate impact of data centers and computation. I think it's a very legitimate concern.

SPEAKER_05

But it's not just the electricity to do the computation. We are making phones. We are making laptops. We're making desktops. And that embodies probably the significant majority of the total energy consumption of that device over its lifetime. And then we have them sitting there completely idle almost all the time. So, Mike is trying to do protocols

SPEAKER_03

to destroy devices.

SPEAKER_03

implications about who owns computation,

SPEAKER_05

where sovereignty sits. Are we going to be forever dependent on a small number of hyperscalers who have the capital and the wherewithal to build the compute that we all then just rent from them? Or is there another way? Well, Mike has some thoughts and, more importantly, actions around that. It's amazing work and it's a privilege to have him come and speak about it. Please welcome Mike Neal. Thank you.

SPEAKER_04

Thank you. You can hear me okay? Great. Yeah. So, yeah. Compute is all around us. It's in this very room of us. Quite a lot, actually. A lot of it's idle. Not all of it's idle.

SPEAKER_03

I can see a lot of people getting a lot of it writing right now. It's getting expensive

SPEAKER_04

as people are starting to find. It's very, very resource heavy. It's not always the most efficient thing with the hardware that's used. And, of course, there's lots of consumer stuff together versus the deployed fleet of AI specialist stuff from 2025. The bar chart kind of looks like that. There's a lot of consumer stuff out there. And it's not like you're not comparing apples with apples, but it just gives you a taste of what's going on. There's the sheer power of compute that comes out of Apple devices and other things out there that's just being bought every year, renewed, or just sitting there idle. It's been there for years. So why do we want to do that?

SPEAKER_04

Well, John kind of talked about this a bit. Sovereignty has been talked about this week a bit. Sovereignty is just kind of giving you optionality of where things run so you don't have to rely on an optic fibre that goes out that's the one that goes out from Bondi Beach and heads across to California. Your data doesn't have to go there because you've got national sovereignty and for some reason this diagram is going via New Zealand which is chilling.

SPEAKER_04

Would you do things differently if you had zero marginal cost? Like if you had, this is one of the things about local models or personal stuff is you're not you're not

SPEAKER_03

collaborating from all over different companies.

SPEAKER_03

you're not So there's no incentives for the public one.

SPEAKER_04

This is not a scam. This is not an attempt or anything. It's really just a proof point. So yeah, that's where we are. So thanks again everyone for having me. This is the technology we use and this is some links you can follow up. So thanks.

SPEAKER_04

Thank you so much

SPEAKER_05

Mike. You can probably hear my voice is going. Don't worry if you're sick of my voice imagine how I feel. All right. Now to round out this round of talks this morning we have a genuine treat for you. So I was up at the sister conference AI engineer Singapore just a couple of weeks ago. Some really amazing speakers up there and one of them I heard speaking on the first day of the leadership track was Jishuan Li. Now Jishuan is the head of ZAI. That's how it's pronounced. It's not ZAI. It's not Zai and Z is I'm not going to pronounce it go and find Xiaipu or Jishuan it's the Chinese word for intelligence it stands for that. ZAI is one of a number of Chinese companies

SPEAKER_05

model labs who are very fast followed