kayashaolu2

I agree with the sentiments that it important to understand the code during major refactoring projects. But what if while the code was being refactored the AI was asked in addition to keep a ledger of the changes it made and why. That ledger could be the basis of providing understanding to a code base that most likely had minimal corporate understanding in the first place. And because it is ok text format, the learning scales well instead of being consolidated to a single team of people working on the project.

I don’t believe it has to be this zero sum game where either you use AI and lose understanding or you don’t use AI and gain understanding. There’s a way to do both since, if used properly, AI could be the best teacher we’ve had.

I think the most important way someone could be able cultivate breadth of understanding as well depth when needed is to be able to truly understand all of the things that are touched when someone uses the system, step by step. This doesn’t require deep knowledge in any one aspect of the system, but it does require someone to be curious, be open, and be willing to put themselves in the users shoes and use the feature, and then switch back into the developers mind and map user action to where in the codebase is being activated and why. And be willing to go back and forth. The interesting thing is that agents can help us, but the exercise loses its value if the agent just maps it out for us. We need to be in the process of discovery in order to build our own mental model.

The heart of the coding interview is to get signal on a candidates’ ability to solve a problem without all of the inputs given to them, see how they and explain their thought process as they do it.

Because of AI, what it means to “not have all of the inputs” has changed as anyone can cut and paste a Leetcode problem to a chatbot and solve it.

I think we are going to iterate a bit to figure out a better signal than the typical coding interview. For junior engineers, I think coding questions will move towards MBA style problems when someone is given more of an open ended question with a codebase and you see what the candidate does without context to reduce the problem.

At the very least, I think there’s going to be a competitive advantage for new engineers that do learn to code by hand even if they never do it at their jobs. There is a cognitive ability and understanding that is developed when building code that becomes very useful when coding with agents.

So, I hope coding goes away, but it is changing form though.

I think a different set of benchmarks focused on measuring the performance of models for real situations is the future. And it also can show how close (or far) models are at accomplishing the full responsibilities of humans. I really look forward to the evolution of this staff eng benchmark.

AI benchmarks are usually focused on the model’s ability to make, build, or solve something while the critical part of most tasks in the real world is in the ability to catch whether there is a mistake. Until we have more benchmarks focused on the ability of a model to detect an error I think we’ll have this discrepancy.

Part of me is wondering, maybe it’s time for part of open source to move from code to just words or prose? Since it’s possible to use AI to fix bugs and add features arguably more easily than before, what we could share with each other are ideas, thoughts, additions to each other’s prompts or skills that could be reviewed by the community.

And in this case carefully crafted, clear, and expressive words that are not too verbose would be the contributions of tomorrow.

I keep going back to LLM Wiki. It has found itself in so many other skills because of its fundamental value. Maybe we don’t have as many pull requests. But that one skill has proliferated in so many other skills because of its value.

My experience has been that if you have a good Engineering Manager / Product Manager combo for a team, you will naturally see skills for one bleed into the other. The EM speaking product strategy while the PM concerned about the technical debt of a surface. So even though lists like these with both the product minded engineer and the engineering minded product manager could seem like wish lists, they can also be seen as a guide on how people can expand their skillsets over time to help make better decisions.

I agree with you no investor or user cares how the code is built, and actually there’s nothing wrong with using LLMs to code. LLMs are the way to code now absolutely.

But, investors do care about the stability of the system they invested in. And how quickly it can be extended and expanded upon while still maintaining functionality. And they deeply care about scalability. I don’t believe this is a question about whether code is LLM generated. I think this is a question of having the ability to build a system that can be up and provide the value that investors expect. And the way you use AI and your knowledge of systems does play a role in that, especially over time.

And another point: it doesn’t have to be either or. Sometimes the prudent thing is to hand code a specific highly sensitive part of the system while your agents are building other things. The fact that these agents can do things in the background frees us with different possibilities. And also, sometimes hand coding some areas in the code that you are not familiar with builds your knowledge which the ln enables you to guide the agents more effectively later on. There’s benefits of both approaches and both approaches can be done simultaneously.

So I teach a couple of web architecture classes, and it’s been my experience that there is still a desire to learn how to truly build quality systems because they want to learn how to build quality systems.

I think our industry needs to transition to figure out what does it mean to build a quality system in the age of AI? It’s one thing to vibe code an application that works. But would you depend your livelihood on it? Would you get business funding and base the future of your team on it?

I think the challenge of the educational space is to figure out how to teach the judgement to build solid systems without relying on “hand coding”. For me I’ve been working on technology agnostic composable frameworks that help build that judgement. But honestly we are all just figuring this out together.

There will still be a need to be able to train system builders, the question really is what do they actually need to learn to be solid system builders in this AI era. And there’s a strong chance that pure programming language or tech stack learning may not be enough. This is what we educators need to figure out.

This is what I think: we will go through all of these other titles and then come back to software engineer (e.g. remember Prompt Engineer?).

The reason IMO is that true software engineering hasn’t been about producing code. It’s about solving problems by building maintainable systems. The best software engineers don’t only build for the feature, they build for the extensibility, maintainability, and scalability of the feature. That is the art of engineering software that I think we can still take pride in even during this AI era.