# ============================================================================= # Published - The Junior Developer Is Gone. The Junior Product Engineer Isn't. (verbatim) # ============================================================================= # An article authored by Cedric Ancellin, first published on this site. # Text is preserved as written (including original wording and any typos). # Governed by ../LAWS. Verbatim files are exempt from the em-dash rule. # # Added on 2026-10-17. # ============================================================================= title: "The Junior Developer Is Gone. The Junior Product Engineer Isn't." author: "Cedric Ancellin" published: "2026-10-17" platform: "zc8.com" linkedin_url: "https://www.linkedin.com/pulse/junior-developer-gone-product-engineer-isnt-cedric-ancellin-p4eme/" cover_image: "/assets/articles/the_junior_developer_is_gone.jpg" topics: ["junior developers", "hiring", "product engineering", "AI coding agents", "ontology", "knowledge base", "data modeling", "database schema", "CS degree", "agent security", "lethal trifecta", "zero trust"] summary: > A follow-up to "We are worrying about the wrong problem". Cedric explains that the entry-level job has moved rather than disappeared: for his next project he will recruit junior product engineers, not junior developers. He argues that a CS degree matters more with AI, not less, because the role now needs a general base across the stack rather than one specialty. He then describes the screening test he is building: the candidate builds a product with an AI agent, live and recorded, without typing any code. Phase one is the ontology and database schema recorded in a knowledge base, with no code and no database. Phase two is having the AI build the product from that knowledge. Throughout, he watches how the candidate handles security, both in the product and in how the agents are run (approval prompts versus a zero-trust environment, and the "lethal trifecta"). He closes by noting this is his personal experience at an early stage of AI. body: | In [We are worrying about the wrong problem](https://zc8.com/published/we_are_worrying_about_the_wrong_problem), I wrote that I would never hire a junior developer again because of AI. I meant it. But I owe junior developers the other half of that sentence: the entry-level job is not gone. It has moved. I am starting a complex project that will need a team. I will not be recruiting junior developers for it. I will be recruiting junior product engineers. I have now worked on enough projects, using AI in enough different ways, that a junior developer in the traditional sense, someone I hand a ticket to who comes back with code, brings me nothing the AI doesn't. What the AI cannot bring me is someone who understands the product, holds the model of the system in their head, and directs the development. That is the job now. It is less about writing software and more about managing how software gets written. Yes, this is a higher bar for an entry-level role. Junior means you lack experience. It no longer means you get to understand less of the system. ## What I still require A CS degree, and I am stricter about this than I used to be, when I happily hired self-taught developers. I know the popular view is that degrees and certifications don't matter anymore, that AI has made them obsolete. I would argue the opposite: their importance has grown. A specialist can get by on what they taught themselves, because they only need depth in one place. I am no longer looking for specialists. I am looking for someone with a general base: code, system administration, networking, databases, and the project discipline of something like a PMP. When you no longer write the code yourself, your only defense against an AI going wrong is knowing what right looks like across the whole stack. Nobody needs to excel at any of it. All of it needs to be known. Formal education is still the best way we have to build that kind of base. The best way to explain what I am looking for beyond the degree is to describe the test I am building to screen candidates. ## The test The candidate builds a product with AI, screen-shared and recorded, live. They are not allowed to type a single line of code. They know nothing about the product in advance. They only know the environment: - A local development environment such as VS Code - A coding agent of their choice, inside it - A knowledge base such as Obsidian - An ERD tool with a text source, such as Azimutt (AML) They are encouraged to prepare: configure their agent, write their rules, set up their knowledge base and ERD templates before the day. How they prepare is already part of the evaluation. ### Phase 1: the ontology Plan the product and build its ontology and database schema. No code. No database. Everything recorded in Obsidian. One of the projects I worked on required a very complex database and data flow, supporting a multitude of use cases. I spent over a month on the ontology and schema alone, refining the methods, simulating scenarios, and walking use cases through the model, without writing code or creating a database. It paid off. When I went to develop it with AI, I had complete mastery of the schema, and the AI made far fewer mistakes than usual, with very little refactoring, because it was building against a complete ontology. So the first question is: can you build an exhaustive ontology and record it properly? Are the entities and relationships complete? Have the use cases been walked through against the schema? Are the invariants written down? Is all of it in a form an AI can consume? I no longer use Obsidian myself, I outgrew it, but the tool is not the point. It is an excellent place to learn to build the knowledge foundation an AI needs to build your product efficiently. ### Phase 2: the build Shorter, not easier. Have the AI build the product from the knowledge in Obsidian. If phase 1 was done well, this goes fast with few errors. There will be refactoring, there always is, and that is what I want to see: how the candidate adjusts when the plan meets reality. ### Throughout: security Two layers. The product itself, starting with authentication, secret keys, sessions and permissions. And the way they use the AI. Do they treat the agent's approval prompt as their security boundary, or do they run their agents in a [Zero Trust environment](https://zc8.com/published/zero_trust_is_being_rewritten), as I explained in a prior article? Do they run a single agent that has access to private data, is exposed to untrusted content, and can send data outside the system? That combination, the "lethal trifecta" as Simon Willison named it, is the most dangerous thing you can do with an agent today, and most people do it without noticing. ## The advice If you want to become a developer today, knowing how to use AI is not enough. Showing me you can vibe code means nothing. Everyone can. Show me that you understand the limits of AI, that you are conscious of the risks, and that you can build an ontology in a knowledge base that an AI can exploit to escape the limits of its context. Learn data modeling seriously. Learn to write for a machine reader. Learn to sandbox your agents. Be a product manager first and a developer second, and you will have my attention. This is my personal experience. I don't know whether my CTO and CIO colleagues agree with me. We are at an early stage of AI where all of us are asking ourselves the same two questions: who to hire, and what they will actually be doing. None of us has had the time to be proven right or wrong yet. If you are hiring and you have landed somewhere else, I would genuinely like to hear where. transcription: "As written by Cedric Ancellin, first published here 2026-10-17."