{"slug": "if-ai-writes-all-the-code-whats-left-for-engineers", "title": "If AI writes all the code, what’s left for engineers?", "summary": "PostHog moved from roughly 20% of its monorepo pull requests being opened by AI agents to 70% over the last four months, according to a PostHog blog post, a shift the company says breaks the definition of an engineer as \"someone who writes code.\" PostHog argues engineers will increasingly spend their time on \"monitoring the situation\" — watching running agents, fixing errors, responding to customer requests, and babysitting outstanding PRs — and on setting direction by synthesizing that information into priorities. The post notes Anthropic has claimed \"coding is largely solved\" yet still lists 208 open roles with \"engineer\" in the title.", "body_md": "We are plausibly coming to a moment where AI will write all the code. This is a reality for many developers already. Over the last 4 months at PostHog, we moved from around [20% of our monorepo PRs](https://posthog.com/blog/10k-prs-a-month?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all) being opened by agents to 70%.\n\nThis breaks the definition of engineer as “someone who writes code.” But no one thinks engineers will go extinct as soon as this happens. Anthropic has claimed “[coding is largely solved](https://www.youtube.com/watch?v=We7BZVKbCVw),” yet it has 208 open roles with “engineer” in the title.\n\nSo what will engineers be doing?\n\n## 1. Monitoring the situation\n\nEngineers spend a lot of time monitoring running agents, fixing errors, responding to customer requests, evaluating competitors, checking dashboards, strategizing on their role in company priorities, learning new workflows, and babysitting outstanding PRs.\n\nI sum this up as “monitoring the situation.” The result of it is ideas and observations of how they can improve.\n\nEngineers did a lot of this before, especially [product engineers](https://posthog.com/product-engineer/what-is-a-product-engineer?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all), but AI has amplified it. AI increased the amount of information an engineer can process, but it also increased expectations from managers and customers about productivity and polish.\n\nThis means engineers can’t be waiting for the right information to come to them. The best ones now create systems to get the information they need at the right time. This is part [loop engineering](https://posthog.com/newsletter/loops?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all) and part [context engineering](https://posthog.com/newsletter/fix-your-agents?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all). Engineers at PostHog have [standup bots](https://posthog.com/blog/standup-bot-revenge?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all), repo summary [scouts](https://posthog.com/blog/what-is-a-scout?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all), [custom setups](https://www.talyn.dev?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all) for monitoring in-progress PRs, [feedback surveys](https://posthog.com/surveys?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all), [changelog](https://posthog.com/changelog?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all) automations, anomaly [alerts](https://posthog.com/docs/alerts?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all), and more.\n\nWhy is doing all this important? Because without this information, you will likely end up working on the wrong thing and not know it. Knowing all the possible things you could be working on enables you to prioritize and pick the right one.\n\n## 2. Setting direction\n\nSoftware might be [increasingly driving itself](https://posthog.com/blog/what-if-your-product-built-itself?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all), but you still need to say where you want it to go. This requires synthesizing and analyzing what you observed to figure out what is valuable and worth acting on.\n\nBased on the input an engineer receives, there will be hundreds of potential paths. In the past, product managers or execs might have been responsible for picking the best ones, but it’s now increasingly up to engineers.\n\nOur [requests for comments](https://posthog.com/newsletter/choosing-technologies#4-we-make-decisions-asynchronously?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all) repos are an example of what this looks like. They contain nearly 1,000 direction-setting decisions on topics like [dashboard MCP improvements](https://github.com/PostHog/requests-for-comments-public/pull/551), [environments](https://github.com/PostHog/requests-for-comments-public/pull/176), and [picking programming languages](http://github.com/PostHog/requests-for-comments-public/pull/71). We can look at [an RFC for a unified health page](https://github.com/PostHog/requests-for-comments-public/pull/475/changes) as a specific example. It filters information through:\n\n- **Personal experience and opinions.** Rafa wrote it and the decision was ultimately his, with others adding their thoughts. As a specific example, he predicts: “We have 4 of them right now, but 3 of them were created in the last couple months, so they might start proliferating.”\n- **Importance to users, customers, and company.** The problem statement details the many surfaces for diagnostic information and the problem this creates for users: discoverability, each health page providing an incomplete picture, and the developer overhead of maintaining each one.\n- **Technical feasibility.** The design outlines the specific architecture using Dagster to run checks and store them in Postgres. It also includes how PostHog AI can use this data to provide suggestions.\n- **How it fits into the broader competitive landscape.** Unifying the health page automates a problem the Onboarding team regularly runs into with customers when setting them up for long-term success. Healthier setups are better for our customers and for us.\n\nWithout a clear direction, you can feel productive without actually making progress. AI makes this worse by enabling you to add anything you can think of easily. The direction and experience of your entire product can become clouded by features that aren’t what users actually want or you can be quickly led down the wrong path that’s hard to reverse.\n\n## 3. Deciding how to build and implement\n\nEngineers might not be writing code, but they are still deciding what code gets written. A direction leads to many smaller decisions. Each decision is a hypothesis of what can be built to make progress towards the direction you're going.\n\nWhat this often looks like is deciding on scope. This requires knowing the codebase, what’s possible, what agents are capable of, and their blind spots.\n\nThe importance of this is made clear when I compare myself against real engineers. As a marketer, I monitor the situation and think about the direction products should be going in. I make feature requests and can use agents to implement them, but just the ability to generate code, even in the right direction, is not necessarily good engineering.\n\nFor example, I wanted the ability to send AI user interviews as a link rather than an email. Although I could have asked an agent to build it, Paul’s reply shows the knowledge I lacked for making a good implementation decision.\n\nI wouldn't have known to accept `distinct_id` and `session_id` as query parameters, to throttle requests, or to look at hosted surveys for inspiration like Paul did. At best, my agents would have taken many more tokens to get to the same solution. At worst, they would have introduced bugs and attack vectors.\n\nIt’s this understanding of the problem area, implementation details, and structure that enables engineers to ask the right questions and follow up to get a solution shipped.\n\n## 4. Evaluating the work of your agents\n\nThis is the point where engineers would have been writing the code. Now, they just tell the agent to do it and that’s it, right?\n\nSadly, not yet. Engineers still need to evaluate whether it was **built right**.\n\nThis is done through [code reviews](https://posthog.com/newsletter/code-review-tips?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all) and asking questions like:\n\n- Did the agent actually follow directions?\n- How is the code quality of this change?\n- Did the tests pass? If not, how do I make them pass?\n\nWith the volume of changes coming from agents, this quickly becomes a bottleneck. If you are generating 20 PRs per day, reading every line and running them by hand is unrealistic. You need new systems, like review and testing agents, to keep up while ensuring the code you ship is good.\n\nFor example, many of our engineers have their own custom-built code review and PR management setups. Tom on our warehouse sources team built [Talyn](https://www.talyn.dev/) as a “mission control” for his PRs, our DevEx team built [speedy virtual machines](https://github.com/PostHog/posthog/tree/master/tools/hogbox-preview) to preview changes, and we’ve already written about Paul’s [code review setup](https://posthog.com/newsletter/code-review-tips?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all).\n\nSystems like these are necessary when engineers are seeing a dramatic increase in the amount of pull requests they need to review. At PostHog, we went from 1,441 PRs merged in January to 4,869 in August while only growing engineering headcount 10%.\n\n## 5. Improving the entire loop\n\nThis process doesn't just end. It loops repeatedly. What you build and ship leads to new observations like “are people using what we built?”\n\nThe loop isn’t just linear either. Stages feed back on each other:\n\n- The information you find valuable while **setting direction** informs how you**monitor the situation** : what information you pay more attention to and what you ignore.\n- How well a **decision** gets built informs the scope of**what you’ll decide for agents to build****next** . Seeing an agent flail and make mistakes leads you to reduce the scope of its future tasks.\n- The functionality and usage of **what you built** informs whether it was the**right direction** , giving you experience and updating your knowledge on agent capabilities, technical feasibility, and customer demand.\n\nIt’s not just one big loop, but many smaller loops as well. The consequence of this is engineers doing more work on the system that builds the product than the product itself. They build the [software factory](https://posthog.com/newsletter/software-factories?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all) rather than the software.\n\nThe growing capability of agents means there are cases where you can skip much of the loop too. Agents often only really need direction and the right tools to ship a valuable fix. With these, they can then figure out what to build, how to build it, and evaluate whether it actually worked. Here’s a real example from PostHog:\n\n- **Direction** is encoded into a prompt for a[Scout](https://posthog.com/blog/what-is-a-scout?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all) , a long-running agent that makes sense of all your data. In this case, we have one that aims to improve our[MCP server](https://posthog.com/docs/model-context-protocol?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all) , an important surface for our ICP of AI-pilled developers.\n- Based on **observations** from`mcp feedback submitted` events and`mcp_tool_call` error rates, the Scout finds agents want to define catalog events before they have been ingested and use an ugly workaround to do so. Related observations are grouped and become a report.\n- This report triggers an agent to **[write a fix](https://github.com/PostHog/posthog/pull/90832)** , which is**reviewed** by another agent before escalating for human review. It wasn’t auto-approved because the review found 2 “must fix” issues.\n- After the fix ships, another agent **evaluates** whether issues are actually solved. It does this by keeping notes in its scratchpad about what was reported, what shipped, and validates that the fix holds before considering a report closed.\n\nIn this case, the monitoring, deciding, and evaluation were all handled by the agent, the direction to improve the MCP server was implicitly guiding it, and our product improved without us needing to do anything. We call this making your product [self-driving](https://posthog.com/self-driving?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all).\n\nBut even this case is reliant on your skills and knowledge as an engineer. Writing code might be cheap, but your system for building a product isn’t. All your sources of information, your way of setting direction, your implementation knowledge, the way you evaluate what was built, and the connections between these stages becomes what makes you and your product unique.\n\nThis is all still engineering work. It just doesn’t look like it once did.\n\n*Words by [Ian Vanagas](https://x.com/ianvanagas), OODA loop respecter. Graphics by [Lottie](https://posthog.com/community/profiles/27881) and [Daniel](https://posthog.com/community/profiles/34810).* \n\n## 🧑💻 We’re hiring too\n\n- **[Backend Engineer – Ingestion (Europe/UK)](<https://posthog.com/careers/backend-engineer-ingestion-(europeuk-timezone)?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all>)**\n- **[Technical Staff Writer (Blogs & Newsletters)](<https://posthog.com/careers/technical-staff-writer-(blogs-and-newsletters)?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all>)**\n- **[Business Development Lead (Americas)](https://posthog.com/careers/business-development-lead-americas?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all)**\n- **[Technical Customer Success Manager (Americas)](https://posthog.com/careers/technical-customer-success-manager-americas?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all)**\n\n## 📖 More good reads\n\n- **[From 1 to 100 IRL events in a year: The secret to getting engineers to demo](https://posthog.com/blog/irl-events?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all) – Daniel Zaltsman**\n- **[Multimodal models need video. We froze time to give it to them](https://posthog.com/blog/multimodal-models-need-video?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all) – Tue Haulund**\n- **[How to turn your data into content with PostHog](https://posthog.com/blog/turning-data-into-content?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=ai-writes-all) – Natalia Amorim**\n- **[Boyd’s OODA Loop (It’s Not What You Think)](https://ooda.de/media/chet_richards_-_boyds_ooda_loop_its_not_what_you_think.pdf) – Chet Richards**\n- **[Why AI hasn’t replaced software engineers, and won’t](https://www.normaltech.ai/p/why-ai-hasnt-replaced-software-engineers) – [Arvind Narayanan](https://open.substack.com/users/19265788-arvind-narayanan?utm_source=mentions) and [Sayash Kapoor](https://open.substack.com/users/891603-sayash-kapoor?utm_source=mentions)**", "url": "https://wpnews.pro/news/if-ai-writes-all-the-code-whats-left-for-engineers", "canonical_source": "https://newsletter.posthog.com/p/if-ai-writes-all-the-code-whats-left", "published_at": "2026-09-14 18:08:17+00:00", "updated_at": "2026-09-14 21:36:20.393171+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "ai-products"], "entities": ["PostHog", "Anthropic"], "alternates": {"html": "https://wpnews.pro/news/if-ai-writes-all-the-code-whats-left-for-engineers", "markdown": "https://wpnews.pro/news/if-ai-writes-all-the-code-whats-left-for-engineers.md", "text": "https://wpnews.pro/news/if-ai-writes-all-the-code-whats-left-for-engineers.txt", "jsonld": "https://wpnews.pro/news/if-ai-writes-all-the-code-whats-left-for-engineers.jsonld"}}