If they just want you to churn out tokens, then chances are it's a) not a great job (although I suppose you have to take what you can get) and b) probably not very future-proofed?
For mid and senior level devs this is the way to do it. write plan, ask ai to code, ai review for bugs and at the end human review. But its so bad for juniors.
With how fast ai is getting better, every company will use AI.
For me, it is about more than just writing the code. It's understanding it, it's understanding what it affects, it's understanding where it lives amongst the other systems that are already in place - and what systems could be in place. AI is not very good at picking this up. It can tell you what it affects, probably, but the rest I have found it to be quite ineffective.
Writing the code was never the hard part
AI can tell a lot of things, but its different when AI tells you vs when you do it and figure things out. When ai tells you about it, it can feel like learning when in reality you are not actually learning it.
ability to read code and finding issues in the code you read is a different thing too.
- Work with the LLM, don't have it work for you.
- Your intuition about needing to hand-code, make mistakes, and then learn from them is correct. So, where possible, try to do as much hand coding as possible, and use the LLM to accelerate where needed, while setting up the correct expectations with whoever you have to report to.
- E.g.1 You are asked to implement feature X, and your boss asks for an estimate for how long X will take. Think about how long it would take you to do X without an LLM and try to give an estimate as close as possible to that.
- E.g.2 You are now working away on X and realize that you have to do this mundane setup of something simple but necessary. Something like parsing a CSV and formatting it in a certain way. Give that to the LLM while you continue to work on the more intense engineering aspects of your tasks.
- You can use the LLM as your teacher. While working on things, try to avoid giving it large tasks that are related to technical aspects or ideas that you're unsure about. Instead, prompt the LLM so that you're asking it incremental questions related to your task.- You will need to learn about some core principles for building systems and the communication and organization of the components therein. Again, you can use the LLM to aid you in this task rather than having it do the work you only rubber-stamp.
- I.e., Sketch out a plan for how you are going to create the systems that you are tasked with working on and then use the LLM to "grade" your plan, while scrutinizing the responses it gives you so that you understand why something does or doesn't make sense.
- Here, systems can be entire applications that have to do something, or a few classes that you have to implement in a large legacy codebase.
The main advice I have is to use the LLM to teach you things and learn where you went wrong or right, while taking advantage of it to speed up things that have become second nature to you.If you think you deserve to just have the answer fall in your lap, you'll never develop any real curiosity or have the motivation to work hard for something.
Now you can choose to believe the people who say that hard work is over, that there's nothing left to invent, that the future is people copying copies of copies of things. Do you believe that?
Now then, if you could see that everyone was trying to be a follower, where is the opportunity? Who will the followers follow? If everyone wants to follow, the opportunity goes to leaders. You must take this into consideration when you hear someone say "in the future, everyone will be a follower, and so to get ahead you should become a follower"
Hard work has now gotten extra hard for juniors.
And you can't keep up with the advancement of AI.