Leonid Bugaev

AI made implementation faster. Trust did not.

Write about building Agentic first organizations and solving verification gap.

Head of Engineering at

[Leonid Bugaev @buger]

Have become top 3 trending developer on Github, with @mitchellh right behind me 😱

[Leonid Bugaev @buger]

@yoheinakajima + Time traveling debuggers (plus tools like https://t.co/EfIaEiMybe), clojure immutable data structures

[Leonid Bugaev @buger]

You can't have such rules. The only thing you can do is to harden the product as much as possible, so it will not matter if someone see your code. We have a bunch of OSS examples, like k8s, which are backbones of the enterprise architectures, yet oss, and secure enough. And basically you can afford the same level of pen testing for your app now, with AI. However, even in this projects, new AI models starts finding new security issues.

[Leonid Bugaev @buger]

Imagine your source code goes public tomorrow. How would you feel? GitHub lost 3,800 repos last week to one poisoned VS Code extension. AI now reads codebases faster than you can. Security by obscurity is dead. What will be our answer?

[Leonid Bugaev @buger]

https://t.co/eXuM2PJUEM

[Leonid Bugaev @buger]

https://t.co/eXuM2PJUEM

Read the full essay in my weekly newsletter

[Leonid Bugaev @buger]

Participated in #dailydevhackathon

Have build 2 ideas so far!

1) Source Bias Atlas
A 2D map of 1,361 dev sources clustered by stylistic personality. 5 views: engagement, volume, hype, title-style. UMAP for tribes.

https://t.co/qcke7Ix4wr

2) Source Originality Score

Who breaks each story first on https://t.co/KrlCUD5MpQ?
Leaderboard of scoopers vs echoers. Per-topic timelines showing lag-to-echo.

https://t.co/WFtC8lFnKQ

[Leonid Bugaev @buger]

I build visor exactly for this, and our company brain use it for last 6 months.

You can see the engine here https://t.co/MmR9xwT4vS

And quickstar how I build agents:
https://t.co/iLs3bKQ079

Each agent based on set of deterministic steps. Some of steps are agents too. And all covered by OTel, and it knows how to debug itself.

[Leonid Bugaev @buger]

I have this personality split issue, maybe someone had the same, and can give advice.

I always was building smth on the side and a few bootstrapping attempts (right now an active one). Big part of it is a marketing. When you just a reader, it is relatively easy to consume (and judge), but when you have to market it, you need to be on LN, X, HN, Reddit, not just as creator but treat all this almost as a "job", turn it into a coversion machine, and sometimes without acknowledging, turning every conversation to your own "promo", and everywhere see the conversion funnel. Even when you are not on the platforms above, and just talking to someone.

And modern marketing standards are quite brutal too, you need be everywhere, stick to the schedule, show up every day. Polish your profiles, target the right keywords, have social media monitoring enabled and so on.

Another side of it, is also being afraid to post what you "actually" think on some of the topics. I may post on some trendy topic to get some traffic, but internally be very conflicting about it. Or being afraid to post smth too direct or smth which can be considered offensive - which can follow you back (you = your business/your employee), after some time.

Anyone found a way how to find this ballance? Feels like you almost need to develop dissociative identity disorder on purpose, to split your identity, and just "be" yourself in some situations or communities, whatever it means.

[Leonid Bugaev @buger]

I have this personality split issue, maybe someone had the same, and can give advice.

I always was building smth on the side and a few bootstrapping attempts (right now an active one). Big part of it is a marketing. When you just a reader, it is relatively easy to consume (and judge), but when you have to market it, you need to be on LN, X, HN, Reddit, not just as creator but treat all this almost as a "job", turn it into a coversion machine, and sometimes without acknowledging, turning every conversation to your own "promo", and everywhere see the conversion funnel. Even when you are not on the platforms above, and just talking to someone.

And modern marketing standards are quite brutal too, you need be everywhere, stick to the schedule, show up every day. Polish your profiles, target the right keywords, have social media monitoring enabled and so on.

Another side of it, is also being afraid to post what you "actually" think on some of the topics. I may post on some trendy topic to get some traffic, but internally be very conflicting about it. Or being afraid to post smth too direct or smth which can be considered offensive - which can follow you back (you = your business/your employee), after some time.

Anyone found a way how to find this ballance? Feels like you almost need to develop dissociative identity disorder on purpose, to split your identity, and just "be" yourself in some situations or communities, whatever it means.

[Leonid Bugaev @buger]

More in my weekly newsletter https://t.co/XydOcEbzeN

[Leonid Bugaev @buger]

The code runs. The code breaks. The code is what production uses.

Specs and docs can help, but they often become stale. So we learned not to trust them too much.

Code is honest in a way documents are not. It may be wrong, but it does exactly what it does.

But I think there was another reason we trusted code so much.

For a long time, code was manual work. We wrote it ourselves. We spent time with it. We were not only typing syntax; we were thinking through the system while writing it. The thinking and the implementation were almost the same activity.

That is why code deserved this level of trust. Not because code was perfect. It was not. But because the code carried a lot of the human judgement that produced it.

With agentic coding, this starts to change.

The code is still real. It still runs. But now the thinking can be distributed across prompts, specs, agent sessions, generated plans, reviews, and the human who is steering everything.

And if the thinking moved, maybe the source of truth moved as well. Or at least it became less obvious.

This is what I tried to explore in this article.

As an individual contributor, I can move incredibly fast with tools like Claude Code. I can start with a rough idea, steer the agent while it builds, change direction during implementation, and let the code teach me what the spec should have been.

I like this. A lot.

But it works best while the system still fits inside one brain.

The experienced person knows the edge cases, dependencies, fragile interfaces, strange behaviours, and old production scars. The agent is not really working from a complete spec. It is working with a human who carries the missing context.

But real systems grow. They get delegated. Teams split. People leave. New people join. Agents improvise. Humans improvise too.

If something was never described, why do we expect the agent, or another human, to implement it the way we imagined?

Maybe this is where requirements become interesting again.

Not as a new idea. Regulated industries already use requirements this way. It is normal for them to have large requirement sets which can be turned into multi-hundred-page documents. But underneath, it is not just one big document. It is a graph of requirements, sub-requirements, interfaces, tests, evidence, owners, dependencies, and links.

I do not think normal software teams need to copy all the heaviness.

But maybe agentic engineering makes some lighter version of this much more important.

Code is still the runtime truth. It tells us what the system does.

But requirement is the intent truth. It tells us what the system is supposed to mean.

And evidence is what connects them.

I do not have the full answer yet. But I think the real risk of agentic engineering may not be bad code.

It may be bad intent, implemented quickly.

[Leonid Bugaev @buger]

@SharadRegoti @ahmetb @ahmetb feel free to DM me if you curious about formal verification and how it can work for your case. Would love to have more real life case studies!

[Leonid Bugaev @buger]

When code becomes easy to produce, the hard part is remembering what we meant.

[Leonid Bugaev @buger]

@heyblake https://t.co/1Z4WAl6Ktk

[Leonid Bugaev @buger]

Reminder: green is not the same as correct.

Your tests can pass because they only check the behavior you remembered to describe.

The missing behavior is still missing.

That is where AI-generated code gets dangerous.

[Leonid Bugaev @buger]

More in my new essay https://t.co/NDmEJEzRrt

[Leonid Bugaev @buger]

Something I keep thinking about:

Maybe AI is not exposing a new problem in engineering.
Maybe it is exposing an old one that we were already bad at.

We talk about AI like the bottleneck is still writing code.
But honestly, writing code has not been the hard part for a long time.
The hard part is all the surrounding context.

Why are we making this change?
Who asked for it?
Which customer depends on the current behavior?
Was this weird edge case intentional?
Is this a product decision or just an implementation accident?
Did security already review something similar before?
Is the documentation describing the current behavior or the behavior we wish we had?

And the uncomfortable part is that most of this context is not in one place.

It is all over GitHub, Slack, docs, tests, head of the engineer who left six months ago.

This was already a problem.
AI just makes it harder to ignore.
Because now we can create more code from less context, more tests, more docs, more confident explanations.

But if the context is incomplete, then all of that output is built on sand.
This is the part I find interesting.

Not “will AI replace engineers?”
I don’t think that is the most useful question.

The more interesting question is:
What happens when engineering teams can generate implementation faster than they can preserve intent?

Because that is where things get messy.

You can have a clean PR.
You can have passing tests.
You can have updated docs.
You can even have a very convincing AI-generated explanation.

And still nobody can answer the basic question: “Is this actually the right change?”

That question is much more expensive than people admit.
I have felt this many times in open source and infrastructure work.

You look at a small change and think, “This should be simple.”
Then you start pulling the thread.
There is a backwards compatibility issue.
There is some behavior that looks wrong but someone depends on it.
There is a test that protects the implementation but not the real promise.
There is a doc page that says one thing and production behavior says another.
There is a customer workaround that became part of the product without anyone naming it.
Suddenly the small change is not small.

And this is why I think “AI will make everyone ship faster” is only half true.
AI can make the creation part faster.
But creation is not the same as shipping.
Shipping means the organization understands the change well enough to stand behind it.

That is a different problem.
I don’t have the perfect answer yet.

But I think “AI coding” is the wrong frame.
The real problem is not coding.
The real problem is engineering memory.

And most teams’ engineering memory is held together with Slack search, old PR comments, and someone saying: “I think I remember why we did that.”

That does not scale.

[Leonid Bugaev @buger]

https://t.co/9UbcD85u4m

[Leonid Bugaev @buger]

Subscribe to my substack newsletter where we will together navigate on where our industry is going: https://t.co/NDmEJEzRrt

[Leonid Bugaev @buger]

Everyone is asking the same question now: if AI can help us create much more code, why aren’t engineering teams suddenly moving much faster?

I think the question is right, but the answer usually stops too early.

The expensive part is trust.

Can I trust this change? Does it match the intent? Does it break a hidden customer flow? Does it affect backwards compatibility? Are the docs updated? Are the tests proving the right thing? Did we think about security, performance, malformed input, error states, release notes, migration, support?

A pull request doesn’t answer all of this.
A pull request is just something asking to be trusted.

And the worst part, are the specs. We talk about flood of AI generated PRs, but rarely talk about applying AI for specs. Everyone does it now. For PRs we at least have verification workflows like CI/CD, for specs we have only hope that engineer reviewing it, actually spent time deeply think about it. The amount of subtle intent issues and scope bloat it introduce is the biggest threat.

In my new essay I try to get deep on how we can get the trust back, and actually scale engineering. And no, new shiny LLM model wont't save you - it require a boring work, with checklists and patience.

See link below