AI in Software Development: Teams Hit 90% AI-Generated Code as New Challenges Surface

When Writing Code Is No Longer the Issue, What Is?

AI has fundamentally changed software development, and this is how it happened: gradually, then suddenly. Over the past few years, engineers have been experimenting with AI code, but the latest progress has enabled us to do things we never thought possible before. The recent model upgrades, combined with agentic abilities, now allow developers to produce not just dramatically more code, but dramatically more complex code. In the span of a quarter, my own team went from skeptical experimentation to 90 percent of our code being AI-written. But this isn't a productivity triumph story. Because when code production becomes fully automated, you get a new set of problems to think about. Here are some challenges the development community is dealing with right now. Accept that the job has changed This shift first requires a mindset change. Engineers need to accept that what they built their careers around has transformed at its core. The developers adapting fastest today were never particularly attached to coding itself. They've always been more interested in systems, architecture, and development practices. For them, AI removed the tedious part. But some are more focused on the craft of writing code. They've honed their skills, specialized in a language, and even developed a personal style. When AI absorbs that layer, it's disorienting in a way that goes beyond skill obsolescence. It's disruptive to their entire professional identity. Team leaders will need to manage both types and those in between. So alongside technical challenges, we're all dealing with change management issues. If we don't name them, discuss them, and actively work through them, no one moves forward. Velocity without governance = slop When you can produce in half a day what used to take five, it's easy to get carried away by the magic of it. But AI-generated code can be deceiving. It looks correct on first read, but it isn't always right, and it's often undertested. Without a proper system in place, teams start to accumulate slop -- technically functional code that's bound to surface problems in production, often in ways that are hard to trace back. That's why our prime focus right now is building a validation system. When slowing down isn't an option, you need a structure that lets you move quickly, without the code degrading beneath you. The acceleration outpaced our infrastructure, and now we're building the net while we're falling. Review is the new bottleneck Solve the slop problem, and you immediately surface the next one: human review. In a single week, I personally reviewed 68 pull requests -- proposals for code changes that need senior team member approval before merging the code. Because of the sheer volume of new code, reviewers are now receiving two or three times more requests than before AI was used for coding. The reviewers also need to perform their reviews with less context, because they weren't in the room when the code was generated. While this code can look fine on a quick pass, it requires engagement to evaluate properly. The fix is building more automated validation earlier in the pipeline to catch problems before they reach a human, so the human reviews are meaningful rather than overwhelming. The validation loop is the real skill now Here's the difference between teams getting genuinely good output from AI and teams getting mediocre outputs: the validation loop. You need to give the agent criteria for success and failure. Let it run the tests, read what broke, and iterate before it hands anything back to you. This is what Claude Code made concrete for us, by moving the experience into the terminal, where the agent can execute code, read CI/CD results, and course-correct on its own. That's how you close the loop. Teams treating AI as a prompt-and-receive tool are capturing maybe a third of the available value. The ones who've figured out how to let the agent self-validate are operating at a different level entirely. Nobody has a clean playbook for building these systems yet. AI drains you faster than you think AI-enhanced work compresses the decision density of your day. You're making high-level architectural calls constantly, at a pace that traditional coding doesn't demand. By mid-afternoon, you're cognitively depleted and it's hard to explain that to someone who hasn't experienced it, because on paper, you've been "productive." But your brain has been running hot in a way it's not designed to sustain itself for eight hours. Some have started calling this the "AI vampire effect." The tool gives you enormous capacity, but drains you in parallel. The partial fix, again, is the validation loop. With that in place, there's less cognitive load on the human and more delegated to the system. But it also requires honest management. The sustainable working pace in this new context is different than before. Pretending otherwise is a good way to burn out your best engineers. When does the next version of software development launch? The acceleration in the AI space happened faster than our systems, processes, and instincts could keep up with. It's now easier to produce code, but that's precisely why it's important that we rethink everything surrounding the production process. For now, no one has a clear model for how this should look. What exists are teams like ours, feeling their way through it, building validation systems in real time, managing engineers through an identity shift nobody trained us for, and occasionally reviewing 68 pull requests in a week while wondering if this is sustainable. It is, but only if we take the matter as seriously as the code itself. The engineering problems we can solve eventually. The harder question is whether we'll build the right habits, systems, and culture around AI fast enough to keep up with what AI keeps unlocking.

A.I. Is Redefining What a Computer Science Education Is For

The debate over whether A.I. will replace programmers misses the bigger shift: how we train engineers to think, and how the next generation will earn the judgment to direct work that it no longer does by hand. For more than a decade, the standard advice to anyone worried about their career was simple: learn to code. Programming was treated as the closest thing to a guaranteed job in the modern economy. But as A.I. has become more capable of writing code, many are beginning to wonder whether programming itself is becoming a dead-end skill. Sign Up For Our Daily Newsletter Sign Up Thank you for signing up! By clicking submit, you agree to our <a href="http://observermedia.com/terms">terms of service</a> and acknowledge we may use your information to send you emails, product samples, and promotions on this website and other properties. You can opt out anytime. See all of our newsletters Experienced engineers are still in high demand. Meta reportedly paid some software engineers base salaries as high as $450,000 last year, while recruiters scour GitHub and fly across the world to land a single experienced hire. But that premium is reserved for engineers who have spent years developing technical experience and judgment. For computer science students watching A.I. generate in seconds the code that once justified an entry-level role, a natural question follows: What exactly is my degree preparing me for? They're already acting on that anxiety. Enrollment at some of the most prominent computer science programs is slipping. I've spent more than 20 years building software, including as a principal engineer on Google Docs, and I think the panic has the problem backward. A computer science education was never really about writing code; it was always about learning how to solve problems, reason about complex systems and understand how computers work. A.I. automating more of the implementation clarifies what the education was for all along. The shift is further along than most people outside the field realize. Ask working developers how much code they still write by hand, and the honest answer, for many, is very little. The A.I. tools most engineers use now draft, test and revise code faster than a person can type it. That change took about two years, and it happened quietly. So the question worth asking is: what should we teach people once A.I. handles the programming itself? Consider why we still teach long division. Almost no one does long division by hand as an adult, because we carry calculators in our pockets. We teach it because working through the procedure teaches you how numbers behave. The same logic applies to computer science. Understanding algorithms, data structures, databases and how a machine executes an instruction is still foundational education, even as the day-to-day work becomes less vocational. Knowing how the system works is what lets you recognize when it's wrong. Other fields are already reorganizing training around that reality. KPMG, for example, expects that the routine audit testing that once trained its junior auditors will become largely automated over the next few years. Instead of emphasizing technical drills, it now trains incoming hires to evaluate machine-generated output and exercise judgment about when it can, and cannot, be trusted. Computer science education is likely to evolve in the same direction. Alongside traditional software engineering, the strongest programs will teach students how to design and supervise systems of A.I. agents. This looks less like classical programming and more like systems design and process engineering. Instead of implementing every function themselves, students design workflows in which specialized agents triage problems, draft solutions, test changes, evaluate outputs and escalate uncertain cases to humans. You decide which decisions are safe to automate, which require human judgment, how success is measured, what the system costs and where failures are likely. Whether universities call this agent engineering, A.I. systems engineering, or something else, the best programs will increasingly teach students to design and supervise these systems alongside traditional software engineering. One caveat is that this field reinvents itself about every six months, and no university curriculum moves that fast. That's another argument for teaching durable fundamentals and how to learn the tooling, rather than any particular tool. The specific agent frameworks a student picks up freshman year will be gone by graduation, but the understanding of how the systems work underneath won't be. Here is the part I don't have a clean answer for, and neither does anyone else in the industry. You can outsource the software development to an agent, but you cannot outsource the understanding. The engineers who use these tools best tend to be the ones with years of experience writing and reviewing code the hard way. They can look at what an agent produced and know quickly whether it's right, because they built the judgment to see it. Reviewing an agent's work isn't far from reviewing a junior engineer's work, which is what many senior people did for years. That points to a problem the whole industry has to solve. For decades, the path from junior developer to technical leader was an apprenticeship. You wrote features, introduced bugs, fixed production incidents, reviewed pull requests and gradually accumulated the judgment that later let you guide teams and make architectural decisions. A.I. is now performing much of the hands-on work that juniors once learned from, but the apprenticeship doesn't have to disappear with it; it just looks a bit different. The next version is an apprenticeship in supervision: a junior working alongside an expert to review A.I.-generated code and run agentic systems, building judgment by doing so under guidance. But that supervision only builds real judgment when combined with firsthand experience, meaning the training also has to become more deliberate than it used to be. Schools should keep making students do the fundamentals by hand. The industry may need fewer people writing production code by hand, but there is still no substitute for learning the fundamentals directly. Understanding how software is built remains the foundation for understanding when A.I. gets it wrong. Pair that with the agents track so students learn to design, evaluate and supervise increasingly autonomous software systems. The same shift applies inside companies. Organizations that continue to treat early-career engineers as low-cost production capacity risk undermining the very apprenticeship that develops future technical leaders. Give workers ownership of real outcomes, and measure their work by whether it helped a user and what it cost in both agent and human time, not by how much code they shipped. That's a different mindset than engineering has run on, and it takes more mentorship than letting the tools run. But it's likely how you end up with people who can direct these systems in a decade rather than just operate them. The best engineers I know already work a level up: on architecture, on product decisions and on the systems that decide what gets built and why. One enduring limit of these tools is that they hold only a narrow slice of context at a time, while a good engineer carries the whole system in their head. That vantage point is what lets them catch what an agent misses. A.I. raises the value of that work rather than replacing it, but it still rests on a deep understanding of how computing systems function. If we stop teaching that understanding, we'll eventually run out of engineers who can recognize when the machines are wrong. That's what a computer science education is for.

Engineering as a Service Is What Happens When You Let Vibe C

Join the DZone community and get the full member experience. Join For Free Vibe coding is not a programming technique. It's an organizational event dressed up as one. When GitHub Copilot launched in 2021, the narrative was "AI as pair programmer." When ChatGPT arrived, it shifted to "AI as junior developer." By the time Cursor and Windsurf and Devin entered the picture, the goalposts had moved so far that we stopped noticing where they used to be. The term itself -- coined by Andrej Karpathy in early 2025 -- describes writing software by describing what you want and iterating on AI output until it looks right. No architecture upfront. No deep understanding of the internals. Just prompt, review, adjust, ship. The name is almost deliberately casual. Vibe. As if the whole thing is low-stakes. It is not low-stakes. Not even close. What's actually happening is that the cost of producing a working prototype has collapsed to near zero. A product manager, a designer, a technically literate founder, or a business analyst with a ChatGPT subscription can now produce something that looks -- and often behaves -- like what an engineering team would have spent two sprints building. The artifact exists. It runs. It answers to a curl command. And that is exactly what makes the next part so uncomfortable. What "Engineering as a Service" Actually Means on the Ground The phrase Engineering as a Service -- EaaS -- has been floating around enterprise architecture circles for a few years. It originally described platform teams offering standardized, self-service infrastructure to internal product teams. Sensible concept. Reasonable organizational model. That is not what I mean when I use the term now. What I'm watching happen -- across teams I've worked with, consulted for, and frankly in my own org -- is a quieter version: engineers becoming a validation and production-hardening layer that sits after the AI has already done the creative work. The product manager vibe-codes a proof of concept. The engineering team is handed it and asked to "make it production ready." Requirements arrive pre-defined. The architecture decision has already been made, implicitly, by whatever structure the AI generated. The engineer's job, in this model, is to clean up after the vibes. "The most dangerous moment isn't when AI writes bad code. It's when the organization stops asking engineers to think before the code exists." That shift is subtle. Gradual. And it doesn't announce itself in a restructuring memo. It shows up in how sprint planning conversations change. In the questions that stop being asked. In the job descriptions that quietly remove "system design" and add "AI code review." In the fact that your most technically sophisticated colleagues are increasingly valued for their ability to spot what the model got wrong -- not for their ability to envision what should be built in the first place. It's hollowing. And the hollow feels comfortable for a surprisingly long time. The 80% Problem Nobody Is Talking About Honestly The statistic getting passed around is that AI can write 80% of the code. Maybe 90%. Some teams will tell you it's higher. They're probably right, for a certain definition of "code." What nobody says in the same breath is what that 20% contains. It contains the decision to use a distributed lock instead of an optimistic concurrency strategy, because you know your write contention pattern at 3 AM on the first of the month. It contains the choice to put that third-party API call behind a circuit breaker, because you were the one paged at midnight when their service went down for six hours two years ago. It contains the knowledge that your payment processor has a 30-second timeout that doesn't appear anywhere in their documentation, and that the retry logic the AI generated will double-charge customers under exactly the conditions that will occur in production. That 20% is not filler. It's the residue of lived system knowledge. And it cannot be prompted for, because it lives in people, not in documentation. The Skill Inversion Nobody Budgeted For Here's the part that makes people genuinely uncomfortable when you say it in a room: the engineers who are worst positioned for this transition are often the best coders. Think about it. If you built your professional identity around the craft of writing clean, efficient, elegant code -- if that's the thing you're proud of, the thing you've spent ten years sharpening -- you are now in a profession where that particular skill is the one being automated away fastest. The engineers who wrote beautiful Ruby. The ones who could implement a red-black tree from memory. The ones whose pull request diffs were a pleasure to read. Those skills are not worthless. But they are no longer the differentiator. The differentiator is now something harder to teach, harder to credential, and much harder to interview for: the ability to look at an AI-generated system and know -- without running it -- which assumptions it made, which failure modes it ignored, and which organizational constraints it has no way of knowing about. That requires something I'd describe as systems intuition. It's not algorithmic. It's not certifiable. It's the thing you develop after you've been on-call for two years, after you've traced a cascade failure through six services at 2 AM, after you've had to explain to a CFO why a "working" deployment is losing the company $4,000 an hour. You can't vibe-code your way to it. What Gets Built When Engineering Is a Service Let's say the EaaS model wins. Let's say your organization fully embraces the idea that non-engineers will prototype, AI will build, and engineers will review and harden. What does the resulting software actually look like? I know, because I've seen early versions of it. Across four teams that went deep on vibe-coding workflows in 2025, there are common artifacts starting to emerge. The code is structurally fine. Readable, even. Comments are excellent -- AI comments well. Test coverage looks good on paper. But the systems have a specific flavor of wrongness that takes a while to name. They're built for the happy path with unusual thoroughness. And they fail in ways that are not in any test suite, because the failure modes weren't imagined in the prompts that generated the code. One team I spoke with -- a Series B SaaS company, roughly 40 engineers -- went vibe-coding-first on a new data pipeline in late 2024. Shipping velocity tripled. Incident rate was flat for two months. Then they hit Black Friday. The pipeline had no backpressure mechanism. The AI had generated clean, efficient queue processing code that assumed queue depth was bounded. Under real peak load, it consumed memory until the service OOMed, cascading into three downstream consumers. Recovery took nine hours. The postmortem finding: no one had asked the AI "what happens when the queue grows faster than we can consume it?" Because the PM who wrote the initial prompt didn't know to ask. And the engineers who reviewed the output were reviewing it for correctness, not for production failure modes they hadn't witnessed yet. So Who Actually Survives This? If the question is "what does the engineering career look like in a world where AI generates 80% of the code," the answer isn't just "learn to prompt better." That framing is too small. It optimizes for the wrong thing. The survivors are the engineers who never let their professional identity live entirely in the code. They're the ones who were always curious about why a system needed to exist, not just how to build it. The ones who sat in product strategy meetings when they didn't have to. The ones who wrote design docs before anyone asked and kept them updated after nobody read them. They're also the engineers who carry operational scar tissue. Production incidents are an education that no prompt can replicate. Every major outage you've lived through deposits something into your mental model of systems -- a new category of "things that go wrong under conditions that weren't in the spec." That library of failure is, right now, one of the most underappreciated professional assets in engineering. The survivors will be engineers who can sit across from an AI-generated system and run it through a mental gauntlet: what happens when the third-party API goes down? What happens when this queue backs up for six hours? What happens when someone sends a payload that's technically valid but semantically adversarial? What happens when this runs in the EU and GDPR applies to this field? Not because they're pessimistic -- but because they've seen all of those things happen. The Uncomfortable Truth About Fighting Back I want to be careful here, because the easy response to all of this is: good engineers will always be needed. And that's technically true in the same way that good writers are always needed in the age of generative text. It doesn't tell you much about the market. It doesn't tell you which specific kind of good engineering will be compensated. The uncomfortable advice, the kind I give to engineers who ask me directly: stop being the person who writes the most code, and start being the person who knows the most about what the code needs to survive in the real world. Those are different identities. They require different habits. And the transition is not comfortable, especially if you built your self-image around your coding ability. The engineers who will own the next decade are the ones who can walk into a room where an AI has already generated a candidate architecture and say -- clearly, specifically, with evidence -- why that architecture will fail, what it will cost, and what needs to change before anyone touches a production database. Not because they can write better code than the AI. But because they've seen this movie before, in a dozen variations, and they know how it ends. That's not a skill you can automate. Not yet. Maybe not ever.

Thoughts on Developing With A(ccelerated) I(nference)

Join the DZone community and get the full member experience. Join For Free AI stands for artificial intelligence, yet I prefer the term Dr. Venkat Subramaniam used in one of his talks: Accelerated Inference. To my mind, it is far more accurate, so I have embraced it. And "accelerated" is precisely the point. With AI, generating code has become cheap; it is no longer the bottleneck of software development. What has become expensive, and what this article is really about, is everything around it: aligning outcomes with intent, owning what we ship, and exercising the judgment that no amount of acceleration can replace. A Brief History The main structures underlying modern AI are neural networks and transformers -- statistical models capable of replicating patterns. The former have been around for much longer than many people today assume; the latter are comparatively new. The field's milestones trace a recurring cycle of bold ideas, disillusionment, and breakthroughs driven by new algorithms, more data, and faster hardware: from the first mathematical model of an artificial neuron (1943) and the perceptron (1958), through the first "AI winter" (1969) and the backpropagation revival (1986), to AlexNet's deep learning breakthrough (2012) and the Transformer architecture (2017) that underpins all modern large language models. In other words, AI as a concept is not new at all. What is new is that today almost everyone, technical or not, has an opinion about AI and how it is changing the way we work. On one hand, this is perfectly normal: the world isn't what it used to be, the available tools are different and more powerful, and certain problems can now be solved much faster. On the other hand, in this new and fashionable landscape, people should strive to form objective opinions first, filter them through their own judgment, and only then express and apply what proves useful. From individual to individual, hasn't this always been the case with everything else? Habits Worth Keeping (and Acquiring) When it comes to people, the recommendations on how to act when 'newness' emerges haven't changed from what we've been used to. Certain responsibilities and habits should be kept, others adapted and continually improved, while new ones acquired. Regarding software engineers, I feel slightly more entitled to an opinion; thus, here are a few pieces of advice I have compiled and consider worth having close. * Before writing code, strive to turn incomplete and ambiguous requirements into a comprehensible starting point -- understand not just how to build something, but why and who it serves. * Before writing code, know when to use a certain algorithm or design, why it matters, and how it fits into the large application you are building. * Before merging in your code, have it reviewed first by yourself, then by at least one human programmer. * Get used to a shift in thinking. Engineers are used to predictable results; LLMs produce variable output. A switch from deterministic to probabilistic thinking may be needed. * Before merging AI-generated code, review every line in detail and thoroughly understand why each decision was made - transform the changes into fully owned ones, as if you had written them yourself. (sounds familiar, doesn't it?) * Before merging AI-generated code, make sure it meets the project's coding standards and remains human-readable, and improve it where possible. * Sharpen your code-reading and reviewing skills. They were always a plus; now that AI agents are programming buddies producing large volumes of output, they are essential. * Avoid "prompt-and-pray vibe coding." Use AI thoughtfully, maintain rigorous standards, and don't short-circuit your own learning. * Use AI as a force multiplier to amplify your existing skills -- knowledge, experience, problem-solving as a professional, and above all, objective, constructive judgment as a human being. * Validate both directions. Check not only what AI agents produce as output, but also what they consume as "trusted" input. * Co-build abstractions. Use LLMs to help build an abstraction, then use that abstraction to communicate with the LLM more effectively and solve problems in a more deterministic manner. * Keep delivering reliable, maintainable software, but pay closer attention to how you spend your time building it. Some of these points are about AI; some are not. Some have been acknowledged for ages; others emerged recently and will be assimilated sooner or later. From Writing Code to Solving Problems One thing is certain: with AI, the software development approach and mindset are fundamentally different. In this shift, I believe software engineers have a great opportunity -- to move their attention even further from writing code to solving problems, and to spend their energy on more meaningful challenges. Oleg Koverznev puts the thesis I opened with even more sharply: "... code generation is cheap and no longer a bottleneck; the real challenge is aligning outcomes with intent, along with managing the growing operational and economic complexity of agent-driven work." AI's instant output tends to fuel our impatient expectations for immediate results. It can make us feel productive and efficient, but let's hold on for a moment, resist the rush, and ask whether the outcome has real value, whether it actually produces impact. Going deeper, there is an idea I find helpful in sustaining this point of view. Luciano Floridi -- a leading figure in the philosophy of information and digital ethics, widely influential in AI ethics - has a thesis (sometimes referred to as Floridi's Conjecture) that can be summarized as follows: As the complexity of a system increases, the ethical significance of its interactions also increases, while the ability to fully predict or control its behavior decreases. In this view, advanced information technologies are re-ontologizing our world, reshaping the very fabric of reality and our place within it, rather than simply serving as tools within an unchanged reality. Applied to AI, the conjecture suggests that a fully autonomous system cannot have great scope and great certainty at the same time; AI agents will therefore always require human oversight. Yet more and more, out of convenience, people tend toward fully embracing agent autonomy, when it would be wiser to remain in the loop: tempered and watchful. Language, Thought, and Staying Sane Science in general and AI in this particular context is not a magic trick, but a special way of using human intelligence. We embrace science and AI not when we put on a white coat, but when we start practicing a set of canons of thought, many of which have to do with the use of natural language, which is, after all, the main medium of AI-human interaction. New technologies change what we understand by "knowledge" and "truth." They alter the deeply rooted habits of thought that give us a sense of the world, of the natural order of things, of what is reasonable, necessary, inevitable, or real. The actual magnitude of the effect varies from person to person. But as Neil Postman observed, a new technology doesn't merely add or subtract something -- it changes everything. It redefines the words by which we guide our lives: freedom, truth, intelligence, reality, wisdom, memory, history. And it never stops to warn us, and we never stop to ask. We keep rushing. Conclusion In these days when AI seems to be the solution for almost everything, I consider it very important to keep improving our reading, writing, and technical skills, our natural language, and our critical thinking, and to apply them wisely. To be respectful to ourselves and to others. To value truth more than mere correctness and, why not, to become good bullshit detectors as well. In a world where consumerism is amplified as never before, where objects are overvalued and abundant, and where speed is prized over competence and quality, remaining sane is a real virtue. Improving our human virtues is a continuous and tedious process, but a rewarding, fundamental, and safe one in the long run. Let's not change the world, let's change ourselves.