A Junior Without Easy Tasks. How Do You Enter Tech in the AI Era?

The old path was familiar: university, an internship, small fixes under an experienced engineer’s supervision, and gradually more demanding work. Simple tasks served two purposes: they helped the business and gave beginners something to learn from. Agents change that arrangement. If a tool can handle small fixes and features, a team has less reason to reserve them for a new hire. The co-hosts do not present the disappearance of junior roles as an established fact across the industry. They explore a conflict of incentives: the profession needs its next generation of experienced engineers, but an individual company may prefer to equip the people it already has. The discussion compares this to the tragedy of the commons: individually rational decisions can deplete a shared pool of future talent. Smaller teams have particularly strong reasons to prefer an experienced hire. A beginner therefore has to demonstrate usefulness earlier, before receiving the familiar opportunity to learn through several years of paid work. Producing code from a well-defined task is becoming a weaker reason to create a position.

One example is a corporate training program for strong programming-contest participants. These beginners already understand algorithms and data structures; with modern tools, a mentor, and a meaningful product problem, their energy can translate into rapid progress. But this is a selected population. Someone without commercial experience may still have spent years preparing, so the program’s success cannot simply be generalized to a person learning to code for the first time. Two complementary routes remain available: relationships within a professional community and technical competence. Relationships provide feedback, referrals, and an understanding of what a particular employer needs. The technical route still matters, but a connected ability to solve a problem carries more weight than a list of languages and libraries. Neither a contact alone nor a résumé full of tool names substitutes for being useful.

Fluency with an agent does not replace debugging, architecture, causal reasoning, or hypothesis testing. Aleksey explains why he initially framed his program as suitable for mid-level engineers and above: seniority was a convenient proxy for already having those foundations. But a beginner can study the foundations alongside AI tools instead of waiting for a formal promotion. The important questions remain what problem is being solved and what observation would distinguish competing explanations. Syntax is only one part of that preparation. Dependence on suggestions creates another risk: a person who acts only when an agent suggests a step is not directing the solution. The opposite extreme is also limiting—strong existing expertise without learning new tools. A useful target lies between them: benefit from acceleration while retaining the ability to explain what is happening and recognize the boundary of your competence. For a beginner, this means learning along two tracks, rather than treating quick results as permission to skip the fundamentals.

A project of your own creates a place to combine both tracks. Evgeny suggests completing the whole cycle: understand a problem, build a functioning product, launch it, and maintain it. The stages before code generation and after the first release are particularly valuable. Bugs, changed requirements, and the need to keep the system easy to modify turn a demonstration into real engineering practice. Yet a functioning product does not guarantee income. Alexander separates two meanings of entering tech: starting to make things and getting paid for them. The tools make the first easier without securing the second. A beginner competes not only with experienced developers. A domain specialist can automate their own work with AI and already understands the desired outcome. A project therefore needs to teach the developer about the user as well as the application. Asking why someone needs the result becomes part of engineering preparation earlier than it did in the familiar hiring model.

Aleksey suggests evaluating a beginner through the story of a completed project. Agent instructions in AGENTS.md, automated checks, CI/CD, and the response to failures all matter. The implementation language or years on a résumé reveal less than an explanation of decisions: how a new model was evaluated, how completion was verified, and what changed after an error. Alexander also proposes a narrower apprenticeship model. A beginner need not master every AI methodology; understanding the company’s own process may be enough. But they must explain the task and acceptance criteria, defend the agent’s implementation to a mentor, and understand release and rollback. Assessment needs to examine learning within the process, not just the final artifact. Working code no longer reliably proves that its author understood the problem. Mentorship therefore needs a deliberately designed feedback loop in which the person’s responsibility grows even when an agent performs the implementation.

The conversation offers a concrete learning tactic: read technical literature, starting with tables of contents if necessary, to discover areas you do not yet know. Observability, alerting, and service-level agreements then become questions to investigate. The value comes from understanding what a concept means and when it applies, rather than adding unfamiliar words to an agent’s instructions. Alexander describes active reading: find a conflict with your existing understanding, request an explanation and an example, and check what has become clearer. Receiving an artifact from a model does not mean the person has learned. Simply following the suggested steps and moving on leaves the feedback loop incomplete. A strong AI answer may therefore require substantial reading, follow-up questions, and independent checking. Cheaper, faster access to explanations does not remove that effort. Persistence in understanding connects reading a book, discussing a question with an agent, and working on a project. The co-hosts also suggest using publicly released development workflows as a learning environment for practicing a similar journey independently.