The AI-Driven Leader
This is how The AI-Driven Leader by Geoff Woods begins. An international bestseller with a catchy title and a good rating on Amazon. Actually, I had pretty high expectations about it.
But let's start from the beginning.
This is a book written by a non-engineer for non-engineers. It explains in simple terms what GenAI is, what risks it brings, and how leaders can integrate AI into their work.
If you boil it down, the whole idea is to use AI as a Thought Partner (I wrote about it here). To demonstrate that the approach works, he provides simple real-life stories and examples of specific prompts. If you don't know where to start with AI, the author suggest 5 main use cases: strategic thinking, decision-making, content creation, idea generation, and analysis.
And that's basically where the meaningful AI-related content ends.
The remaining 80% of the book is mostly basic leadership recommendations that I would summarize as "do the right things, don't do the wrong things". Ideas like "leaders should focus more on strategy and less on operations" don't really have much to do with AI.
Overall, I was left with mixed feelings.
On one hand, the book is quite entertaining, easy to read, it provides a simplified introduction to GenAI and explains what leaders can actually do with it.
On the other hand, it feels like a mix of generic leadership practices with AI that sometimes added just because it's a hot topic. At the same time, the author is extremely positive about the solutions AI produces. And as engineers, we know that something that looks like a convincing result at first glance can be AI slop on the second.
From my perspective, the book can be useful if you're only starting to use AI at work and don't know where to begin. Otherwise, you can safely skip this one and spend your time reading something more useful.
#booknook #ai #leadership
"Our humanity lies in our ability to think strategically, be creative, and communicate and collaborate to solve complex problems... AI presents a unique opportunity for us to reclaim these human strengths and have machines adjust to meet our needs."
This is how The AI-Driven Leader by Geoff Woods begins. An international bestseller with a catchy title and a good rating on Amazon. Actually, I had pretty high expectations about it.
But let's start from the beginning.
This is a book written by a non-engineer for non-engineers. It explains in simple terms what GenAI is, what risks it brings, and how leaders can integrate AI into their work.
If you boil it down, the whole idea is to use AI as a Thought Partner (I wrote about it here). To demonstrate that the approach works, he provides simple real-life stories and examples of specific prompts. If you don't know where to start with AI, the author suggest 5 main use cases: strategic thinking, decision-making, content creation, idea generation, and analysis.
And that's basically where the meaningful AI-related content ends.
The remaining 80% of the book is mostly basic leadership recommendations that I would summarize as "do the right things, don't do the wrong things". Ideas like "leaders should focus more on strategy and less on operations" don't really have much to do with AI.
Overall, I was left with mixed feelings.
On one hand, the book is quite entertaining, easy to read, it provides a simplified introduction to GenAI and explains what leaders can actually do with it.
On the other hand, it feels like a mix of generic leadership practices with AI that sometimes added just because it's a hot topic. At the same time, the author is extremely positive about the solutions AI produces. And as engineers, we know that something that looks like a convincing result at first glance can be AI slop on the second.
From my perspective, the book can be useful if you're only starting to use AI at work and don't know where to begin. Otherwise, you can safely skip this one and spend your time reading something more useful.
#booknook #ai #leadership
👍4🔥2❤1😁1
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
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
YouTube
Black Hat USA 2026 | The 'Breaking' News: The OpenAI–Hugging Face Incident
The 'Breaking' News: The OpenAI–Hugging Face Incident - A Technical Reconstruction and Its Implications for AI
When AI Goes Rogue. The Incident That Changed Everything. An OpenAI evaluation agent broke out of its sandbox, infiltrated Hugging Face infrastructure…
When AI Goes Rogue. The Incident That Changed Everything. An OpenAI evaluation agent broke out of its sandbox, infiltrated Hugging Face infrastructure…
🔥3❤2👍1
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
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
👍2🔥2❤1
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.
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
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
YouTube
Loop Engineering from First Principles — Kyle Mistele, HumanLayer
A coding agent will happily hand you a 40,000 line pull request that nobody can review and that quietly does the wrong thing. Kyle Mistele's argument is that the fix is not a better prompt but a better loop, borrowed from control theory: a thermostat senses…
👍3❤2🔥2
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
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
👍3🔥2❤1
Illustrations from The Culture Map showing how different cultures compare on the scales.
#booknook #softskills #leadership
#booknook #softskills #leadership
❤2🔥2👍1
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.
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
"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
YouTube
Why Software Factories Fail
In July 2025 Dex Horthy turned the lights off: an agent software factory where nobody read the code. It fell apart. An issue appeared that no amount of prompting could fix, the site was down, users were furious, and he was digging through a codebase he had…
🔥3👍2❤1
Tracer Bullets
Continuing the topic from the previous post, let's talk in more detail about implementing vertical slices.
The original concept comes from The Pragmatic Programmer, where it was called tracer bullets. A tracer bullet is a small, end-to-end slice of functionality that touches all layers of the system at once.
Matt Pocock in his article adapts this concept to AI engineering:
- Build a small feature end-to-end
- Test it immediately
- Get feedback
- Move to the next slice in a fresh context window
- Repeat
Matt explained this in the following way: AI's natural inclination is to build big layers in isolation. But we need to do the opposite: build the whole scenario end to end across all layers.
The article also provides a prompt sample:
So this approach forces the agent to think by small chunks and produce more predictable results.
As they say, everything new is just well-forgotten old. As we can see, AI often doesn't bring really new concepts, but rather brings existing ones back to life.
#engineering #ai
Continuing the topic from the previous post, let's talk in more detail about implementing vertical slices.
The original concept comes from The Pragmatic Programmer, where it was called tracer bullets. A tracer bullet is a small, end-to-end slice of functionality that touches all layers of the system at once.
Matt Pocock in his article adapts this concept to AI engineering:
- Build a small feature end-to-end
- Test it immediately
- Get feedback
- Move to the next slice in a fresh context window
- Repeat
Matt explained this in the following way: AI's natural inclination is to build big layers in isolation. But we need to do the opposite: build the whole scenario end to end across all layers.
The article also provides a prompt sample:
When building features, build a tiny, end-to-end slice of the feature first, seek feedback, then expand out from there. When building systems, you want to write code that gets you feedback as quickly as possible. Tracer bullets are small slices of functionality that go through all layers of the system, allowing you to test and validate your approach early. This helps in identifying potential issues and ensures that the overall architecture is sound before investing significant time in development.
So this approach forces the agent to think by small chunks and produce more predictable results.
As they say, everything new is just well-forgotten old. As we can see, AI often doesn't bring really new concepts, but rather brings existing ones back to life.
#engineering #ai
👍4❤2🔥1
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
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
👍2🔥2❤1
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
🔸 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
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
YouTube
Fixing the PR Bottleneck — Matt Pocock, AIHero
(sorry bad audio at start, goes away after 2 mins)
The pull request has always been the bottleneck, and now it's slowing down every organization. Agents make it trivial to open a PR. They make it only slightly easier to open one worth reviewing.
In this…
The pull request has always been the bottleneck, and now it's slowing down every organization. Agents make it trivial to open a PR. They make it only slightly easier to open one worth reviewing.
In this…
👍2🔥2❤1
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
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
👍5🔥2❤1
Software Factories
We haven't even had enough time to fully adopt SDD or build deep expertise in loop engineering, and they're already no longer the hottest topics. Now there's a new concept on the hype wave: Software Factory.
Software Factory is a software development approach where autonomous agents handle implementation, testing, and validation within standardized workflows, while engineers define requirements, architecture, quality standards, and guardrails.
The idea is that we should move from just implementation (inner) loops to building factories that orchestrate those loops (outer loop). In other words, we should create a system that can build a software on its own.
Factories can be:
🔸 Light factories: Humans are still in the loop.
🔸 Dark factories: Agents define scope, build, and ship code without anyone really reading the details.
I would say only some startups are brave enough to use dark factories (and it's also fine for pet projects). Companies where mistakes can have a real impact still prefer to keep humans in the loop.
But by the way, code generation has never been the hardest part of software engineering. The most complex part has always been understanding and agreeing on what we actually need to build, how to build it, and how to verify that we built the right thing with the expected quality.
Agents just make it more visible.
For a deeper dive:
- Addy Osmany Software Factories, Light and Dark
- Zach Lloyd Software Engineering Is Becoming Factory Engineering
- Tereza Tížková What It Actually Takes to Build a Software Factory
#engineering #ai #ai4sdlc
We haven't even had enough time to fully adopt SDD or build deep expertise in loop engineering, and they're already no longer the hottest topics. Now there's a new concept on the hype wave: Software Factory.
Software Factory is a software development approach where autonomous agents handle implementation, testing, and validation within standardized workflows, while engineers define requirements, architecture, quality standards, and guardrails.
The idea is that we should move from just implementation (inner) loops to building factories that orchestrate those loops (outer loop). In other words, we should create a system that can build a software on its own.
Factories can be:
🔸 Light factories: Humans are still in the loop.
🔸 Dark factories: Agents define scope, build, and ship code without anyone really reading the details.
I would say only some startups are brave enough to use dark factories (and it's also fine for pet projects). Companies where mistakes can have a real impact still prefer to keep humans in the loop.
But by the way, code generation has never been the hardest part of software engineering. The most complex part has always been understanding and agreeing on what we actually need to build, how to build it, and how to verify that we built the right thing with the expected quality.
Agents just make it more visible.
For a deeper dive:
- Addy Osmany Software Factories, Light and Dark
- Zach Lloyd Software Engineering Is Becoming Factory Engineering
- Tereza Tížková What It Actually Takes to Build a Software Factory
#engineering #ai #ai4sdlc
👍5🔥3✍2❤1😎1
Skills Distribution
Nowadays, skills are everywhere... Thousands of them have been written, some useful, some not so much. But the questions of proper management and distribution are still not solved, especially at scale.
Imagine a medium-sized engineering department of 50 people: 6 separate teams, 20+ applications, and 50+ repositories.
Now you start introducing SDD, shared skills for development, documentation updates, code reviews, etc. And here comes the famous human factor: someone installed the skills, someone forgot, someone installed only a few, someone updated them, and someone just didn't bother.
As a result, you have no idea who uses what, and predictable results are out of the question.
My position is pretty simple: anything that requires even occasional manual actions to keep working will never work.
The solution I chose for my team is quite straightforward:
🔸 Required internal skills are declared in the root
🔸 The skills are committed directly to the repository for all required agent harnesses.
🔸 A nightly CI job checks
🔸 Profit!
The same approach can be used for external skills and npx packages, but that would also require security checks for vulnerabilities and prompt injections. We must be much more careful with external skills.
So, what does this give me?
- The team uses the same set of basic development skills.
- The team uses up-to-date versions of those skills.
- I vibe coded a report that shows if the required skills are present in the repository and the CI job is configured.
Maybe it's not the most elegant solution. We intentionally duplicate skills across repositories. BUT! It works, and it works reliably. Moreover, it costs almost nothing in terms of internal infrastructure and maintenance.
#engineering #ai #ci
Nowadays, skills are everywhere... Thousands of them have been written, some useful, some not so much. But the questions of proper management and distribution are still not solved, especially at scale.
Imagine a medium-sized engineering department of 50 people: 6 separate teams, 20+ applications, and 50+ repositories.
Now you start introducing SDD, shared skills for development, documentation updates, code reviews, etc. And here comes the famous human factor: someone installed the skills, someone forgot, someone installed only a few, someone updated them, and someone just didn't bother.
As a result, you have no idea who uses what, and predictable results are out of the question.
My position is pretty simple: anything that requires even occasional manual actions to keep working will never work.
The solution I chose for my team is quite straightforward:
🔸 Required internal skills are declared in the root
apm.yml file (you can read about APM here).🔸 The skills are committed directly to the repository for all required agent harnesses.
🔸 A nightly CI job checks
apm.yml for updates to the installed skills and automatically commits any updates.🔸 Profit!
The same approach can be used for external skills and npx packages, but that would also require security checks for vulnerabilities and prompt injections. We must be much more careful with external skills.
So, what does this give me?
- The team uses the same set of basic development skills.
- The team uses up-to-date versions of those skills.
- I vibe coded a report that shows if the required skills are present in the repository and the CI job is configured.
Maybe it's not the most elegant solution. We intentionally duplicate skills across repositories. BUT! It works, and it works reliably. Moreover, it costs almost nothing in terms of internal infrastructure and maintenance.
#engineering #ai #ci
👍2❤1🔥1
Guns, Germs and Steel
Guns, Germs, and Steel: The Fates of Human Societies is a popular science book by American scientist Jared Diamond. The book tries to explain why some civilizations are more successful than others.
To answer this question, the author goes back to ancient history, particularly to the domestication of plants and animals.
He explores how domestication actually works, what conditions are required, and how humans have influenced the evolution and selection of plants and animals. For example, wild strawberries and modern cultivated strawberries look very different. And there are hundreds of examples like this.
Interestingly, not all animals are suitable for domestication. For example, horses were domesticated, but zebras weren't. According to the author, zebras simply have a terrible personality and bite too much 😃.
And what conclusion does he draw from all this?
One of the most important steps in the development of civilization was the transition from a nomadic to a settled lifestyle. And this transition was only possible when suitable plants and animals were available for domestication.
Another advantage was the east-west orientation of a continent. Similar climates made it easier to exchange crops, livestock, technologies, and diseases.
Eurasia stretches from east to west, while Africa and the Americas stretch mostly from north to south. According to Diamond, this is one of the main reasons why civilizations in Africa and the Americas developed differently and were eventually colonized. And during colonization, Europeans also brought plenty of unfamiliar diseases, which devastated local populations.
Overall, the book is quite interesting, and I know people who absolutely love it.
Unfortunately, I'm not one of them.
Despite the interesting concept, I found the book incredibly tedious. It was really hard for me to finish. I don't think I've ever read so much about agricultural crops in my entire life. Apparently, agriculture is just not my thing 🙃.
#booknook #science
Guns, Germs, and Steel: The Fates of Human Societies is a popular science book by American scientist Jared Diamond. The book tries to explain why some civilizations are more successful than others.
To answer this question, the author goes back to ancient history, particularly to the domestication of plants and animals.
He explores how domestication actually works, what conditions are required, and how humans have influenced the evolution and selection of plants and animals. For example, wild strawberries and modern cultivated strawberries look very different. And there are hundreds of examples like this.
Interestingly, not all animals are suitable for domestication. For example, horses were domesticated, but zebras weren't. According to the author, zebras simply have a terrible personality and bite too much 😃.
And what conclusion does he draw from all this?
One of the most important steps in the development of civilization was the transition from a nomadic to a settled lifestyle. And this transition was only possible when suitable plants and animals were available for domestication.
Another advantage was the east-west orientation of a continent. Similar climates made it easier to exchange crops, livestock, technologies, and diseases.
Eurasia stretches from east to west, while Africa and the Americas stretch mostly from north to south. According to Diamond, this is one of the main reasons why civilizations in Africa and the Americas developed differently and were eventually colonized. And during colonization, Europeans also brought plenty of unfamiliar diseases, which devastated local populations.
Overall, the book is quite interesting, and I know people who absolutely love it.
Unfortunately, I'm not one of them.
Despite the interesting concept, I found the book incredibly tedious. It was really hard for me to finish. I don't think I've ever read so much about agricultural crops in my entire life. Apparently, agriculture is just not my thing 🙃.
#booknook #science
👍3❤1🔥1