AI-Native: What Does It Mean for a Company?

The conversation starts without a settled definition of AI-native. Aleksey proposes one distinguishing feature: agents working for different people coordinate with one another. Two engineers with dozens of assistants may still operate in isolation if their outputs meet only in existing tools and require manual reconciliation. Evgeny considers the entire path from intent to outcome, with fewer handoffs between functions and agents participating fully in the process. Alexander compares this with digital transformation: individual tasks are automated first, then workflows change, and eventually the organization’s interactions are redesigned. Producing a document faster does not remove the queue at the next stage. Frameworks such as Team Topologies therefore remain relevant. Interfaces between participants still matter, but they must now accommodate agents. These are perspectives for examining work, rather than a universal test that certifies a company as AI-native.

For a new technology business, Alexander sees this approach as a natural starting point. A founder already testing hypotheses with agents will look for a partner who can work at a similar pace. Knowledge must also accumulate outside the founder’s head and become available to the wider system. Aleksey later extends that argument to established companies: maintaining context should become routine work for engineering, design, product, and operations. Product changes should feed back into shared knowledge, with agents helping maintain it. Yet more output creates a new constraint: human attention. Aleksey suggests remembering previous decisions, managing a queue of questions, and reducing the effort required to understand a response. Alexander illustrates this with learning system design through a game: try a configuration, observe the consequences, then study the theory. Likewise, an agent’s research becomes more useful when people can understand and question it, rather than merely receive a long report.

Changing an established company is harder than starting a new one. Evgeny describes a familiar sequence: investigate current work, define a target process, pilot it with one or two teams, and expand with executive support. Aleksey accepts that outline but stresses how much the actual engagement depends on people and authority. A request for a tool may conceal limited awareness of the possibilities or fear of losing a role. An audit alone cannot resolve those issues. The company needs baseline measurements and a clear success criterion: what improvement in time, cost, or quality would justify expansion? Aleksey recalls accelerating one team’s work without shortening the overall product cycle because dependencies on other teams remained. Measuring only the local stage could celebrate success while overlooking the unchanged system. Productivity assessment also needs to consider people’s experience, obstacles, and context handoffs, rather than simply count artifacts.

The co-hosts disagree about pace. Alexander favors gradual change in a large operating organization: find a willing participant, demonstrate an effect within reach, and earn trust for the next step. Retaining employees who already want to improve the company is essential. If initiative meets only restrictions, those people leave and later transformation becomes harder. Aleksey worries that corporate evolution cannot keep up with technological change. He favors more radical redesign, although a consultant’s mandate often permits only local steps. His estimates of enormous productivity differences remain personal observations and hypotheses. Evgeny connects the scale of transformation to executive support and competitive pressure. Alexander adds that a successful business may feel little urgency to reorganize. Finding internal champions and giving them resources and recognition helps, but does not replace the business decision about why change is necessary.

The next disagreement concerns software built for a specific need. Aleksey describes replacing a simple form with a training recommendation system: a manager’s answers are scored, saved to a database, and used to suggest a program. He reports building it with an agent in a few hours. Such tools can fit a company’s processes without waiting for an external vendor. Evgeny cautions against extending that argument to every system: payments may be better served by Stripe than by custom infrastructure. The hosts use the distinction between core, supporting, and generic domains. Alexander sees opportunities in supporting internal tools, but stresses total cost of ownership. A successful prototype accumulates integrations, commitments, and dependencies; its creator may then become responsible for years of maintenance. Even when coding gets easier, migration and obligations to users remain. Building something internally therefore requires boundaries and conditions for reconsidering the decision.

The same reasoning challenges the promise that automation inevitably frees people for more interesting work. Aleksey supports retraining and finding new products, so increased capacity can expand the business. Evgeny asks why an employer would choose training if reducing costs appears more attractive. Alexander points to the diminishing usefulness of additional changes: more application screens or the next ideas on a list may not pay for themselves. Available capacity does not create demand for its output. The hosts also differ on management decisions. Aleksey sees emotion and imitation; Alexander allows for economic reasons that an observer with incomplete information cannot see. They offer no common prescription for hiring or layoffs. Near the end, Aleksey argues for someone to track technological developments, with success measured through implemented changes rather than news consumed. Alexander brings the discussion back to the listener’s role, authority, and willingness to participate in organizational change.