Don’t Be Cheap: AI and the Appearance of Engineering

Birger Halfmeier at AI Engineer Melbourne 2026

This presentation is part of a premium event, 'AI Engineer Melbourne 2026' available exclusively for puchase. Learn more and

Defining a Particular Kind of Stupidity

The speaker opens by framing a specific type of stupidity — not one rooted in lack of intelligence or education, but one that can befall anyone. Drawing on a 1942 quote from Dietrich Bonhoeffer, the speaker connects this idea to how people become 'mindless tools' under the influence of power, while noting Bonhoeffer's consoling insight that this condition is not permanent and depends on whether leaders expect more from people's independence and wisdom than from their compliance.

A Brief History of Dumbing Down: From Turing to Waterfall

The speaker traces a recurring pattern of oversimplification through the history of computing, starting with Alan Turing's nuanced 1950 imitation game being reduced to the blunt 'Turing test', then moving to Winston Royce's 1970 paper on software development lifecycles, whose iterative diagrams were misread as an endorsement of waterfall methodology. The speaker highlights that simplification is inevitable and not always bad, but consistently strips out the substance of original ideas.

Agile, Scrum, and the Pattern of Cheap Practice

The speaker fast-forwards to the 2001 Agile Manifesto and its subsequent dilution, citing Martin Fowler's term 'flaccid scrum' and the 2017 concept of 'zombie scrum' — processes that look like the real thing but lack genuine engagement, user contact, or continuous improvement. The same pattern, the speaker notes, appears across DevOps, SRE, blameless post mortems, and other practices that lose their demanding core in adoption.

Cheap Engineering as the Real Deadly Enemy

Drawing on Bonhoeffer's concept of 'cheap grace' — getting the comforts of faith without its demands — the speaker proposes that 'cheap engineering' is the true threat to the field, not AI. Cheap engineering means artifacts and velocity metrics look good on the surface while engineers lose genuine connection to their work and impact. The speaker sharply distinguishes this from frugal engineering, which protects what matters most: the uniquely human investment of attention, effort, and judgment that makes an engineer irreplaceable.

Thank you. That just gave away my talk, but it's good because we don't have much time. I'm really worried about the time. So please, you need to fill in all the good bits because I had to take them out and all the connective tissue between slides if they don't make sense, fill it in. And your conclusion and yes, okay.

So my talk is called Don't Be Cheap. But what I really want to talk about is a particular kind of stupidity. Not stupidity like being unintelligent. No, it's not actually like about any sort of defect that you might be born with at all. It's also not about your level of education. It's actually a kind of stupidity that can befall any of us at any moment. And it's very similar to what is very easily recognizable by us in LLMs, but much harder in humans and especially in ourselves. We're almost completely blind to it.

And it's been written about a lot. So I want to start with a quote. Not sure if anyone recognizes this quote, but it says, under the overwhelming impact of rising power, the stupid person is under a spell, blinded, misused, and abused in his very being. Having thus become a mindless tool, the stupid person will also be capable of any evil and at the same time incapable of seeing that it is evil.

Now this is not about AI, it's actually about people and it's not even from this era. This was actually recognized before technology as we know it today was a thing. This was Dietrich Bonhoeffer in 1942, few months before he got arrested. So that's that's a movie about him.

I heard it's not very good. But so, yeah, very, very serious circumstances. Obviously, not comparing those. But but the interesting thing is that despite those really, really dire circumstance that he was in, he actually had some consoling words for us. He did not say that the stupid person is forever doomed. He did not say that we are forever doomed to live with them. No. He actually said that it really depended on whether those in power expected more from people's stupidity than from their inner independence and wisdom. Now when you see those words, those in power, I do not want you to think of other people.

It's us. We're the leaders in the room no matter what our title is. It's up to us. Don't wait for anyone or anything else. And I could stop the talk there, but that's really the question I want you to walk away with like, are you expecting more from people's stupidity or from their independence and wisdom and of yourselves?

So if you have a few more minutes to stick around, seven minutes, I want to show you that this is actually something that our field has been struggling with for basically since the beginning, since roughly 1950 you could say that sort of around the start of the field of computer science, Doctor. Alan Turing, often seen as the father of computer science and AI.

And it's interesting because even back in 1950 when he published this paper, which I realized is not too small up there, it was called Computing Machinery and Intelligence. So even back then, were already discussing like can machines think? And he thought that wasn't actually a very useful question. So he decided to change the question and he came up with this thing called the imitation game.

There's a movie about there's a movie called that, but it's not really about that. It's more about his work during World War II. But if you have time, read the paper. There's also a paper that is linked to from Wikipedia about how this imitation game, which is basically a person talking through kind of like what we would think of as a chat interface to two other humans that he can't see.

One's a man, one's a woman. They're both trying to convince him that they are the woman. He needs to work out who's trying to fool him. And then what happens if you replace one of them with a machine? Like would he be fooled more often or less often? That got dumbed down a lot to what these days people refer to as the Turing test.

And obviously that's become like a bit of a benchmark and used in discussions about AGI. And that's sort of I guess my point. Like things get dumped down. It's not something we can really avoid. And it's not always bad like the contribution is still there. He's still done a lot of good stuff. But yeah, let's fast forward.

So 1970, this guy, does anyone in this room know Doctor. Winston Royce? No, probably that's fine. But you might recognize when I show you another page of this paper. So again, think it's amazing, 1970 he was already talking about managing the development of large software systems. It was already becoming a thing and he was the first to actually describe the development life cycle and included this diagram.

Yeah. So this is the thing, right? So people saw this diagram and they say, that looks like a waterfall. Right? And yeah, some people think he actually coined the term waterfall, that he promoted waterfall. It's not true. First of all, he never used the word waterfall in his paper. And secondly, he actually said, yeah, well this is sort of in theory what needs to happen, but in practice it doesn't actually work like this.

But you know, people miss that, at least some people missed it. And then he went through like multiple iterations in his paper and you know, there's like some you know sort of iterative like feedback and all that. If you were to scroll or at that time I guess on paper, flick through the pages to the very last page and rotate it because the last page is in landscape format, you'd actually see something like this.

Now this is the kind of diagram I think you were expecting at an AI engineering conference, right? Doesn't this look like an agentic workflow? Doesn't this look like, know, spec driven development or something? Anyway, I just thought it's cool. Yeah, like I said, you have to fill in the connective tissue. Fast forward to 2001, this is like the anti waterfall event.

Bunch of guys met on a mountain in Utah and walked down the mountain with this manifesto. We all know what happened to Agile. Not that, right? It didn't actually take that long for even one of the signatories, Doctor. Martin Fowler to realize many times, yeah, we're doing stand ups so we're agile and that's pretty much it.

All the other sort of demanding practices underneath gone and he called it flaccid scrum. All the XP stuff, all the good stuff that these people liked had become very optional. And then in 2017, we got zombie scrum, same idea. Like it looks like scrum from the distance, but it lacks the beating heart. That's the idea. Like no contact with the users, no adapting from feedback, no real ownership anymore, no continuous improvement.

If I had time, could give you more examples from DevOps, from SRE, toil, error budgets, all that kind of stuff, great ideas, blameless post mortems. In practice, they don't always turn out as intended. But interestingly, the guy we met at the beginning, Doctor. Dietrich Bonhoeffer, he saw the same pattern in 1937 in his church and he called it cheap grace.

So because he saw that people could get like the superficial comforts of their faith without actually putting any demand on themselves to live any differently. And I would like to propose that so by the way, this is what he called the deadly enemy of his church. And I would like to propose that our deadly enemy is not AI, it's cheap engineering.

So same thing, you know, the artifacts appear, the processes look mature on the surface according to some velocity metric, your teams are getting faster and faster. But you're no longer really connected with the work, you're no longer connected with the impact. Like it's the works passing through the process, but not really through you anymore. You're not really absorbing, you're not really forming yourself the way you used to.

And just wanna make a really quick distinction. Cheap engineering, bad. However, frugal engineering, absolutely not the same thing. Because frugality means protecting what matters. Like it means not wasting your precious resources, your time, your attention, your effort, everything that makes you uniquely human. You should absolutely be frugal with that, right?

Whereas with cheap engineering is the opposite. You're wasting all of that, everything that makes you special. And so if you engage in cheap engineering, that's what makes you replaceable. But being frugal is what makes you you. So I invite you to all think about that. Like what does engineering and being an engineer mean to you? And on that note, please don't be cheap.

Thank you.

Yeah. Cool. Alright.

Thank you.

Sitting right there. Yeah. The clock will count down to you. Should we start? Yeah. Countdown to you. Alright. So

you can see you'll be able to see

your screen at the top there. Yep. So if you have to drag Actually yeah. Screen. Where is my screen?

I don't know which way it is.

Alright. Well, I need to get out of the full screen mode first. Exit full screen. Alright. Where is it? Yeah. Oh, that way. No. Maybe that way? Actually, let's just go. I'll just reconnect this. I'll just do, like just share my screen.

Stop. No. I'm fine. How do I enter screen?

Don't Be Cheap!

AI and the appearance of Engineering

Birger Halfmeier

Stupidity

"Under the overwhelming impact of rising power [...] (the stupid person) is under a spell, blinded, misused and abused in his very being.
Having thus become a mindless tool, the stupid person will also be capable of any evil and at the same time incapable of seeing that it is evil."

1942

"It really will depend on whether those in power expect more from people's stupidity than from their inner independence and wisdom."

Dietrich Bonhoeffer

Black and white photograph of Dietrich Bonhoeffer.

A. M. Turing (1950) Computing Machinery and Intelligence. Mind 49: 433-460.

COMPUTING MACHINERY AND INTELLIGENCE

By A. M. Turing

1. The Imitation Game

I propose to consider the question, "Can machines think?" This should begin with definitions of the meaning of the terms "machine" and "think." The definitions might be framed so as to reflect so far as possible the normal use of the words, but this attitude is dangerous. If the meaning of the words "machine" and "think" are to be found by examining how they are commonly used it is difficult to escape the conclusion that the meaning and the answer to the question, "Can machines think?" is to be sought in a statistical survey such as a Gallup poll. But this is absurd. Instead of attempting such a definition I shall replace the question by another, which is closely related to it and is expressed in relatively unambiguous words.

The new form of the problem can be described in terms of a game which we call 'imitation game.' It is played with three people, a man (A), a woman (B), and an interrogator (C) who may be of either sex. The interrogator stays in a room apart from the other two. The object of the game for the interrogator is to determine which of the two is the man and which is the woman. He knows them by labels X and Y, and at the end of the game he says either "X is A and Y is B" or "X is B and Y is A." The interrogator is allowed to put questions to A and B thus:

C: Will X please tell me the length of his or her hair?

Now suppose X is actually A, then A must answer. It is A's object in the game to try and cause C to make the wrong identification. His answer might therefore be:

"My hair is shingled, and the longest strands are about nine inches long."

In order that tones of voice may not help the interrogator the answers should be written, or better still, typewritten. The ideal arrangement is to have a teleprinter communicating between the two rooms. Alternatively the question and answers can be repeated by an intermediary. The object of the game for the third player (B) is to help the interrogator. The best strategy for her is probably to give truthful answers. She can add such things as "I am the woman, don't listen to him!" to her answers, but it will avail nothing as the man can make similar remarks.

1950

Two identical diagrams illustrating the setup of the Imitation Game, also known as the Turing Test. Each diagram depicts an interrogator (represented by a smiley face with a question mark thought bubble) communicating with two hidden entities. One entity is explicitly labeled "MACHINE" (with a female symbol in its speech bubble), and the other is a human (also with a female symbol in its speech bubble). A cloud with male and female symbols and question marks signifies the interrogator's challenge to determine the true nature or gender identity of the hidden entities.

Figure 2. The Imitation Game: Stage 2, Version 1.

Figure 3. The Imitation Game: Stage 2, Version 2.

A black and white portrait of Alan Turing, a man with neatly combed dark hair, wearing a patterned suit, white shirt, and dark tie with a tie clip. He is looking slightly to the left with a neutral expression.

Alan Turing

1950

TURING TEST: 50 YEARS LATER

Figure 4. The Imitation Game as it is generally interpreted (The Turing Test).

Figure 2. The Imitation Game: Stage 2, Version 1.

Figure 3. The Imitation Game: Stage 2, Version 2.

Alan Turing

A gradient banner displays the year 1950.

A black and white portrait of Alan Turing, a man with neatly combed dark hair, wearing a patterned suit jacket, collared shirt, and dark tie.

A diagram labeled "Figure 4" illustrates the standard interpretation of the Imitation Game, depicting an interrogator (smiley face with a question mark thought bubble) trying to distinguish between a human (smiley face with speech bubble) and a machine (labeled "MACHINE" with a smiley face in a speech bubble), both separated by a line.

Two diagrams, "Figure 2" and "Figure 3", depict variations of Stage 2 of the Imitation Game. In both, an interrogator (smiley face with a question mark thought bubble containing male and female symbols) interacts with a machine (labeled "MACHINE" with a female symbol in a speech bubble) and a human. In Figure 2, the human is represented by a smiley face with a female symbol and a speech bubble also containing a female symbol. In Figure 3, the human is represented by a smiley face with an arrow pointing to a speech bubble containing a female symbol.

MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS

Dr. Winston W. Royce

INTRODUCTION

I am going to describe my personal views about managing large software developments. I have had various assignments during the past nine years, mostly concerned with the development of software packages for spacecraft mission planning, commanding and post-flight analysis. In these assignments I have experienced different degrees of success with respect to arriving at an operational state, on-time, and within costs. I have become prejudiced by my experiences and I am going to relate some of these prejudices in this presentation.

COMPUTER PROGRAM DEVELOPMENT FUNCTIONS

There are two essential steps common to all computer program developments, regardless of size or complexity. There is first an analysis step, followed second by a coding step as depicted in Figure 1. This sort of very simple implementation concept is in fact all that is required if the effort is sufficiently small and if the final product is to be operated by those who built it – as is typically done with computer programs for internal use. It is also the kind of development effort for which most customers are happy to pay, since both steps involve genuinely creative work which directly contributes to the usefulness of the final product. An implementation plan to manufacture larger software systems, and keyed only to these steps, however, is doomed to failure. Many additional development steps are required, none contribute as directly to the final product as analysis and coding, and all drive up the development costs. Customer personnel typically would rather not pay for them, and development personnel would rather not implement them. The prime function of management is to sell these concepts to both groups and then enforce compliance on the part of development personnel.

A scanned document titled "Managing the Development of Large Software Systems" by Dr. Winston W. Royce. The year 1970 is displayed at the top right. A black and white portrait photo of Winston Royce, a man wearing glasses and a suit, is on the right side of the slide.

1970

SYSTEM REQUIREMENTS
SOFTWARE REQUIREMENTS
ANALYSIS
PROGRAM DESIGN
CODING
TESTING
OPERATIONS

Figure 2. Implementation steps to develop a large computer program for delivery to a customer.

A black and white diagram illustrating the sequential steps of the waterfall software development model.

COMPLETE PROGRAM DESIGN BEFORE ANALYSIS AND CODING BEGINS
DOCUMENTATION MUST BE CURRENT AND COMPLETE
DO THE JOB TWICE IF POSSIBLE
TESTING MUST BE PLANNED, CONTROLLED AND MONITORED
INVOLVE THE CUSTOMER

Figure 10. Summary

A detailed flow diagram illustrating a software development lifecycle model. The diagram shows processes such as "SYSTEM REQUIREMENTS," "SOFTWARE REQUIREMENTS," "PRELIMINARY PROGRAM DESIGN," "ANALYSIS," "PROGRAM DESIGN," "CODING," "TESTING," "USAGE," and "OPERATIONS." It features multiple feedback loops, particularly between "USAGE," "PROGRAM DESIGN," "CODING," "TESTING," and "ANALYSIS." Key review points include "PRELIMINARY SOFTWARE REVIEW" (PSR), "CRITICAL SOFTWARE REVIEW" (CSR), and "FINAL SOFTWARE ACCEPTANCE REVIEW" (FSAR). Various documents are referenced, such as "SOFTWARE REQUIREMENTS," "PRELIMINARY DESIGN (SPEC)," "INTERFACE DESIGN (SPEC)," "FINAL DESIGN (SPEC)," "TEST PLAN (SPEC)," and "OPERATING INSTRUCTIONS." A dashed diagonal line separates an initial, more linear flow on the right from a more iterative and detailed process on the left.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

© 2001, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.

2001

The left side of the slide features a faded, sepia-toned image in the background depicting several people engaged in what appears to be a collaborative setting, subtly underscoring the manifesto's themes of individuals and interactions.

2009

Flaccid Scrum

29 January 2009

A small, partially visible profile picture of a person wearing a hat.

2009

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

Flaccid Scrum

29 January 2009

Martin Fowler

AGILE
AGILE ADOPTION
BAD THINGS

There's a mess I've heard about with quite a few projects recently. It works out like this:

They want to use an agile process, and pick Scrum
They adopt the Scrum practices, and maybe even the principles
After a while progress is slow because the code base is a mess

What's happened is that they haven't paid enough attention to the internal quality of their software. If you make that mistake you'll soon find your productivity dragged down because it's much harder to add new features than you'd like. You've taken on a crippling TechnicalDebt and your scrum has gone weak at the knees. (And if you've been in a real scrum, you'll know that's a Bad Thing.)

I've mentioned Scrum because when we see this problem, Scrum seems to be the nominative process the team is following. For many people, this situation is exacerbated by Scrum because Scrum is process that's centered on project management techniques and deliberately omits any technical practices, in contrast to (for example) Extreme Programming.

The left panel displays the Agile Manifesto text with a faint background image of people. The right panel, titled "Flaccid Scrum," includes a profile picture of Martin Fowler.

2017

Screenshot of The Liberators article: The Rise Of Zombie Scrum by Christiaan Verwijs

An illustration for 'The Rise Of Zombie Scrum' article showing stick figures. Some are in yellow hazmat suits, one with a net catching a figure, another holding a syringe, and one displaying an 'Epic Gantt Chart' with red markings. Other stick figures appear zombie-like, and one is running away. Potted plants and office desks are visible.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Signatories:

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

2017

The Rise Of Zombie Scrum

Symptoms, causes and what you can do about it

By Christiaan Verwijs. Published on Mar 30, 2017.

Image credit: Christiaan Verwijs, Johannes Schartau & Barry Overeem (Creative Commons Attribution-ShareAlike 4.0 International License).

Source: zombiescrum.org

An illustration depicts an office scene where individuals in yellow hazmat suits confront "zombie" figures. One hazmat-suited person uses a net to capture a regular person. Another stands beside an "EPIC GANTT CHART" covered in red splatters. A third hazmat-suited figure holds a spray bottle. Several green-skinned, disheveled "zombies" are scattered throughout the office, near plants and desks. A regular person runs away, having spilled a coffee cup. This illustration is from the article "The Rise Of Zombie Scrum."

∞

A rounded horizontal bar with a blue, purple, and pink gradient contains an infinity symbol.

Don't be Cheap...

A horizontal, rounded gradient bar from teal to pink in the top right corner contains a white infinity symbol.

Don't be Cheap...

Be an Engineer!

AI Engineer MELBOURNE

Community Partners

MLAI: https://www.meetup.com/melbourne-ai-engineer-meetup/
Women Coders: https://women-coders.com/
AI Jobs Australia: https://aijobsaustralia.com.au/

Logos for MLAI (a kangaroo wearing glasses), Women Coders (interconnected circles), and AI Jobs Australia (a networked globe). Each logo is accompanied by a QR code linking to their respective website.

AI Engineer

MELBOURNE

AI Engineer Melbourne

Flagship Sponsor

Google Cloud
Google DeepMind

https://www.aidev.codes/

A QR code linking to aidev.codes.

AI Engineer Melbourne

Premium Sponsor

ClickHouse

https://clickhouse.com/

Logo for AI Engineer Melbourne, featuring "AI Engineer" in large white text and "MELBOURNE" below it, enclosed within a white rectangular border.

Logo for ClickHouse, which includes four vertical bars of varying height to the left of the word "ClickHouse".

A QR code.

macOS Desktop

Screenshot of a macOS desktop with a scenic wallpaper featuring a clear turquoise lake, large smooth rocks in the water, snow-capped mountains in the background, and a bright blue sky.

Choose to Mirror from the screen mirroring menu

A white outline icon of a laptop computer is displayed above the text. A smaller white outline icon of two overlapping rectangles, commonly used to represent screen mirroring, is positioned within the instructional text.