ESSAY ON AI - EMIT KNOWLEDGE

The world is changing at a pace that our minds struggle to grasp. As human beings, we are wired to understand immediate danger, but we struggle to respond to threats that unfold over years. Our biological systems are optimized for immediate danger; adrenaline is our default response. If someone tells us that a comet will hit the Earth in 40 years and wipe us out, we feel almost nothing. On the other hand, if someone pulls out a knife, adrenaline spikes immediately and instinct takes over.

The difference with this comet analogy is that there will be no point zero, no single moment of impact but rather a slow erosion of skills, labor-market churn, institutional incentives, and deskilling.

What we are discussing here is AI. Instead of end-of-the-world thinking or inevitable destiny, this essay focuses on creating a path that helps us ride this high tide.

Over the past 19 years in software engineering, I have focused more on finding the right tooling than chasing the latest trends or gimmicks. When assessing technology, I have always prioritized understanding goals, budgets, and product vision before adopting anything new. When does it actually make sense to discard hard-earned know-how for the “shiny” new thing? Is it because everyone is doing it, or because we actually have some benefits?

We are once again at a crossroads but with a crucial difference. This time, the question is not if, but how. This time it is not about the tech itself or the budgets. We need to examine this change from different angles: business value (how business impact is measured), personal behavior, cognitive improvement or decline, tooling, continuity of junior positions, psychological manifestations (greed*), impact, and the meaning of existence.

The purpose of this essay is to set up a path for the years to come that will help knowledge-based workers(white-collar) not become obsolete and get themselves ready for the years to come. Instead of living in fear of replacement, they can become the navigator, the catalyst of change, the exponent within their organization.

In the past, we had punch cards. Getting from idea to a completed product took ages. Then we had ASM, and the time shrank. Then we had C, and the timeline shrank once again. Then OO, RAD frameworks, generators, boilerplates. The timeline from idea to getting a taste of the product kept shrinking. Today, we have AI. That line is collapsing into a dot.

AI is continuously shrinking the gap between an idea and a fully built product. This will likely force a rethink of the business models behind how software is built and sold.

One thought I keep returning to is this: in an AI-accelerated world, time becomes cheap, while responsibility becomes increasingly expensive. This means that in a world that sells hours, fixed bids, or headcount, that model becomes harder to defend. What used to take nine months of work will be possible to deliver within one to two months. If it takes months to close a deal but delivery now happens faster than new work can be brought in, that model becomes unsustainable.

How is AI going to affect innovation and software products?

It increasingly appears that, in many segments, billing based on hours will give way to outcome-based models. Delivery will shift toward risk absorption, code will become capabilities, speed will turn into trust.

Pricing will move toward accountability, trust, domain expertise, and strategic judgment, more about becoming a partner and less about being a vendor. This means that code will more and more become infrastructure. Think of it as Visa or Mastercard networks.

Software developers and business organizations that are in the software business will need to position themselves as partners that manage their clients’ headaches. If you are still thinking in “this is not my work” and “register a JIRA ticket” terms, in the long game you are on the path to becoming obsolete.

The world will move more into small specialized teams. Think of it as Delta Force, where the software engineer has the right set of skills and domain expertise to speak the client’s language, understand their lingua, their pain, bring this in the form of a requirement, write the solution proposal, navigate the AI, test it, and deliver it. At the same time, maintaining good communication with the client, applying agile principles to their fullest potential, and proposing what needs to be done based on value and experience. I believe this will become the norm at some point. Some might say they do not agree, and I agree with them. There will be exceptions, particularly in artisan or bespoke work, but they may become marginal in the broader alignment of the industry.

The next topic is more personal and is related to personal behavior.

It all started as fun. Who would have thought that the biggest innovation would be a chatbot, a large, statistical, non-deterministic model that often reproduces patterns extracted from vast amounts of historical data?

Yes, it started as fun, but slowly, using it day to day, people started optimizing for productivity. What started as “this is my text, let’s polish it very fast” converged into “write me a post about” or “solve this problem.” We ended up in a place where we delegated authority to a statistical non-deterministic machine to decide how we are going to act and what we are going to say. By delegated authority, I mean outsourcing the steps that produce judgment to an AI system, then accepting its output as if you had done the thinking yourself.

It seems like a problem at scale, as what has distinguished us was our way of thinking, speaking, writing, and being authentic (having a distinctive style in speaking and writing). Now we have ended up managing relationships by letting our chatbots speak to each other. We accepted reducing creativity to gain productivity, and that will have an opportunity cost down the road.

Unfortunately, there are a few problems I see, and I would like to discuss and propose how we can fix them.

All of these are interconnected with each other. The moment you accept and delegate your thinking process to the chatbot is the moment you lose. The reason is quite simple. You need to work on your brain the same way you work on your physical strength and muscles. If you do not train, the body will optimize the resources spent, and as a result, muscle mass is the first thing to go away. The same applies to the brain.

It is becoming much harder to resist the dopamine urge and to keep yourself focused on the long game, starting from being bored to removing all the useless apps that capture attention. It seems that the world does not need thinkers anymore. It needs consumers, consumers at scale, so we can accelerate economies, focus on what others are buying and doing, and replicate that without any questions asked. The moment you start thinking and clear out your head, you will soon realize that the same emotions that were your driving force into making decisions against yourself, buying what you do not need, engaging in relationships that do not have a future, will suddenly stop, and you will regain your independence in decision-making.

Getting back to AI, let’s talk a bit about greediness. Humans are fundamentally energy-efficient prediction machines. A natural consequence of this efficiency is cognitive offloading. This means that to get something right without using AI, I need to do X, Y, and Z. Now AI becomes a one-stop shop that can do everything for me, so instead of giving precise instructions, using it to understand better, and finding gaps in our  thinking process, we use it as a brain with minimal input.

Solving the problem is coming back to basics: philosophy. It might sound funny, but at this time we need philosophy more than at any other time in history, as the change in progress will potentially reshape the answers to “who we are” and “why we are here.” I will focus on the core, as answering those questions is out of my capabilities.

Feel free to use this approach regardless of whether you are a marketer, a software engineer, a doctor, or having any other white-collar type of a job.

The system we are about to design is based on trust but verify. Treat AI as an exoskeleton, not as a replacement for your brain. Use it to understand the gaps in your thinking process.

If you stop for a moment and observe, you will see that people have different approaches when it comes to thinking. This is part character and part context, situation, or role. Some are fast, some are slow, but rarely will you find people who can zoom out, think, then zoom in and think again. Thinking is a trait of intelligence used to predict what is going to happen next. Then why are we stopping too early?

Most of us, if hungry at 11 p.m., will open the fridge and eat. Few will say it might be too late for a meal as it will affect sleep. Even fewer will think that poor sleep will affect tomorrow, where they need energy for work, kids, and training to give their full potential.

We have first-order thinking, which is more or less reflex-based. We see a problem, we react, we move on.

The limit is that we solve what needs to be solved in the moment, but we do not see the ripple effects or how it fits the bigger picture.

Then we have second-order thinking. This is more chess-like thinking. If I move this piece, what effect will it have? What is the compounding effect?

Finally, third-order thinking. We try to connect how this fits into the bigger picture. For example, when you introduce a new law, you cannot just think about the ripple effects; you need to understand how it will reshape culture and behavior.

The same applies to using AI. Let’s analyze this example where we utilize AI to propose/solve a specific task for a change management problem.

Prompt:
You are an expert in change management, and I need a bulletproof strategy from you on the change we are looking to incorporate starting from 01 January.

We would like to introduce a new change within the company. The change would be that starting from 01 January, all team members are going to communicate with the stakeholders via their project manager, via email. Draft a guideline, present a timeline, and a communication path that we can use to communicate with the team.

Response:
———

Below is a robust, low-risk change management strategy designed to ensure clarity, compliance, and stakeholder confidence for introducing the new communication rule effective 01 January.

Change Management Strategy
Centralized Stakeholder Communication via Project Managers

And we are done. We stick to the plan, release it, and feel happy and proud about how smart we are to prompt the AI in such a manner to get those excellent results. That may be the case, but then things start to crack. Why?

Because you were sloppy in doing your job of providing better context in terms of what you have tried, what has worked, and what has not worked. Then how is this change going to affect the teams? We need to upgrade job descriptions and responsibilities. We need to understand how it will affect the work of that person, what their throughput is, and when they become a bottleneck. We might need to apply new SLAs for response times. Prioritization needs to be sorted out. We have a single point of failure and a transparency risk.

If you apply third-level thinking, we need to discuss how this change is going to affect the value system we have been living with in the past years. We have been responding right away. Now the client needs to wait until we have time to respond. This goes against our company value system, which says we are here for you and we respond quickly. You get the idea.

AI can generate plausible policy, but it cannot own the local truth: constraints, culture, bottlenecks, and value tradeoffs. That’s where responsibility lives.

When writing about tooling, we have to zoom out and consider that AI tools will only get better. There might be a hard limit, but that is irrelevant to our discussion. We need to set up a framework that we can use as guidance so that, regardless of the tooling, AI will act as an extended hand to our brain instead of becoming our brain.

There is one simple rule to build around: do not be greedy.

Do not start with “do or create this for me.” Going back to what we discussed above, start with the thinking process. If you are a manager, it can be a memo where you fill in the details about its purpose, context, changes, how it affects our work both immediately and in the big picture, what the meeting is for, risks, and action plans.

If you are a software engineer, you can start with a solution proposal or technical analysis document. This document should include details about what you are trying to achieve, the business value delivered, business requirements and constraints.

Start as granular as possible. Treat AI as a junior expert: knowledgeable, but blind to context, ripple effects, and the bigger picture. Include affected areas and components, data flow, validation and testing plans, task breakdowns such as how you are going to implement it, which files will be created, updated, or deleted, and risks and considerations.

The idea is simple. You create the plan. You are the navigator, the pilot, the thinker. Once you create this, run it through an AI tool of choice. Ask about blind spots. Iterate, and once you feel ready, you can proceed with the next steps, if any.

For a software engineer, that would be: here is the technical analysis, create a prompt that can be used by my tool of preference.

Now instead of the agent working its way out to find a solution, it will follow your proposal and implement it. Remember not to be greedy and to make the memo, technical analysis or any other template used for problem solving as granular as possible.

When it comes to being greedy, remember not to produce more than you can process. The throughput between you and the agents needs to match. Agents can run for days. They can generate code, documentation, whatever you ask of them. They will never be tired. On the other hand, you will be. You have limited energy throughout the day, with limited focus and processing capacity. AI increases production capacity faster than human verification capacity -> risk accumulates.

If you generate 100 pages of documentation, you will not be able to read it, and you will fail because you will pass authority to the AI, believing it will work great like last time. Agents can generate 10,000 lines of code as well. You cannot review 10,000 lines of code per day. You will end up accepting it and delegating authority, so the problem remains. Failure is inevitable, and because of greed, you will pass authority to the AI and then criticize the AI for being inefficient.

Trust but verify. You must step up so you can deliver responsibility to your stakeholders. Time is cheap. If the AI is generating the code, you should be the one reviewing and testing it.

If we have to put this into a simple framework that would be: