Can You Keep Up With AI?

This is the final part of a conversation between Norbert Korny, Jeff Allison, and Sean Murphy on where AI is taking engineering: can you keep up with AI?

This is part 3 of a podcast with Norbert Korny, Jeff Allison, and Sean Murphy exploring the impact of AI on engineering.

Edited Transcript

Code alone won’t cut it

Norbert Korny: What’s stopping you from building something like Facebook when you have all the tooling at your hands?

Sean Murphy: It turns out that building the Facebook application is not the barrier to the next Facebook. It’s the fact that they’ve got a billion people using it.

This plays out in a number of domains already. Many people use AutoCAD or other tools for common design, and they customize them by adding their own building blocks and plugins. They create multi-tool flows, adding their own bits to the recipe to get differentiation. If you can stay on the path for 80 to 90% of the effort, commoditize that cost, and provide differentiation with just 10 to 20% of the total investment, then that’s a better strategy.

Competitors collaborate all the time. Nobody comes out and says, “I’ve got a new refrigerator, but instead of running on 120 volts, it’s going to run on 147, because that would make my compressor run better.” There’s always going to be a role for standards. There’s always going to be a role for common infrastructure. What’s tricky right now is we don’t yet really see the stack. It took a little bit of time with SaaS to figure out what the stack was going to look like, and I think that’s true here. Even in networking, it took a while to figure out how to maintain a clean separation of layers. Don’t mix layer four and layer two, or layer seven and layer five.

Public Information vs. Secret Sauce

Jeff Allison: The competitive stuff comes with the you know the secret sauce you add because you’ve done that internally somewhere, and it’s not public domain. It’s not out there.

Sean: The semiconductor guys have solved this problem. They collaborate. There’s a common roadmap. There are common things, but they each keep their piece. They all agree they’re going to use 300 millimeter (12 inch) wafers. They agree on how they will collaborate, and how they will compete.

Jeff: Is the software world ready for this now? That’s not the way it works today. They’re not all saying, “Okay, well, 80% of the infrastructure is given, and we’re just going to add 20% as a secret sauce.” In hardware and in stack-based things, I totally agree. I don’t know whether that works for many software applications. Does Facebook develop on a stack methodology?

Sean: Yes, they worry a lot about security, they’re deploying at scale. Google has it’s own stack for deploying at scale, some of which they give away as open source but other parts they don’t.

Infrastructure vs Security

Norbert: The software has already moved to the cloud to some extent. There’s a lot of it running out there, but with AI you still need to rely on that infrastructure because cloud computing is much more powerful than the edge, and the edge somehow failed to deliver. You just need that compute power. From what I can see, what’s missing is the security layer. If you put something in, you don’t know where it is. That’s one thing. The other is that there’s no basic concept of security. For example, those libraries.

Jeff: With anything that’s new, there’s also an aftermarket, and they are sometimes as big as the initial market. Look at networking and security. Security wasn’t part of networking, and then it became a huge aftermarket. I don’t know how big the security market is now, but it’s massive.

So maybe the same thing happens here. We have this core technology that allows us to be efficient, and there are other markets that have to develop to address the issues that weren’t taken into account, such as security or other things we don’t know about yet.

Faster development, complex coordination

Sean: To me, another challenge is that engineers may be moving ten to twenty times faster, but still relying on a weekly process for sync. That’s now got to be twice a day, or you’ve got to find ways to keep people in sync because a week of progress is now what you would normally get done in two and a half months. So the chance for divergence and the loss of a shared situational awareness goes way up.

I’ve been in situations where something that used to take a long time and was error-prone suddenly collapsed to a short, very reliable step. For example, instead of two guys with eye pieces taking three weeks to check plots to determine if there were errors in a chip layout, it would now take four hours with software that did automated checking. The schedule collapsed in some ways, but we also did more iterations. You say, we can make a change in a day and still have it checked in two days. The uncertainty of the verification went away. I think the flip side is that we’re less able to handle shared situational awareness. We need new kinds of tools for keeping things in sync.

A more complex kind of revision control for managing the frontier of design exploration, and more diagrams and visualizations for where things stand, to collapse a thousand words in a report into a single picture. I think we are going to move from plain-English specifications to domain-specific languages with controlled terminology, so everyone on the team, everyone in an organization, perhaps everyone in a supply chain, understands what things mean.

Faster Can Backfire

Jeff: The going faster part kind of made me chuckle, because going faster is not always a good thing. If you can go faster, sometimes people just start throwing stuff at the problem. They don’t think about the solution. They say, “Well, I can develop 10 thoughts and throw that into this regression.”

Sean: Back to shotgun debugging: let’s try 10 things in parallel. Sometimes I think the problem behind the problem is that my customers can only absorb so much change. If I’m plugging into their workflows and their plans, they don’t want a new tool every day for stability reasons. They might agree to periodic software updates, but if functionality changes too much, it’s hard to compare current results with prior ones and to plan. The workflow can destabilize, and communication becomes harder because everyone is not on the same page

Jeff: You need to agree on how you are going to do this. And that’s just the chip market. There are other markets where, if you start dropping code into a big telco, they have their own process to verify this stuff works. They have their own test cycle you need to fit into, and if you start dropping new code every month, that’s not going to work because they can’t absorb it that fast. I remember the problem with faster was when we brought in faster hardware to run jobs. Engineers tended to wait until that faster hardware was available because they said it’ll run faster. Well, I said, you just waited two days to get on this machine, but he said no, it runs faster. So when you get this faster mentality going in engineering, it can create strange behavior. Engineers stop thinking about what they need to do and just start throwing stuff into an automated process that may be broken. I think that’s where we’re headed with some of these speed ups.

Sean: We need another coordination layer or new techniques for coordinating business and engineering work in process.

Jeff: I don’t want “new” to mean bypassing good engineering practice. I do worry about that a little bit.

Sean: It’s like a clock-domain-crossing problem: you need explicit synchronization between signals in a domain that’s moving very fast, at a high clock speed, and slower-moving domains. Most decision processes in companies aren’t set up to make decisions every four hours. You can if you’ve got a customer hot site. Some processes in a company are designed to move very fast, but it’s typically firefighting—hot sites, or the last days of the quarter when we’re negotiating with customers to close a deal. But most of the time, decisions benefit from sleeping on it and thoughtful consideration.

Norbert: The domain language will need to be something we figure out. We need to have that shared understanding, not only in the ubiquitous language way we do in architecture, but how we express things and the context that AI is trying to find. How do we specify that? How do we capture that shared context? This is basically why we invented parse trees in programming: one written statement to express one exact thing.

What Can Engineers Stop Doing and Delegate?

Jeff: I have a question for you, Norbert. You are a very talented senior engineer and architect. Given that AI is now mainstream and we have figured out libraries, internal training, and other key building blocks, what do you stop doing? What are you doing today that you’re not going to be doing tomorrow because you are now relying on AI?

Norbert: Well, the first thing that comes to mind is reading documentation, and we can already see that Stack Overflow’s visit rate just crashed. No one reads that anymore because you have AI that reads through the documentation and especially reads through Stack Overflow and helps you find the solution you’re looking for. Another example is Tailwind, which has paid quite a price for being successful. Because AI is an averaging thing that gives you something everyone else uses, it started suggesting Tailwind, and people stopped reading the documentation, which collapsed their premium model. They ended up letting a lot of people go and were ultimately acquired by Shopify.

LLMs Acting as Locusts Drive Paywalled Content

Sean: Stack Overflow and Tailwind are examples of locust behavior by the AI firms. Somebody has carefully assembled this bounty. They’ve got this thing ready to harvest, and then the locusts come in and eat everything. The problem is the LLMs can take advantage of the Tailwind documentation as of January 1, 2026. But come January 1, 2028, if Tailwind’s out of business, there’s nothing for the LLMs to harvest. Same thing with Stack Overflow, if it’s been a condensation point for people sharing expertise and it crashes, then the answers age out.

Google actually had a positive effect because it allowed you to find answer but it brought traffic to people who had built up these useful documents. The LLMs disintermediate all that. So I get a smart answer from an LLM and I don’t know, and have no easy way to find out, that it was actually written by Charlie Jones. The LLM paraphrased five paragraphs from his a document without crediting him, so I never learned who Charlie is. Charlie gets no traffic on his website aside from an AI robot, and he goes, “I have to give this up.

Jeff: They need to keep going because the AI agents need them to keep learning.

Sean: The problem is, all the AI agents are doing is really an averaging function of information already assembled. It’s reading textual content. When Google did that, they would bring people back to those websites. Tailwind benefited from making some of their documentation available because people would go, “Oh, wow, this is really good. I should pay for this when they bring the new stuff out.” But if the LLM harvests that and doesn’t tell me it’s Tailwind, then Tailwind gets no money. They’re intercepting the request and masking who is coming. So it destroys the incentive for people to assemble the knowledge bases. It’s bankrupting Tailwind as an example. Stack Overflow, same thing. Their traffic has crashed.

Jeff: What does this do to product development?

Sean: So I either have to have the scope and size of a firm like IBM, where I have the resources to manage internal documentation, but it chokes off the publicly curated content because the LLMs are snatching all of it instead of pointing to it the way that Google or Bing does. The LLMs are disintermediating them, starving them. The problem is it’s taking away the incentive for experts to contribute and collaborate because I get no reputational value. AI is only as smart as the people who write the content or provide the insights. It’s not independent. The artists are seeing the same thing. If an LLM vacuums up 10 years of an artist’s output and can duplicate their style, who will hire the artist?

Artists Rev 1.0 vs. Artist Rev 2.0

Jeff: But that’s artist Rev 1.0. What if the artist is Rev 2.0 and leveraging AI?

Sean: It depends on the AI; if it uses everything Artist 2.0 enters and creates, then they are screwed. The artist needs to find a way to do private work that can’t be spidered while still getting the word out about their capabilities. Innovation slows down in the communities of practice where AI is curating the content if it’s fed back into a public information repository without attribution. Even if it is provided with attribution, it’s included in the subscription, and neither the artist nor the expert is paid for their work product.

Jeff: I’m trying to get to what it’s going to do for overall product development. If I’m using old models, like three or four years old, to develop a product, then my product is not as efficient or as productive as it could be if those models were kept up to date. But they’re not being kept up to date because they are ripping firms off.

Sean: It’s a spike forward, and then things slow down.

What’s a CEO to Do?

Jeff: So if I am the CEO of a company, what’s my 5-10 year plan? Will I be less innovative in five years?

Sean: You have to build your own internal repositories for private sharing of what’s been learned. That rewards larger firms because they have more people contributing. And I am going to learn from the Tailwind experience and find a way to prevent my content getting shared outside of my control or pick a different business model.

Jeff: So in this new world I need one software guy for a few test guys and some other experts. There may be one software engineer for 10 other experts.

Norbert: think we’re compensating for that by having agents write your documentation. But what keeps it from hallucinating in a loop and giving nonsensical information? The problem is, especially after those years when no one’s inclined to write those explanatory blog posts or creative work and put it online, AI will be feeding on itself and starting to degenerate.

Jeff: That’s a big issue. It’s great right now, and engineering productivity is going up, but at some point it’s going to flatten and then go down.

Sean: I think you’re going to see different business models for things like Tailwind, archives, and other things where they’re going to put everything behind paywalls.

Jeff: So it will be available but I will have to pay; it’s going to affect my costs.

Sean: So your custom agent will pay for access to content behind the paywall. That’s OK for certain kinds of projects, but for people contributing for reputational value, if they keep getting disintermediated, they’ll stop contributing.

Jeff: I think it’s important to talk about this, Norbert. A lot of things are getting broken to enable the productivity LLMs offer. And the damage is undermining the productivity LLMs can offer, so it’s not sustainable long-term.

Where AI Defied Expectations

Norbert: Looking back, how has AI defied your expectations?

Jeff: It’s going to work and it’s going to be fine. But I think we need to take an approach of planning around it: what it is, what it isn’t, and what it needs to be. I think the smart companies are going to start to invest in how to bring this into their organization rather than just having each software guy go out and pay ChatGPT 20 bucks out of their pocket to make their coding better. It’s going to take a while. Companies don’t change very quickly. It takes a while to get change into the environment. The guys that just run into this stuff and say, “Hey, this is going to work,” are going to have an awakening that things were not like they thought they were going to be. I do think this is going to find its way and it’s going to work. I worry about a lot of different things. I worry about innovation. I worry about just accepting stuff and saying, “Hey, that’s as good as it could ever be.” It has to come through good engineering practice and good engineering culture. Engineers develop stuff. They get onto projects, and sometimes 50% of what they’re trying to do, they haven’t even invented yet. They’re saying, “I know I can. We can. We’ve done it before. We will be innovative.” They just don’t know what it is yet, and I think AI can help that, but AI cannot replace that. Companies like Nvidia are probably doing this now, saying, “Hey, AI can help you be innovative, but you’re the innovator, not the engine itself.” So hopefully, if we get to that, I’ll be happy.

Lessons From Past Technology Transitions

Sean: When I was in college, which I admit was a long time ago, all the smartest guys in computer science were excited about AI. I was excited about AI. Within five years of graduation, I was working in semiconductors, and the guys that had gone into the AI startups were looking for work. The AI startups had cratered in what was called “AI Winter” because they couldn’t deliver on the promises they had made. So I have been dubious about AI ever since, especially after a second AI Winter a decade later.

I have been surprised to see Waymo cars driving around downtown Mountain View, because I thought it would take until 2040 or 2050. It was a shocker. There’s an analogy to the introduction of the printing press, which changed the role of scribes who were copying manuscripts. The Bible was mass-produced, and other books followed. But there were several decades of chaos because it took a while to figure out the business models.

Journalism is going through something similar now. The Internet has upended the established newspaper models and, to a certain extent, television journalism models. I think we’re in a period where the old rules are clearly fracturing, and we haven’t figured out the new rules. I don’t think that’s going to be a rapid transition or an easy one. Ultimately, I think it will get better. I’m not a doomer.

I think AI labs are using too many scare tactics. AI is not going to take your job next week. It’s used too often as an excuse for layoffs that are really due to bad management or poor decisions.

Adding Tokens Effectively is Like Adding Horsepower

Sean: I recently read Firestone’s biography, and I really enjoyed his perspective on business. As they moved from a workshop model that was entirely manual to introducing automation and evolving into a factory model, he realized they needed to increase the horsepower available to each worker. As they designed special tools and material flows that added more horsepower to a worker’s job, he became more productive. They could pay him more, and over time they walked that curve: adding horsepower, increasing productivity, increasing wages. It didn’t take away the need for skill; in fact, it required new skills.

I started work in 1981, in an office where we had time-sharing terminals on people’s desks that connected to a central computer that’s probably less powerful than a microprocessor used in a garage door opener. Over time, I have had a PC, then workstations, then PCs more powerful than workstations, all networked to many computers. We continue to provide more computing power to people, and AI builds on the microprocessor trend that started in the mid-70s.

I don’t know that that means we get rid of people as much as redefine jobs. Firestone realized he needed people to master an evolving set of skills. Applying more horsepower didn’t mean taking away human judgment. I think we’re in the first blush of optimism that we can capture all the rules people know, and then we’ll just have one guy press a button and get an entire new copy of Microsoft Word. I think it’s more complicated than that.

Another Tool In the Toolkit for Engineers

Jeff: I’m with you, Sean. I think it’s another tool in the toolkit, and we just need to iron out the business model. I think the business model is like a funnel. It’s all over the place right now, and it will converge over time based on what we understand, what we get good at, and what we fail at.

Companies that run lots of experiments quickly, fail quickly, and iterate on that are going to come through this just fine. It’s going to take a while with anything this new. Again, I’ll come back to engineers developing products, and we’re not going to get away from that as an executive for a while. I just wanted to enable engineers to give them the best chance they ever had to develop the best product they could come up with. If these AI tools enable that for individuals, have at it, because that’s the way it should be, and not the other way around. Don’t take the individuals out of the equation—they’re the center of the equation—and surround them with the ability to be more productive and innovative, and then you will always win.

Nobert: If you try to replace them, you’re going to lose. This has been great. Thank you very much.

M	T	W	T	F	S	S
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30

Can You Keep Up With AI?