Coding agents shift much of an engineer's work toward architecture, planning, delegation, and checking whether the result is correct.
2
Agents make it possible to run more work in parallel, but productive engineers still keep a small number of difficult tasks under close human direction.
3
The skills that gain value include clear articulation, technical judgment, planning, and sharing working practices across the team.
Summary
Mihail Eric describes software engineering in a world where coding agents can write, test, and explain code. He argues that agents require more upfront thought because engineers must define architecture, split work, delegate tasks, and create checks that show whether an agent has gone wrong. He is skeptical of social-media demonstrations with dozens of agents running at once. In his experience, people get more from a few substantial tasks and a larger list of smaller tasks that can be delegated when appropriate. The conversation also covers junior engineers, team size, changing product and engineering roles, tool FOMO, and the need for teams to share failures and working methods. Mihail puts special weight on articulation. Engineers need to explain the desired result, the surrounding context, the acceptable tradeoffs, and what success means. He also expects engineers to take on more product thinking as agents make implementation faster.
Agents could help fill the training gap for junior engineers
Demetrios Brinkmann and Mihail Eric discuss the risk that junior engineers will struggle to get hired if companies assume coding agents can replace their early work. Traditionally, juniors learn through pairing, code review, and gradual movement into senior responsibilities. Mihail suggests agents could help fill part of that missing training path because they can explain unfamiliar code as well as generate it. A developer can use a chatbot to learn an area before implementing a change. He also warns that some people may choose to remain ignorant of how an implementation works, accepting an agent's output because it appears to function. That may be tolerable for low-risk work, but Mihail says engineers should retain stronger control over architecture and core infrastructure.
Agent creativity is useful when the engineer lacks a strong prior
Mihail calls agents glorified pattern matchers, yet he still sees value in the unfamiliar approaches they produce. If he does not know Next.js or Vue well and has no strong design preference, an agent's implementation can provide a reasonable starting point based on patterns that exist in the world. This does not mean allowing the agent to proceed without review. The engineer still needs to control the result when the system is important or the design has meaningful consequences. Demetrios connects poor agent output in JavaScript to the large amount of poor JavaScript available on GitHub. Mihail agrees that the quality of the material an agent has encountered affects the patterns it produces.
Validation is the foundation for autonomous coding work
Mihail says the most important part of an agent workflow is the validation system around it. An agent might work on one task, many tasks, or several tasks in parallel, but it needs checks that can show whether the result is correct. Those checks might include opening a browser and using a website, running backend tests, or checking that new test coverage passes. Humans remain involved in defining and reviewing these validations. The limit is that some production actions are still hard to verify automatically. Infrastructure changes, DNS work, and interactions that require API keys can demand human judgment. Mihail expects this boundary to move outward, though he says coding agents still reach it today.
Deep work has to be found in tasks that agents cannot finish immediately
Demetrios observes that tasks he considers substantial often finish in five or ten minutes. Mihail says teams need to identify where deep work still exists because sustained concentration takes time to develop. A useful workflow contains tasks that occupy an agent while the engineer works on something else, followed by a review and validation loop. He expects this to be more common in large existing codebases, where even a small change can trigger extensive testing. The build system may identify which parts are affected and run tests incrementally, but the overall loop of changing code, building, checking errors, and fixing the result can still take time. Those longer loops create room for meaningful task switching.
Demetrios asks how teams should decide when to save a skill, create a rule, use a prompt, start several agents, or run parallel attempts. Mihail says there is no settled answer. Teams are still forming hypotheses and learning through feedback loops. His practical advice is to distribute both successes and failures. Shared Slack channels, lunch-and-learns, and groups that define internal practices can help raise the capability of the whole team. He compares this with internal developer infrastructure teams that help developers use CI and build systems. The same groups may decide what belongs in an agents.md file and how new developers should work with agents. Giving everyone access to tools is insufficient because people still use them with very different levels of care.
Outcome-based pricing may replace token-based pricing
Mihail argues that tokens are an implementation detail and a proxy for the path an agent took to complete a task. Users ultimately care whether the task was completed, even if the agent used an inefficient loop of repeated attempts. He imagines providers charging more like a service that completes a defined job than like a system that meters every token. Demetrios points out that companies building on models from Anthropic or OpenAI would still bear the underlying model cost. Mihail does not claim to have a solution. He describes a tension for AI companies that are both major model customers and potential competitors to the model providers. The conversation also touches on open-source models and the way commercial pressure can weaken stated principles.
Engineers should choose a tool and build skill with it
Mihail is skeptical of developers who constantly tune their setups around small benchmark differences. He sees a common set of features across the leading coding tools and recommends choosing one of the top options, then learning how to design systems with it. Switching every time a new model or benchmark appears creates FOMO and distracts from the work. He does support keeping fallbacks because these services can go down. Mihail says he is comfortable with Claude, Cursor, and Devin, so an outage does not stop his workflow. His advice is to spend more time developing a method for using a tool than comparing minor differences between rapidly changing products.
Parallel agents work best for small, well-checked tasks
Demetrios asks how to start enough parallel agents when a single task often finishes before the next agent is configured. Mihail thinks online demonstrations with many tiled assistants romanticize the idea. The most productive developers he has seen keep roughly two substantial tasks under close human involvement. Those tasks require careful review of specifications, requirements, architecture, and design choices. Additional agents can handle smaller changes such as configuration edits, modest refactors, or adding tests. This approach depends on a useful validation harness. Mihail recommends starting with one agent, then trying two after becoming comfortable with context switching. He plans his day around a few difficult tasks and several smaller tasks that can be delegated when there is available time.
Demetrios says the skill he most wants to improve is articulation. Engineers need to state what they want, what context matters, what counts as good enough, and what success looks like. Mihail agrees that agents expose the cost of vague requests. Humans can often ask follow-up questions when a request is unclear, while an agent may spend time moving in the wrong direction unless it is prompted to interrogate the user first. A brainstorming skill can collect missing context before work begins, but that adds time. Mihail treats clear communication as a forcing function that makes engineers better at expressing requirements. This matters as engineers take on more planning, delegation, product thinking, and system design.
"The most crucial piece that you have to get right as a developer is the validations, like the testing harness, like the checks to make sure that what you let the agent go off autonomously on is correct."Mihail Eric07:07
Who should watch
You are deciding how your engineering team should use coding agents and need practical guidance on tests, shared practices, and task delegation.
You are a junior engineer worried that agents will remove the usual path from implementation work to more senior responsibilities.
Your team keeps switching between Claude Code, Cursor, Codex, and other tools because of benchmarks, outages, or online discussion.
