I was hired about a month ago after a web development internship to work with ASP.NET and Angular at a company in the agriculture industry. The company encourages us to use Claude Code, and I rely on it heavily because I still only know the basics of C# and SQL. I recently learned how to print "Hello, World!" in C#, yet I'm working on one of the company's most important real-time applications.
The biggest problem is that I'm given projects with little or no business context, requirements, or explanation of the database. There are hundreds of tables spread across multiple project databases, and I'm expected to figure out which data to use as I go. I'm handling the backend, frontend, Figma designs, database queries, and trying to determine what users are supposed to see—all at once.
The AI-generated queries are often long, convoluted, or incorrect. The one experienced developer on the team says the queries could be much simpler and points out better tables after the fact, but usually doesn't explain the broader data model or business rules. The company has hired several junior developers because management believes AI makes it possible to build applications quickly.
I'm stressed that I'm not actually learning C#, Angular, SQL, testing, deployment, or software design. Is this a normal junior developer experience? Am I gaining useful experience, or am I being placed in a role far beyond my current level?
4 Answers
There are two separate issues here. Learning to investigate an unfamiliar codebase and database is absolutely part of being a developer, but discovering business requirements by guessing is a management and communication problem. Before writing code, ask what screens or reports are needed, what the expected behavior is, and which tables are the source of truth. Write down the inputs, joins, filters, and expected output, then have the experienced developer review that short plan. It is much easier to correct a one-page data map than several days of generated code.
Treat AI as a tutor and assistant, not as a replacement for understanding. Set aside regular time to study C#, ASP.NET, Entity Framework, Angular, and SQL without asking it to build everything for you. Have it explain existing code, compare a generated query with a simpler version, and help you test your assumptions. You can gain valuable experience from this situation, especially in investigation and dealing with incomplete information, but only if you slow down enough to learn what you are delivering. Building critical software that you cannot review is dangerous for both you and the company.
You are not failing because you feel lost after one month. Even experienced developers need time to understand a new system, and nobody can infer undocumented business rules perfectly. However, being the sole junior responsible for a critical application with no requirements, testing process, deployment guidance, or mentoring is a serious organizational risk. Raise the problem professionally: list the missing requirements, risks, decisions you need answered, and areas where you need review. Keep a written record of assumptions so management can see what is unknown instead of blaming you for guessing incorrectly.
The whole development team is made up of junior developers, so I think the company really does expect AI to fill the experience gap. I’ll start documenting the assumptions and risks more clearly.
The model cannot know your company’s schema or business rules unless you give it that context. With hundreds of tables, it will confidently choose a complicated route through the database. Use the database catalog, such as information_schema.tables and information_schema.columns, to inventory tables and columns. Look at existing queries and naming patterns, document useful tables as you discover them, and verify the source of truth with the experienced developer. Also, don’t merge code you cannot explain. Ask the tool to walk through each query and C# class line by line, but spend time learning the language and SQL directly as well.
That makes sense. I think I’ve been asking vague questions after I’m already stuck instead of bringing a concrete plan for someone to correct.