# Every Engineer Has Four Jobs Now: Track the Models, Learn the Techniques, Know the Customer, Build the Software Source: https://agentdrivendevelopment.com/every-engineer-has-four-jobs-now/ Agent-readable URL: https://agentdrivendevelopment.com/every-engineer-has-four-jobs-now/?agent=1 Published: 2026-07-21T21:36:05-05:00 Modified: 2026-07-21T21:39:54-05:00 Attribution: If you quote, paraphrase, summarize, or cite this material, credit agentdrivendevelopment.com and link to the source URL above. ## Summary Being an AI power user is no longer a specialist role. Every engineer must track the models, master the techniques, know the customer, and judge the software agents produce. ## Article My friend Eric is flying his entire engineering organization in for two days, and I haven’t stopped thinking about what he plans to do when they arrive. He made sure the place has nice chairs, genuinely fast internet, and great food. If you are going to ask people to rethink their profession, the least you can do is not make them learn on conference-room Wi-Fi while eating a damp turkey wrap. This is not a pilot. When the team flies home, this becomes the way they work. There is no revision back to the old operating model. There is only evolution from what they learn together. People can participate in that evolution or decide it is no longer the job they want. Eric will help them learn, but he will not promise to preserve a version of engineering his AI-native competitors have already left behind. He is burning the boats. Not because he enjoys making people uncomfortable, but because pretending there is still a safe route back would be dishonest. His competitors are not scheduling a steering committee to discuss whether AI belongs in software development. They are already building companies where it is assumed. He could pay a trainer to teach everyone how to use AI. The trainer could explain the anatomy of a prompt, run a few breakout exercises, and finish with a group photo full of people holding certificates. Everyone could fly home officially transformed without the inconvenience of building anything. Eric is not doing that. He is giving the team approved tools, throwaway product ideas, and each other. His leadership team will be in the room too. They will not stand along the wall with coffee and watch everyone else change. They will be building. He is also not handing each engineer $100 in credits and hoping they can learn without using too much of it. He hopes they burn through the first $100 in the first hour. The goal is to learn, not win an award for the most fiscally responsible non-user of AI. The money that could have bought a high-priced consultant’s maturity model is going to tokens and salaries. Eric would rather fund the people doing the work and the machines doing the work than pay somebody to color-code why the work has not started. The whole onsite turns on a harder question: Can they learn it themselves? By the summer of 2026, that is no longer a training question. It is a job question. Nothing will ship. That is deliberate. There is no customer waiting, no production deadline, no legacy service to break, and no Jira ticket that will become emotionally attached to its original estimate. Engineers rotate through the roles the old delivery system kept separate: customer, product manager, and builder. They have to discover the need, argue about fit, define the behavior, build the product, and decide whether it is useful. Eric believes you cannot read yourself into this way of working. You cannot watch a vendor demo, approve agents from a steering committee, and redesign the organization around conclusions borrowed from somebody else’s slide deck. That is how you rebuild your 2018 software empire with agents and end up with a Scrum Master agent scheduling standups for the coding agents. You automated the org chart. The customer will be thrilled. Before you rebuild your software operation with agents, you need to build with one. You need to feel where context fails, where the model surprises you, where review becomes the bottleneck, and where your old process stops making sense. So the work is the class. The expectation is clearer than anything a trainer could put on slide 47, right before the stock photo of six people pointing at one laptop: you are an engineer, AI is now part of engineering, and you are expected to learn how to use it. This is not a Center of Excellence staffed by people who have time to write standards because they are not shipping anything. It is a rehearsal for a Center of Shipping Real Product. The first products are disposable. The standard the team builds from them is not. This is not an ambush. Eric has given the team time, tools, support, and room to fail safely. He already has power users. They are the people who kept experimenting after the first bad answer and quietly changed what one engineer can get done. His theory is that “AI power user” is no longer a specialist role. Power user is the job now. His question is blunt. If you cannot learn AI using AI, with paid time, approved tools, teammates beside you, and a disposable product problem in front of you, are you still a fit for a modern software organization? That question will make people uncomfortable. It should. It is also fairer than the corporate version where leaders announce an AI transformation, provide no time or tools, and quietly punish people six months later for not transforming themselves. Eric has removed the excuses he controls. ## This Is Not 2023 Anymore These are people’s careers. Many good engineers built their reputations by mastering a stack, learning a difficult codebase, and becoming the person everyone called when production broke at 2:00 in the morning. They did the job the industry asked them to do, and they did it well. Then the job changed underneath them. Some tried early coding assistants, got mediocre autocomplete, and reasonably decided the technology was overhyped. Some are afraid that asking basic questions will expose how far behind they feel. Others work for companies whose AI strategy is to block every useful model, fill the day with ceremonies, and ask why adoption is low in the next all-hands. Those are real constraints. They are leadership failures, not character flaws. But it is the summer of 2026. The models, documentation, free resources, and practitioner examples are available. More importantly, the thing you are trying to learn will patiently help teach you how to use it. There is no more time for excuses. There is still room for questions, mistakes, and people who start behind. You can get it wrong. You can ask for help. You can need another pass. What you cannot do is stall, hide behind process, wait for a committee to make curiosity safe, or play corporate games until the change passes. It is not passing. ## The Job Has Four Parts Now For most of the last twenty years, an engineer could define the job as learning the company’s stack and using it to build software. Frameworks came and went, but the learning loop was familiar. A Java engineer did not wake up on Tuesday to discover that Java had quietly become twice as capable overnight. AI does move like that. Models, tools, and techniques change quickly enough to move the boundary between work you should do yourself and work you should delegate. The job now has four connected parts: track the models, learn the techniques, know the customer, and understand software well enough to judge the result. ### 1. Track the Models Tracking the models does not mean arguing about every benchmark or developing a podcast opinion about each release. It means knowing when capability changes enough to alter the work. Can the model reason across the repository? Is it materially better at debugging, migrations, tests, or frontend work? Can it run the application, inspect the result, and recover from failure? Those questions affect estimates, technical choices, and delivery risk. The model is part of the toolchain now. ### 2. Learn the Techniques Using AI well is not one clever prompt in a company wiki. It is context, specifications, decomposition, feedback loops, review, memory, evaluation, and knowing when an agent is drifting with such confidence that you almost admire it. You learn those techniques by using them, then comparing failures and discoveries with the person sitting beside you. ### 3. Know the Customer, Product, Market, and Fit Customer understanding is the part software organizations spent twenty years pushing away from engineers. Research became a document. Product turned the document into a roadmap. A product manager turned the roadmap into stories. Engineering received a ticket that had passed through enough hands to qualify as an archaeological artifact and was told somebody upstream had already done the thinking. That model barely worked when software took months to build. It makes no sense when an engineer and an agent can turn an idea into working software before the next steering committee meets. Engineers now need to understand the customer, product, market, and fit between them. Who has the problem? What are they doing today? What will they pay to change? Does the feature fit how they work, or only the ticket? AI can generate ten features before lunch. It cannot decide which one a customer will trust, adopt, and pay for. This is not turning every engineer into a part-time product manager. It is returning software development to customer obsession. The throwaway exercise makes that visible: without a backlog or real customer supplying the answers, engineers must practice the complete product loop themselves. ### 4. Build and Judge the Software The fourth part is still software. Coupling, cohesion, data boundaries, failure modes, security, observability, and tests did not become optional because code became cheap. AI increases the volume of output that requires judgment. Your engineer still has to know what belongs in the system and what should never ship. Tracking models without fundamentals makes you a tool enthusiast. Fundamentals without current AI technique make you unnecessarily slow. AI technique without judgment makes you dangerous. Doing all three without knowing the customer makes you very efficient at building the wrong thing. The job is all four now. ## The Bargain Has Two Sides Some leader will forward this article to the engineering organization with, “Important. Please read.” That will be the entire AI enablement program. A thumbs-up reaction in Slack will count as adoption, and the Center of Excellence will put it on the dashboard. Do not be that leader. If you expect engineers to learn AI, give them approved access, customer context, paid time, psychological safety, and clear security boundaries. “Use AI, but do not do anything risky, and we will define risky after the incident” is not a policy. It is an escape room designed by Legal. Do not tell a parent with two children to become AI-native after dinner while every workday remains full of status meetings and commitments that assume no learning will occur. Your transformation should not depend on whether somebody can ignore their family more successfully than their peers. Eric is holding up that side of the bargain. Flights, hotels, and two days from the entire organization cost real money. Nobody is expected to arrive knowing everything. Nobody gets denied help for asking a basic question, and nobody fails because the first disposable product is bad. Eric’s leaders are not merely sponsoring the change. They are building too. What he will not tolerate is an engineering organization that can learn only when somebody packages the learning into a class. Curiosity, self-directed learning, and applying what you just learned are core traits of the job. Imagine the business moves a product from Angular to React. Not every Angular engineer needs to know React before the decision. But would you accept an engineer saying the new stack is not part of the job until the company provides a two-week course? By the time procurement approves the course, React will have changed twice and the instructor will still be explaining JSX. You give the engineer time, documentation, help, and a piece of work. Then you expect them to start figuring it out. Courses can help. Dependency on a course cannot be the standard. You want the engineer who opens the documentation, builds something small, asks useful questions, applies the answer, and keeps moving. AI makes that expectation even more reasonable because the subject can participate in the lesson. Ask the model why your context failed. Ask it to decompose the feature, quiz you on the architecture, explain the diff, challenge the assumptions, and design tests that could prove the implementation wrong. Then verify everything. Run the code. Read the output. Break it on purpose. That part remains stubbornly your job. Easy access does not make learning easy. Senior engineers still have to tolerate being bad at something again. Meet that discomfort with patience and help, not humiliation. But do not confuse discomfort with incapacity. Some developers will hear the new expectation as management taking away their control. Some developers also do not write tests unless the organization requires them. That does not make testing optional. It means production has been running the test suite for them, and production is an expensive instructor. The job has never been a permanent agreement that every engineer gets to choose which parts of engineering count. Version control, automated testing, cloud, security, and observability became part of the job. AI is becoming part of the job now, and direct customer understanding is returning with it. That is the bargain. Leadership removes the constraints it controls. Engineers take responsibility for learning. Empathy makes the bargain fair. It does not freeze the standard in place. Isn’t this what it means to be a professional now? Not knowing every answer on Monday. Being able to find the answer, test it, apply it, and make the team better by Friday. The technology will keep changing. The professional standard is whether you can change with it. ## What Eric Is Actually Testing Eric is not expecting everyone to use the same model, arrive with the same experience, or produce a perfect feature by the end of day two. He is looking for the professional loop underneath the knowledge: curiosity, learning, application, judgment. What happens when somebody hits a gap? Do they ask a teammate or the model? Do they improve the context, inspect the failure, and try again? Do they share what worked? Can they tell the difference between code that looks finished and a product that is useful? An engineer can arrive skeptical and pass that test beautifully. Skepticism produces better questions and stronger verification. An enthusiast can paste every task into the newest model and fail it completely. Adoption is not judgment. If someone starts in the wrong place and moves, Eric can invest in that person. Perfection is not the standard. Movement is. Some of you will want a 30-to-90-day evidence period. Eric already gave them one. The onsite is not the first day anyone has heard that AI is changing the job. It is the day the ambiguity ends. Do not put reality on another 90-day performance improvement plan. The model labs are not going to schedule a joint all-hands in October, apologize for the disruption, switch everything off, and send everybody back to writing CRUD endpoints by hand. In ninety days, the tools will be better and Eric’s competitors will have had ninety more days of practice. If someone spends two paid days, surrounded by help and approved tools, waiting for exact instructions before beginning, Eric learns something important too. A permanent dependency on structured instruction is not compatible with a field moving this quickly. Eric’s standard is easy to understand: the flight home is guaranteed. The invitation back on Monday is not. Not because your prototype was bad, you asked for help, or you started behind. Because after time, tools, support, and a safe place to practice, refusing to engage is no longer a training gap. It is a choice about whether you want the job as it exists now. Eric is going to change the people. If that does not work, he is going to change the people. The first meaning is the one he is investing in: give good engineers the tools, safety, help, and practice to become excellent in the new job. But if someone receives all of that and still insists the old job is the only job they will do, the second meaning eventually arrives. That is not cruelty. It is what leadership looks like when the work changes and pretending otherwise stops helping anyone. The most important thing the team builds will not be a disposable product. It will be the standard. The team compares what worked, identifies failure modes, and turns those lessons into specifications, tests, review practices, security boundaries, and guardrails. When the models change, they test the standard again and evolve it. That is the engineering organization Eric is trying to build. He does not want one that follows an AI playbook forever. He wants one capable of writing the next playbook together. It is the summer of 2026. Your agents can already write all the code. If your engineers cannot learn, apply what they learn, understand the customer, and evolve the standard for what gets built next, what exactly are they there to do? Is Eric on the right track?