The future of software development lies in the "dark factory" model, where AI agents autonomously build, test, and ship code based on human-written specifications, a stark contrast to the current industry reality where AI adoption often leads to slower development cycles due to unadapted workflows and organizational structures.
Mind Map
Click to expand
Click to explore the full interactive mind map • Zoom, pan, and navigate
90% of cloud code was written by claude
code. Codeex is releasing features
entirely written by codecs. And yet most
developers using AI empirically get
slower, at least at first. The gap
between these two facts is where the
future of software lives. Imagine
hearing this at work. Code must not be
written by humans. Code must not be even
reviewed by humans. Those are the first
two principles of a real production
software team called Strong DM and their
software factory. They're just three
engineers. No one writes code. No one
reviews code. The system is a set of AI
agents orchestrated by markdown
specification files. The system is
designed to take a specification, build
the software, test the software against
real behavior scenarios, and
independently ship it. All the humans do
is write the specs and evaluate the
outcomes. The machines do absolutely
everything in between. As I was saying,
meanwhile, 90% and yes, it's true. Over
at Anthropic, 90% of Claude Code's
codebase was written by Claude Code
itself. Boris Triny, who leads the
Claude Code project at Anthropic, hasn't
personally written code in months. And
Anthropic's leadership is now estimating
that functionally 100% the entirety of
code produced at the company is AI
generated. And yet at the same time, in
the same industry, with us here on the
same planet, a rigorous 2025 randomized
control trial by METR found that
experienced open-source developers using
AI tools took 19% longer to complete
tasks than developers working without
them. There is a mystery here. They're
not going faster, they're going slower.
And here's the part that should really
unsettle you. Those developers are bad
at estimation. They believed AI had made
them 24% faster. They were wrong not
just about the direction but about the
magnitude of the change. Three teams are
running lights out software factories.
The rest of the industry is getting
measurably slower. Just a few teams
around tech are running truly lights out
software factories. The rest of the
industry tends to get measurably slower
while convincing themselves and everyone
around them with press releases that
they're speeding up. The distance
between these two realities is the most
important gap in tech right now and
almost nobody is talking honestly about
it and what it takes to cross it. That
is what this video is about. Dan
Shapiro, the CEO over at Glow Forge and
the veteran of multiple companies built
on the boundary between software and
physical products, just published a
framework earlier this year in 2026 that
maps where the industry stands. He calls
it the five levels of vibe coding. And
the name is deliberately informal
because the underlying reality is what
matters. Level zero is what he calls
spicy autocomplete. You type the code,
the AI suggests the next line. You
accept or reject. This is GitHub copilot
in its original format. Just a faster
tab key. The human is really writing the
software here. And the AI is just
reducing the keystrokes and the effort
your fingers have. Level one is coding
intern. You hand the AI a discrete well
scoped task. You write the function. You
build the component. You refactor the
module. That's the task you give the AI.
You hand the AI a discrete and well
scoped task like write this function or
build this component or refactor this
module. You then review as the human
everything that comes back. The AI
handles the tasks. The human handles the
architecture, the judgment and the
integration. Do you see the pattern
here? Do you see how the human is
stepping back more and more through
these levels? Let's keep going. Level
two is the junior developer. The AI
handles multifile changes. It can
navigate a codebase. It can understand
dependencies. It can build features that
span modules. You're reviewing more
complicated output, but you as a human
are still reading all of the code.
Shapiro estimates that 90% of developers
who say they are AI native are operating
at this level. And I think from what
I've seen, he's right. Software
developers who operate here think
they're farther along than they are.
Let's move on. Level three, the
developer is now the manager. This is
where the relationship starts to flip.
This is where it gets interesting.
You're now not writing code and having
the AI help. You're simply directing the
AI and you're reviewing what it
produces. Your day is whether you want
to read, whether you want to approve,
whether you want to reject, but at the
feature level, at the PR level. The
model is doing the implementation. The
model is submitting PRs for your review.
You have to have the judgment. Almost
everybody tops out here right now. Most
developers, Shapiro says, hit that
ceiling at level three because they are
struggling with the psychological
difficulty of letting go of the code.
But there are more levels. And this is
where it gets spicy and exciting. Level
four is the developer as the product
manager. You write a specification, you
leave, you come back hours later and
check whether the tests pass. You're not
really reading the code anymore. You're
just evaluating the outcomes. The code
is a black box. you care whether it
works, but because you have written your
eval so completely, you don't have to
worry too much about how it's written if
it passes. This requires a level of
trust both in the system and in your
ability to write spec. And that quality
of spec writing almost nobody has
developed well yet. Level five, the dark
factory. This is effectively a black box
that turns specs into software. It is
where the industry is going. No human
writes the code. No human even reviews
the code. The factory runs autonomously
with the lights off. Specification goes
in, working software comes out. And you
know, Shapiro is correct. Almost nobody
on the planet operates at this level.
The rest of the industry is mostly
between level one and level three, and
most of them are treating AI kind of
like a junior developer. I like this
framework because it gives us really
honest language for a conversation
that's been drowning in hype. When a
vendor tells you their tool writes code
for you, they often mean level one. When
a startup says they're doing agentic
software development, they often mean
level two or three. But when strong DM
says their code must not be written by
humans, they really do mean level five,
the dark factory, and they actually
operate there. The gap between marketing
language and operating reality is
enormous. and collapsing that gap into
what is actually going on on the ground
requires changes that go way beyond
picking a better AI tool. So many people
look at this problem and think this is a
tool problem. It's not a tool problem.
It's a people problem. So what does
level five software development actually
look like? I think strong DM software
factory is the most thoroughly
documented example of level five in
production. Simon Willis, one of the
most careful and credible observers in
the developer tooling space, calls
StrongDm Software Factory, quote, "The
most ambitious form of AI assisted
software development that I've seen
yet." The details are really worth
digging into here because they reveal
what it looks like to run a dark factory
for software on today's agents. And as
we have this discussion, I want you to
keep in mind that for most of us
listening, we are getting to time
travel. We are seeing how a bold vision
for the future can be translated into
reality with today's agents and today's
agent harnesses. It is only going to get
easier as we go into 2026 which is one
of the reasons I think this is going to
be a massive center of gravity for
future agentic software development
practices. We are all going to level
five. So what does strong DM do? The
team is three people. Justin McCarthy,
CTO, Jay Taylor, and Nan Chowan. They've
been running the factory since July of
last year, actually. And the inflection
point they identify is Claude 3.5
Sonnet, which shipped actually in the
fall of 2024. That's when long horizon
agentic coding started compounding
correctness more than compounding
errors. Give them credit for thinking
ahead. Almost no one was thinking in
terms of dark factories that far back.
But they found that 3.5 sonnet could
sustain coherent work across sessions
long enough that the output was reliable
and it wasn't just a flash in the pan.
It wasn't just demo worthy and so they
built around it. The factory runs on an
open-source coding agent called
attractor. The repo is just three
markdown specification files and that's
it. That's the agent. The specifications
describe what the software should do.
The agent reads them. It writes the code
and it tests it. And here's where it
gets really interesting and where most
people's mental model really starts to
break down. Strong DM doesn't actually
use traditional software tests. They use
what they call scenarios. And the
distinction is important. Tests
typically live inside the codebase. The
AI agent can read them, which means the
AI agent can intentionally or not
optimize for passing the tests rather
than building correct software. It's the
same problem as teaching to the test in
education. You can get perfect scores
and shallow understanding. Scenarios are
different. Scenarios live outside the
codebase. They're behavioral
specifications that describe what the
software should do from an external
perspective, stored separately so the
agent cannot see them during
development. They function as a holdout
set. The same concept that machine
learning users use to prevent
overfitting. The agent builds the
software and the scenarios evaluate
whether the software actually works. The
agent never sees the evaluation
criteria. It can't game the system. This
is really a new idea in software
development and I don't see it
implemented very frequently yet. But it
solves a problem that nobody was
thinking about when all the code was
written by humans. When humans write
code, we don't tend to worry about the
developer gaming their own test suite
unless incentives are really, really
skewed at that organization and then you
have bigger problems. When AI writes the
code, optimizing for test passage is the
default behavior unless you deliberately
architect around it. And it's one of the
most important differences to really
understand as you start to think about
AI as a code builder. Strongdm
architected around that with external
scenarios. The other major piece of the
architecture is what StrongDM calls
their digital twin universe. Behavioral
clones of every external service the
software interacts with. a simulated
octa, a simulated Jira, a simulated
Slack, Google Docs, Google Drive, Google
Sheets. The AI agents develop against
these digital twins, which means they
can run full integration testing
scenarios without ever touching real
production systems, real APIs, or real
data. It's a complete simulated
environment purpose-built for autonomous
software development. And the output is
real. CXDB, their AI context store, has
16,000 lines of Rust, nine and a half
thousand lines of Go, and 700 lines of
TypeScript. It's shipped, it's in
production, it works, it's real
software, and it's built by agents end
to end. And then the metric that tells
you how seriously they take it. They say
if you haven't spent $1,000 per human
engineer, your software factory has room
for improvement. I think they're right.
That's not a joke. $1,000 per engineer
per day enables AI agents to run at a
volume that makes the cost of compute
meaningful if you are giving them a
mission to build software that has real
scale and real utility in production use
cases and it's often still cheaper than
the humans they're replacing. Let's hop
over and look at what the hyperscalers
are doing. The self-referential loop has
taken hold at both anthropic and open
AAI and it's stranger than the hype
might make it sound. Codex 5.3 is the
first frontier AI model that was
instrumental in creating itself. And
that's not a metaphor. Earlier builds of
Codeex would analyze training logs,
would flag failing tests, and might
suggest fixes to training scripts. But
this model shipped as a direct product
of its own predecessors coding labor.
OpenAI reported a 25% speed improvement
and 93% fewer wasted tokens in the
effort to build Codeex 5.3. And those
improvements came in part from the model
identifying its own inefficiencies
during the build process. Isn't that
wild? Cloud code is doing something
similar. 90% of the code in Claude Code,
including the tool itself, was built by
Claude Code, and that number is rapidly
converging toward 100%.
Boris Churny isn't joking when he talks
about not writing code in the last few
months. He's simply saying his role has
shifted to specification, to direction,
to judgment. Anthropic is estimating all
of their company moving to entirely AI
generated code about now. Everyone at
Anthropic is architecting and the
machines are implementing. And the
downstream numbers tell the same story.
When I made a video on co-work and
talked about how it was written in 10
days by four engineers, what I want you
to remember is it wasn't just four
engineers hyperting so that they could
get that out super fast and write every
line by hand. No, no, no. They were
directing machines to build the code for
co-work. And that's why it was so fast.
4% of public commits on GitHub are now
directly authored by Claude Code, a
number that Anthropic thinks will exceed
20% by the end of this year. I think
they're probably right. Claude Code by
itself has hit a billion dollar run rate
just 6 months since launch. This is all
real today in February of 2026. The
tools are building themselves. They're
improving themselves. is they're
enabling us to go faster at improving
themselves and that means the next
generation is going to be faster and
better than it would have been otherwise
and we're going to keep compounding. The
feedback loop on AI has closed and the
question is not whether we're going to
start using AI to improve AI. The
question is how fast that loop is going
to accelerate and what it means for the
40 or 50 million of us around the world
who currently build software for a
living. This is true for vendors as much
as it's true for software developers.
And I don't think we talk about that
enough because the gap between what's
possible at the frontier in February of
2026 and what tends to happen in
practice and what vendors want to sell
has never been wider. That MER study, a
randomized control trial, by the way,
not a survey, found that open source
developers using AI coding tools
completed their task 19% slower. We
talked about that, right? The
researchers controlled for task
difficulty. They controlled for
developer experience. They controlled
even for tool familiarity and none of it
mattered. AI made even experienced
developers slower. Why? In a world where
co-work can ship that fast. Why? Because
the workflow disruption outweighed the
generation speed. Developers spent time
evaluating AI suggestions, correcting
almost right code, context switching
between their own mental model and the
model's output, and debugging really
subtle errors introduced by generated
code that looked correct but weren't.
46% of developers in broader surveys say
they don't fully trust AI generated
code. These guys aren't lites, right?
This is experienced engineers running
into a consistent problem. The AI is
fast, but it struggles with the
reliability to trust without what they
view as vital human review. And this
irony is the J curve that adoption
researchers keep identifying. When you
bolt an AI coding assistant onto an
existing workflow, productivity dips
before it gets better. It goes down like
the bottom of a J. Sometimes for a
while, sometimes for months. And the dip
happens because the tool changes the
workflow, but the workflow has not been
redesigned around the tool explicitly.
And so you're kind of running a new
engine on old transmission. The gears
are going to grind. Most organizations
are sitting in the bottom of that J
curve right now. And many of them are
interpreting the dip as evidence that AI
tools don't work, that the vendors did
not tell them the truth, and that the
evidence that their workflows haven't
adapted is really evidence that AI is
hype and not real. I think GitHub
Copilot might be the clearest
illustration of this. It has 20 million
users, 42% market share among AI coding
tools, apparently. Uh, and lab studies
show 55% faster code completion on
isolated tasks. I'm sure that makes the
people driving GitHub Copilot happy in
their slide decks. But in production,
the story is much more complicated.
There are larger poll requests. There
are higher review costs. There's more
security vulnerabilities introduced by
generated code. And developers are
wrestling with how to do it well. One
senior engineer put it really sharply.
C-Ilot makes writing code cheaper but
owning it more expensive. And that is
actually a very common sentiment I've
heard across a lot of engineers in the
industry. not just for co-pilot but for
AI generated code in general. The
organizations that are seeing
significant call it 25 30% or more
productivity gains with AI are not the
ones that just installed co-pilot had a
one-day seminar and called it done.
They're the ones that thought carefully
went back to the whiteboard and
redesigned their entire development
workflow around AI capabilities.
changing how they write their specs,
changing how they review their code,
changing what they expect from junior
versus senior engineers, changing their
CI/CD pipelines to catch the new
category of errors that AI generated
code introduces. End to end process
transformation. It's not about tool
adoption. And end toend transformation
is hard. It's sometimes it's politically
contentious. It's expensive. It's slow
and most companies don't have the
stomach for it. Which is why most
companies are stuck at the bottom of the
J curve. Which is why the gap between
frontier teams and everyone else is not
just widening, it's accelerating
rapidly. Because those teams on the edge
that are running dark factories, they
are positioned to gain the most. As
tools like Opus 4.6 and Codeex 5.3
enable widespread agentic powers for
every software engineer on the planet.
95% of those software engineers don't
know what to do with that. It's the ones
that are actually operating at level
four, level five that truly get the
multiplicative value of these tools. So
if this is a politically contentious
problem, if this is not just a tool
problem but a people problem, we need to
look at the nature of our software
organizations. Most software
organizations were designed to
facilitate people building software.
every process, every ceremony, every
role. They exist because humans building
software in teams need coordination
structures. Stand-up meetings exist
because developers working on the same
codebase, they got to synchronize every
single day. Sprint planning exists
because humans can only hold a certain
number of tasks in working memory and
then they need a regular cadence to rep
prioritize. Code review exists because
humans make mistakes that other humans
can catch. QA teams exist because the
people who build software, they can't
evaluate it objectively. You get the
idea. Every one of these structures is a
response to a human limitation. And when
the human is no longer the one writing
the code, the structures, they're not
optional, they're friction. So what does
sprint planning look like when the
implementation happens in hours, not
weeks? What does code review look like
when no human wrote the code and no
human can really review the diff that AI
produced in 20 minutes because it's
going to produce another one in 20 more
minutes. So what does a QA team do when
the AI already tested against scenarios
it was never shown? Strong BM's
threeperson team doesn't have sprints.
They don't have standups. They don't
have a Jiraa board. They write specs and
they evaluate outcomes. That is it.
The entire coordination layer that
constitutes the operating system of a
modern software organization. The layer
that most managers spend 60% of their
time maintaining is just deleted. It
does not exist. Not because it was
eliminated as a cost-saving measure, but
because it no longer serves a purpose.
This is the structural shift that's
harder to see than the tech shift, and
it might matter more. The question is
becoming what happens to the
organizational structures that were
built for a world where humans write
code? What happens to the engineering
manager whose primary value is
coordination? What happens to the scrum
master, the release manager, the
technical program manager whose job is
to make sure a dozen teams ship on time?
Look, those roles don't disappear
overnight, but the center of gravity is
shifting. The engineering manager's
value is moving from coordinate the team
building the feature to define the
specification clearly enough that agents
build the feature. The program manager's
value is moving from track dependencies
between human teams to architect the
pipeline of specs that flow through the
factory. The skills that matter are
shifting very rapidly from coordination
to articulation. From making sure people
are rowing in the same direction to
making sure the direction is described
precisely enough that machines can go do
it. And oh, by the way, for engineering
managers, there's an extra challenge.
How do you coach your engineers to do
the same thing? It's a people challenge.
If you think this is a trivial shift,
you have never tried to write a
specification detailed enough for an AI
agent to implement it correctly without
human intervention. And you've certainly
never sat down and tried to coach an
engineer to do the same. It is a
different skill. It requires the kind of
rigorous systems thinking that most
organizations have never needed from
most of their people because the humans
on the other end of the spec could fill
in the gaps with judgment, with context,
with a slack message that says, "Did you
mean X or Y?" The machines don't have
that layer of human context. They build
what you described. If what you
described was ambiguous, you're going to
get software that fills in the gaps with
software guesses, not customer- ccentric
guesses. The bottleneck has moved from
implementation speed to spec quality.
And spec quality is a function of how
deeply you understand the system, your
customer, and your problem. That kind of
understanding has always been the
scarcest resource in software
engineering. The dark factory doesn't
reduce the demand for that. It just
makes the demand an absolute law. It
becomes the only thing that matters.
Now, let's be honest. Everything that I
have just talked about assumes you're
building from scratch. Most of the
software economy is not built from
scratch. The vast majority of enterprise
software is brownfield. It's existing
systems. It's accumulated over years,
over decades. It's running in
production, serving real users, carrying
real revenue. CRUD applications that
process business transactions. Monoliths
that have grown organically through 15
years of feature additions. CI/CD
pipelines tuned to the quirks of a
specific codebase and a specific team's
workflow. Config management that exists
in the heads of the three people who've
been at the company long enough to
remember why that one environment
variable is set to that one value. You
know who you are. You cannot dark
factory your way through a legacy
system. You cannot just pretend that you
can bolt that on. It doesn't work that
way. The specification for that does not
exist. The tests, if they're any, cover
30% of your existing codebase, and the
other 70% runs on institutional
knowledge and tribal lore and someone
who shows up once a week in a polo shirt
and knows where all the skeletons are
buried in the code. The system is the
specification. It's the only complete
description of what the software does
because no one ever wrote down the
thousand implicit decisions that
accumulated over a decade or more of
patches of hot fixes of temporary
workarounds that of course became
permanent. This is the truth about the
interstitial states that lie along this
continuum toward more autonomous
software development. For most
organizations, the path is not to start
with deploy an agent that writes code.
It starts with let's develop a
specification for what your real
existing software really actually does.
And that specification work that reverse
engineering of the implicit knowledge
embedded in a running system is very
difficult and it's deeply human work. It
requires the engineer who knows why the
billing module has the one edge case for
Canadian customers. It requires the
architect who remembers which micros
service it was that carved out of the
monolith under duress during the 2021
outage and we've always maintained it
ever since. It requires the product
person who can explain what the software
actually does for real users versus what
the PRD says it does. Domain expertise,
ruthless honesty, customer
understanding, systems thinking. exactly
the human capabilities that matter even
more in the dark factory era, not less.
Look, the migration path is different
for every business, but it starts to
look something like this. First, you use
your AI as much as you can at say level
two or level three to accelerate the
work your developers are already doing,
writing new features, fixing bugs,
refactoring modules. This is where most
organizations are at now and it's where
the J-Curve productivity dip and it's
where the J-Curve productivity dip
happened. You should expect that.
Second, you start using AI to document
what your system really does, generating
specs directly from the code, building
scenario suites that capture real
existing behavior, creating the holdout
sets that a future dark factory will
need. Then you redesign your CI/CD
pipeline to handle AI generated code at
volume. different testing strategies,
different review processes, different
deployment gates. Fourth, you start to
begin to shift new development to level
four or five autonomous agent patterns
while maintaining the legacy system in
parallel. That path takes time. Anyone
telling you otherwise is selling you
something. The organizations that will
get there the fastest aren't necessarily
the ones that bought the fanciest vendor
tools. They're the ones who can write
the best and most honest specs about
their code, who have the deepest domain
understanding, who have the discipline
to invest in the boring, unglamorous
work of documenting what their systems
really do and of how they can support
their people to scale up in the ways
that will support this new dark factory
era. I cannot give you a clear timeline
here. For some organizations, this is
looking like a multi-year transition,
and I don't want to hide the ball on
that. Some are going faster and it's
looking like multimonth. It will depend,
frankly, on the stomach you have for
organizational pain. And that brings me
to the talent reckoning. Junior
developer employment is dropping 9 to
10% within six quarters of widespread AI
coding tool adoption, according to a
2025 Harvard study. Anyone out there at
the start of their career is nodding
along and saying it's actually worse
than that. In the UK, graduate tech
roles fell 46% in 2024 with a further
53% drop projected by 2026. In the US,
junior developer job postings have
declined by 67%.
Simply put, the junior developer
pipeline is starting to collapse, and
the implications go far beyond the
people who cannot find entry-level jobs,
although that is bad enough and it's a
real issue. The career ladder in
software engineering has always worked
like this. Juniors learn by doing. They
write simple features. They fix small
bugs. They absorb the codebase through
immersion. Seniors review the work and
mentor them and catch their mistakes.
Over 5 to seven years, a junior becomes
a senior through accumulated experience.
The system is frankly an apprenticeship
model wearing enterprise clothing. AI
breaks that model at the bottom. If AI
handles the simple features and the
small bug fixes, the work that juniors
lean on, where do the juniors learn? If
AI reviews code faster and more
thoroughly than a senior engineer doing
a PR review, where does the mentorship
start to happen? The career ladder is
getting hollowed out from underneath.
Seniors at the top, AI at the bottom,
and a thinning middle where learning
used to happen. So, the pipeline is
starting to break. And yet, we need more
excellent engineers than we have ever
needed before, not fewer engineers. I've
said this before. I do not believe in
the death of software engineering. We
need better engineers. The bar is rising
and it's rising toward exactly the
skills that have always been the hardest
to develop and the hardest to hire for.
The junior of 2026 needs the systems
design understanding that was expected
of a mid-level engineer in 2020. Not
because the entry-level work necessarily
got harder, but because the entry-level
work got automated and the remaining
work requires deeper judgment. And you
don't need someone who can write a CRUD
endpoint anymore. Right? The AI will
handle that in a few minutes. You need
someone who can look at a system
architecture and identify where it will
break under load, where the security
model has gaps, where the user
experience falls apart at the edge
cases, and where the business logic
encodes assumptions that are about to
become wrong. And if you think as a
junior that you can use AI to patch
those gaps, I've got news for you. The
seniors are using AI to do that and they
have the intuition over the top. So you
need systems thinking, you need customer
intuition. You need the ability to hold
a whole product in your head and reason
about how those pieces interact. You
need the ability to write a
specification clearly enough that an
autonomous agent can implement it
correctly, which requires understanding
the problem deeply enough to anticipate
the questions the agent does not know to
ask. Those skills have always separated
really great engineers from merely
adequate ones. The difference now is
that adequate is no longer a viable
career position regardless of seniority
because adequate is what the models do.
Enthropics hiring has already shifted.
Open AAI's hiring has already shifted.
Hiring is shifting across the industry
and it's shifting toward generalists
over specialists. People who can think
across domains rather than people who
are expert in one really narrow tech
stack. The logic is super
straightforward, right? When the AI
handles the implementation, the human's
value is in understanding the problem
space broadly enough to direct
implementation correctly. A specialist
who knows everything about Kubernetes
but can't reason about the product
implications of an architectural
decision is way way less valuable than a
generalist who understands the systems,
the users, and the business constraints
even if they can't handconfigure a pot.
Some orgs are moving toward what amounts
to a medical residency model for their
junior engineers. Simulated environments
where early career developers learn by
working alongside AI systems, reviewing
AI output, and developing judgment about
what's correct and what's subtly wrong
by working with AI. It is not the same
thing as learning by writing code from
scratch. I don't want to pretend it is,
but it might be better training for a
world where the job is directing and
evaluating AI output rather than
producing code from a blank editor. I
will also call out, as I've called out
before, there are organizations
preferentially hiring juniors right now,
despite the pipeline collapsing
precisely because the juniors they are
looking for provide an AI native
injection of fresh blood into an
engineering org where most of the
developers started their careers long
before chat GPT launched in 2022. In
that world, having people who are AI
native from the get-go can be a huge
accelerating factor. And that points to
one of the things that is a plus for
juniors coming in. Lean into the AI if
you're a junior. Lean into your
generalist capabilities. Lean into how
quickly you can learn. Show that you can
pick up a problem set and solve it in a
few minutes with AI across a really wide
range of use cases. Gartner is
projecting that 80% of software
engineers will need to upskill in AI
assisted dev tools by 2027. Estimating
wrong. it's going to be 100%. The number
is not the point. The question isn't
whether the skills need to change. We
all know they will. It's whether we in
the industry can develop the training
infrastructure quickly enough to keep
pace with the capability change. Because
I've got to be honest with you, if
you're a software engineer and the last
model you touched was released in
January of 2026, you are out of date.
You need a February model. And that is
going to keep being true all the way
through this year and into next year.
And whether the organizations that
depend on software can tolerate a period
where the talent pipeline is being built
and rebuilt like this on a monthly basis
is a big question because you have to
invest in your people more to get them
through this period of transition. So
what does the shape of a new org look
like when we look at AI native startups?
How are they different from these
traditional orgs? cursor. The AI native
code editor is past half a billion
dollars in annual recurring revenue and
it has at last count a couple of dozen
few dozen employees. It's operating at
roughly three and a half million in
revenue per employee in a world where
the average SAS company is generating
$600,000 per employee. Midjourney is
similar. They have the story of
generating half a billion in revenue
with a few dozen people around a hundred
a little bit more depending on who's
counting. Lovable is well into the
multiundred million dollars in ARR in
just a few months and their team is
scaling but it's way way behind the
amount of revenue gain they're
experiencing. They are also seeing that
multi-million dollar revenue per
employee world. The top 10 AI native
startups are averaging three and change
million in revenue per employee which is
between five and six times the SAS
average. This is happening enough that
it is not an outlier. This is the
template for an AI native org. So what
does that org look like? If you have 15
million people generating a hund00
million a year, which we've seen in
multiple cases in 2025, what does that
look like? It does not look like a
traditional software company. It does
not have a traditional engineering team,
a traditional product team, a QA team, a
DevOps team. It looks like a small group
of people who are exceptionally good at
understanding what users need, who are
exceptional at translating that into
clear spec, and who are directing AI
systems that handle that implementation.
The org chart is flattening radically.
The layers of coordination that exist to
manage hundreds of engineers building a
product can be deleted when the
engineering is done by agents. The
middle management layer is going to
either evolve into something
fundamentally different at these big
companies or it's going to cease to
exist entirely. The only people who
remain are the ones whose judgment
cannot be automated. The ones who know
what to build for whom and why, and who
have excellent AI sense. Sort of like
horse sense where you have a sense of
the horse if you're a rider and you can
direct the horse where you want to go.
You'll need people who have that sense
with artificial intelligence. And yes,
it is a learned skill. The restructuring
that is going to happen as more and more
companies move toward that cursor model
of operating, even if they never
completely get there, that restructuring
is real. It's going to happen. It's
going to be very painful for specific
people in specific roles. the middle
management layer, the junior developer
whose entry-level work is getting
automated first, the QA engineers who
just run manual test passes, the release
manager whose entire value is just
coordination. Those kinds of roles are
going to have to transform or they're
just going to disappear. And for people
in those roles, you need to find ways to
move toward developing with AI and
rewriting your entire workflow around
agents as central to your development.
That is going to look different
depending on your stack, your manager's
budget for token spend, and your
appetite to learn. But you need to lean
that way as quickly as you can for your
own career's sake. I want to leave you
with one thing that gets lost in every
conversation about AI and jobs. We have
never found a ceiling on the demand for
software and we have never found a
ceiling on the demand for intelligence.
Every time the cost of computing has
dropped from mainframes to PCs, from PCs
to cloud, from cloud to serverless, the
total amount of software the world
produced did not stay flat. It exploded.
New categories of software that were
economically impossible at the old cost
structure became viable and then
ubiquitous and then essential. The cloud
didn't just make existing software
cheaper to run. It created SAS, mobile
apps, streaming, real-time analytics,
and a hundred other categories that
could not exist when you had to buy a
rack of servers to ship something. I
think the same dynamic applies now and
it applies at a scale that dwarfs every
previous transition. Every company in
every industry needs software. Most of
them, like a regional hospital or a
mid-market manufacturer or a family
logistics company. They can't afford to
build what they need at current labor
costs. A custom inventory system
traditionally could cost a half a
million or more and take over a year. A
patient portal integration might cost a
third of a million. You get the idea.
These companies tend to make do with
spreadsheets today. But we are dropping
the cost of software production by an
order of magnitude or more. And now that
unmet need is becoming addressable. Not
theoretically now. You can serve markets
that traditional software companies
could never afford to enter. The total
addressable market for software is
exploding. Now this can sound like a
very comfortable rebuttal to people
struggling with the pain of jobs
disappearing. It is not the same thing.
Just saying the market is getting bigger
doesn't fix it. But it is a structural
observation about what happens as
intelligence gets cheaper. The demand is
going to go up, not down. We watched
this happen with compute, with storage,
with bandwidth, with every resource
that's ever gotten dramatically cheaper.
Demand has never saturated. The
constraint has always moved to the next
bottleneck. And in this case, the
judgment is to know what to build and
for whom. The people who thrive in this
world are going to be the ones who were
always the hardest to replace. The ones
who understand customers deeply, who
think in systems, who can hold ambiguity
and make decisions under uncertainty,
who can articulate what needs to exist
before it exists at all. The dark
factory does not replace those people
and it won't. It amplifies them. It
turns a great product thinker with five
engineers into a great product thinker
with unlimited engineering capacity. The
constraint moves from can we build it to
should we build it and should we build
it has always been the harder and more
interesting question. I don't have a
silver bullet to magically resolve this
but I have to tell you that we must
confront the tension or we are being
dishonest. The dark factory is real. It
is not hype. It actually works. A small
number of teams around the world are
producing software without any humans
writing or reviewing code. They are
shipping shippable production code that
improves with every single model
generation. The tools are building
themselves. The feedback loop is closed.
And those teams are going faster and
faster and faster and faster. And yet
most companies aren't there. They're
stuck at level two. They're getting
measurably slower with AI tools they
believe are making them faster. They're
wrong. running organizational structures
designed for a world where humans do all
of the implementation work. Both of
these things are true at the same time.
The frontier is farther ahead than
almost anyone wants to admit and the
middle is farther behind than the
frontier teams like to talk about. The
distance between them isn't a technology
gap. It's a people gap. It's a culture
gap. It's an organizational gap. It's a
willingness to change gap that no tool
and no vendor can close. The enterprises
that get across this distance are not
the ones that buy the best coding tool.
They're the ones that do the very hard,
very slow, very unglamorous work of
documenting what their systems do, of
rebuilding their org charts and their
people around the skill of judgment
instead of the skill of coordination.
And they are organizations who invest in
the kind of talent that understands
systems and customers deeply enough to
direct machines to build anything that
should be built. And those orgs need to
be honest enough with themselves to
admit that this change will not happen
as fast as they want it to because
people change slowly. The dark factory
does not need more engineers, but it
desperately needs better ones. And
better means something different than it
did a few years ago. It means people who
can think clearly about what should
exist, describe it precisely enough that
machines can build it and who can
evaluate whether what got built actually
serves the real humans it was built for.
This has always been the hard part of
software engineering. We just used to
let the implementation complexity hide
how few people were actually good at it.
The machines have now stripped away that
camouflage, and we're all about to find
out how good we are at building
software. I hope this video has helped
you make sense of the enormous gap
between the dark factories in automated
software production and the way most of
us are building software today. Best of
luck navigating that transition. I wrote
up a ton of exercises and a ton of
resources over on the Substack if you'd
like to dig in further. This tends to be
something where people want to learn
more, so I wanted to give you as much as
I could. Have fun, enjoy, and I'll see
Click on any text or timestamp to jump to that moment in the video
Share:
Most transcripts ready in under 5 seconds
One-Click Copy125+ LanguagesSearch ContentJump to Timestamps
Paste YouTube URL
Enter any YouTube video link to get the full transcript
Transcript Extraction Form
Most transcripts ready in under 5 seconds
Get Our Chrome Extension
Get transcripts instantly without leaving YouTube. Install our Chrome extension for one-click access to any video's transcript directly on the watch page.
