Shubhankar (Shubs), an engineering manager at Assetnote, published an essay and a real dialogue with a subordinate about how the joy of engineering work is being lost in the AI era. In the dialogue, the engineer describes no longer fully understanding every commit and no longer feeling ownership of the result, while the manager formulates the diagnosis: the place of design and debugging is increasingly being taken by reviews and planning. In return, the author offers techniques that can be applied immediately — from CLAUDE.md and AGENTS.md files instead of unreliable built-in 'memories' to consciously choosing complex, rather than routine, tasks for AI.

What happened

Shubhankar (Shubs), who leads development in code security auditing at Assetnote, published an essay titled 'Do we still enjoy software engineering in the age of AI?' on shubs.io, along with a real dialogue with a subordinate. In this dialogue, the engineer lists specific losses: previously, he fully understood every commit he submitted, kept the codebase architecture in his head, and felt ownership of the result; now, AI tools 'eat up' critical thinking, their built-in 'memories' don't retain the fixes made, and models and tooling change roughly every six months, which devalues deep customization for a specific stack. The diagnosis the author formulates as a result of the conversation: AI is turning engineers into 'middle managers' whose reviews and planning replace design and debugging.

Context

The value of the text lies in its status as a primary document: this is not a retelling of someone else's survey, but a real exchange of messages between a manager and an engineer on an active team, where what is usually left out of presentations about productivity growth is discussed. The author himself developed source code auditing skills for over fifteen years, and it is against this backdrop that he notes the rapid success of AI in source code auditing — an area into which he had invested half his life. The complaint that agents' built-in memories don't retain fixes aligns with known limitations of agent memory: fixes made by the engineer during work are not fixed between sessions, and he is forced to repeat the same instructions over and over.

Why this matters for the industry

For the industry, this is not just another article about development speed, but a pain map of a real agent user: memory failures between sessions, loss of context between prompts, and the shift of the engineer's work to reviews and coordination. The mechanism recorded in the dialogue is simple: when the time spent writing code decreases, the share of coordination and reviews increases, and critical thinking is replaced by managerial — it is precisely this shift that the author describes as the path to burnout that many engineers do not want. Each pain point is a ready-made product hook: a context layer for agents, memory that learns from fixes, review-first UX in agent platforms. For employers, the text is a signal to reconsider the role of the engineer and team structure, not just to implement tools; the stated six-month cycle of model and tooling changes additionally means that investments in deep customization for a specific stack quickly lose value.

Why this matters for users

The practical part is immediately applicable and without purchasing any products. Instead of unreliable built-in AI memories, the author advises keeping instructions and context in ordinary CLAUDE.md and AGENTS.md files in the repository: they are forcibly included in each subsequent agent prompt, so necessary instructions are not lost between sessions. The second technique is to consciously feed AI tasks of increased complexity, not routine. The third is not to dismiss your pre-AI deep understanding of systems: the author calls it 'artisanal programming' and considers it a superpower that others will not be able to catch up to for a long time. Additionally, it makes sense to introduce mandatory review of AI commits and measure the actual share of time spent on code, not on coordination.

What is still unknown / limitations

The source is a personal essay and one dialogue, i.e., the experience of one person: the text has no methodology, quantitative metrics, or reproducible evals, so the thesis about turning engineers into 'middle managers' should be read as a qualitative hypothesis, not a measurement. Strong claims about model capabilities — rapid success in source code auditing, mentions of tasks at the level of unsolved mathematical hypotheses and zero-day vulnerability discovery — remain without reproducible checks and are indistinguishable from an anecdote. The observation about the six-month cycle of model and tooling changes aligns with the actual release speed, but there are no systematic data in the text either.

Sources

Author

Look at AI, editorial team