This book is about something much more interesting: how to set up your project and development process so that AI agents can do most of the actual work — guided by clear intent, context, guardrails, and verification.

Agentic Spec-Driven Development: A Practical Method for Using AI to Build Complete Specifications for Software, Products, and Knowledge Work

More than spec-driven development

The core idea is that when AI writes the code, engineering judgment does not disappear. It moves into the specification. You define the intent, constraints, architecture, and expected behavior. The agent figures out how to implement it.

But this does not mean writing a huge specification upfront. The book acknowledges that you cannot think of everything in advance. Specifications evolve iteratively as implementation exposes missing decisions, conflicts, and edge cases.

That makes the approach much more pragmatic than it might sound from the title.

Intent over instruction

A key idea of this book is intent over instruction. Tell the agent what you want to achieve, why you want it, which constraints matter, and where the guardrails are. Then let it reason about how. You do not need to dictate the answer. You need to give AI enough context to find it.

The same principle applies to rules. Do not try to prevent every possible failure with more and more natural-language instructions. Keep rules generic and use deterministic mechanisms such as scripts, tests, and architecture fitness functions when you need deterministic behavior.

A practical guide to agentic development

What makes the book especially useful is that it goes far beyond specifications. It covers prompts, durable rules, token efficiency, sessions and memory, project knowledge, artifacts, auditability, tests, architecture fitness functions, and the overall development process.

It even provides a complete sample setup with ready-to-use rule files.

So you can either try the author’s method as it is or take the underlying concepts and integrate them into your own setup. If you are new to agentic development, this is a great foundation because it explains not only how to write specs, but how to structure an entire project around AI agents.

And if you already work extensively with coding agents, it is still worth reading because it makes you reflect on your own setup.

Despite the title, I would almost call this a book about harness engineering. And that is exactly why I found it worth reading.

Harness Engineering: Designing the Systems That Make AI Coding Agents Reliable

The book starts with the fundamentals: what exactly is harness engineering, and why is it important? From there, it covers a broad range of topics such as context and state, workflows, verification, team behavior, handoffs, recovery, and governance.

One theme runs through the whole book: Make knowledge, rules, and expected behavior explicit. The goal is to structure the context, processes, and environment around coding agents well enough that more and more of the work can be automated reliably.

Interestingly, many of the suggested practices also make sense for human software teams: clear responsibilities, explicit rules, defined processes, and automated verification. With agents, however, these things need to be even more explicit so they can actually follow them.

This broad coverage is also the biggest value of the book for me. It makes you aware of how many different aspects influence whether coding agents work reliably and provides plenty of patterns and ideas to think about.

The downside is that it is not an easy read. It is well structured, but often feels more like an instruction manual. Examples are included throughout the book, but they often stay on an abstract, meta level. I frequently understood why something was important, but missed the concrete example that creates the real “aha” moment.

I think the book would be much stronger with simpler explanations and one realistic sample project used consistently throughout.

So, important content and definitely worth knowing about - but probably not the best book on harness engineering. 🤷‍♂️

Context Engineering Fundamentals: Learn Prompt Design, Context Memory, and Agent-Based AI with LangChain, RAG, and MCP for Next-Gen LLM Applications by James Acklin focuses mainly on building LLM applications.

It covers prompt design, context and memory, RAG, MCP, agent patterns, and application architecture.

The book includes lots of exercises and code samples, mostly using LangChain, which illustrate the concepts very well and help you understand how things actually work.

Even though this is not a book about coding agents directly, many of the concepts transfer. For coding agents to be productive, they need the right context at the right time - focusing on relevant information while ignoring what is not needed. Understanding the fundamentals of context engineering helps a lot when thinking about how to provide that context.

The book also goes beyond managing the context window. It explains how complete LLM applications are built and how the different pieces work together.

It finishes with a few case studies that put those concepts into practice. Even if you are not planning to build an LLM application yourself, I found this part interesting. It gives you a better idea of how LLMs can be embedded into real applications and also a better understanding of how tools like GitHub Copilot work behind the scenes.

So, while this is not a practical guide for coding agents, I think it is well worth reading if you want to build a solid foundation in context engineering and become better at working with agents.

Staff Engineer: Leadership Beyond the Management Track

The book explains different senior individual contributor roles, such as Tech Lead, Staff Engineer, and Software Architect. More importantly, it explains what is expected from these roles beyond technical expertise.

And that is probably the most valuable part.

At this level, engineering is no longer only about writing better code yourself. It is about creating leverage. You are expected to influence technical direction, improve collaboration, guide decisions, mentor others, and help the organization make better trade-offs.

In that sense, the book gives a useful map for engineers who want to grow without becoming managers. It also gives practical guidance on how to move toward these roles, what kind of work gets you there, and what expectations usually come with the title.

That said, I think the relevance depends heavily on context.

If you work in a smaller company, this book may not be that useful. Many smaller organizations simply do not have such a clearly defined individual contributor ladder. The same person may be developer, architect, tech lead, mentor, and delivery driver all at once — without anyone calling it “Staff Engineer.”

I also doubt the book is highly relevant if you or your company do not care much about titles. A lot of the book is about understanding the shape of these roles inside larger organizations. If your environment is more pragmatic and less title-driven, the value is more limited.

The second half of the book contains stories from people who took that career path. I skipped those completely. Maybe they are useful if you want personal career examples, but for me they were not worth the time.

TLDR;

The book is useful if you want to understand how senior technical roles work in larger companies and how to grow beyond the management track. It is less useful if you are mostly interested in better engineering practices, smaller-company realities, or hands-on technical leadership without the title system around it.

Thinking Fast and Slow

The key idea

The core thesis of the book is that our thinking can be described as two systems.

System 1 is fast, automatic, intuitive, and effortless. It helps us recognize patterns, react quickly, read emotions, and make instant judgments. But it also jumps to conclusions.

System 2 is slow, deliberate, analytical, and effortful. It helps us calculate, reason, compare options, and question assumptions. But it is also lazy.

Most of the time, System 1 creates an answer first, and System 2 only checks it if there is enough reason or energy to do so. That means we often feel rational while we are actually just justifying our first impression. And because System 1 is very good at creating coherent stories from incomplete information, wrong conclusions can still feel obviously true.

This is not just interesting psychology; it has very practical consequences for how we explain ideas, make decisions, give feedback, and collaborate as software engineers.

5 practical takeaways

1. Make the missing context visible

One of the strongest ideas in the book is: What you see is all there is.

People reason based on the information available to them, not based on all the information that would be relevant. And definitely not based on all the context you have in your head.

This matters a lot in collaboration. When people disagree with your proposal, they may not be irrational. They may simply see a different part of the problem.

So before arguing for a solution, make the context visible. What problem are we solving? What constraints do we have? What alternatives did we consider? What information influenced our conclusion?

Better context often creates better alignment.

2. Do not trust confidence too much

The book shows again and again that confidence can be misleading.

A conclusion can feel correct simply because the story in our head is coherent. But a coherent story is not the same as a true story.

This is important in discussions, planning, and architecture decisions. Someone may sound very confident and still be wrong. And that someone may be you.

A useful habit is to ask: What evidence would change my mind?

This moves the discussion away from confidence and toward verification.

3. Use framing consciously

Kahneman shows that the way information is framed influences how people judge it.

The same facts can lead to different reactions depending on how they are presented. That does not mean we should manipulate people. It means we should be responsible with framing.

In collaboration, this means we should be careful how we present problems, risks, and proposals.

“Refactoring this module will take two weeks.”

creates a different reaction than:

“Every new feature in this area currently takes longer because this module is hard to change. Spending two weeks on refactoring should reduce the cost of all future changes in this area.”

Same topic. Different frame. Different understanding.

Good communication is not only about being logically correct. It is also about helping others see the point clearly.

4. Make comparison easy

System 2 is slow, effortful, and lazy.

So if we want people to think carefully, we should not make the thinking unnecessarily hard.

This matters when we present options. Long verbal explanations are difficult to compare. People will often anchor on the first option, remember the most vivid argument, or simply follow the most confident person in the room.

A small decision table is often better:

• option
• benefit
• cost
• risk
• when it works
• when it fails

This does not make the decision automatic. But it makes careful thinking easier.

5. Slow down important decisions

Fast thinking is useful. We need intuition, experience, and quick judgment.

But the book is also a warning: intuition is not reliable everywhere.

For important decisions, we should deliberately slow down. Especially when the decision is expensive, risky, hard to reverse, or emotionally loaded.

Write the decision down. List alternatives. Separate facts from assumptions. Ask what could go wrong. Use an ADR when the decision matters.

Not because documents are magic.

But because writing forces System 2 to participate.

Conclusion

Do not believe everything you think. 😉

Radical Candor

Some time ago I started looking for material on how to become more effective inside an organization.

Technical skills alone are rarely enough.
At some point, the real challenges become communication, feedback, and collaboration.

That search eventually led me to Radical Candor.

What immediately caught my attention was the subtitle:

How to get what you want by saying what you mean.

That sounded exactly like the kind of practical advice I was looking for.

What I Took Away From the Book

While reading the book, I found several helpful ideas and practical hints.

Many concepts felt familiar because I had encountered similar ideas in the past, particularly in books by Tom DeMarco.
Still, it was useful to see these principles applied specifically to leadership and management.

The central idea of the book is simple but powerful:

Good leadership requires a balance between caring personally and challenging directly.

Managers should be honest and direct with feedback, while also showing genuine care for the people they work with.

That balance is what the author calls Radical Candor.

My Perspective

I am not a people manager myself.

My role is closer to that of a technical lead or staff engineer, so I skipped some sections that focus heavily on day-to-day management topics like hiring, performance reviews, or team administration.

However, many ideas in the book are still highly relevant even if you are not managing people directly.

In any technical role, you constantly interact with colleagues, give feedback on work, and discuss decisions.
Learning how to do that clearly and respectfully is an important skill.

Final Thoughts

Overall, I would say the book is definitely worth reading.

That said, it is probably most valuable for people managers or aspiring managers.

If you mainly work in technical roles, you will still find useful insights, but some parts of the book may feel less relevant.

Still, the core idea is simple and powerful:

Clear, honest communication combined with genuine care for people can dramatically improve how teams work together.

And that is a lesson that applies far beyond management.

At first I could not make much sense of the first part of the title, but I bought the book anyway. After reading the introduction it suddenly made perfect sense, because already there I learned:

In systems thinking, a system is more than just the sum of its parts.

A system is something that maintains its existence and functions as a whole through the interaction of its parts.

Your body is the perfect example. It consists of many different parts and organs, each acting separately yet all working together and each affecting the others.

The Art of Systems Thinking: Essential Skills for Creativity and Problem Solving

Once you start looking at the world through the lens of systems thinking, you begin to notice systems everywhere. We live in a world shaped by systems: political systems, economic systems, belief systems, organizations, teams - and of course software systems.

One quote from the book captures this shift in perspective very well:

If you cut a system in half, you do not get two smaller systems, but a damaged system that will probably not function.

This illustrates why traditional scientific analysis - breaking things into smaller pieces - only provides a limited understanding. Many important behaviors arise from the interactions between parts, not from the parts themselves.

To truly understand systems - whether a team, an organization, or a complex software system - we must respect this idea.

This is especially relevant in software engineering.

A team is more than a group of individuals. An architecture is more than a collection of modules. A development process is more than a sequence of activities.

What actually shapes the outcome are the connections and dependencies between the elements.

This book provides a framework for thinking about exactly that. It encourages you to step back from isolated incidents and ask a much more useful question:

What kind of system is producing these results?

Instead of focusing on individual mistakes or symptoms, systems thinking pushes us to examine the structure that creates the patterns we observe.

The behavior of a system is largely determined by how its components interact, not simply by the components themselves.

Many of the most interesting properties of a system belong to the whole, not to any individual part. When we take a system apart to analyze it, we often lose exactly the properties we were trying to understand.

Because the elements within a system influence each other, systems often resist attempts to change them. But when change finally happens, it can sometimes occur abruptly and dramatically.

A key shift in systems thinking is moving away from linear cause-and-effect reasoning. Instead of straight lines, systems are better understood as circles of influence.

The essence of systems are feedback loops, which we can split into two types:

• reinforcing feedback, which amplifies change and pushes the system further in the same direction
• balancing feedback, which counteracts change and stabilizes the system

All systems have a goal, a desired state where the system tends to settle or remain balanced.

Another important aspect of systems is delay. Cause and effect are often separated in time because feedback loops take time to complete. This is one reason why systems can behave in ways that appear confusing or counterintuitive.

Most systems contain certain points where small adjustments can lead to disproportionately large results. These leverage points are far more effective places for intervention than applying more effort everywhere.

Interestingly, some of the most powerful leverage points lie in mental models.

Mental models are the beliefs and assumptions we rely on to interpret the world. They shape how we understand cause and effect and how we decide to act.

In that sense, our mental models themselves form a kind of system. If these internal models are incomplete or flawed, we may unknowingly recreate the same systemic problems.

Learning can also be viewed through a systems perspective.

Learning follows a feedback pattern: we take action, observe the results, adjust our understanding, and act again. Over time this cycle moves us closer to our intended outcome.

Since the world is always richer than any single representation we hold, it is important to consider multiple perspectives. Broadening our viewpoints expands our mental models and improves our ability to understand the system.

The final part of the book demonstrates how systems can be visualized through diagrams and causal maps. Making relationships and feedback loops visible helps turn vague intuition into something that can be analyzed and discussed.

When you work in a great team, it’s one of the most enjoyable aspects of the job. But when teams don’t function well, the amount of friction can be enormous.

A key factor behind great teams is great technical leadership.

Good tech leads are not only strong in technical topics. More importantly, they need leadership skills.

In that regard, military teams and software teams are not so different. Both operate under pressure, must coordinate complex work, and rely heavily on trust and clear communication.

If you want to understand what truly matters in leadership, this book is an excellent resource.

That’s why I picked this book, and if you are a tech lead - or want to become one - I highly recommend reading it.

Extreme Ownership: How U.S. Navy SEALs Lead and Win

The book presents 12 principles to “lead and win.”

Each chapter follows the same structure:

A story from Navy SEAL operations in Iraq that sets the stage for the principle and helps build an intuitive understanding of why it matters.
If you are not interested in the military details, these sections can be read quickly.

The principle section then explains the core idea.

Finally, the business section shows how the principle applies in organizations and teams.

Here are the 12 leadership principles from the book.

1. Extreme Ownership

The leader must own everything in his or her world.

Leaders must take full responsibility for everything in their team’s results. There are no excuses and no blaming others. When leaders own failures, they can fix the real problems.

2. No Bad Teams, Only Bad Leaders

When it comes to standards, as a leader, it’s not what you preach, it’s what you tolerate.

Team performance reflects leadership quality. If a team fails, the leader must change the approach rather than blame individuals. Good leadership can turn around even poorly performing teams.

3. Believe

In order to convince and inspire others to follow and accomplish a mission a leader must be a true believer in the mission.

Leaders must truly believe in the mission. If they don’t, they cannot convincingly communicate it to the team. Understanding the “why” is essential to gain commitment.

4. Check the Ego

Ego prevents learning, collaboration, and effective decision-making. Leaders must stay humble and open to feedback. Mission success is more important than personal pride.

5. Cover and Move

Teams must support and protect each other to succeed. Success depends on collaboration between units rather than isolated efforts. The entire organization must work as one team.

6. Simple

And when things go wrong — and they inevitably do — complexity compounds issues that can spiral out of control into total disaster.

Plans must be simple and easy to understand. Complexity creates confusion and increases the risk of failure. Clear and straightforward plans improve execution.

7. Prioritize and Execute

“Relax, look around, make a call.”

When multiple problems arise, leaders must focus on the most critical one first. Solve issues step by step instead of becoming overwhelmed. Calm prioritization enables effective action in chaos.

8. Decentralized Command

Every tactical-level team leader must understand not just what to do but why they are doing it.

Decision-making authority should be pushed down to leaders closest to the problem. Everyone must understand the mission well enough to act independently. This creates speed, flexibility, and resilience.

9. Plan

Leaders must carefully plan missions and involve key team members in the process. Clear communication of the plan ensures everyone understands their role. Preparation reduces uncertainty and improves execution.

10. Leading Up and Down the Chain of Command

Leaders must manage relationships with both superiors and subordinates. If higher leadership doesn’t understand something, it’s the leader’s responsibility to explain it clearly. Ownership extends both upward and downward.

11. Decisiveness Amid Uncertainty

There is no 100 percent right solution. The picture is never complete.

Leaders must make decisions even when information is incomplete. Waiting for perfect certainty often leads to missed opportunities. Timely action is usually better than hesitation.

12. Discipline Equals Freedom

Discipline in planning, training, and execution creates freedom in operations. Consistent discipline reduces chaos and improves performance. The more disciplined the team, the more effectively it can operate.

Final Thoughts

While reading the book, I could immediately relate many of the principles to my daily work.

If you take a fresh look at how your team operates,
I’m pretty sure you’ll recognize some of the same patterns.

And that’s a good place to start improving.

We can use it as intelligent auto-completion, or ask it to implement entire features.

But to get good results, we need to engineer good prompts.

That’s why I picked up Prompt Engineering for LLMs. Here’s what I learned.

Prompt Engineering for LLMs: The Art and Science of Building Large Language Model-Based Applications

The book primarily targets developers who want to build LLM applications. Think of a chat application like ChatGPT or a coding assistant like Copilot.

But even if you do not plan to build such systems yourself, understanding how these applications are constructed gives you deep insight into how today’s LLMs and LLM-based products really work.

The book is divided into three parts.

Part 1 – Fundamentals

The first part covers the fundamentals of large language models.

It explains how they work, how they process data, what they can do, and just as importantly,what they cannot do. It also introduces the core architecture of LLM-based applications.

This section is especially helpful if you mainly use LLMs but want to understand what is happening behind the scenes. It builds the conceptual foundation you need before thinking about prompt engineering in a more systematic way.

Part 2 – Engineering Prompts

The second part focuses on prompt engineering itself.

Some of the concepts are useful for everyday users of LLM tools. But the primary audience here is developers who design and build LLM applications.

This section explains how to gather relevant content, how to structure and preprocess that content, and how to assemble effective prompts using different techniques. It moves from theory to applied engineering and shows how prompts are not just “questions,” but carefully constructed inputs that shape the model’s output.

Part 3 – Advanced Topics

The third part goes deeper into advanced topics.

It discusses integrating tool execution into prompts and building more capable LLM applications. It covers how to simulate reasoning, how to design conversational agents, and how to structure larger LLM workflows.

The book concludes with a discussion about evaluating the quality of LLM applications once you have built them - which is an important and often overlooked aspect.

Final Thoughts

If you simply want to use LLMs more effectively in your daily work, you probably do not need to spend the money. There are cheaper resources that teach basic prompt tips.

But if you want to deeply understand how LLM applications work internally - and eventually build your own - this is a solid book.

Beyond Vibe Coding cuts through the hype and draws a sharp line between short-term velocity and sustainable AI-assisted engineering.
It explains why prompting is really about expressing intent, why fundamentals still matter, and how juniors, mid-levels, and seniors must adapt differently in the AI era.

Beyond Vibe Coding: From Coder to AI-Era Developer

AI tools are now part of everyday development.
The real question is not whether we use them - but how.

How do we integrate AI without sacrificing quality, maintainability, and engineering discipline?

Beyond Vibe Coding: From Coder to AI-Era Developer attempts to answer exactly that.

The book introduces a useful distinction:

• Vibe coding optimizes for short-term speed.
• AI-assisted engineering optimizes for sustained velocity and reliability.

AI can accelerate you - but only if it is embedded in real engineering practices.

Programming With Intent

The central shift the author proposes is subtle but important:
AI development is not about generating code - it’s about expressing intent clearly.

Prompting, in this view, is less about clever tricks and more about communication discipline:

• Provide context
• Be specific
• Avoid overloading
• Refine iteratively

Treat AI like a junior developer. Give direction. Review the results. Iterate.

The book introduces techniques such as role prompting and chain-of-thought reasoning, but the deeper takeaway is this: effective prompting requires structured thinking.

The 70% Problem

One of the strongest ideas in the book is the “70% problem.”

AI can reliably scaffold a feature, generate boilerplate, or get a system mostly running.
But the final 30% - domain-specific decisions, edge cases, architectural trade-offs - remain human territory.

AI handles accidental complexity well.
Engineers still own essential complexity.

That distinction matters.

• You must understand the generated code
• You must review and test it
• You must debug it when it breaks
• You must not merge what you cannot explain

The last 30% is where real engineering begins. For juniors especially, skipping that part risks long-term skill atrophy.

Practical Guidelines

The book reinforces pragmatic, almost conservative engineering habits:

• One task per session to avoid context confusion
• Keep prompts concise and focused
• Treat AI output like code from a junior developer
• Don’t merge what you don’t understand
• Provide coding standards and architectural rules explicitly
• Share effective prompts within the team
• Reflect and iterate regularly

In short: AI does not replace engineering practices - it amplifies them.

Adapting to the AI Era

The book makes one thing clear: AI does not level the playing field.
It changes how each experience level creates value.

For seniors, AI is leverage.

• Act as architect and editor-in-chief
• Use AI to accelerate large refactorings and strategic improvements - without losing control
• Continue cultivating domain mastery and long-term foresight

Experience becomes more valuable, not less.
AI amplifies judgment.

Mid-level engineers are encouraged to grow beyond feature implementation.

• Build deeper domain expertise
• Take ownership of code review and quality assurance
• Develop systems thinking, architecture, and design skills

The shift is subtle but important: move from writing code to understanding systems.

For juniors, AI is an accelerator - but only if fundamentals are solid.

• Learn the fundamentals - don’t skip the “why”
• Practice problem-solving and debugging without the AI safety net
• Build an eye for maintainability
• Develop prompting and tooling skills deliberately

AI can speed up progress.
It cannot replace foundational understanding.

Final Thoughts

If you are new to AI-assisted development, this book provides a structured and grounded starting point.
It helps you avoid common mistakes and establish sustainable workflows from the beginning.

If you have already experimented extensively with vibe coding and developed your own patterns, you may find fewer surprises. The book consolidates solid ideas rather than introducing radically new ones.

Still, it offers an important reminder:

While tools evolve, software engineering fundamentals still apply.