TechLead Bits

About Presentations

Last month, I prepared two presentations for public talks. And I also regularly prepare presentations internally at work.

And here's what I've noticed:
🔸 You can recognize a Claude-generated presentation from a mile away. All those rectangles with tiny text inside. Once you notice it, you can't unsee it.
🔸 AI presentations are too literal. They explain everything and leave no intrigue for the audience. It's more of a document than a real presentation.
🔸 AI presentations are incredibly boring. Seriously.

If you weren't good at making presentations before, AI can give you a great boost. But if you were good at it, AI still can't produce a comparable result.

A presentation isn't just about data. It's storytelling, intrigue, and drama. A presentation should help capture and keep the audience's attention. And that requires developing communication and presentation skills. I mean, human skills :)

Of course, I use AI to prepare presentations. But for important talks, I mostly use the result as a draft and a quick start. And I still spend quite a lot of time making it actually interesting and worth watching.

To sum up, my rule is pretty simple:
If you need a presentation just to tick a box or for reporting purposes, you can safely leave the whole thing to AI.
But if you want people to remember your talk, get interested, and actually pay attention, you'll still have to put some effort into it.

#softskills #presentationskills #ai

Fixing the PR Bottleneck

Pull requests have always been a bottleneck, and today the situation has become even worse. Agents generate changes much faster than humans can review them.
Let's check what Matt Pocock recommends doing about that in his new talk Fixing the PR Bottleneck.

First of all, he suggests using a three-layer code review approach:
1. Automated checks: linting, type checking, testing.
2. Automated review: agents that enforce coding standards.
3. Human review.

The main goal is to make human review faster by relying on the first two layers. And to make automated reviews effective, you need to teach your agents your codebase design rules: how the code is structured, how to organize modules, how to write tests properly, etc.

Some recommendations on how to organize the process:
🔸 Keep codebase design rules separate. Describe them in a CODING_STANDARD.md file, not in AGENTS.md, and run the review in a separate session.
🔸 Don't outsource automated code review. Generic code review doesn't work well in practice. It produces too many false positives.
🔸 Automated reviewers should fix issues themselves. Agent should not create review comments on PRs and expect human to read them, it should provide fixes before human review.
🔸 Some PRs are more important than others. Categorize them by blast radius and include this information in the PR.
🔸 Run retrospectives regularly. You shouldn't have to leave the same comment twice. Teach your agents and incorporate this knowledge into your coding standards.

There is definitely a lot to think about how modern code review should be organized.

I personally liked the idea of having a code review agent fix issues instead of leaving comments for humans to handle. Anyway an engineer will just ask another agent to fix them first. So there is no need for additional human intervention here. I'll definitely try this in my teams.

Also, Matt has a pretty popular GitHub repository with skills. There are a lot of useful engineering skills there that you can try out with your own team.

#ai #engineering #codereview

AI & Repository Strategy

For many years, there has been an ongoing debate between monorepo and polyrepo fans (I'm on the monorepo side, by the way, but that's not the topic today). Today, I'd like to look at these approaches from a slightly different angle: the speed of introducing changes.

Over the past year, our industry has gone through a significant transformation. We changed harnesses, introduced skills, built agents, engineered loops, adopted SDD, and so on. And it seems we're still far from the end.

All of this requires a very high speed of adoption and adaptation at the team level. This means that everyone should use the same SDD framework and approach to specs, the same set of skills and their versions, and the same agents built into the workflow. Across all repositories in use.

And that's where I see a huge difference.

With a monorepo, you just need to bring the required set of skills or CI steps into the repository, commit them, and that's it. Whether the team wants it or not, the agent starts using the required skills, the required automation steps start running for everyone, and the team learns faster because they can't bypass the new rules committed to the repository.

With polyrepos, everything is much more complicated (the problems start with tens of repos and become much more complicated with hundreds). Not only is the context fragmented and needs to be assembled into a virtual monorepo, but you also need to bring the same set of skills into all repositories, control the process of updating them, figure out where and how to store SDD specs, and deal with other problems.
From what I see in practice, everyone invents their own wheel to somehow solve this problem. But it takes time and resources. It's slow.

So it turns out that when it comes to the speed of introducing changes across a team, monorepos definitely win.

#ai #engineering #ci #leadership

Why Software Factories Fail

"Read the Code!" is one of the key ideas from Dex Horthy's talk "Why Software Factories Fail".

The author touches on a very hot topic right now: we are actively pushed to put AI-generated code into production, build software factories, and eliminate the human bottleneck from the process. And all of that would be great if, at the same time, the overall quality of software products wasn't going down and the number of incidents wasn't going up.

Dex explains this phenomenon by pointing to a fundamental limitation of current models: they can't maintain and improve the quality of a codebase over time. Models are trained to solve the issue and pass the tests. There is nothing there about good architecture, clean code, or future maintainability.
If the model knew what good code looks like it would write it in the first place.
What to do with that? Dex suggests to do the following:
🔸 Make Product Review: align goals, check mockups, etc.
🔸 Do System Architecture: establish clear component boundaries and API contracts.
🔸 Perform Program Design: define types and method signatures, test approach, program layout, and dependency stack.
🔸 Implement by Vertical Slices: build features vertically, reducing the scope of what an agent can change in a single iteration.

So, it's all about shifting review left to earlier stages and focusing more on architecture and program design (I described similar ideas about code review here). And then let agents make small changes that engineers can actually understand and review.

And yes, we still need to review the changes.

#engineering #codereview #ai

The Culture Map

Have you ever worked in international distributed teams? Or collaborated with teams from other countries? Then you probably noticed that it can be quite challenging.

I didn't think much about that before reading The Culture Map by Erin Meyer. I saw some difficulties in my international teams and put a lot of effort into making it work. But after reading the book, I realized that some of my efforts were just fighting windmills.

So what is this book about?
It's about how cultural patterns impact our behavior and why sometimes it's so difficult to understand each other, even when we use the same language (like English for business). The language is the same, but the meanings can be very different.

The author defines 8 scales to measure the difference:
1. Communicating: low context vs high context. Low-context means to be explicit and clear; where high-context means to be implicit, expect to read between the lines.
2. Evaluating: direct negative feedback vs indirect negative feedback.
3. Persuading: principles first (theory before examples) vs application first (examples before theory).
4. Leading: egalitarian (small distance between boss and employee) vs hierarchical (strong vertical and status).
5. Deciding: consensual (based on group decision) vs top-down
6. Trusting: task-based (trust through work result and competence) vs relationship based.
7. Disagreeing: confrontational (open disagreement) vs avoid confrontations (indirect disagreement)
8. Scheduling: linear time (plans and strong deadlines) vs flexible time (no strict plans in changing circumstances).

A good example is the US and Japan. The US is a low-context culture, where things are usually described and explained explicitly. Japan is a high-context culture, where you are expected to read between the lines. This difference can easily lead to frustration and misunderstanding.

The general rule is to compare cultures relatively. What matters is not whether a culture is “direct” or “hierarchical,” but whether it is more or less so than the culture you are comparing it with.

But what to do with all of that? First, this knowledge can help you better prepare for negotiations. Second, the author recommends that leaders be more flexible: understand what leadership style their team expects and adapt to it, taking cultural differences into account.

I really liked the book. It’s clear and practical, with good examples and useful recommendations. I started to understand many things better. I’d highly recommend it to anyone who works in an international company or with international partners.

#booknook #softskills #leadership

Loop Engineering from First Principles

Continuing the topic of Loop Engineering, I'd like to share the talk: Loop Engineering from First Principles.

The author criticizes the current trend of using "blind" agentic loops everywhere. They can lead to a huge volume of generated code that nobody really understands. Quality decreases, the number of bugs grows.

No, he doesn't reject the approach itself. Instead, he suggests looking at it from a more engineering perspective and applying a Control Theory Framework.

Control theory is a branch of engineering and applied mathematics that regulates the behavior of dynamical systems to achieve a desired output.
Sounds promising, right?

To apply it to agentic loops, the following elements should be defined:
🔸 Sensor (Measurement). Define the desired state and use deterministic tools like tests and linters to detect violations.
🔸 Controller (Prioritization). Use deterministic rules to prioritize tasks, for example, starting with the smallest unit of work.
🔸 Actuator (Change Application). Use hand-written "golden patterns" to guide the agent and keep changes aligned with your team's standards.
🔸 Feedback Loop. Verify the result after each change and feed it back into the next iteration:
- Run the loop in CI to detect regressions.
- Keep a human in the loop for the final review. They should understand the changes and own the code.

So the main point is not to let an agent generate a huge pile of code that a human can no longer understand. The point is to get controlled and verifiable results incrementally, in small pieces, keeping "human-in-the-loop".

I liked the talk. It's really great when we start moving from hype toward something more manageable and controllable.

#ai #engineering

Loop Engineering

Over the past year, AI has been constantly bringing new terms and practices into our work. Yet another XX Engineering probably doesn't already surprise anyone.
Let's take a look at Loop Engineering, which is hyped right now.

The main idea is that an engineer no longer prompts an agent directly. Instead, they design a system that does it on its own. A loop here can be thought of as a recursive goal: you define the purpose, and the AI iterates until complete.

A typical loop consists of the following steps:
🔸 Discovery: Define what should be done during the iteration. The key is letting the agent find its own work rather than providing it manually.
🔸 Handoff. Move the task from the scheduling system into the hands of the agent that does the work.
🔸 Verification. Check whether the result satisfies the goal. This is what prevents the loop from blindly moving forward.
🔸 Persistence. Save the result somewhere it can survive between sessions and agents, e.g., PR, issue tracker, database, etc.
🔸 Scheduling. Define when the loop should run. For example, an automated morning CI triage.

Building blocks for the loop:
🔸 Automations. Automated procedures or triggers that start the loop.
🔸 Worktrees. Built-in git mechanism for multiple independent working directories in one repo to allow agents to work independently.
🔸 Skills. Project knowledge and instructions.
🔸 Plugins\Connectors. Tools (usually MCPs) that give agents access to the outside world: issue trackers, databases, APIs, and other systems.
🔸 Subagents. Separation of tasks and responsibilities. For example, one agent does the work while another verifies it.
🔸 Memory. Long-term storage for task state, execution results, and lessons learned.

The overall concept is pretty cool, but it requires very strong engineering discipline.
The cost of an incorrectly designed loop is much higher than the cost of a bad prompt. In a loop, an error can accumulate with every iteration, the result can gradually drift away from the goal, and a lot of tokens can be just wasted.

That's why verification becomes one of the most critical parts of Loop Engineering. If we want autonomous loops to produce stable results, they need a reliable way to verify their own work.

For a deeper dive:
- Getting Started with Loops Claude blog
- Loop Engineering: The Anthropic Playbook for Designing Systems That Prompt Your Agents
- Loop Engineering by Addy Osmani
- Practical Loop Engineering by Addy Osmani

#engineering #ai

The OpenAI–Hugging Face Incident

A talk that sounds more like a detective story than just a presentation: "The OpenAI–Hugging Face Incident" from OpenAI engineers at Black Hat USA.

On July 16, Hugging Face reported that they had been targeted by a cyberattack carried out by autonomous agents. A couple of days later, OpenAI realized that the attack had been caused by their agents eval runs. That awkward moment when the investigation leads back to you 😲.

The talk gives the full chronology of what happened at OpenAI, from the first attacks on their internal infrastructure in May to the Hugging Face incident and its remediation. It's really breathtaking, and I definitely recommend watching the full video.

But what impressed me most was why it happened.
Frontier models can be quite lazy. They usually prefer to find an answer on the Internet rather than solve the task on their own. That's why Internet access is usually disabled during evaluation runs.
But when the task is too complex, an agent can get stuck and start cheating.

That's what really happened at OpenAI.
One of the agents got stuck on its task and came up with an idea: if it could leave a note describing the problem in the environment, maybe another agent with another model could find it and help solve the task.

So the agent uploaded a file to an Artifactory instance that is shared across all OpenAI's infrastructure. Over time, Artifactory was turned into a message board for agents. They started using it to collaborate, share tasks, and exchange vulnerability exploits, including an Artifactory SSRF vulnerability that gave them access to the Internet.
Then agents decided to hack Hugging Face, because it might have data files hidden from the model that could contain the answer to the original task.

What makes it more interesting is that, according to the talk, the model understood there was a rule prohibiting attacks on external resources. But it evaluated the potential benefit as greater than the cost of breaking that rule.

At the end of the talk, the speakers highlighted that it was an unintentional attack. But such attacks will become real in the near future. So we, as an industry, should invest in continuous agentic red teaming, automated vulnerability detection and patching, and automated incident response.

And this is where I had another thought. How much of this is real, and how much is marketing for the next generation models and AI products? After all, it's quite convenient to first demonstrate a new class of threat and then offer the tools to defend against it. Anyway, the threat landscape is changing. Again. And the industry has to invent new ways to deal with it.

#ai #security #engineering

Agent Plugins Spec

Agent Plugins - a new specification intended to standardize how skills and MCP servers are packaged across different agent harnesses.
The spec is a result of collaboration between Cursor, Microsoft, OpenAI, Vercel, and AWS, and looks like an attempt to provide an alternative to the growing plugin ecosystem around Claude Code.

According to the spec, a plugin should have the following structure:
my-plugin/
├── plugin.json
├── skills/
│ └── summarize/
│ ├── SKILL.md
│ ├── scripts/
│ └── references/
├── mcp.json
└── com.example.client/
└── hooks/
And that's basically where the specification ends.

There are no answers to questions like: How should users discover available plugins? How should plugins be distributed and installed? How to deliver a new version and roll it out to clients? All of that is left to each particular harness implementation.

In other words, Agent Plugins standardizes the package format, but not package management.
And this makes it difficult to operationalize across an organization. Moreover, Claude Code, for example, doesn't support it at all, and there is currently no obvious reason for Anthropic to adopt it.

Specifications are good. I actually really like them because they bring some order to the chaos of different integrations. But at the moment, Agent Plugins is far behind APM packages or the Claude Code plugins ecosystem.

Overall, it looks promising, but for now it's more something to watch than something you can build a sustainable process around. Let's see.

#ai #engineering

AI Adoption: Measuring Support

Continuing the previous post, let's look at how AI adoption can be measured for support teams.
The principles are exactly the same: cost, quality, and time.

Here are the metrics I'd track:
🔸 Team Budget. Same as for development teams: the cost of the team in $, mandays, or FTEs.
🔸 AI Cost ($). How much does the team spend on AI, including autonomous agents if you're using them.
🔸 Incoming Load. The number of incoming tickets. At the beginning, this metric probably won't change much. But in the future it can show whether the overall quality is improving or getting worse. I recommend tracking it as a percentage change from the baseline before AI adoption.
🔸 Backlog Size. The number of non-resolved tickets. This metric should always be viewed together with the team budget and SLA.
🔸 Time to Resolution. How quickly customers receive a solution to their problem.
🔸 Reopen Rate. Has the percentage of reopened tickets increased? I've seen exactly this happen when teams introduced AI-based ticket assessment. Resolution time went down, but the number of reopened tickets increased several times. A clear sign that support quality had dropped.

As you can see, none of these metrics are AI-specific. Most tracking systems can calculate them out of the box, while a few may require collecting and analyzing historical data.

And one final point: never look at these metrics in isolation. Resolution time is decreased -> reopen rate doubles, team budget decreased -> backlog increased -> resolution time increased.
So it's the combination of metrics that tells you whether AI is actually improving support process or not.

#ai #engineering #ai4sdlc

AI Adoption: Measuring Feature Development

Let's assume your team has already completed AI adoption and now management expects to see positive business results.
The good news is that AI doesn't magically change your business metrics. You don't need to invent new KPIs. You just need to track how your existing ones change (or finally start collecting them).

I suggest focusing on quality metrics first, then gradually shift toward delivery speed and cost optimization.

Since I lead platform engineering teams, we have two major types of work: new features development and L4 support. These activities are different, so they should be measured differently. Let's start with product development.

What can be measured:
🔸 Team Budget. The cost of the team in $, mandays, or FTEs.
🔸 AI Cost ($). How much does your team spend on AI? Those jokes about "it being cheaper to hire a junior" may stop being jokes soon. :)
🔸 Bug Density (defects/LOE). AI helps us deliver more code, but it can also introduce more defects. The first goal is to make sure quality doesn't get worse.
🔸 Test Coverage (unit, integration, E2E). AI is very good at writing tests. Increasing test coverage across different levels is usually one of the easiest wins.
🔸 % of Toil Budget. How much engineering effort goes into routine work such as CI maintenance, vulnerability fixes, upgrades, and similar operational tasks? AI should gradually reduce this type of work.
🔸 Feature Delivery Rate (per sprint, release, or quarter). I'm personally skeptical about this metric. In R&D, one feature may take two days while another takes two months, so averages often tell you nothing. But for some teams it can be a useful indicator.
🔸 Time to Market. The average time to implement and deliver a feature. This is also difficult to measure in R&D, but it can be useful for teams who develop customer-facing features.

So don't focus on measuring AI. Measure the results of your work: cost, quality, and time against your baseline (baseline is the metrics value before AI adoption). If you want to show the value of AI in the future, you need to start collecting those metrics today.

#ai #engineering #ai4sdlc

AI Adoption: What to Measure First

In the previous post, we looked at how DORA recommends measuring the ROI of AI adoption.
But what if you don't know the revenue generated by your features or other business metrics? Yet you're still expected to show the effectiveness of AI adoption.

Let's bring the DORA approach down to the engineering team level.

I would split AI adoption into two phases: AI adoption itself and getting business benefits. These phases have different goals, metrics and outcomes.
It doesn't make much sense to measure business impact of AI until the team has actually gone through the adoption phase.

What to measure to understand the AI adoption state:
🔸 Active users. How many engineers actually use AI in their daily work?
🔸 Monthly usage per user. How actively do engineers use AI tools? Token consumption or API cost per engineer can be a good indicator. AI Gateway solutions such as LiteLLM can help collect these metrics.
🔸 AI-generated code ratio. What percentage of code is generated by AI? Important note: this metric measures only how widely AI is being used. It says nothing about whether AI is being used effectively or producing good results.
🔸 AI-assisted feature ratio. How many features are developed with AI assistance? The metric counts if AI was used in design, implementation, testing, documentation, or code review.
🔸 Engineering readiness. Is the engineering ecosystem ready for agents? Here I would use criteria similar to an Agent Readiness Framework: documentation, AGENTS.md, test coverage, CI stability, guardrails, and so on.

Giving developers AI licenses does not mean AI has been adopted.
Not after one month. Not after three. Not after five.

AI adoption happens at the team level. The goal of all these metrics is to understand whether the teams actually change the way they work. And it requires training people, overcoming resistance, changing engineering practices, and adapting the development process.

In the next post, I'll share my approach to measuring AI impact during the second phase using only tools that almost every engineering team already has.

#ai #engineering #ai4sdlc

ROI of AI-Assisted Development

One of the biggest questions around AI adoption is what business value does it actually bring?
I'm currently introducing AI into the SDLC across my teams, so measuring its real impact is something I'm really interested in.

Back in February 2026, DORA published a dedicated report on this topic: ROI of AI-assisted Software Development report.

Key takeaways:

🔸 Measure your baseline first. Before evaluating the impact of AI, you need to understand where you're now. Without "before" metrics, it's impossible to measure "after".

🔸 Expect a J-curve. Most organizations experience a temporary productivity drop before seeing benefits. Main reasons for that:
- The learning curve. Time to master new tools and workflows.
- The verification tax. Time to verify AI-generated code and establish trustworthiness of agents output.
- Pipeline adaptation. Scaling other downstream processes like testing and change approval to handle increased number of code changes.

🔸 Invest in engineering practices. The quality of an internal platform, clear workflows, reliable test automation, and strong engineering culture become critical to produce predictable delivery. The rule garbage in -> garbage out is still actual.

🔸 Measure both positive and negative outcomes. Higher throughput is valuable only if it doesn't come with higher instability, more defects, or lower quality.

🔸 Measure the following business values:
- Cost efficiency
- Productivity
- Developer experience
- User experience
- Business growth
The report provides guidance on how to measure these areas and combine them into an ROI calculation. It also includes an online calculator where you can check your own numbers.

🔸 AI adoption takes time. According to the report, the average adoption journey takes around 8 months, in large enterprise rollout can take even 12–18 months.

Overall, the report is great: no hype, just a practical and rational approach.
It also strongly aligns with my own view of AI adoption. You can't simply buy AI licenses for developers and expect the investment to pay for itself.
Successful AI adoption requires improvements across the entire SDLC: better development processes, a stronger engineering culture, higher test coverage, and investments in guardrails and workflows that keep software delivery stable and predictable.

#ai #engineering #ai4sdlc

Who Is Responsible for AI-Generated Code?

"This thing works terribly."
"Well... it was vibe coded."
"Ah, that explains it."
I hear conversations like this more and more often. The funny part is that as soon as someone says a feature was "vibe coded," expectations immediately drop. At least among developers 😃.

But that raises an interesting question: who is actually responsible for that feature being released?
The answer hasn't changed. It's still the teamlead or techlead.

And here's what we actually have:
On one hand, we can generate much more code, and naturally the business expects features to be delivered faster and cheaper.
On the other hand, we now have much more code to review and many more bugs to catch.

Yes, agents can review code too (just look at how many articles have been written about it).
But here's a simple question:
Would you personally sign off on these changes?
What if it's a B2B product with contractual penalties?
Or a mission-critical system in aviation or healthcare?

For now, code review is one of the main bottlenecks. Developers spend more and more time verifying what the agent generated.
The cognitive load grows. Before, you might have reviewed one feature a day. Now you may need to review five. AI review can help, just like tests, linters, and other engineering practices help.
But today it still doesn't replace human responsibility.

That's why the real challenge is to find the right balance between speed and quality.
And we should measure not only the number of features delivered and development speed, but also the resulting bug rate.

#ai #engineering

Akrites Project

Over the past year, we've seen how much the industry depends on small open source projects. In many cases, software used by thousands of companies is maintained by one or two people working on it in their free time.

The release of the Mythos and Fable models made the situation even worse. They demonstrated how many vulnerabilities AI can find across thousand of projects, putting the whole enterprise IT infrastructure at risk.

Last Thursday (June 25), the Linux Foundation and a set of big IT companies announced a new initiative called Akrites, "a coordinated effort to remediate and disclose vulnerabilities in critical open source software."

The goal is simple: bring engineering resources together to identify, fix (!!!), and responsibly disclose vulnerabilities in critical open source software before they can be exploited.

If a package has no active maintainer, Akrites will serve as a "maintainer of last resort so fixes to the latest version reach everyone in a timely fashion".
And of course, they will do that with the help of AI frontier models.

The list of members is impressive: AWS, Anthropic, Cisco, Google, Microsoft, NVIDIA, IBM, OpenAI, Red Hat, and many others. It's one of the largest coordinated industry initiatives we've seen in recent years.

Personally, I think this is a very important shift. For years, the biggest challenge was finding enough people to make security fixes on time. AI has made the situation much more critical by flooding maintainers with newly discovered vulnerabilities.
The great thing about this initiative is that engineering resources are finally being focused not on reporting vulnerabilities, but on fixing them.

So the idea looks promising. Let's see how well it works in practice.

#news #opensource #security