Then consider on top that the perceived time needed for implementation has dropped so additional work that would have never been taken up in the past gets added.
Actually learn to code instead of just prompt. Get any internship you can as early in your college years so you can understand if you like working in the industry before getting to far along. Once you have an internship take it seriously. Just because the company or team you are on is terrible its much better to be in a position to get a return offer instead of being desperate to find a job upon graduation.
Interns that I have seen be successful at Amazon do the following:
1. Show interest in the process.
2. Work really hard to unblock yourself. (You should feel like you're stuck a lot of the time. If you're not the project is too easy)
3. Learn when to get help to unblock yourself.
4. DO NOT tell anyone on the team or adjacent to the team you are on that you are not interested/ would not accept a return offer. This will guarantee no offer. Our best intern did this. (If you are skilled everything will turn our fine but it is nice to have options)
It all depends on how hands on you are willing to be.
If you are using the model to write to code faster with extensive human oversight you can develop a lot faster using the non-frontier models. I was doing that extensively last summer.
But now my thought process is I want to focus on architecture and product direction. I have not seen Sonnet level models be capable of performing autonomously enough to take a feature end to end reliably enough to be completely hands off. In fact there a many cases where Opus will fail as well where Fable will succeed.
Of course that is not to say that Fable will always do things correctly. It will happily take an under-specified problem statement and happily use up all of your usage to build the wrong thing, while Opus at least recently stops constantly to check in.
When I was working at amazon (left May 8) working on agents was all the rage. Combined with initiatives that set goals for nearly all services to have a MCP built and available by the end of the year agents will be even more emphasized in the future.
However what happens when you actually build and launch your agent is customers try it, do some initial runs and then go ask your manager to automate their use case. That is why I have been building https://toolscaled.com/ The goal being work through your problem space using agentic chat (like Claude Desktop) and then at the end convert it to a workflow. I am pretty close to launching and have been testing. If you're interested send me an email! (if you do sign up just fyi its still in beta so YMMV.
I built a workflow execution engine that dispatches to my tool service. I had previously looked into using Temporal but at the time decided to focus on what differentiated the idea. Maybe in the future execution durability will be important enough to make using Temporal the right solution however as of now I am focused on explore the problem space using chat -> convert the good parts to a repeatable process -> trigger appropriately.
