Can AI Help Less Experienced Engineers Grow?

AI can help experienced engineers, but what happens to people who struggle with engineering decisions? My view is that coding assistants can raise the floor by suggesting more conventional solutions and catching some obvious mistakes. They can also let a person produce more harmful changes, so this is a judgment about a tradeoff, not a guarantee.

I am reacting to Sean Goedecke’s article about AI making less effective engineers less harmful. He argues that engineering output varies widely and that poor changes can create work for colleagues. I would frame part of the issue as a mismatch between people’s abilities and responsibilities rather than a single fixed ranking of individuals.

I can be part of that mismatch myself. I am good at moving quickly and understanding a system, but the quality of my code varies. On my team I sometimes use a pull request to show an idea with no expectation that it will be merged; colleagues can then examine the idea and implement it properly.

Team size matters as well. Fred Brooks’s The Mythical Man-Month warns that adding people to a late project can make it later because onboarding and coordination consume time. That is not a claim that extra people never help; the effect depends on how work can be divided and the costs of bringing them in.

I see this in requests to add more people to delayed work on T3 products. Contributors can help, but someone must onboard them and coordinate changes. In previous roles I sometimes helped a late project by reducing scope and prioritizing what could actually ship, rather than assuming that a bigger team would solve the schedule.

Ability is multidimensional, and experience is only one part of it. I might invest in a less experienced engineer with strong growth potential rather than judge them solely by their current output. That investment can slow a team in the short term while paying off later, provided people have support and a chance to stay and grow.

Goedecke argues that coding agents have raised the floor: changes that might once have contained obvious local errors can become more coherent. I have seen something like that when people working outside their familiar language use an assistant. But a plausible pull request can still be wrong, especially when it needs cross-system context.

An agent may push back on obvious mistakes such as a cache key that omits the user or an unclosed file. It may also miss subtle issues or accept a bad instruction. Treating model output as reviewable work is safer than assuming that AI assistance makes every change functional or secure.

I want to illustrate my frustration with a past workflow, but first I want to credit the Mod View team at Twitch. They were among the best people I have worked with, and they solved difficult problems under demanding deadlines. I am proud of that team and the product they shipped.

The problem I describe concerned the announcement blog post, not the Mod View product. We supplied video demonstrations, and I say the initial post used very large GIF conversions instead of lightweight embedded videos. The page became extremely heavy. This is my recollection of a particular episode, not an independently audited account of the people involved.

I recount a series of attempts to fix it: using Twitch video embeds, converting the demonstrations to WebM, providing HTML and arranging storage. The result still did not match the intended autoplaying demonstrations, and the article shown in the video later has broken embeds. The episode illustrates communication and workflow failures as I experienced them.

I also describe responding with intense frustration and the possible effect on my promotion. I wonder whether a coding agent would have handled a straightforward embedding request better. That is a hypothetical comparison, not a test of a specific model, and a single anecdote cannot measure a colleague’s overall ability.

Goedecke notes a potential downside when someone simply relays requests to an assistant without understanding its work: colleagues may wait longer for responses, the person may learn less, and the company still bears the cost of both the employee and the tool. Those are concerns about a workflow, not proof that using AI means a person adds no value.

I draw a rough diagram with experience on one axis and my subjective assessment of engineering skill on the other. The point is to separate experience from current ability: some newcomers learn rapidly, and years in a role do not ensure every relevant skill. This is a conceptual sketch, not a validated way to rank people.

To explain what I mean, I describe hiring Mel for Ping, a live collaboration product involving web development, WebRTC and streaming integration. She came from game development and was building a game engine, rather than following a conventional web engineering path. Her curiosity and prior projects made me interested in her potential.

After I explained our stack, Mel quickly rebuilt her portfolio with it and started another project before I had even prepared an exercise. I hired her, and she went on to help with product work, administration tools and video recording infrastructure. The lesson for me was to look for demonstrated learning and initiative, not only a familiar résumé.

About a year later we were planning a recording-storage system together. I had a rule asking new hires to voice at least one question a day, to reduce the fear of sounding inexperienced. After the design discussion, Mel asked what an endpoint was—a basic term she had not needed in the same way in her previous work.

The question did not erase what she had already built. In our stack, much of the communication was exposed through function-like calls, and her earlier game-engine work had different demands. The same knowledge gap can mean different things depending on a person’s experience, responsibilities and willingness to learn.

I think motivated newcomers can use AI to ask follow-up questions they might otherwise be embarrassed or unable to ask, and to explore an unfamiliar diagram or concept. That is an opportunity for learning, though answers still need checking and access to human mentorship remains valuable.

I contrast that with using an assistant only to appear productive while avoiding understanding. My distinction is about how someone uses a tool, not whether they use it at all. An agent can make a first draft easier, but the person still has to learn enough to judge whether the draft serves the real problem.

I redraw my diagram so that experience runs from new to seasoned and the other axis represents my impression of skill. I use it to discuss people who grow quickly despite limited experience. It is a personal heuristic and does not capture the full range of skills, opportunities or circumstances that shape an engineer’s work.

I mention an intern, Yash, who independently explored modifying web bundles, as another example of curiosity and initiative. I think AI can give people like this more ways to investigate and experiment. My predictions about how quickly individuals will improve are personal expectations, not measured career outcomes.

The article raises a concern that relying on generated answers may reduce learning. I think the outcome depends on the person and the workflow: someone can use an assistant to compare ideas and ask why a solution works, or accept output without understanding it. Both patterns are possible.

There is also a social difference when discarding work. I have sometimes felt guilty rejecting a human colleague’s pull request after they invested effort, even when the change was not right. I find it easier to discard an AI-generated attempt, and I tell my team that my own proposals can be closed when they do not fit.

That does not remove the need for considerate communication with people. If a colleague uses AI and shares its output, a human still receives the feedback. Teams need to discuss the substance of the work without treating a person as though they were merely a tool.

I argue that deeply held preferences can steer an agent toward a poor choice, because an assistant may comply with a user who confidently rejects its suggestion. My disagreements about React are an example of the kind of strong technical preference I am discussing; the merits of any framework depend on the actual project and constraints.

I credit Alex Russell’s research on the performance gap between devices even while disagreeing strongly with some of his views on React. The chart I show compares single-core benchmark scores across selected phones over time. It illustrates hardware differences, not a complete measure of every user’s web experience.

An assistant can reinforce a user’s assumptions as well as challenge them. I worry about a workflow where someone insists on a preferred solution and the model agrees without exposing the tradeoffs. That risk is a reason to test alternatives and inspect the result, not a reason to assume all disagreement with a framework is ignorance.

My forecast is that AI could widen differences between engineers who use it to learn and those who rely on it without building understanding. I speak bluntly about possible employment consequences, but the claimed scale and timing are my speculation, not a demonstrated statistic or a prediction about any particular person.

My advice to newer engineers is to keep asking questions, experiment and record what you learn. Not knowing a term is different from refusing to learn it. AI can be a useful learning companion, but progress still depends on curiosity, practice, feedback and checking its answers.

The central opportunity is to use these tools to grow, not just to make output look more polished. I expect the field to change and encourage people to keep learning as it does. My confidence about individual outcomes is a personal view, not a guarantee.