388
Explore articles, books, news, videos, and insights on software architecture, people management, and leadership. Author: @nelia_loginova
Project Hail Mary
Technical books and articles are great, but sometimes my brain needs a break. Especially now, when AI is generating more and more new things to learn every day. One of my favorite ways to recharge is reading fiction, and I recently finished the very popular Project Hail Mary by Andy Weir.
I'm not a big sci-fi fan, but I definitely enjoyed this book.
Thanks to the recent movie adaptation, the story is probably familiar to many.
A man wakes up alone on a spaceship with no memory of who he is or why he's there. As his memories gradually return, he discovers that he's a scientist on a mission in another star system.
Humanity is facing extinction. The Sun is losing energy because of a mysterious organism called Astrophage. Nearby stars are also infected except Tau Ceti. A crew is sent there to find out why it's different and, hopefully, save Earth.
Unfortunately, only the main character survives the journey.
He starts his scientific research of the star and eventually noticed a spacecraft on his radar.
And then the almost impossible happens: first contact with an alien. The problem is, how do you communicate when you don't even share the same way of producing speech? The answer is physics. I really liked the idea that laws of physics are universal, making math and science the foundation for building communication between two civilizations.
I won't spoil the rest, but the story is really engaging. Despite being a disaster novel, it contains a good dose of humor and places a strong emphasis on friendship, kindness, and mutual help. And when you finish it, you're left with a surprisingly warm feeling.
I watched the movie after finishing the book, and for once I can say the adaptation is actually good. Of course, it's much more compact and some details are simplified, but it stays remarkably close to the original story while preserving its emotional depth.
Overall, I loved it. Highly recommended both the book and the movie.
#offtop #booknook
Agent Readiness Framework
A few weeks ago I wrote that adopting coding agents requires strong engineering practices.
Test stability, linting, documentation, security controls matter much more than a particular harness or model.
Agent Readiness framework is an attempt to formalize these criteria for a particular repository and define how much autonomy can be safely delegated to agents.
The framework evaluates repos across 8 dimensions:
- Style & Validation
- Build System
- Testing
- Documentation
- Dev Environment
- Code Quality
- Observability
- Security & Governance
Based on these dimensions, the framework defines 5 levels of repo maturity:
🔸 Level 1: Functional. Basic checks: README, linters, unit tests.
🔸 Level 2: Documented. Detailed documentation and basic automations: AGENT.md, reproducible dev env, contribution guides.
🔸 Level 3: Standardized. E2E tests, observability, security scanning, maintained documentation.
🔸 Level 4: Optimized. Fast validation loops, canary deployments, build optimization. Process is optimized for fast feedback.
🔸 Level 5: Autonomous. Task decomposition, multi-service orchestration, self-healing logic, auto-remediation.
The idea is simple: the higher the maturity level, the more predictable and reliable agent results. But looking at these levels, I can see that most repos are actually somewhere between Level 1 and Level 3.
Framework authors also provide a tool to automatically measure these criteria and maturity level, but it's available only after registration and using proprietary APIs. Scanned examples you can find at https://factory.ai/agent-readiness.
There is also an open-source alternative https://github.com/kodustech/agent-readiness. The project doesn't look active, but it gets the job done. It analyzes the repo and generates a report with the overall maturity level, findings for each dimension, and suggestions for improvements. Some rules are not very accurate. Looks like the project was mainly designed for python and js code verification. But anyway the tool gives you a good sense of what to pay attention to in your codebase.
What I like about this framework is that it shows that agent effectiveness is actually limited by the maturity of engineering practices. And it provides measurable and actionable results, that are easy to convert into an improvement plan for a particular repo.
#ai #engineering
Skill Packaging
Engineering teams are actively building internal collections of skills for agents: code review, troubleshooting, design preparation, onboarding, security practices.
And it looks great until you hit the question: how do you distribute those skills across dozens of teams and multiple harnesses? For Claude you need to put skills into .claude, for Cursor into .cursor, for Gemini into .gemini, etc. And things become even messier when you need to roll out updates.
To solve this problem big companies mostly build their own in-house solutions. Smaller companies usually just copy files from some shared repository and manage this complexity manually.
I don’t like reinventing the wheel, so when my team faced the same problem, we started looking for an existing solution we could reuse. And the only actively maintained tool we managed to find was apm by Microsoft.
APM is a package manager for prompts, skills, and MCPs. In other words, it’s maven or gomod for agents.
APM package structure:
my-package/
├── apm.yml
└── .apm/
├── instructions/
│ └── my.instructions.md
├── skills/
│ └── my-skill/
│ └── SKILL.md
├── agents/
└── prompts/
name: my-projecty
version: 1.0.0
targets:
- claude
- copilot
dependencies:
apm:
- <git-address>/my-package
- <git-address>/another-package
mcp: []
apm install
.claude, .copilot, etc.). apm update. And on top of apm dependencies format it’s pretty easy to vibe-code your own internal skills marketplace.
AI Engineering
I strongly believe that if you want to use any technology effectively, you need to understand how it works under the hood. Especially in software engineering.
So if you haven’t looked into LLM internals yet, I’d highly recommend reading AI Engineering by Chip Huyen. The book was published in December 2024. And as AI is moving extremely fast, you might think it’s already outdated. Yes and no.
The book focuses on fundamentals. And they don’t really change that fast. You won’t find hype topics like skills, harnesses, or agents orchestration there. But for building structured understanding of how AI works, you don't actually need them.
What I personally found useful:
🔸 Core LLM concepts: tokenization, training and post-training processes, datasets preparation. This part is very similar to Mashing Learning Crash Course from Google.
🔸 Model evaluation: quite complex but interesting topic about model output results and their comparison. The book covers ranking, model specialization, public benchmarks and AI-as-a-judge approach.
🔸 Prompt engineering: good reference about context and prompting. Additionally, the author described different security aspects of using prompts, that part really extended my thoughts about what can go wrong.
🔸 Finetuning: a deep dive into different ways to optimize models. You need to be a good mathematician to understand this part. So I was really glad I'm not an ML engineer 😃 (huge respect to all ML experts, it's really hard).
🔸 User feedback: basic patterns on how to collect feedback, what to measure and why, common pitfalls.
To sum up, this book is really great to structure your knowledge about modern AI systems. Once you have that foundation, it becomes much easier to navigate all the new tools, patterns and paradigms that appear almost every month.
#booknook #ai #engineering
Inside the Context Window
What makes your work with agents efficient? Chosen model? Harness? Instructions clarity?
I would say that first of all it's the quality of the context you provide.
Context is everything the model sees before it generates a response.
Two facts to know about the context:
1. It's limited (and costs you money 💰 ).
2. The longer the context, the worse the results.
So context engineering is a set of practices to fill the context with just enough information to get the desired results. The main goal is to balance the amount of context given: not too little and vague, not too much and detailed.
The first step in context engineering is to understand what the context actually contains. And it’s not just your prompt.
Typical context structure:
🔸 System prompts & instructions: the hidden layer of system prompts, safety policies, behavioral rules, role definition. Usually it's part of the harness and you cannot change it.
🔸 Project context: AGENT.md\CLAUDE.md, repo structure, settings. It's added as a first prompt to any session you open with the agent.
🔸 Available tools: skill descriptions, MCPs, available CLIs.
🔸 Retrieved information: loaded files, data from RAG system.
🔸 State & history: The current conversation, including user, model and tools responses.
🔸 Reasoning: intermediate reasoning results (thinking mode).
🔸 Long-term memory: knowledge base from previous conversations like user preferences, summaries of working sessions, facts the agent was asked to remember for future use.
🔸 Your prompt: the actual user request.
As you can see, the context is already filled with a lot of information before you even start the real work. To make agents efficient, keep their context clean and focused. Don't overload it with unnecessary information.
#ai #engineering
Agent Harness
Harness is a new buzzword introduced by modern AI.
Let's check what it is and why it matters.
The term harness refers to the logic around LLM that controls and guides how an agent operates. It's not the agent itself but the tools and guardrails that help it achieve better results.
A harness typically includes:
🔸 System prompts
🔸 Tools, skills, MCPs and their descriptions
🔸 State & memory (current task state, past runs, intermediate states)
🔸 Planning & task decomposition
🔸 Context engineering strategies
🔸 Safety & guardrails (allowed tools, rate limiting, prompt injection protection)
🔸 Bundled infrastructure (filesystem, sandbox, browser)
🔸 Subagent orchestration logic
🔸 Hooks/middleware for deterministic execution (compaction, continuation, lint checks)
Well-known examples of harness ecosystems include Claude Code, Cursor, LangChain.
The overall trend is that each model provider now builds and promotes its own harness. But because each provider uses different system prompts, model tuning techniques and context management strategies, the same model in different ecosystems will produce different results.
So the same model does not mean the same agent. And the real competition is no longer between models. It’s between harnesses fighting for your workflow and your budget.
#ai #engineering
SDD: OpenSpec
Last week I wrote about spec-driven development (SDD) as a new wave of frameworks for vibecoding. I tried a few of them. If you’re just exploring SDD, I’d suggest starting with OpenSpec.
Why?
For me, it felt the simplest and least overloaded.
To get started, you basically need 3 commands:
/opsx:propose
Here you describe what you want to build: bugfix, feature, design or something else (but using SDD for bugfix still feels like overkill).
What I liked:
- You get a structured design (design.md)
- It explains why decisions were made
- It adds open questions for clarification to think more
- You get tasks.md with detailed steps what will be done
At this stage I had to iterate a few times because some assumptions were wrong. But in the end I identified gaps in initial feature definition and got a clear plan of future changes. The good thing is that changes at this stage are cheap.
/opsx:apply
If you’re ok with the design, you can ask the agent to execute the plan. It's possible to execute all tasks at once, split them or run multiple agents for parallel execution. Implemented steps are marked as completed in tasks.md.
/opsx:validate
This is a control step. You can request the agent to validate that the implementation matches the design. Because… agents still drift and make mistakes.
Of course, OpenSpec contains other interesting commands, but you can add them later when you get used to SDD.
How is it different from Plan mode?
Plan mode mostly generates tasks.md. No design. No real spec.
SDD reframes the work into a design-first approach and adds additional prompts to do it well.
And honestly, I liked the preparation phase result much more.
I wouldn’t use it everywhere, but for refactoring or feature development it looks really good.
#engineering #ai #sdd
Spec-Driven Development
Do you like frameworks? I'm quite skeptical about them.
They try to solve everything at once and end up adding complexity where it’s not really needed. But engineers love inventing frameworks. Vibecoding is no exception. A new family of frameworks is called spec-driven development (SDD).
The main idea is to write a "spec" before writing code with AI.
A spec is a structured description of WHAT should be done and WHY. In classic terms, a spec is like an interface, generated code is like an implementation.
Main principles:
🔸 Spec-first. A thoughtful spec is written first, reviewed and then used in a development workflow.
🔸 Spec-driven. The spec is kept in git repo and it’s used to evolve and maintain the feature.
🔸 Spec-sourced. Only the spec is edited by human, the code is edited by AI-agent.
Development workflow:
intention -> requirements -> design -> tasks -> implementation
The Minto Pyramid
Do you know how to structure your docs to make it readable?
The Minto Pyramid Principle is very famous concept to organize docs, presentations and your own thoughts. I met it many times in different resources, so I decided to read the book as an initial source of truth.
Surprisingly, the book was difficult for me, mostly because of academical language and a lot of samples from economic and marketing area. It took me 4 months to finish it and 3 more months to prepare its overview 😃.
The idea is simple:
🔸 Put the main message at the top. It can be a key point, idea, or even a question.
🔸 Then add supporting arguments. Keep them consistent, arguments should of the same type and detail level.
🔸 On the next level add facts and details that back those arguments.
🔸 Each level should summarize what’s below it.
🔸 You can go through pyramid in both directions: from top to down (presentations, explanation) or vice versa (research).
🔸 Use either induction or deduction when moving between arguments, but don’t mix both.
The overall concept looks obvious. It even reminds me of a math logic course at the university.
But in reality I've seen a lot of unstructured, difficult-to-follow documents. And good structure is important not only for humans, but now it's even more important for AI agents. That’s where this book can help. It doesn't just teach how to write readable docs, it teaches you how to organize your thoughts and ideas so others can easily understand you.
#booknook #softskills #communications #documentation
Uber: Agent-Centric Organization
Looking for inspiration on how to apply AI in your team? Then check Uber: Leading engineering through an agentic shift where the Dev Platform team presents Uber's AI adoption approach and its current state.
Uber's agent platform includes:
🔸 MCP Gateway & Registry. Central MCP gateway to expose external and internal MCPs and provide a secure sandbox for experiments.
🔸 ML Michelangelo platform. An agent builder with no code or SDK solutions with built-in visualization, telemetry, tracing.
🔸 AIFX. A tool to access internal agents infrastructure: provisioning, discovery, configuration, background tasks.
🔸 Minion. Background agent platform to integrate them with CI\CD, slack, PRs.
🔸 Code Inbox. Unified inbox for PRs developers need to review. It tries to find the most relevant person to review the code, track review SLOs, help reassign PRs or make escalation if necessary.
🔸 uReview. Review pipeline that enriched with internal context, best practices, guidelines.
🔸 Autocover. A system to generate unit tests. 3x higher code test quality than generated by generic agent, 5000+ tests generated per month.
🔸 Automigrate. A tool to implement large-scale changes. It consists of problem identifier, code transformer (openwrite, piranha or agents), validation, and campaign manager (route PRs to reviewers, split changes on reasonable PRs, rebases, changes prioritization)
As you can see the team uses AI to support the entire development lifecycle. The whole strategy sounds like "Enable Uber engineers to focus on creative work by eliminating toil". By toil they mean upgrades, migration, bugfixes, writing docs, cleanup.
To sum up, Uber has a very reasonable strategy for AI adoption. Of course, they made a huge investment to their agent platform. But one simple recipe suits everyone: define the most tedious repeatable tasks and give it to AI. People are burnt out, agents are not.
#ai #engineering #usecase
AI-Generated Architecture Diagrams
If you've ever built architecture diagrams, you know how time-consuming it can be.
I use drawio and sometimes I spend hours aligning elements to make the picture compact, clear and not overloaded with elements and connections between them (hello to my perfectionism).
The great news is that AI now can help with this task also using Drawio MCP. Initially I was quite skeptical. Anyone who has tried to generate a diagram by architecture description will understand me 🙂.
Surprisingly, the result is good. Not perfect, but really good.
I tested it with creating new diagrams and modifying existing ones according to some template. New diagrams are a bit clumsy, so you need to clean them up. Modification according to the template shows better results, it aligned around 10 different diagrams to the same template within minutes.
Of course as with any AI agent task you need to tune the output, explain mistakes and save lessons learnt to the memory. But finally I got desired result much faster then doing that on my own.
#engineering #ai #tips
The Developer Skill Shift
New AI tools appear every day, new coding models become smarter and smarter, AI agents can automate more and more work. It seems impossible to keep up with everything and easy to get lost in all this diversity. And the common question is "Are we gonna be replaced by AI soon?"
In the last few months I attended multiple AI events, watched the latest talks from conferences, read a lot of blogs and discussions. So what I can say for sure is that the developer role is changing. And this change is not about a future where anyone can just vibe-code anything. No. What we give as an input for LLMs will be multiplied in the final result. Garbage in -> garbage out.
This means that developers must have much more professional skills than ever. And it's not the knowledge of particular framework or technology.
New paradigm prioritizes a different set of skills:
🔸 System Design: knowledge of architectural patterns, trade-offs and cost analysis.
🔸 System Thinking: ability to understand a system as a whole, analyze consequences from the changes, build the system of checks and balances for AI agents.
🔸 Critical Thinking: ability to challenge AI generated results.
🔸 Product Thinking: understanding the business context and real problem to solve, product roadmap and evolution.
🔸 Communication Skills: ability to clarify requirements, discuss architecture, clear and in detail explain our intensions to AI assistants, remember "garbage in -> garbage out."
Of course, all those skills are not really new. But previously we expected them from more senior positions like senior developers, architects and leads. Now they are expected from every engineer.
But the important thing is that we are still engineers. We still transform our knowledge and expertise into working products.
AI doesn't replace expertise. It gives us tools to produce better results faster, making strong engineers even stronger.
#engineering #ai
The Let Them Theory
Sometimes we plan which book to read. And sometimes the book we need just finds us.
That's exactly how I got "The Let Them Theory" by Mel Robbins. I went to the bookshop and saw this green-covered book on multiple stands. I bought it a bit spontaneously. And for me it was the right book at the right time.
So what is this book about? It's about interaction between people.
The theory is very simple and consists of 2 parts:
✅ Let Them. All human beings have a hardwired need for control. But the truth is that the only person we are in control of is ourselves. Our actions, our feelings, our reactions. Other people will do what they want to do. As Mel writes in the book: "Instead of driving yourself crazy trying to manage or please other people, just Let Them." Let them have their own reactions, express their own opinions, make their own mistakes.
✅ Let Me. We cannot change and control other people, but we can change our reactions to their behavior. It's a choice to be proactive and get opportunities that we want.
The book has a really good metaphor for the whole theory. Imagine that situations and people around you are like a weather. We cannot change it but we can adapt to it - get warmer clothes, take the umbrella, or just stay at home. It's our power to choose how to respond.
If the theory is so simple and consists only of Let Them and Let Me, what are the other 300 pages about? The author applies this theory to many different life situations from an annoying coughing passenger sitting next to you on a plane to breaking up with the partner.
"The more you allow people to live their lives, the better your life will get" - the author writes.
The book helps us to understand and build healthier internal boundaries, stop wasting energy expecting other people to behave as we want.
I would say the book teaches adults to be adults.
The whole theory sounds a bit counterintuitive if we think about how to apply it at work. There is a separate guideline on applying The Let Them Theory in leadership. I will write about that in the next post.
#booknook #softskills #communications
Scale Cube
In IT, we work in a very complex domain. We have to keep a lot of things in our heads at once: technologies, patterns, trade-offs, limitations.
That's why I like simple models that help me stay focused and remember technical concepts.
One such model is Scale Cube. This is the model introduced in 2009 in the book "The art of scalability" and it suggests 3 dimensions for scaling:
🔸 Horizontal scaling: duplicate similar things, clone data, add more replicas.
🔸 Functional decomposition: split application to multiple services.
🔸 Sharding: split data into subsets by region, tenant, hash, or range.
The starting point is always monolith.
The end point is near-infinite scale with all 3 dimensions implemented together (see diagram in the post).
That's it. It's very simple and powerful. If you want to scale something you have only 3 strategies to do that 😎. So you don’t need to waste time reinventing the wheel.
#architecture #engineering #scalability
1001 GenAI Use Cases
Over the past year, AI has been everywhere, even the coffee machines seem to be talking about it.
Google collected over 1001 GenAI use cases from their clients. For me it's really interesting to see how different businesses adopted AI capabilities.
So I picked the top-5 the most impressive to share with you:
🔸 In-car assistant (Volkswagen of America, Mercedes Benz): Voice assistant that can explore user's manual and answer questions like "How do I change a flat tire?" or "What does this red indicator mean?". I think that's an absolutely amazing idea especially for drivers like me 😃
🔸 Intersatellite communication (Satlyt): In-orbit AI workloads to orchestrate intersatellite communication and routing. This is a real "rocket science" example.
🔸 Emotional temperature of conversations (704 Apps): Audio content from car rides goes to an LLM and risky language patterns generate alerts. The main idea is to improve safety for both drivers and passengers.
🔸 Driver safety (Geotab): AI analyzes billions of vehicle data points for fleet optimization, safety, and sustainability on the roads.
🔸 Logistics networks (UPS): building a digital twin of the distribution network (live simulation environment) to show where delivery is at any time.
#ai #usecase
How Anthropic Writes Skills
Last week Anthropic published lessons learnt of how they build agent skills internally. It's quite interesting to read recommendations from the company that introduced the concept in the first place.
Key ideas:
🔸 Don't be obvious. Model already knows how to code. A skill should provide instructions that change default agent behavior, not repeat the data the model was trained on.
🔸 Build a gotchas section. Add common mistakes and lessons learned. This helps the agent avoid repeating the same failures.
🔸 Use progressive disclosure. A skill is not just a SKILL.md. It can include additional files that are loaded on demand, reducing context overload.
🔸 Don't be too specific. Give the agent information it needs, but leave the flexibility to adapt to the situation.
🔸 Separate configuration from instructions. Store setup data in config.json or collect required input from the user.
🔸 Write description for the model, not for humans. A description should help the model to understand when the skill should be invoked.
🔸 Use long-term memory. Skills can maintain their own data in a subdirectory and reuse it across executions.
🔸 Automate where possible. Not everything should be a prompt. Some actions can be automated with helper scripts and functions.
Unfortunately, the article doesn't provide any guidelines of how to evaluate skill effectiveness. It's still not clear how to understand if a skill actually works, how to compare two versions of the same skill, or how to detect that a skill is no longer useful.
Provided recommendations are based mostly on observations of how popular internal skills are structured. It's useful but not measurable.
So despite the fact that skills are the most powerful agent extension now, evaluating them remains on of the hardest engineering problem.
But that's another story.
#ai #engineering
The Fearless Organization
The most dangerous teams are the quiet teams. There are no disagreements, no bad news, no conflicts. Looks like harmony until the real incident.
That's the topic of the book The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth by Amy C. Edmondson.
Amy is a professor of Leadership and Management at the Harvard Business School. She has studied the phenomenon of psychological safety and its impact on team performance for many years across different organizations.
She defines psychological safety as follows:
a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes, and that the team is safe for inter-personal risk taking.
Ralph Loop
Underterministic nature of AI sometimes produces very interesting engineering solutions. One such example is Ralph (or Ralph Wiggum) Loop.
This is an AI coding pattern inspired by The Simpsons character Ralph Wiggum, known for saying weird things with high confidence 🙃.
The idea is simple: The agent can be dumb in a single iteration. But if it keeps retrying with feedback long enough, it eventually converges.
The loop steps:
Start a new agent\subagent -> load task + memory -> execute 1 selected task -> run validation -> save learnings -> commit progress -> repeat
passes:true or it reaches the maximum number of iterations (default is 10).
ReasoningBank
Currently AI agents have one major limitation: they cannot learn. I mean they don't learn from their experience or from the results of completed tasks. Once the model is trained, all we can do is to tune our prompts or enrich results with domain data from RAG.
Researchers from Google started exploring how to overcome this limitation and introduced the concept called ReasoningBank.
The overall idea is simple:
1. The agent writes down the result of successful or failed tasks into a dedicated md file.
2. During task execution, the agent searches the ReasoningBank and pulls relevant memories into the context.
3. Then it uses an LLM-as-a-judge approach to self-evaluate the result, analyze the trajectory of reasoning, and extract success insights or failure reasons.
Each file has the following structure (very similar to skills):
- Title: identifier of the core strategy.
- Description: short summary of the memory item.
- Content: reasoning steps, decision explanation, or operational insights extracted from past experience.
To be honest, benchmark results compared to other agent memory approaches do not look extremely impressive:
ReasoningBank without scaling outperformed memory-free agents by 8.3% on WebArena and 4.6% on SWE-Bench-Verified.
CliftonStrengths 34
I recently passed the CliftonStrengths 34 assessment, so today I will share what it is and how it can be useful for your career.
CliftonStrengths is a framework that identifies your natural talents that help create value at work.
It was launched by Gallup in 2001, and since then more than 26 million people have taken it.
So it's based on real data and many years of consulting experience.
The main idea is that we should focus on our strengths to achieve results and not try to improve our weaknesses.
How it works:
- 200 questions
- 4 strength domains: executing, influencing, relationship building, and strategic thinking.
- 34 strength areas within those domains.
- All 34 themes are ranked in a personal order from the strongest to the weakest.
- Top-10 are our main talents to focus on.
The interesting part is that every strength has both a positive and a negative side. It can help you succeed or hold you back.
For example: Learner. The person with this strength quickly picks up new topics, constantly extend their knowledge. But it's easy to get stuck in a “forever student” mode.
The test is really helpful from self-reflection perspective:
🔸 Once you know your strengths, you can rely on good parts and mitigate the downsides.
🔸 The less you do the work that isn’t natural to you, the more productive and energized you are.
🔸 We assume others think and work like we do. But they don't. And this is our advantage to use.
What it gave to me? First of all, I realized that I really do the work I'm naturally good at (hello, imposter syndrome). Second, I started noticing my strengths in real situations and using them more consciously.
So the assessment is a helpful tool to understand what to focus on to achieve better results. And it’s a good starting point to rethink your day-to-day activities and align it more with what you enjoy.
#softskills #leadership #productivity
Building AI-Powered Team
AI adoption is one of the biggest challenges and at the same time one of the biggest opportunities for business.
Some teams report significant productivity boost. Others say: “AI might be useful for some tasks.”
So what’s the difference?
AI adoption is not about access to the tools. Just buying licenses and giving them to engineers doesn't work. The team need to rethink how they work and integrate these tools into their daily workflow. And that’s already classic change management task.
On this topic, I recently came across the GitHub Internal Playbook for building an AI-powered workforce. They highlight that AI adoption is not really a technical problem, it’s a human one.
GitHub suggests 8 pillars to drive adoption at the organization level:
- AI advocates. Internal champions who scale adoption through peer-to-peer influence and feedback.
- Clear policies. Defines rules for using AI.
- Learning & development. External and internal training and education.
- Metrics. Track adoption, engagement, and business impact.
- Ownership. A central owner who orchestrates the program and drives the overall strategy.
- Executive support. Visible leadership commitment and strategic vision.
- Right tools. Different tools for different roles.
- Communities. Peer-to-peer learning, knowledge sharing, and collaborative problem-solving.
And in reality, the key part here is the people on the ground, the experts who drive the change, adapt the tools to real tasks, and teach others. This is also covered in more detail in the companion article Activating your internal AI champions.
You can’t roll out AI top-down.
You can’t standardize it with one template for everyone. Every team has its own context. Without understanding it, any “unified approach” will fail.
#leadership #ai
Rethinking High Availability
Have you noticed how the world has changed? Again.
A year ago I used to say that in public clouds three availability zones are enough. Each zone is in its own data center, data centers are located within ~100 km of each other, and the probability of losing two at the same time was considered very low.
There is no such assumption anymore.
Today, losing two or even all three availability zones in a single region is no longer extremely rare. It’s something that can actually happen.
What does it mean in practice?
If your business requires system 99.5% availability or higher, relying on a single region is not an option.
Technically it means:
- Using multiple regions even in public clouds (or even different cloud providers).
- Switching to cold or hot standby setup.
- Storing backups in a different region.
- Regularly testing DR scenarios.
Disasters do happen.
The question is whether your system is ready or not.
#engineering #systemdesign #reliability
Tech Blogs Reading List
Any technical leader or architect needs to stay on top of the industry trends and develop a broad perspective on architectural solutions and engineering practices.
For that, I read blogs from big tech companies. They give me a sense of what’s going on, show real-world architecture examples, inspire with new ideas that I can try with my teams.
List of blogs:
- https://www.uber.com/en-IN/blog/engineering
- https://medium.com/airbnb-engineering
- https://engineering.fb.com/
- https://www.linkedin.com/blog/engineering
- https://netflixtechblog.com/
- Pinterest_Engineering" rel="nofollow">https://medium.com/@Pinterest_Engineering
- https://engineering.atspotify.com/
- https://aws.amazon.com/blogs/architecture/
- https://github.blog/engineering/
- https://blog.booking.com/
- https://developers.openai.com/blog/
- https://research.google/blog/
- https://www.anthropic.com/engineering
- https://www.anthropic.com/research
I use Feedly to keep everything in one place and check it 1-2 times a week. Most of these blogs are available on free plan.
I’m always curious what others are reading. So if you have good resources, feel free to share in the comments 📚.
#tips #learning #engineering
Are You Ready for Coding Agents?
Coding agents are booming. Only the lazy haven’t yet talked about how they built their own agent. But the reality is much more complex. To get the benefits from AI your development ecosystem should be ready for it.
Garbage in -> garbage out, remember?
Low coverage, flaky tests, undefined code style, long verification cycle, poor documentation. Add AI-generated code to this and you will increase the entropy and reduce overall system stability.
To produce predictable results the engineering infrastructure must be stable.
By infrastructure I mean:
🔸 Linters and automated code style verification.
🔸 High unit tests coverage (>=80%).
🔸 Contract tests for all public APIs.
🔸 System, integration, and E2E tests that run at least once a day.
🔸 No flakiness. You must fully trust your tests and CI process otherwise you cannot guarantee that agent won't break anything.
🔸 Security gates. Secret management, vulnerability checks, SAST verification.
🔸 Documentation. Requirements, architecture, guides, internal agreements. Everything that helps the agent understand how we work.
The most non-obvious part here is test flakiness.
What's the problem with just rerunning the test?
Developers know the context, the agents do not. It means that they will try to fix the test, making it weaker, or modify the code, introducing a bug. The overall result is worse code generation and increased maintenance overhead. So each rerun must be treated as a bug report, not a solution.
If you check how different companies adopt AI, you can notice that all success stories are based on existing powerful CI\CD processes that can safely check AI agent output (Google, Claude Code, Uber, Google, Airbnb).
AI adoption doesn't just bring new tools and processes but also forces the best engineering practices we already have.
#engineering #ci #ai #agents
Claude Code: Behind the Scenes
Claude Code is one of the most popular developer tools today. But did you know that initially it was just a side project inside the company?
This and many other interesting details are discussed in an interview with Boris Cherny, the creator and head of Claude Code at Anthropic.
Key insights from the interview:
🔸 Boris built Claude Code as a bash chat-based tool when he was learning public Anthropic APIs and how people use the model. It quickly became popular among other employees, that led to a future public success.
🔸 Claude writes ~80% of the code at Anthropic on average.
🔸 Boris ships 20-30 PRs a day by running 5 parallel Claude instances. He starts with a plan mode, iterates over the plan, then let the agent do the implementation. Since the Opus 4.5 release, Claude writes 100% of his code.
🔸 There is no "right way" to use Claude Code. According to Boris, "The way we build cloud code is to be hackable because we know every engineer's workflow is different. There's no one way to do things. There's no two engineers that have the same workflow."
🔸 The Claude team doesn't write Product Requirement Documents (specs). They just build dozens of working prototypes before shipping a feature.
🔸 Claude Code reviews every pull request at Anthropic and it catches ~80% of bugs. There are 2 rounds of review: the first is performed by AI agent, the second is always done by human who finally approves the changes.
🔸 Claude Cowork is intended to provide Claude capabilities for non-engineers. The tool was built in ~10 days and the main engineering complexity here is about safety: building classifiers, a shipping VM, OS-level protections against accidental file deletion, and rethinking the permission model for non-technical users.
🔸 There are no technical grades inside Anthropic. Everyone has the same title "Member of Technical Staff", that highlights the assumption that everyone can do everything: product, design, infrastructure, research.
During the interview Boris repeated multiple times that it's more important to ship fast and get user feedback early than to wait and deliver a fully featured product. That's why they built their engineering culture around prototyping. I think it's one of the reasons Anthropic products are so successful.
By the way, if you haven't tried Claude Code yet I highly recommend to do so. And as a starting point you can use Claude Code In Action Anthropic course.
#ai #engineering #usecase
10 Tips for AI-Assisted Coding
10 Tips To Level Up Your AI-Assisted Coding is an absolutely wonderful talk from the latest NDC London conference. Alex Stensby shares practical recommendations on how to improve interaction with coding agents:
🔸 Context is King. Context is a limited resource, so we must actively manage it:
- Provide enough context for the task: role, file references, specs, schemas, logs, etc.
- Explicitly request the agent to ask additional questions if more information is needed. It helps to prevent hallucinations.
- Start a new context for each new feature to keep agent focused.
- Summarize the progress and save it to md file for future work.
🔸 Rules & Docs make all the difference. Actively document contracts, specifications, database schema, use AGENT.md to set the initial context of the project, build a library of reusable skills.
🔸 Make a plan. Always use plan mode. It forces the LLM not to go with the first suitable solution but to reflect on the task. Review the plan, give feedback on it, "make it your plan".
🔸 Break it down. Break complex tasks into smaller manageable pieces of work, keep track of them in md file or github issues, track the progress.
🔸 Pick the right model. Use a cheaper model for simpler tasks. But Alex said that he uses the latest Opus 4.x for all coding tasks now.
🔸 Use the tools. Turn repetitive prompts into skills or slash commands, use subagents to run work in parallel or focus on specific task types (e.g., architect, code reviewer, QA specialist)
🔸 Git everything & learn from rabbit holes. Ask AI to learn from and reflect on its mistakes, save results in md files and add it to the memory.
🔸 Power up with MCPs. Use MCPs carefully, especially with databases or other resources where AI can make dangerous changes, better to give it read-only access only.
🔸 Release the agents. Use multiple agents to solve different tasks, orchestrate them, fork their context to explore other options, send them for remote execution when needed.
🔸 Be the human in the loop. Agents make mistakes. That's a fact. So we must review and verify work results.
I definitely recommend watching the full video, as it contains not only common tips for using AI agents but it also has a lot of practical examples of Claude Code usage.
#engineering #ai
Leading with Let Them
Leading with Let Them is a separate guide on how to apply The Let Them Theory in leadership. The guide is published separately from the book and co-authored with David Gerbitz, an executive coach who previously held senior leadership roles at Amazon, Microsoft, Yahoo, and Qurate Retail Group.
Key recommendations:
🔸 Lead yourself (Let Me). Leader defines the mood of the team: "If you’re not managing your own emotions, mindset, and reactions, you can’t expect your team to manage theirs."
🔸 Choose inspiration over micromanagement (Let Them). Let Them means start creating the conditions where the team can grow: let them think, decide, take ownership and accountability of their work.
🔸 Choose influence over control (Let Me). Leadership is about building connection, trust and understanding. Recognize our triggers, test our beliefs, pause before responding, lead by example.
🔸 Focus on outcomes (Let Me). Provide a clear vision of what should be achieved (the “what” and the “why”) and support the team on their way when needed.
🔸 Reframe mistakes as growth opportunities (Let Me).
🔸 Be personable and present (Let Me). Give people our time and our attention and encourage the team to do the same for each other. Put away the phone and focus on the moment.
🔸 Be consistent (Let Me). Consistency is a base of certainty, certainty is the base of safety. Safe environment is a foundation of successful teams.
As you can see, most of the items relate to the Let Me part. This highlights that a leader should control and adjust their own behavior to make the team effective.
In addition to the main principles the guide contains practical recommendations like do's and don'ts. So it can be really helpful when applying those principles in real life.
From my perspective, the guide is very useful and it's definitely a must-read for leaders, especially those who are just starting their leadership career.
When I read it I realized it describes many things I already do in practice: sometimes intuitively, sometimes based on experience. I just know it works and it reflects my leadership style. And now I have a very good reference with this knowledge to recommend.
#softskills #leadership
Residual Architecture
The business environment is dynamic and complex: markets change, new regulations appear, technologies evolve. And systems we design must operate within this complexity. That's where Residuality Theory of Architecture starts from.
The theory was developed by Barry O'Reilly and was presented at multiple conferences. One of the talks was on GOTO 2025 Residues: Time, Change & Uncertainty in Software Architecture.
The main idea:
Randomly stressing an architecture produces architectures that are more likely to survive unexpected events in their environment.
Self-Doubting
Have you ever doubted your decisions?
I do all the time.
Previously I thought that the reason was the lack of expertise or relevant experience. But now I understand that the answer is much simpler: self-doubt is OK.
Doubts motivate us to ask more questions, discover alternative solutions, closely collaborate with the team, listen and, most importantly, hear another points of view. Doubts help us to stay curious and not rush to choose the first answer that looks convincing.
A leader who doesn't doubt their decisions is dangerous. They are blind and deaf.
But be careful: self-doubt is often a contributor to imposter syndrome. By understanding your limiting beliefs and triggers, you can look at your self-doubt more rationally.
Funny fact: according to the US National Science Foundation the average person has about 12,000 to 60,000 thoughts per day, and 80% of them are negative 😲. Doubting itself can be a survival mechanism, as it push us to carefully assess risks and potential consequences before taking action.
#leadership #softskills
Can you see the forest for the trees?
How often have you seen developers stuck in code review discussing some method optimization or "code excellence"? Spending hours or even days trying to make code perfect? Did that really help build a well-architected solution?
Developers often get stuck in small details and completely lose sight of the bigger picture. That's a very common mistake that I see in engineering teams. As a result, there are perfect classes or functions and complete mess in overall structure.
A proper review should always start with a bird’s-eye view:
🔸 Component structure: Are changes implemented in the components\services that are actually responsible for this logic?
🔸 Module structure: Are changes in the modules you expect them to be (public vs private, pkg vs internal, etc.)?
🔸 Public contracts: Review how your APIs will be used by other parties. Are they clear, convenient, easy to use, and easy to extend?
🔸 Naming: Are module, class and function names clear and easy to understand? Don't they duplicate existing entities?
🔸 Data model: Is the domain modeled correctly? Does the model follow single responsibility principle?
🔸 Testing: Are main cases covered? What about negative scenarios? Do we have proper failure handling approach?
In most cases, there’s no point in reviewing code details until the items above are finalized. The code will likely be rewritten, maybe even more than once.
That’s why specific lines of code should be the last thing to check.
Details are cheap to fix.
Structure and contracts are not.
#engineering #codereview