Employees, AI, and AI employees

Two and a half years ago, my cofounder, Lav, and I tried to create an AI cofounder (CofounderGPT, as we called it), had a lot of fun, and failed. That’s not the only thing we’ve tried using AI; far from it. We use it daily for a variety of tasks, including (but not limited to) research, coding, marketing, managing and improving our product, creating new products, and for our hobbies. However, the AI cofounder project still runs somewhere in the back of our heads. Can we, or anyone, create it at some point in the future? And, what would be the impact on our products, employees, friends, and everyone if it gets created?

This is not another AGI discussion (well, it’s a monologue). I do not believe the evil artificial intelligence will threaten us all in the near future. However, if you continue reading past this point, expect a long article with diagrams and (mostly wrong) opinions on AI, employees, and cofounders.

A tale of an impossible AI cofounder

I do not understand things very well until I can visualize the way they work. In tech, the easiest way to understand how things work is to try to recreate them or use them to build something.

From the first moment I tried using LLMs, it was clear that they are amazing and have huge potential. Lav and I kept sending each other amazing demos we saw on Twitter. Then we tried recreating them just for fun and learning purposes. Most ended up with facepalming and “of course, it does not work except for this specific case in the demo!” But we learned a lot.

Then, one day, we decided to try building a product using AI (like building one product is not hard enough). And to make things even more interesting, we decided to use AI as a cofounder and create something without any employees or external help (while still running and working on Vacation Tracker full-time). This decision set us on a journey of 36 working days with CofounderGPT (over 5 months), which was fully documented here: https://knowlo.co/blog/day-1-startup-adventure-with-cofoundergpt/. And then, we just stopped. From the very beginning, it was clear that this experiment had failed. It was impossible to have a real AI cofounder. However, we continued because it was fun and we learned a lot.

But why was it impossible? Were we too early? Would it be different today with GPT 5 Pro, Claude Opus 4.1, Cursor, reasoning models, and all the other amazing tools we have access to? It would be different for sure. And we would have an illusion that our experiment might succeed for a long time.

There were and still are many problems with the potential AI cofounder. Some are very obvious, such as the context window (the amount of data an AI can keep in its memory), reasoning (the ability to think through and analyze problems), and available tools (the things an AI cofounder can use to do its job). All these things are getting better and better. Just look at Cursor, Claude Code, OpenAI Codex, and other coding AI tools today. The improvement of AI coding abilities over the past few years is so big that it’s not even measurable anymore.

However, a cofounder is more than a set of skills. Cofounders have visions, motivation, passion, and many other qualities that an AI cannot replicate. They make decisions (which is easy for an AI) and accept the potential consequences of these decisions (which is not even close to possible with LLMs and the current state of AI). And they have emotions and gut feelings.

To be honest, a true AI cofounder would not be possible from a legal perspective at the moment. However, the focus was on cofounder skills, not legal matters (they are not fun anyway).

Ok, let’s say that cofounders are a bit out of reach of the AI in its current stage. But what about employees? Will AI replace developers and other employees in the near future?

To understand that, let’s rewind a bit and try to understand how people do things.

A case of AI employees

I enjoy using AI for coding, research, and product management. Writing code or exploring and building a feature prototype has never been easier. I feel a lot more productive. Everything moves so fast! New tools, new models, better practices. Does that mean that we’ll have full-time AI developers replacing actual people soon?

If you compare the number of data center vs office space construction in the US, it seems so. The trend of building space for GPUs and our future digital employees is rising rapidly.

Source: https://x.com/JosephPolitano/status/1951740903925715126.

But, of course, it’s not that simple. To understand why, we need to go back to the core goal of each company: to make money. Whatever a company does, it needs to generate revenue to survive. Even hot new startups that focus on market capture instead of profits need to make money through investments.

How do companies make money? By selling products or services (providing value) to entities that can pay. So, companies hire employees to do things that lead to creating and selling products or services (directly, such as sales, programming, or indirectly, such as management, HR, etc.).

So, our oversimplified value chain could look similar to the following.

1. Companies need to make money.
2. Companies make money by creating and selling products or services (value) to entities capable of purchasing them.
3. Companies need employees to create and sell products or services.

Obviously, it’s more complex than that. But if we focus on the employees, we can simplify even more and say:

1. Companies need to make money.
2. Companies make money by doing something (creating, selling, etc.).
3. Companies need employees to be able to do that “something.”

But what type of employees are we talking about here? It’s quite different when we talk about factory workers or product managers and software developers. Or is it? In a timeline long enough, all jobs will either become obsolete and disappear or become fully automated.

But let’s focus on what we call knowledge workers. “Knowledge workers are professionals whose primary asset is their mental skills and expertise, used for critical thinking, problem-solving, and generating new information rather than just performing manual tasks.”

How do knowledge workers do their jobs? The answer is obvious: it depends on the actual job. Their main asset are their mental skills and expertise, but they use various tools to accomplish more and amplify their skills.

Initially, knowledge workers did everything manually, but eventually, they or someone else created a variety of tools to automate and simplify parts of their jobs, enabling them to complete more tasks and reduce the number of mistakes. For example, software developers have frameworks, linters, and many other tools. But we now have AI, too! Where do Cursor, Claude Code, OpenAI Codex, and other tools fit?

Let’s try to visualize this evolution. First, we’ll take our company value chain and add another axis to it, which represents an evolution of all these components (an X-axis). We’ll get something similar to the diagram below. Actually, this diagram is a special type of map, known as a Wardley Map. The Y-axis represents a value chain with a user (or an anchor) at the top (Company) and all of its needs (company needs, interaction channels, activities, etc.) below. Needs higher on the vertical axis are more visible and important in the context of the map than those lower in the value chain.

Wardley Maps define the following stages of the evolution:

1. Genesis - Novel, uncertain, constantly changing
2. Custom Built - Growing, becoming more defined
3. Product - Stable, well-defined, widely available
4. Commodity - Ubiquitous, standardized, utility-like

It’s a bit hard to fit employees in these evolution stages. We do not think about human evolution in the same way. However, we could fit the work they do.

Initially, we had knowledge workers doing everything manually, which was the genesis stage, because it was novel. Then knowledge workers started using tools to amplify their skills, which was (and still is) a custom build stage. This may be a bit confusing because the actual tools they (or we) use are often in the product or even commodity stage, but the way we use them is still custom, and it’s slowly becoming more defined. Finally, we see these amazing AI tools that are still not stable enough, but they are slowly moving knowledge workers to the product stage: an employee + AI automation will become well-defined and widely available over time. But what’s next? What would be the actual commodity version of a knowledge worker? Fully automated (AI) employee, I guess.

Scary, right?

It is! Luckily, it’s as true as the Windows updater telling you it’s 99% done.

So, is AI coming for our jobs? And if it does, when?

Is AI coming for our jobs?

The only proper way to answer this question is to define what our job actually is. As I already said, if we look far enough in the future, all currently known jobs will eventually become either obsolete or fully automated. But we don’t really care about thousands of years from now. We care about the relatively near future (decades, I guess).

Let’s take software developers as an example. If you are a software developer and you think your job is to write code, then I have bad news.

Luckily, businesses rarely care about code (yet some care even about GitHub stars, I know). Ok, but what are the actual responsibilities of a software developer, then? Companies need to make money, so it must be something related to earning more money or spending less money. They need to use their mental skills and expertise to:

• Intent & prioritization: Decide which problems are worth solving, define success metrics (revenue, retention, service levels), identify constraints, and set sequencing.
• Boundaries & contracts: Shape the domain model and API/data contracts to keep change cheap and risk contained.
• Code & implementation: Turn intent into working software: write code and tests, integrate with existing systems, and document expected behavior.
• Verify & operate (reliability & maintenance): Verify changes using tests and controlled rollouts, run the system in production with monitoring, alerting, error tracking, incident response, rollbacks, etc.
• Security: Define trust boundaries, access controls, and data‑handling rules; manage vulnerabilities, exceptions, and risk acceptance.
• Delivery & pipelines: Automate build/test/deploy/rollback, with quality and compliance checks, ensuring changes ship safely and predictably.
• Long‑term strategy & evolution: Choose a target architecture and evolve it in alignment with the business strategy; manage tech debt and total cost of ownership.

Obviously, these depend on the software engineer’s expertise. It’s not the same for frontend and backend engineers, juniors and seniors, etc. It also depends on the person who is preparing the list. Finally, it depends on the LLM and model we use to analyze the list of essential software engineer activities. Yes, of course, we use LLMs to assist us with almost everything today.

AI affects most of these activities, but some have a high potential to be fully (or mostly) replaced by AI, and other activities will be augmented by AI. Let’s see activity by activity:

• Intent & prioritization: AI can help you find relevant information faster and help you evaluate everything you need to know (you can run potential scenarios through brainstorming-like sessions, etc.). It could help with KPIs, ROI, documentation, and many other things. But, it can’t replace your judgment, among other important things. AI could help, but it’s, again, up to you to use and apply that help and come up with something that makes sense in each specific case (so, it’s still in the custom built phase).
• Boundaries & contracts: API schemas, payloads, examples, scaffolds, and similar things are (or soon will be) a commodity with AI. These will be mostly automated. However, you’ll still need to define domain boundaries and understand the domain. However, this will get more well-defined over time, so I think it’s closer to the product phase.
• Code & implementation: This one seems obvious, AI already writes code well enough. Over time, you’ll write code only in specific cases, such as very novel logic, examples of tricky integrations, or in cases when you need to gain a very high level of performance in your area of expertise (and when I say expertise, I mean you are one of the best, not just good). So, this goes to the commodity stage.
• Verify & operate (reliability & maintenance): You still need to make decisions, but everything gets easier to decide (AI does triage, correlates logs and traces, sends PRs, suggests decisions). I would say that this goes to the product phase and gradually shifts to the commodity phase over the years.
• Security: Something similar might happen to security. It’s still crucial for you to make a decision and have the final word, but applications are continually improving. You make decisions, and the app provides what you need. Well-defined, widely available => product phase.
• Delivery & pipelines: This is another area that we can see easily dominated by AI in the relatively near future. You might still need to think about the release strategy and to give final approvals in some cases, but CI/CD, versioning, changelogs, canaries, rollbacks, and similar are strong candidates for the full AI automation (shifts to the commodity stage).
• Long‑term strategy & evolution: Similarly to the intent and prioritization, AI will be able to give you all the critical information and assistance you might need. For example, codebase analytics, refactor opportunities (or even PRs), potential impact analysis, and different potential paths. However, it’s still up to you, your understanding of the goal, judgment, and a team to use these and come up with something that makes sense for the current and desired state of the business you are working on (or for). This stays in the custom built phase.

Here’s the updated map:

So, what do you say, is AI coming for software engineer jobs? AI has high potential to eliminate the typing aspect of the job really fast, but a software developer’s job is not typing code. It’s problem-solving through thinking, judgment, communication, and writing instructions for computers to follow.

We are going in circles. Now that we can get the code faster, we started talking about better specifications, then we’ll focus on tests, and so on. The only important difference is that, as my good friend said recently, these circles are not actually circles; they are a big spiral, and everything goes faster and faster.

Focused and recharged super employee

If AI automates most of the typing aspect of the software engineering job, we can expect something similar for other knowledge workers sooner or later. However, that does not sound so scary if you remember that the main asset of knowledge workers is their mental skills and expertise, used for critical thinking, problem-solving, and generating new information rather than just performing manual tasks.

We will have more time to devote to the essential things, such as thinking and judgment. Ok, that sounds a bit scary.

However, there’s one problem with that: you can write code 14 hours per day, but you can’t really make good decisions and process large amounts of high-quality information that long.

You need to be focused and rested.

Are you a cofounder, software developer, marketing manager, product manager, or do you have some other role? It does not matter. What matters is that you have enough focus and mental power to review all generated code, prepare prototypes, write instructions (prompts), orchestrate all agents, and decide what matters. These activities burn your energy faster than AI burns tokens. You can’t do that and have 10 meetings a day. Or work long hours and weekends. You need your battery at 100%.

How do you recharge and get focused? That’s different for each of us. However, skipping meetings that do not provide value, replying to non-urgent Slack messages or emails the next working day, closing your laptop after you finish your workday, and taking PTO are definitely helpful.