The Architect, the Paranoid, the Dreamer, and Other Employees of Tomorrow’s IT Company
It is often said that progress moves in spirals. We seem to be entering another turn, one in which breaking into IT is becoming harder, perhaps even harder than 30 years ago, when programmers were seen as geeks and eccentric nerds whom many people preferred to avoid.
Of course, the obvious objection is that anyone can now open Codex or another AI development tool, describe an idea, and produce something that looks like a real software product in a few hours. And that is true. Up to a point.
I watch colleagues, partners, students, and acquaintances without conventional programming backgrounds attempt to build digital products using generative AI. Quite often, what emerges is that AI has drastically reduced the cost of writing code, but barely reduced the cost of figuring out what code ought to be written.
You can quickly produce a beautiful interface, an API, a database, and even deploy the whole thing to a server. But behind that convincing facade you often find little understanding of architecture, uncontrolled dependencies, inadequate testing, strange data-handling decisions, and questionable security practices. The code becomes unmanageable, things break in the least expected places, and the results become unpredictable.
That is why I believe it is a mistake to think AI makes professional developers obsolete. Quite the opposite: AI makes code cheap while making architecture, accountability, engineering judgment, and common sense more valuable.
Developers used to spend most of their time writing code. Strong developers increasingly design the rules, constraints, and architectures within which machines write code.
That line of thought led me to a model. A small, modern AI-native IT company is not simply a scaled-down version of a large IT company. It is a small human core of highly capable generalists surrounded by digital workers.
Here is roughly how I would staff its development team:
1. Systems and business analyst.
In a small company, I think these two roles should be combined in one strong professional. This person must be a domain expert, or be ready to become one very quickly. Their job is to dive headfirst into the business, experience the customer’s pain points, gather the knowledge of functional specialists, and turn it all into more than a conventional requirements document: a structured system context that both humans and machines can understand.
They should describe the domain, business rules, constraints, exceptions, data model, user scenarios, and acceptance criteria. Structured Vibe++, or something similar, could serve as the format.
In effect, the central artifact of software development is gradually becoming not the code itself, but a carefully constructed context from which the code can be generated.
2. Architect-developer.
This is a senior technical specialist who can take the analyst’s requirements and understand what system actually needs to be built. They define the architecture, component boundaries, data structures, integrations, and technical constraints.
Their job is no longer primarily, or even necessarily, to write code. They must know how to frame tasks for AI, break them down, set architectural guardrails, verify the results, and stop the model from slowly turning the system into an uncontrollable pile of beautifully written fragments.
AI is good at producing code that looks plausible in isolation, but much worse at maintaining the overall architecture. So senior engineers are needed no less than before, and possibly more.
3. Super-tester.
People no longer need to perform hundreds of identical actions. Automation and AI are better suited to that. The new tester’s value lies elsewhere: they must be exceptionally good at breaking the system.
They must think like an everyday user, someone who has completely misunderstood the interface, an attacker, someone with a terrible internet connection, an integration that sends unexpected data, or a person who clicks the same button 20 times in a row.
This specialist must understand the domain and the product architecture, uncover unusual scenarios, and turn discoveries into structured tasks that both developers and AI can act on.
In effect, this is no longer just a tester. It is a professional product destroyer.
4. Dreamer.
A technical visionary with unconventional thinking, fresh eyes, and opinions of their own. Someone who can fall in love with their ideas and make other people fall in love with them too.
Essentially, this person is an entire R&D department in one. Rather than asking how something is usually done, they keep asking: why on earth must it work this way?
This role becomes especially important in the age of generative AI. Models reproduce the sum of humanity’s accumulated experience and naturally gravitate toward average, conventional solutions.
Without someone capable of thinking beyond existing patterns, we may become incredibly fast at making products that are high quality, technically correct, and utterly unremarkable.
5. DevOps engineer.
Someone still has to understand what really happens after beautiful code leaves the Codex window. DevOps owns infrastructure, CI/CD, environments, monitoring, backups, secrets, access controls, and resilience. More and more of the routine work can be delegated to machines.
6. Security specialist, also known as the paranoid one.
A small IT company may not be able to afford a dedicated information-security specialist. But it can no longer afford to have no security function at all. Someone on the team must constantly examine the system through the eyes of a person trying to access things they are not supposed to access.
There is one more part of the company I would put in a category of its own. It is not exactly a production role.
7. A nursery for future IT engineers.
Build a company staffed entirely by seniors and AI, and the architecture looks nearly perfect. There is just one problem: where will the new seniors come from a few years down the road?
AI is taking over precisely the tasks through which young developers used to grow: CRUD, basic layouts, small procedures, straightforward bug fixes. Everything on which juniors once cut their teeth is now done faster by machines.
So I would not put junior developers directly into the production core of a small AI-native company. I would build a separate training track for them, a sort of IT-engineer nursery.
This would be a department for students, interns, and entry-level engineers. The company would deliberately give them real tasks, assign mentors, and let them make mistakes safely. Their job would not be to compete with AI at writing simple code quickly. The new junior must learn to understand systems: read other people’s code and AI-generated code, explain why it works, discover its weaknesses, verify AI’s solutions, and gradually take responsibility. In this nursery, juniors would draw flowcharts, write algorithms, optimize them, and test them.
In the short run, a nursery like this looks like an expense. But I will say it again: unless we train people internally, in a few years there will be nobody to replenish the company’s human engineering core. Although some people (hello, Elon Musk) seem to believe that within ten years we will enter an era of universal prosperity and worldwide idleness =)
So I think the IT company of the future will, strangely enough, have to be both extremely high-tech and a bit like a school. Incidentally, we should think about redirecting some university funding toward these trainees.
Other roles no longer need to exist as separate full-time positions in this kind of company. The functions do not disappear; the need for a dedicated person for each one does.
Technical writer. Documentation is essential, but a significant share of it should be generated automatically from requirements, code, architecture decisions, and change history.
Designer. For a small product, you can define a common dress code once: a design system and a set of UX principles that both humans and AI follow. And your dreamer might invent something more interesting than yet another four-column layout with rounded corners and soft shadows.
Project manager. In a small team, task breakdown, meeting notes, status reporting, task tracking, and reminders can be largely automated, with management responsibilities shared by the analyst and architect. Of course, somebody still needs to join video calls with clients and write them emails so the team’s work does not look too effortless.
The result is a fairly unusual setup: a handful of strong professionals form the human core, with lots of digital workers operating around them. And by the way, that handful could even be one person, provided they are extremely experienced and very busy. Like me.
To make such a company work, there is one more crucial thing it needs: memory. A structured record of the organization’s knowledge and experience, readable by humans and machines alike.
One of the biggest problems in AI-driven development today is losing context. A model can forget a constraint, revisit a decision already made, or propose an architecture that contradicts earlier decisions.
That is why the company needs a unified, machine-readable knowledge base (yes, I am suggesting Vibe++ again): business descriptions, requirements, architecture, development rules, security requirements, the design system, decision history, test scenarios, and constraints. It also makes sense to maintain a project passport for every project, perhaps as a Markdown file stored with the project and continuously updated. Automatically, naturally.
Corporate documentation used to be written mostly for people and regulators. Now much of it must be written for people and machines.
And that changes what we need from employees. Systems thinking, strong writing skills, clear expression, the ability to learn quickly, broad knowledge, a critical attitude toward AI output, and a willingness to be personally accountable for the result all come to the forefront.
Strangely enough, in the age of AI, knowing how to read well may become almost more important than knowing how to write good code. AI can generate a thousand lines in seconds. But somebody still has to understand what it wrote and why it should work in the first place.
So I do not think tomorrow’s IT company will have no people. I think it will have far fewer people and much higher expectations of every single one.
The human role is moving toward precisely those things machines do less well: understanding the domain, questioning assumptions, seeing the whole system, moving beyond templates, trying to break things, and ultimately taking responsibility for the outcome.
That organization no longer resembles a traditional software company with dozens of narrow specializations. It is a small human core surrounded by digital workers, shared memory, automated infrastructure, and a system of guardrails.
And here is the great paradox of this technological moment: writing software code has never been easier. Building good software systems may never have been harder. And competing in the market and proving your company’s worth has become insanely difficult.
The company of the future is not a large group of people using AI. It is a few strong, ambitious people directing a large workforce of digital agents.