Why the Engineering AI conference?
Engineering AI is our new one day conference for software engineers, regardless of their area of focus or the languages they use, and engineering leaders focussed on the impact of AI and LLMs on the practice of Software Engineering. It takes place in Sydney, and on Conffab our streaming platform, September 12th.
Read on for our motivations behind creating this event, or head to the conference site for the full lineup and to register, for just $695 in person or $295 for a streaming pass.
Four decades of writing software
I’ve been writing software in one way or another for well over 40 years, since I was fortunate enough for our family to get a TRS-80 back in the early 1980s (well an Australian rebranded version called the Dick Smith System 80, Dick Smith being the entrepreneur who started a chain of RadioShack like electronics stores in Australia back then) back in the early 1980s.
This interest lead me to Computer Science (if you were interested in writing software back then this is what you studied), a still nascent field at the time, where we wrote software in C and Pascal on minicomputers running Unix, then later in Pascal for the still new Mac platform.
Structured programming was the methodology back then, with Object Oriented programming a still emerging approach (C++ was released in 1985, the year I started university, but SmallTalk predates it by some years, with ultimately its roots in the 1960s and languages like Algol).
We still learned about the software crisis, and Computer Aided Software Engineering (CASE) was itself in its infancy–even the Integrated Development Environment (IDE), that today we all cannot imagine developing without, was novel.
Software engineering as a practice has had many significant, at times revolutionary, transitions, both before and since.
But this long history of someone who writes software, who has done so on numerous platforms, with a significant number of languages, over several decades does give me a sense of perspective.
This time feels different
And right now I don’t think I’m alone in believing we’re experiencing a transformation in the practice of software engineering as significant as any that has come before, in a timeframe that will likely be far more accelerated than earlier transformations.
The emergence of new development paradigms, like Object Oriented, and Functional, Programming have typically been additive too–older methodologies, and their associated languages, and most importantly code bases, may be replaced, but over a time frame of years, or even decades. There are still systems written in COBOL that underpin major applications in banking and insurance. C++ still dominates the codebases of web browsers (Mozilla developed Rust as a replacement for C++ in their codebase, but after years of effort abandoned that effort). And despite the emergence of Node and other Javascript runtimes, much of the Web still runs on PHP.
The fundamentals have remained unchanged
And significantly what it is to write software, the actual code, in many ways that’s unchanged since the arrival of the command line and terminal, replacing punchcards, over half a century ago.
We humans formulate complex strings that meet specific syntactic rules. We may draw UIs on screens, wire up these UIs in tools like XCode, but the actual functionality is still mostly code typed out by hand (or pasted from Stack Overflow).
Humans still develop the overarching architectures of systems, we write the tests, still do much of the QA. This is what Software Engineering has looked like for decades. Yes, things have been automated here and there, and we abstract away lower level implementations with frameworks and libraries (as we have done for decades) though the code for these are still written by humans.
It’s not turtles, it’s humans all the way down.
The promise of higher abstractions
There have been attempts to create higher order abstractions, most notably Fourth Generation Languages (or 4GLs). The term appears to have been first used in this sense by James Martin in a 1981 book titled, tellingly “Application Development Without Programmers”.
Simon Willison recently quoted Martin
Applications development did not change much for 20 years, but now a new wave is crashing in. A rich diversity of nonprocedural techniques and languages are emerging. As these languages improve, they promise to change the entire fabric of DP development.
(In case you’re wondering DP happens to stand for Digital Processing 😅).
It’s not that these 4GLs never materialised, or ever went entirely away, they found their niches for developing specific kinds of applications (you can think of Microsoft Access, as a kind of 4GL).
But these languages and environments didn’t generalise.
Languages that look a lot like those from 50 or even 60 years ago (at least if you squint), 3GLs, are still what we write the vast majority of our code in–whether Python, Go, JavaScript, TypeScript, Java…
But it seems clear to many even very experienced software developers and engineers that we are likely already well into a paradigmatic change in how software is developed. Not simply how we generate lines of code, but the entire software development lifecycle-from architecture to code, testing, QA, Large Language Models models are impacting how software is being developed.
As Greg Storey wrote recently about the practice of design “It’s happening…If you’re not building AI collaboration skills right now, you’re already behind. But paradoxically, as Scott Werner recently observed, “Nobody Knows How To Build With AI Yet”
There’s this moment in every new technology where everyone pretends they know what they’re doing. We’re past that moment. Or maybe we haven’t reached it yet. Either way, we’re in this delicious middle ground where nobody can pretend expertise because the whole thing keeps changing under our feet.
The questions keeping engineering leaders up at night are practical ones: How do we maintain code quality when AI is generating significant portions of our codebase? What does code review look like when the ‘author’ is an LLM? How do we train junior developers when the fundamentals of the craft are shifting? How do we balance productivity gains with technical debt risks? How do we measure the value of an LLMs contributions and allocate resources?
This is something I’ve been thinking a lot about for quite some time now. I’ve been working with various LLMs over the last 2 or more years as a software developer, and seen their capabilities increase dramatically. I’ve followed numerous developers like Simon Willison as they have documented their experiences, which have often mirrored mine. And more recently I hosted two unconferences, bringing together dozens of experienced software engineers to explore this topic–you can find detailed writeups of these from both Melbourne and Sydney.
All of which leads us to Engineering AI, a conference we announced a few weeks back, with a focus on the question, “how are AI, Machine Leaning and LLMs impacting the practice of Software Engineering”–not just coding, the entire SDLC? You won’t hear much, indeed anything about vibe coding. There won’t be vague speculation about the ‘future of…’. There won’t be the ‘top 10 prompts for…’
The developers and engineering leaders speaking at Engineering AI aren’t just experimenting—they’re already shipping AI-assisted systems at scale, rebuilding development workflows, and solving the thorny integration challenges that separate proof-of-concept from production reality.
They will be really experienced, deeply thoughtful experts sharing their actual lessons–warts and all. They’ll help you chart the way forward for you and your team, uncover new ideas and approaches to explore, and hopefully validate your existing approaches.
The transformation is happening whether we’re prepared or not
The question isn’t whether AI will reshape software engineering—it’s whether you’ll help shape that transformation or scramble to catch up later.
Join us in Sydney, September 12th to move beyond the speculation and into the practical reality of building software in the AI era. This isn’t about the future of development—it’s about the present, and the teams already getting it right.
Register now – $695 in-person, $295 streaming. Team discounts available.
The developers who excel at AI-assisted software engineering today will define the industry tomorrow. Be one of them.
Four decades of writing software
I’ve been writing software in one way or another for well over 40 years, since I was fortunate enough for our family to get a TRS-80 back in the early 1980s (well an Australian rebranded version called the Dick Smith 80, Dick Smith being the entrepreneur who started a chain of RadioShack like electronics stores in Australia back then) back in the early 1980s.
This interest lead me to Computer Science (if you were interested in writing software this is what you studied), a still nascent field at the time, where we wrote software in C and Pascal on minicomputers running Unix, then later the still new Mac platform.
Structured programming was the methodology back then, with Object Oriented programming a still emerging approach (C++ was released in 1985, the year I started university, but SmallTalk predates it by some years.)
We still learned about the software crisis, and Computer Aided Software Engineering (CASE) was itself in its infancy–and the Integrated Development Environment (IDE) we all cannot imagine developing without was also novel.
Software engineering as a practice has had many significant, at times revolutionary transitions, both before and since.
But this long history as someone who writes software, has done so on numerous platforms, with a significant number of languages, over decades, does provide some context.
This time feels different
And right now I don’t think I’m alone in believing we’re looking at a transformation in the practice of software engineering as significant as any that has come before, in a timeframe that will likely be far more accelerated than earlier transformations.
With the emergence of new platforms like GUI-based Operating systems in the 1980s and 90s, the Web in the early 90s, smartphones 15-20 years ago, the shift toward cloud computing, we typically see initially additive changes and only relatively gradual substitutions over the course of many years.
The emergence of new development paradigms like OO programming and Functional Programming have typically been additive too–older paradigms and their associated languages and most importantly code bases may be replaced, but in the order of years or decades. There are still systems written in COBOL that underpin major corporations in banking and insurance. C++ still dominates the codebases of web browsers (Mozilla developed Rust as a replacement for C++ in their codebase, but after years of effort abandoned that effort).
The fundamentals have remained unchanged
And what it is to write software, the actual code, in many ways that’s unchanged since the arrival of the command line and terminal, replacing punchcards over half a century ago.
We humans formulate complex strings that meet specific syntactic rules. We may draw UIs on screens, wire up these UIs in tools like XCode, but the actual functionality is still mostly code typed out by hand.
Humans develop the overarching architectures of systems, we write the tests, do much of the QA. This is what Software Engineering has looked like for decades. Things have been somewhat automated here and there, and we abstract away lower level implementations with frameworks and libraries (as we have done for decades) though the code for these are still written by humans.
It’s not turtles, but humans all the way down.
The promise of higher abstractions
There have been attempts to create higher order abstractions, most notably Fourth Generation Languages (or 4GLs). The term appears to have been first used in this sense by James Martin in a 1981 book titled, tellingly “Application Development Without Programmers”.
Simon Willison recently quoted Martin
Applications development did not change much for 20 years, but now a new wave is crashing in. A rich diversity of nonprocedural techniques and languages are emerging. As these languages improve, they promise to change the entire fabric of DP development.
(DP happens to stand for Digital Processing).
It’s not that these 4GLs never materialised, or ever went entirely away, they found their niches for developing specific kinds of applications (you can think of Microsoft Access, as a kind of 4GL).
But these languages and environments didn’t generalise.
Languages that look a lot like those from 50 or even 60 years ago (at least if you squint), 3GLs, are still the foundation of software engineering.
But it seems clear to many even very experienced software developers and engineers that we are likely already well into a paradigmatic change in how software is developed. Not simply the generation of lines of code, but the entire software development lifecycle-from architecture to code, testing, QA, Large Language Models models are impacting how software is being developed.
As Greg Storey wrote recently about the practice of design “It’s happening…If you’re not building AI collaboration skills right now, you’re already behind. But as Scott Werner recently observed “Nobody Knows How To Build With AI Yet”
There’s this moment in every new technology where everyone pretends they know what they’re doing. We’re past that moment. Or maybe we haven’t reached it yet. Either way, we’re in this delicious middle ground where nobody can pretend expertise because the whole thing keeps changing under our feet.
The questions keeping engineering leaders up at night are practical ones: How do we maintain code quality when AI is generating significant portions of our codebase? What does code review look like when the ‘author’ is an LLM? How do we train junior developers when the fundamentals of the craft are shifting? How do we balance productivity gains with technical debt risks?
This is something I’ve been thinking a lot about for quite some time now. I’ve been working with various LLMs over the last 2 or more years as a software developer and seen their capabilities increase significantly. I’ve followed numerous developers like Simon Willison as they have documented their experiences, which have often mirrored mine. And more recently I hosted two unconferences, bringing together dozens of experienced software engineers exploring this topic–you can find detailed writeups of these from both Melbourne and Sydney.
All this leads us to Engineering AI, a conference we announced a few weeks back, with a focus on the question, how are AI, Machine Leaning and LLMs impacting the practice of Software Engineering–not just coding, the entire SDLC? You won’t hear much, indeed anything about vibe coding. There won’t be vague speculation about the ‘future of…’. There won’t be the ‘top 10 hacks for…’
The developers and engineering leaders speaking at Engineering AI aren’t just experimenting—they’re already shipping AI-assisted systems at scale, rebuilding development workflows, and solving the thorny integration challenges that separate proof-of-concept from production reality.
They will be really experienced, deeply thoughtful experts sharing their actual lessons–warts and all. They’ll help you chart the way forward for you and your team, uncover new ideas and approaches to explore, and hopefully validate your existing approaches.
The transformation is happening whether we’re prepared or not
The question isn’t whether AI will reshape software engineering—it’s whether you’ll help shape that transformation or scramble to catch up later.
Join us in Sydney, September 12th to move beyond the speculation and into the practical reality of building software in the AI era. This isn’t about the future of development—it’s about the present, and the teams already getting it right.
Register now – $695 in-person, $295 streaming. Team discounts available.
The developers who excel at AI-assisted engineering today will define the industry tomorrow. Be one of them.