2026-02-28 09:39:37

A former senior Air Force official is weighing in on the growing dispute between Anthropic and the Pentagon.

Retired Air Force Lieutenant General Jack Shanahan, who led Project Maven and previously clashed with Google over defense AI work, says on LinkedIn he understands the Defense Department’s desire for access to the best technology.

Read the rest of the story here:

2026-02-28 09:35:41

Каждый день я вижу одни и те же заголовки: "AI заменит программистов через 5 лет", "ChatGPT пишет код лучше джуна", "90% разработчиков потеряют работу из-за AI".

И знаете что? Это всё чушь. Но не по той причине, о которой вы думаете.

AI не заберёт вашу работу. Но кое-что другое заберёт. И вот об этом стоит реально волноваться.

Почему AI НЕ заменит программистов

Давайте начнём с фактов, а не с хайповых заголовков.

Я использую AI каждый день. Claude, ChatGPT, Copilot. Это мои основные инструменты. И именно поэтому я знаю их ограничения лучше, чем те, кто о них только читает.

AI отлично справляется с:

• Генерацией бойлерплейта
• Написанием тестов по готовому коду
• Объяснением чужого кода
• Рефакторингом простых функций
• Ответами на типовые вопросы

AI ужасно справляется с:

• Пониманием бизнес-требований
• Проектированием архитектуры
• Принятием решений в условиях неопределённости
• Общением с заказчиком
• Отладкой сложных багов, которые зависят от контекста
• Пониманием, что пользователю НУЖНО, а не что он ПРОСИТ

Попробуйте дать Claude задачу "спроектируй архитектуру приложения для доставки еды с учётом того, что у нас 3 разработчика, бюджет на инфраструктуру $200/месяц, и через 3 месяца ожидается x10 рост нагрузки". Он выдаст что-то разумное, но это будет решение для сферического проекта в вакууме.

Реальная разработка состоит из контекста. И этот контекст невозможно передать в промпт.

Так что же реально заберёт вашу работу?

Ответ простой: разработчик, который умеет использовать AI.

Это не мем. Это уже происходит.

Я лично видел, как один разработчик с AI-инструментами делает работу, которая раньше требовала команду из трёх человек. Не потому что AI заменил двоих. А потому что AI убрал рутину, и один человек стал успевать больше.

Вот реальный пример из моей практики:

Раньше написание типового CRUD-модуля для iOS приложения занимало у меня 3-4 часа. Модель данных, сетевой слой, вью-модель, экран. Много повторяющегося кода.

Теперь я описываю структуру Claude, получаю 80% кода за 10 минут, и трачу оставшееся время на то, чтобы адаптировать это под реальный проект. Итого: 1-1.5 часа вместо 4.

Я не стал менее нужным. Я стал в 3 раза продуктивнее.

Но вот что происходит с теми, кто отказывается учиться: они делают ту же работу за 4 часа, пока я делаю её за полтора. Угадайте, кого выберет работодатель?

Три типа разработчиков в 2026

Я наблюдаю за рынком и вижу чёткое разделение:

Тип 1: "AI это хайп, я буду кодить как раньше"

Эти ребята принципиально не используют AI. Они считают, что настоящий программист должен всё писать сам. Что использование AI это "читерство".

Они правы в том, что понимание кода важно. Но они неправы в том, что отказываются от инструмента, который делает их быстрее. Это как отказываться от IDE и писать код в блокноте, потому что "настоящий программист знает все команды наизусть".

Через 2-3 года они будут неконкурентоспособны. Не потому что плохо кодят. А потому что слишком медленно.

Тип 2: "AI напишет всё за меня"

Противоположная крайность. Люди, которые копипастят из ChatGPT не глядя, не понимают, что сгенерировано, и не могут отладить результат.

Они быстрые на старте. Но как только появляется нестандартная задача, они тонут. Потому что не понимают основ. Не могут прочитать стектрейс. Не знают, почему решение работает (или не работает).

Это как водитель, который умеет только следовать за навигатором. Пока GPS работает, всё отлично. Стоит ему сломаться, и ты потерян.

Тип 3: "AI это мой множитель"

Вот это правильный подход. Эти разработчики:

• Понимают код, который генерирует AI
• Используют AI для рутины, а своё время тратят на архитектуру и сложные задачи
• Могут обнаружить ошибку в сгенерированном коде
• Знают, когда AI стоит использовать, а когда быстрее написать самому
• Постоянно учатся промпт-инженерии и новым инструментам

Это люди, которых будут нанимать. Это люди, которые будут зарабатывать больше. Потому что они не соревнуются с AI. Они используют AI для усиления себя.

Конкретные навыки, которые спасут вашу карьеру

Хватит теории. Вот что конкретно стоит учить прямо сейчас.

1. Промпт-инженерия

Не в смысле "придумать красивый запрос для ChatGPT". В смысле понимания, как эффективно взаимодействовать с LLM для решения инженерных задач.

Это значит:

• Уметь декомпозировать задачу для AI
• Давать правильный контекст
• Итерировать над результатом
• Знать ограничения разных моделей

Это навык, который отличает "я попросил ChatGPT и получил мусор" от "я получил 80% решения за 5 минут".

2. Системное мышление

AI генерирует код. Но он не проектирует системы. Понимание того, как компоненты связаны друг с другом, как данные текут через приложение, как масштабировать архитектуру, это то, что AI ещё очень долго не сможет делать.

Инвестируйте в понимание паттернов проектирования, архитектуры, и системного дизайна. Это ваша страховка.

3. Коммуникация

Половина работы программиста это не код. Это общение. С заказчиком, с дизайнером, с тестировщиком, с менеджером.

AI не сходит на встречу с клиентом. AI не объяснит CEO, почему фичу нельзя сделать за неделю. AI не разрулит конфликт в команде.

Разработчики, которые умеют общаться, всегда будут в цене.

4. Доменная экспертиза

Чем глубже вы понимаете бизнес-домен, в котором работаете, тем сложнее вас заменить. Программист, который понимает финтех, медицину, логистику, или e-commerce на уровне бизнеса, а не только на уровне кода, это на порядок более ценный специалист.

Реальный прогноз на ближайшие 3 года

Вот что я думаю произойдёт:

2026-2027: AI-инструменты станут стандартом. Компании начнут ожидать, что разработчики используют AI. Не знать как, станет как не знать Git в 2020.

2027-2028: Количество рутинных задач для джунов сократится. Джунам станет сложнее входить в профессию, потому что та работа, на которой они раньше учились, теперь автоматизирована. Но потребность в миддлах и сеньорах останется.

2028-2029: Появятся новые роли. "AI-инженер", "промпт-архитектор", специалист по интеграции AI в бизнес-процессы. Люди, которые начали осваивать AI сейчас, займут эти позиции.

Заметьте: нигде в этом прогнозе нет пункта "программисты больше не нужны". Потому что этого не будет.

Что делать прямо сейчас

Если вы дочитали до сюда, вот конкретный план действий:

1. Начните использовать AI в работе. Claude, Copilot, Cursor. Неважно что. Важно начать.
2. Учитесь писать промпты. Это навык, не магия. Чем больше практики, тем лучше результат.
3. Не забрасывайте фундамент. Алгоритмы, архитектура, паттерны. AI усиливает вас. Но если усиливать нечего, результата не будет.
4. Развивайте софт-скиллы. Коммуникация, менеджмент проектов, работа с клиентами. AI этого не заменит.
5. Следите за трендами. Не через хайповые заголовки, а через реальные кейсы и инструменты.

Итог

AI не ваш враг. AI не заберёт вашу работу.

Но ваш конкурент, который освоил AI раньше вас, может сделать вас ненужным. Не потому что вы плохой разработчик. А потому что он делает ту же работу быстрее.

Хорошая новость: освоить AI-инструменты не сложно. Это не новый язык программирования. Это новый подход к работе. И если вы начнёте сегодня, через полгода вы будете тем самым разработчиком, которого выберут вместо того, кто не адаптировался.

Выбор за вами.

Я каждый день делюсь практическими советами по карьере в IT и использованию AI для разработки:

Telegram: t.me/SwiftUIDaily - советы, инструменты, карьера в IT

Boosty: boosty.to/swiftuidev - готовые наборы для собеседований, карьеры и продуктивности

А вы уже используете AI в своей работе? Или считаете, что это пока рано? Пишите в комментариях, интересно узнать ваше мнение.

2026-02-28 09:18:55

This is a submission for the DEV Weekend Challenge: Community

The Community

I built this for the builders who are too tired to speak.

We’ve all been there: it’s 2 AM, your terminal is finally green, the features are humming, and you’ve just pushed that final commit. You feel a surge of triumph, but then—the wall hits. To share your work with the DEV community, you have to face the blinking, judgmental cursor of a blank text editor. You have to translate the elegant logic of your functions into human sentences.

For many of us, the "paperwork" of coding—the documentation, the blog posts, the storytelling—is where our projects go to die. I built this for every developer who has amazing code sitting in a dark repository because they didn't have the emotional energy to write the "How I Built It" post. I built this for us.

What I Built

ForkToPost is a bridge between your repository and your community. It is an AI-powered narrative engine that analyzes your codebase and breathes life into a draft submission post.

Inspired by my previous work on Source Persona, ForkToPost doesn't just list your files; it interprets your intent. It looks at your forks, your commits, and your structure to generate a meaningful starting point for your next DEV post. It’s designed to handle the "heavy lifting" of structural writing so you can focus on adding your unique human spark.

Demo

You can explore the project and see how it transforms raw code into readable stories here:

https://github.com/vero-code/forktopost

Code

How I Built It

The journey of building ForkToPost was one of radical empathy. I had to ask myself: What does a developer actually need when they are exhausted? They don't need more complexity; they need a partner.

I utilized a modern stack designed for speed and intelligence:

• React & TypeScript: To ensure the interface felt snappy and reliable.
• Tailwind CSS: To create a focused, low-friction UI that doesn't overwhelm the senses.
• Gemini Integration: The "soul" of the app, which uses specialized prompting to identify the "Aha!" moments in a user's code.
• GitHub: To seamlessly pull repository data without making the user copy-paste their entire life.

Technical Architecture

I designed the system to follow a Context-Extraction-Transformation pipeline:

1. The Ingestion Layer: The user provides a repository URL. The system uses the GitHub API to crawl the file tree, prioritizing README.md, package.json, and core logic directories.
2. The Context Synthesis Engine: Instead of sending raw code to an LLM (which hits token limits and loses focus), I built a "Context Scraper." It extracts the technological fingerprint of the project—identifying the stack, the project's scale, and the primary problem it solves.
3. The Persona Layer: Drawing from the philosophy of Source Persona, the engine applies a "Community-First" lens. It doesn't just summarize; it looks for the emotional hooks—why this project matters to other developers.
4. The Markdown Generator: The final output is structured specifically for the DEV.to editor, pre-formatted with Liquid tags and section headers to ensure the path from "Code" to "Publish" is as short as possible.

The Data Flow:
User Input -> GitHub API Fetcher -> Context Filter -> LLM Narrative Processor -> Markdown Stream -> User's Screen.

Building this reminded me that technology is most powerful when it protects our time for creativity. ForkToPost is my love letter to the DEV community—a tool to ensure that no great project is ever left unheard.

This post was generated with ForkToPost — transform your repositories into compelling stories.

2026-02-28 09:18:52

Operators are special symbols that perform specific operations on one, two, or three operands, and then return a result.
Simple Assignment Operator
= Simple assignment operator
Arithmetic Operators

• Additive operator (also used for String concatenation)
• Subtraction operator
• Multiplication operator / Division operator % Remainder operator Unary Operators

•   Unary plus operator; indicates
  positive value (numbers are 
  positive without this, however)
  

•   Unary minus operator; negates
  an expression
  

++ Increment operator; increments
a value by 1

-- Decrement operator; decrements
a value by 1

! Logical complement operator;
inverts the value of a boolean

Equality and Relational Operators
== Equal to
!= Not equal to

  Greater than

= Greater than or equal to
< Less than
<= Less than or equal to

Conditional Operators
&& Conditional-AND
|| Conditional-OR
?: Ternary (shorthand for
if-then-else statement)

Type Comparison Operator
instanceof Compares an object to
a specified type

Bitwise and Bit Shift Operators
~ Unary bitwise complement
<< Signed left shift

 Signed right shift

Unsigned right shift

& Bitwise AND
^ Bitwise exclusive OR
| Bitwise inclusive OR

You can also combine the arithmetic operators with the simple assignment operator to create compound assignments.
For example, x+=1; and x=x+1

Operator Precedence
(4 * 4) + (8 * 8) * (4 * 4) - 16/4
// Found brackets - highest precedence.
// more than one, so evaluate left to right
16 + (8 * 8) * (4 * 4) - 16/4
16 + 64 * (4 * 4) - 16/4
16 + 64 * 16 - 16/4
//brackets finished, back to precedence. Found multiplicative operators

Unary Operators:
int i = 10;
int n = i++%5; output is n=0 (First operation is done 10%5 so,n=0;the i value is incremented)

int i=10;
int n=++i%5; output is n=1

//evaluate left to right
16 + 1024 - 16/4
16 + 1024 - 4
//multiplicative finished, back to precedence. Found additive operators
//evaluate left to right
1040 - 4
1036
// Expression fully evaluated. Can now be used / assigned to a variable

2026-02-28 09:15:53

Counterfactual Thinking: Learning From What Did Not Happen

We learn from experience. But what if we could also learn from experiences that never happened? Counterfactual thinking -- the mental exercise of imagining alternative outcomes -- is one of the most powerful and underutilized tools for improving decision quality.

What Is Counterfactual Thinking?

Counterfactual thinking is the process of imagining how things could have been different. "What if I had taken that other job?" "What if we had launched the product a month earlier?" "What if the market had gone the other way?"

Everyone engages in counterfactual thinking naturally, but usually in an unproductive way -- ruminating over past regrets or fantasizing about missed opportunities. The disciplined version of counterfactual thinking, however, is a rigorous analytical tool.

Two Types of Counterfactuals

Upward counterfactuals imagine how things could have been better: "If we had tested more thoroughly, we would not have had that production outage." These generate regret in the short term but improve future performance by highlighting specific improvements.

Downward counterfactuals imagine how things could have been worse: "If we had not caught that bug before release, we could have lost customer data." These generate gratitude and help us recognize the value of existing safeguards.

Both types are useful. Upward counterfactuals drive improvement. Downward counterfactuals prevent complacency.

Why It Matters for Decision-Making

Most people evaluate their decisions based on outcomes. A decision that led to a good outcome is judged as good. A decision that led to a bad outcome is judged as bad.

But outcomes are influenced by luck, timing, and countless factors beyond your control. A good decision can produce a bad outcome, and a bad decision can produce a good outcome. Judging decisions purely by outcomes is like judging a poker player by a single hand.

Counterfactual thinking corrects this by asking: "Given what we knew at the time, was this the right decision? And how could different choices have led to different outcomes?" This separates decision quality from outcome quality -- a distinction that is essential for learning.

The principles on KeepRule are built on this kind of rigorous analysis of decision quality rather than outcome bias.

Practical Applications

In post-mortems. After a project failure, most teams focus on what went wrong. Counterfactual thinking adds a second question: "What could we have done differently, and what would the likely result have been?" This generates actionable improvements rather than blame.

In strategy. Before making a major strategic decision, imagine the counterfactual: "If we do not do this, what happens? What does the world look like in two years if we take path A versus path B?" This exercise forces you to confront the consequences of inaction and the risks of each alternative.

In personal development. When reflecting on your career, counterfactual thinking helps you identify the decisions that mattered most. Which choices had the biggest impact on your trajectory? What would be different if you had chosen differently? This analysis sharpens your judgment for future decisions.

In risk management. Counterfactual thinking about near-misses is especially valuable. "We almost lost that client. What would have happened if we had? How much revenue, how much reputation?" Near-misses are free lessons -- they show you the consequences of failure without actually experiencing them.

The Premorten Technique

One of the most practical applications of counterfactual thinking is the premortem, developed by psychologist Gary Klein. Before starting a project, imagine that it has already failed. Then work backwards: "What caused the failure?"

This is counterfactual thinking applied to the future. By vividly imagining failure, you activate knowledge and intuitions that optimistic forward planning suppresses. Team members who would not speak up about concerns during planning will readily identify causes of failure in a premortem.

The scenarios at KeepRule often use this kind of forward-looking counterfactual analysis to stress-test decisions before they are made.

How to Practice Counterfactual Thinking

1. After every important decision, journal about alternatives. What else could you have done? What would the likely outcomes have been? This builds the habit of thinking beyond the path you chose.

2. In team settings, assign a "counterfactual advocate." This person's job is to articulate the best case for alternatives that were not chosen. This ensures that rejected options receive fair consideration.

3. Focus on controllable factors. Counterfactuals about things you could not have controlled ("What if the economy had been different?") are less useful than counterfactuals about your own choices ("What if we had diversified our client base?").

4. Balance upward and downward. If you only imagine how things could have been better, you will become discouraged. If you only imagine how things could have been worse, you will become complacent. Use both types deliberately.

5. Apply time limits. Counterfactual thinking is a tool, not a lifestyle. Spend a defined amount of time on the exercise, extract the lessons, and move forward. Unlimited rumination is not counterfactual thinking -- it is anxiety.

Counterfactuals and Creativity

Counterfactual thinking is also a creativity tool. By imagining worlds that do not exist, you generate novel ideas and approaches. "What if we had no budget constraints?" "What if our main competitor disappeared?" "What if we had to rebuild from scratch?" These hypotheticals free your thinking from current constraints and reveal possibilities that conventional analysis misses.

The masters on KeepRule frequently used this kind of creative counterfactual thinking to see opportunities that others missed.

Conclusion

The past is fixed, but our understanding of it is not. Counterfactual thinking allows us to extract maximum learning from every experience -- including the experiences we never had. By systematically imagining alternatives, we sharpen our judgment, improve our planning, and make better decisions going forward.

For more frameworks on structured thinking and decision-making, visit KeepRule and explore the blog for regular essays on the mental models that shape better outcomes.

The question is not just "What happened?" The question is "What else could have happened -- and what does that teach us?"

2026-02-28 09:15:31

Chesterton Fence: Never Remove Something Until You Understand Why It Exists

Imagine walking along a country road and finding a fence stretching across it. Your first instinct might be to tear it down -- after all, it seems to serve no purpose. But G.K. Chesterton argued that this instinct is precisely backwards. If you do not understand why the fence was built, you are not qualified to remove it.

The Principle Explained

Chesterton Fence is a principle of reform that states: before you remove or change something, you must first understand why it was put there in the first place. The reasoning is simple -- if you do not know why something exists, you cannot predict the consequences of removing it.

This is not an argument against change. It is an argument against uninformed change. The fence might indeed be useless, but you need to establish that fact through understanding, not assumption.

This principle is one of the most practical mental models for anyone making decisions that affect existing systems.

Why This Matters in Software Development

Programmers encounter Chesterton Fence constantly. Legacy codebases are full of seemingly pointless code -- mysterious configuration flags, redundant checks, oddly specific error handling. The temptation to "clean up" by removing these is strong.

But experienced developers know the horror stories. That "unnecessary" null check was handling a rare edge case that crashes production. That "redundant" database query was preventing a race condition. That "weird" timeout value was tuned through months of painful debugging.

The principle does not say "never refactor." It says "understand before you refactor." Read the git history. Find the commit message. Talk to the person who wrote it. Understand the context before you delete a single line.

Real-World Applications

In Organizations: New managers often arrive eager to change processes they see as inefficient. But many organizational processes evolved to solve specific problems. The weekly status meeting that seems pointless might be the only mechanism preventing two teams from duplicating work. Understanding the history helps you make better changes.

In Policy: Government regulations often seem bureaucratic and unnecessary from the outside. But many exist because of specific failures or crises. Removing safety regulations without understanding the disasters that prompted them invites those disasters to return.

In Personal Habits: Even your own "bad" habits may serve hidden purposes. The afternoon coffee ritual might not just be about caffeine -- it might be your only social interaction in an isolated workday. Before eliminating a habit, understand what need it fulfills.

Exploring different decision-making scenarios helps build the muscle of understanding context before acting.

The Second-Order Thinking Connection

Chesterton Fence is fundamentally about second-order thinking -- considering not just the immediate effects of a change, but the downstream consequences. The fence might be preventing cattle from wandering onto the road. Remove it, and you do not just lose a fence; you gain a traffic hazard.

The greatest strategic thinkers throughout history have understood this. They study what came before, understand the reasoning behind existing structures, and only then make informed changes.

How to Apply This Principle

1. Ask "Why Does This Exist?"
Before proposing any removal or change, make this your first question. If nobody can answer it, that is a signal to research further -- not a green light to proceed.

2. Seek the Original Context
Decisions make sense in their original context. A policy created during a crisis may seem extreme in calm times, but understanding the crisis helps you make a nuanced decision about whether to keep, modify, or remove it.

3. Consider What Would Happen If It Were Removed
Run a mental simulation. Who might be affected? What edge cases might emerge? What problems might resurface? This thought experiment often reveals the fence's purpose.

4. Propose Modifications Before Removal
If you suspect something is outdated, consider modifying it rather than eliminating it entirely. This preserves the original protection while adapting to new circumstances.

5. Document Your Understanding
When you do remove something, document why it existed and why you believe it is no longer needed. Future maintainers will thank you.

The Balance: Avoiding Blind Conservatism

Chesterton Fence does not justify keeping everything forever. It is not an excuse for resistance to all change. The principle has two steps:

1. Understand why it exists
2. Then decide whether to keep or remove it

If you complete step one and discover the original reason no longer applies, removing the fence is perfectly reasonable. The principle only demands understanding as a prerequisite to action.

Common Violations

• "Nobody knows why we do this, so it must not matter" (the opposite is true -- unknown reasons demand more caution)
• "This is old, therefore it is outdated" (age alone says nothing about relevance)
• "I am smarter than whoever built this" (intelligence without context is dangerous)
• "We need to move fast" (speed without understanding creates technical debt and organizational chaos)

Building a Culture of Understanding

Teams that internalize Chesterton Fence make better decisions. They build institutional knowledge, maintain documentation, and approach change with appropriate humility.

Visit KeepRule to explore more principles that sharpen your thinking, and read the blog for practical applications of mental models in everyday decisions.

The next time you encounter something that seems pointless, resist the urge to tear it down. Instead, ask: "Why is this fence here?" The answer might surprise you.