Two AI Conferences. One Speckled Takeaway

1. After the Shift Think Tank, you said that practically every software team is experimenting with LLMs, but nobody is letting agents work independently on production code. Where is the actual boundary today between what AI can do and what software teams are willing to let it do?

There is no clear boundary, nor can there really be one. Software has become far too diverse a field for us to take some grand statement from some grand CEO of some grand company and automatically apply it to our own cubicle. Every team and project is different, and realistically, so is every activity within a project.

The problem is that teams are drawing this boundary amid a noisy hype cycle. People listen to panelists promising superintelligences that will autonomously cure cancer, generate software on the fly, or run entire sales pipelines. Then they turn up for work on Monday and discover a bigger pile of laundry than the week before. 

One response to this AI psychosis is control, where developers use LLMs but maintain a white-knuckle grip on their code. Another is looser experimentation, where some let models deeper into their projects and see where things break. The third is shrugging and carrying on as before. And since software is hardly a uniform field, all three reactions should be understandable.

So, there’s no reason to expect LLMs to have a homogeneous impact across the industry. What concerns me more is that some newer teams will overindex on LLMs as a technology and overlook the fundamental work of software development: building a theory of the system, then spending years maintaining, extending, and defending that same theory against whatever changes the outside world throws at it.

Neuralab, for example, started in 2008, and since then we’ve delivered more than 200 complex web and eCommerce projects. Our particular stack, tooling, development and DevOps processes certainly played important roles in their success. But more often, the decisive factors were understanding the problem, designing the overall solution, managing data flows, interface copywriting, integrations with ERP, CRM, and omnichannel modules, long-term code maintainability, and a mountain of tiny engineering decisions that will never show up in a benchmark.

That’s why I find this boundary far more useful: How much can you hand over to an LLM while still understanding and verifying the system, and taking responsibility for whatever ends up in production? At the end of the day, the market doesn’t ask whether you’re using Claude or Codex, Vue or React, PHP or .NET. It asks whether you can deliver something and stand behind it.

2. You’ve argued that today’s AI productivity metrics, such as the number of shipped features, lines of code, or tokens consumed, are largely meaningless. So how can we actually tell whether AI has made a software team more productive?

The trouble is that these metrics were terrible even before AI came along, which is one of my favorite pieces of evidence that we’re living through collective amnesia as well as an AI hype cycle. Software production has always been remarkably good at measuring output: lines of code, commits, pull requests, or resolved bugs. Measuring what that same work actually did for user experience, application stickiness, revenue, or costs has always been much harder.

One of the main reasons is the attribution of success. If a team ships a feature that people genuinely find useful, you first need to somehow measure its impact on the overall business. Then comes the even trickier question of who deserves the credit. The designer who came up with the interaction? The PM who pushed the idea forward? The copywriter who made the interface understandable? Or the developer who engineered and implemented the whole thing?

Attribution is partly a political decision within the team, so it’s much easier to cling to something that can be conveniently counted. Yesterday it was lines of code. Today it’s burned tokens, commits, or the number of synthesized changes.

Collective amnesia becomes even more dangerous when we forget that 60 to 80% of IT activities go toward maintaining, improving, and extending existing systems. And this is where the whole “more is better” logic becomes particularly stupid. Every new feature, dependency, or additional thousand lines of code becomes something that somebody will eventually have to understand, test, maintain, and one day remove. Alan Cooper famously argued that code is a liability rather than an asset to an organization, and I suspect the IT industry will spend the next few years rediscovering what that actually means.

That’s why I find the recent Bend2 case interesting. Its creator, Victor Taelin, explicitly asked contributors to start submitting changes that reduce the number of lines of code rather than increase it. Zig and Godot offer another perspective, with projects restricting or outright banning LLM-generated contributions. Together with Bend2, they illustrate something connected to your first question: the industry isn’t going to converge on one universal AI practice. Some projects will aggressively embrace models, while others will deliberately keep them out of certain parts of the work.

3. You mentioned “speckled intelligence”, the idea that what works for one team or task might not work for another. Is this unpredictability the biggest obstacle to broader, systematic AI adoption in software development?

“Speckled intelligence”, or pjegava inteligencija in Croatian, is a concept that draws heavily on something economist Frank Knight explored: the distinction between measurable risk and true uncertainty. I use that distinction to separate complicated tasks from complex ones.

The complicated parts of our work can, in principle, be modeled, and their risks estimated. They may be brutally difficult, but the rules exist and are stable enough for us to optimize or automate them. Complex tasks, on the other hand, depend on shared interpretations, politics, timing, the environment, and a broader context that refuses to sit still. The consequence is that only certain speckles and patches of our work can be automated or accelerated. Over the last few decades, most white-collar activities have developed this complex little belly, and in the book I argue that it will only get bigger.

There are plenty of AI influencers, prompt peddlers, and vibe-coding workshop hosts who would insist that any failure or slowness in LLM adoption is simply a “skill issue”. Part of my thesis in the book is that the fundamental problem isn’t the people, but the models themselves. Artificial neural networks are, de facto, approximators of recorded history. They operate on the recorded and represented portions of your team, while complex, uncertain work constantly produces new environments that remain invisible in those records. That’s the moment when an agent automates half your inbox, while the other half, which it either cannot or must not touch, turns out to be precisely where the real value of your work sits.

AI boosters will naturally tell you that we need bigger datasets, longer context windows, more generous skills, stronger harnesses, and MORE SCALE! But the problem with human uncertainty is that accumulating more data doesn’t automatically resolve a problem. Sometimes it simply increases the number of competing interpretations.

For instance, Jev, a new LLM model that outputs probabilities rather than words, was released the other day. And now everyone’s experimenting with how Jev could handle the classification of incoming and outgoing invoices. That’s all lovely, but the decision about whom to invoice, when, and how, or when and how to accept an incoming invoice, is fundamentally political rather than mathematical. You can certainly try to automate it, but that very automation can produce an unknown and potentially unlimited amount of damage.

None of this means that parts of a team’s activities cannot be automated, modeled, or handed over to agents. Of course they can. The point of speckled intelligence is that this effort will remain patchy, heterogeneous, uneven, and specific to each task and each team.

4. AI was supposed to simplify parts of our work, but you argue that it’s simultaneously creating a new problem: developers are reading longer PRs, PMs longer documents, and HR teams more and longer job applications. Have we reached a point where AI generates work faster than humans can properly process it?

The essence of white-collar work is that it isn’t a zero-sum game. New ideas and new work generate more ideas and more work. Say you’re specifying a new feature for an application. A designer reads it and immediately expands the concept with a fresh perspective. Then a developer comes along and spices up the whole thing with their own interpretation. By the time you’re done, the feature specification that started cooking inside your head might contain just 20% of the original meat. The other 80% only appeared once you put the idea on paper.

This was already a challenge before AI, but the bottleneck of human hands naturally kept it under control. Now that we have LLMs capable of spitting out convincing-sounding text, we’ve created the illusion that the bottleneck has disappeared. And that introduces a whole new downstream problem.

For instance, we’re increasingly receiving Request for Proposal documents from clients or stakeholders that used to be two or three pages long and are now proper little novellas. The problem is that these books often haven’t even been read or checked by the clients themselves. So they’re stuffed with contradictory statements, architectural decisions, and conclusions that the client doesn’t even know are there, let alone ones that should have been included in the first place.

There’s even a meme suggesting we’d all prefer our clients, bosses, mentors, or colleagues to simply forward the original prompt they used to generate the document. At least then we’d know what they were initially thinking.

So one thing we’ll have to figure out as an industry is that artificial intelligence is also becoming a matter of etiquette, and even a deeply embedded cultural issue. After all, we’ve spent the past 70 years turning AI into something resembling a digital god. And naturally, we now expect this new god to answer our little prompt-prayers of “please make the document better”.

Which brings me back to my earlier answer and speckled intelligence. Knowing when to use a language model, video generator, classifier, and so on will offer only a limited competitive advantage. The real advantage lies in design, engineering, original content, a deep understanding of the environment, and everything that sits outside the tools. That’s where the productive friction lives, the kind that actually improves the quality of what goes into the system in the first place.

5. AI is often presented as the main reason behind the current software industry crisis, but you’ve also connected it to post-COVID overhiring, layoffs, interest rates, inflation, and shrinking budgets. How much do we actually understand about AI’s impact on the software industry, and how much are we still trying to answer a question that’s too early for definitive conclusions?

We have growing evidence that AI accelerates certain parts of software production, although nowhere near as much as it accelerates code synthesis itself. One of this year’s NBER papers tracks more than 500,000 developers and reveals how productivity gains leak away across the software production pipeline. With the most advanced agents, the number of commits increases by roughly 240%, the number of projects by 80%, and actual releases by just 30%. When the researchers examined four major software marketplaces, they also found an increase in the number of new applications, but so far no corresponding growth in their overall usage.

So part of that initial AI productivity gain ends up creating additional work downstream. Faros Research, looking at a sample of 22,000 developers across 4,000 teams, finds that higher AI adoption is associated with increased throughput, but also more bugs, incidents, churn, and time spent on verification. In their latest Q3 report, the time a piece of work spends in QA increased by a staggering 300.6%.

Something similar happened in the gaming industry, roughly between 2013 and 2023. Unity, Unreal, asset stores, and various no-code tools made huge portions of game development cheaper. The number of annual Steam releases grew from a few hundred to around 9,000, while the number of quality games remained practically unchanged.

I know this is anecdotal, but during the Shift Think Tank, we repeatedly heard versions of the same problem. Developers were approaching their managers and saying they no longer wanted to manage a herd of agents. They wanted to go back to writing code.

And if the bottleneck of formalism is shifting toward verification and QA, why should developers spend their creativity and engineering judgment on that formal layer instead of the original act of creation? To me, the fundamental cause of this “agentic fatigue” is the severed connection between the creator and the artifact.

In the long run, it isn’t sustainable for people responsible for managing software to lose their connection with the formal contract that describes its explicit workings. I think these findings are the beginning of a much larger taste war over where we should retain formalism and where we should let it go.

Perhaps the most important number in the entire AI story comes from that same NBER paper. Their model estimates the elasticity of substitution between AI output and downstream human labor at just 0.23. This suggests that, in today’s software production pipeline, AI and human labor are far more complementary than easily interchangeable inputs. The faster we make code synthesis, the more review, integration, testing, and release become the relative bottlenecks.

That’s why I’m not entirely convinced we’ll end up with some monumental productivity leap in the classical “waterfall” sense of the word. I find it far more likely that we’ll build more powerful, tightly interconnected software, and, perhaps more importantly, software that otherwise would never have existed at all.

So to me, the question isn’t whether AI has made a particular software team more productive. It’s whether AI enables software teams to build better and genuinely new solutions that make life easier for people working in other industries.

---

A year ago, we asked whether the AI market was actually one big bubble that would have to burst sooner or later. A lot has changed since then, and now we get to check how right we were.

On November 3, Krešimir is launching his book Coding Is the Easier Part: Makers, Machines, and the Mess in Between, and to mark the occasion we’re getting the same crew from last year’s episode back together. This time it’s a live podcast recording in front of an audience at Holographic Space, which will also serve as the book’s launch event. We’ll revisit what we predicted back then, look at what has actually happened in the meantime, and try to answer the question of what comes next.

---

Shift Think Tank Photos by: Luka Gerlanc

AI & Automation Summit Photos by: AI Summit Media Crew

Original Netokracija Interview on Croatian: https://www.netokracija.com/kresimir-koncic-ai-kod-software-247379

Coding Is