Diasoft explains why junior hires, AI magic and an in-house platform won't save dev projects

Diasoft and other IT companies have dissected three persistent myths that keep causing large customers to lose money and time on development. They are the belief that a complex project can be sped up by mass hiring, that an old system can be rewritten almost entirely by AI, and that the efficiency problem can be settled for good by launching an in-house platform. The participants in the discussion argue that all three ideas look logical only on paper: in real enterprise projects they most often add chaos, grow technical debt and raise the cost of change.

The first myth is "add people and go faster." The participants point out that this approach contradicts Brooks's law: the more people are thrown into a late, complex project, the higher the communication overhead and the harder synchronization becomes. In practice this shows up as a familiar set of symptoms: teams build incompatible pieces of the system, bugs surface at integration points, UX diverges between products, and scalability and security requirements stop being applied uniformly.

This is especially visible where hundreds of teams work at once. According to the speakers, juniors and merely cheap developers do not make up for a lack of architectural thinking. On the contrary, after six to twelve months the organization often ends up with accumulated technical debt and has to redo a substantial part of the solution.

The second myth concerns generative AI. Here the experts' position is more nuanced: they do not dispute that tools such as Cursor, in-house models and agentic scenarios already speed up time-to-market, cut manual routine and help close bugs faster. Some teams even treat token consumption as a separate efficiency metric.

But it does not follow that a neural network can rewrite a legacy system built over ten or fifteen years "overnight." With hundreds of thousands or millions of lines of code, generation is not the only critical part: so are validation, architectural constraints, information security requirements and uniform standards across the whole perimeter. That is why AI works as a useful layer inside the pipeline, not as an autonomous replacement for the engineering function.

Mass migration and transpilation still require deterministic tools, parsing, AST transformations and people who understand the business context and can verify what exactly the model generated.

The third myth is "we'll build our own platform and stop depending on the market." The discussion notes that this path sometimes does work, but only for companies with a very long investment horizon, a huge budget and a business that critically depends on its own digital platform. The reference case is a large bank that spent years and tens of billions of rubles on an internal platform, restarting the project several times.

For most companies this strategy means not acceleration but years spent on infrastructure construction instead of solving applied problems. There is also a counterargument: if you assemble a small group of strong senior specialists, give them authority and modern AI tools, you can cover part of the way noticeably faster than before. But even supporters of this idea do not propose a false dichotomy.

They describe a hybrid model in which the core of the product stays in-house, while external teams or platform vendors handle individual services and project peaks.

This leads to a more pragmatic view of the custom development market. Clients increasingly do not buy just programmers' hours; they expect the contractor to take on the whole result: quickly assemble a working architecture, build in quality and security checks, apply AI competently and shrink the team without losing quality. By the participants' estimate, with a high degree of automation and a properly built process, a team of four to five people can ship the volume that once required twelve to fifteen.

But these savings do not appear out of thin air or from "prompt magic." They come from standards, a pipeline, static analysis, automated tests, mature leads and a clear split between what can be handed to the machine and what remains the human's responsibility.

What this means for the market: the era of simple answers in enterprise development is ending. Mass hiring without strong architecture no longer looks like a working accelerator, AI without guardrails does not become a self-sufficient code factory, and an in-house platform without business scale easily turns into an expensive distraction. The winners will be teams that can combine senior expertise, a platform approach and delivery automation. In this setup AI is not a magic wand but an amplifier of an already mature engineering system.