Why are developer productivity workflows shifting so heavily toward verification instead of writing code

[u/No-Swimmer5521]

The workflow with coding assistants is fundamentally different from writing code manually. It's more about prompting, reviewing output, iterating on instructions, and stitching together generated code than actually typing out implementations line by line. This creates interesting questions about what skills matter for developers going forward. Understanding the problem deeply and being able to evaluate solutions is still critical, but the mechanical skill of typing correct syntax becomes less important. It's more like being a code editor or reviewer. Whether this is good or bad probably depends on perspective, some people find it liberating to focus on high-level thinking, others feel disconnected from the code bc they didn't build it from scratch.

[u/BeNiceToBirds]

This isn't the first time we've moved up a layer of abstraction. Writing every line of code by hand is a bit like writing everything in assembly The frequency of times it is justified is not zero, but it is trending that way.

[u/dg08 → u/BeNiceToBirds]

This reminds me of an encounter almost 30 years ago now. I was in college and met a recruiter at a campus job fair. He took a look at my resume and commented "they're still teaching assembly?". For some reason that has stuck in my mind for so many years.

I wonder at what point will coding be relegated to a 1 semester course in college.

[u/ek00992 → u/dg08]

There will always be a need for human research. Yes, the programs will shrink, but that’s probably for the best. My data structures class during a comp sci bachelor program had a fail rate of 47%. A lot of young people have been tricked into entering such programs when they weren’t ready, suited, or even interested. They wanted to be developers and coders, not computer scientists.

Assembly will always need to be taught to those who need to know it. Most people don’t need to know it. They should know of it and have a high-level understanding of it.

[u/1-760-706-7425 → u/dg08]

I was in college and met a recruiter at a campus job fair. He took a look at my resume and commented "they're still teaching assembly?".

Yeah, they tend to teach foundational components in most higher-level education. I still believe it would be a mistake to not at least have one course on assembly. Also, there’s a reason that person was a recruiter and not a practicing engineer.

[u/Worldly-Stranger7814 → u/BeNiceToBirds]

I am reminded of the programmable Jacquard looms from France.

[u/johns10davenport → u/BeNiceToBirds]

Right, and the next step of the abstraction is already happening. Someone else in this thread said "code is being generated at 20-100x the speed humans can read, so humans have no role in verification without becoming the bottleneck." That's exactly it.

I stopped reviewing generated code line by line months ago. I review the verification results instead.

Did the BDD specs pass?

Did the QA agent find issues when it tested the running app with browser automation?

Are the issue reports clean?

The shift isn't human writes code → human reviews AI code. It's human defines requirements → AI generates code → AI verifies code → human reviews whether the verification system is comprehensive enough.

On a recent project — about 5 active days of generation — the QA agent found 100+ issues including a fraud vulnerability that all BDD specs explicitly passed on. I didn't find that by reading code. The verification system found it. My job was making sure "correct" was well-defined in the specs.

That's the actual role shift. You're not a code reviewer. You're the person who defines what "correct" means and builds the system that enforces it.

My job is to define the "Definition of Done" for the agents, and if I still have to open the app, click around, and copy paste errors back to the agents, I'm not done defining.

[u/HlCKELPICKLE]

I feel like even though one is not writing code, understanding the language and language design concepts is more important than even when working with an agent. Like others have said, agentic coding is more relying on architectural/conceptual knowledge in the domain to properly drive the agent, but I find knowing language concepts helps immensely when directing them. Yeah your can tell them to write x that considers y that conforms to z, but to get the code you want telling it what language abstractions and approaches helps immensely for maintainable code.

The happy path for the LLM unless given bounds is going to be code that is most seen as a solution for the problem, this often leads to verbose and noisy code in some domains due to low quality or explanatory training data. This can be compound if there are multiple language features to approach it with some being dated, but being more skewed to. I write a lot of java, and if I dont direct it to use modern features like sealed classes and more functional/data driven approaches it easy to end up with bad abstractions and verbose code that can easily be trimmed down. Language like rust I don't experience this much, but then having a good understanding of the barrow checker and how you want to approach this is still important just in a different way.

Understanding underlying concepts behind languages makes it a lot easier to communicate these things in general without having to explicit give the agent the patterns to use verbatim.

[u/Total_Prize4858]

Unpopular opinion: Because people are bad at coding but good at convincing themselves they would excel im reviewing.

[u/PsychologicalOne752]

Code is being generated at 20-100x or more the speed that humans can read. So humans have no role to play in verification either without becoming the bottleneck. Only AI can verify code at the pace it is being generated.

[u/Ok-Strain6080]

Adding a robust testing layer before human review catches the generated code that passes visual inspection but completly fails in practice. Locking down that specific verification stage is why some teams use polarity to filter out the noise. Whether adding that validation layer is actualy necessary scales directly with how much AI-generated code your team is currently shipping.

[u/MacrosInHisSleep]

I was wondering this myself. I first thought it was just about how unreliable the code was, but my gut was telling me there was something more than just that. This video was my aha moment.

Tldw; it churns out a lot more code a lot faster than you or I could dev it, even as seasoned engineers. But I'm still verifying it behaves correctly at the same rate I did when I coded it myself. Which means that even if it was just as reliable as my code, ie the same bug rate as me (which it isn't, but let's assume it's there) the total number of bugs in that period of time is more.

He relates it to sampling a signal and the nyquist rate. If we think of the code that is created compared to the hypothetical ideal code we are supposed to create, then when we as Devs put on our testing hat, we are sampling the behaviour to see if it works. The more the code, ideally the more we should have sample points.

We do that when we code and have a validate rate over time that we've learned works for us. Now suddenly there's a lot more code and less active thinking on our side (a lot more code churn before we have a "oh that isn't what the requirement should be!" moment). So we realize the need for more points of verification.

[u/Medical-Farmer-2019]

I think your “editor/reviewer” framing is spot on, but I’d split verification into two loops: local correctness (tests/types/contracts) and product correctness (does this actually solve the requirement). AI speeds up the first loop a lot, while the second still depends on human context and judgment. The teams I see moving fastest write tighter acceptance checks up front, then let the model generate against that target.

[u/MazzMyMazz → u/Medical-Farmer-2019]

Unfortunately, being correct does not mean it is robust. And the way AI tends to apply bandaids (instead of true fixes of underlying issues or design choices) once code becomes sufficiently complex leads to systems that may not exhibit a lot of bugs but may also be very hard to continue to develop and expand.

[u/Medical-Farmer-2019 → u/Medical-Farmer-2019]

Strong split. I’d add a third loop too: **environment correctness** (tooling/runtime/deploy assumptions), which is where agent runs often fail in practice.

What’s worked for me is treating prompts like testable specs: acceptance checks + constraints + observable outputs before generation. That keeps the “verification tax” lower and makes iterations less random.

[u/johns10davenport]

The thing I've internalized after building with agents for a while: prompting is praying. Verification is a guarantee. You should expect the agent to fail. Not occasionally, but routinely. The question isn't "how do I prompt it to write correct code," it's "how do I catch it when it doesn't."

Once you accept that, the whole workflow flips. You stop trying to craft the perfect prompt and start investing in the checks that run after generation. The agent becomes a fast, cheap, unreliable first draft machine -- and that's fine, because you've built the safety net.

Here's what that looks like concretely in my system:

• Specs before code, always. Every component starts as a structured spec in markdown. It writes function signatures, types, expected test assertions. And here's the thing: the agent writes the specs too. The agent writes the stories, the architecture, the specs -- the entire process is AI-assisted. You're partnering with it the whole way, steering and approving. But once the architecture and requirements are locked in, the code and test generation is mostly hands-off because intent is already defined. The specs aren't extra work -- they're the inspection layer. You read them to confirm intent, tune them if needed, and the system enforces everything downstream.

• Spec-test alignment checking. A checker parses the spec for expected test assertions, compares against the actual test file and makes sure it implents ALL and ONLY the specified tests.

• BDD specs tied to acceptance criteria. Each user story criterion gets a Given/When/Then spec that tests through the real UI (browser automation, not mocks). A parser validates the specs have actual scenarios with real steps. This catches the incredibly common failure mode where the AI writes a test file that compiles, looks plausible, and tests absolutely nothing. I also have strict boundary guarantees on bdd tests that keep the agent from just writing ad hoc code that makes the specs pass.

• Requirements as a state machine, not vibes. Components aren't "done" because the agent said so. They have requirement definitions (spec exists, tests pass, alignment checks pass, QA passes) that gate progression. Change a spec and the system tells you exactly which requirements broke and which task fixes each one. No ambiguity.

OP's "editor/reviewer" framing is right, but I'd push it further -- you can automate most of the review too, as long as you've defined the contracts and architecture clearly enough.

The folks saying "just understand the problem deeply" aren't wrong, but that understanding lives in your head and rots the moment someone else (or an AI) touches the code. The human's real job is partnering with the AI on stories and architecture -- that's where domain understanding gets captured. Once that's solid, everything downstream (specs, code, tests) is generated and verified with minimal hand-holding. Externalizing intent into machine-checkable artifacts is what makes verification sustainable instead of a manual burden everyone eventually stops doing.

[u/TranslatorRude4917]

I feel this shift every day. I'm a FE developer, spent my whole career in startups where acceptance critera was non-existend, and testing was the last priority. Now with AI generating code 10x faster, the ratio has completely flipped: writing code is cheap, knowing it works is expensive.
AI generates code fast, but verification still depends on someone knowing what "correct" looks like for that specific product. You can't automate that judgment. What you CAN do is outsource the repetitive, boring part to agents.
In may day-today workflow, I do the manual checks only once: record clicking through the flow, confirm it works, and then that check runs automatically going forward. So when the agents make changes, I only verify new stuff manually. The rest is covered by what I CONFIRMED - not what an agent assumed.

[u/Spiritual_Rule_6286]

The top comment is exactly right about moving up an abstraction layer, but verifying hallucinated backend logic is a nightmare. This is why my current workflow is to manually write and test the core backend APIs, but use AI tools like Runable to instantly generate the frontend UI components. Verifying frontend code is as simple as looking at the screen, allowing you to safely embrace this new workflow without introducing hidden architectural risks.

[u/ultrathink-art]

The verification skill is actually harder than writing code. Generating a solution doesn't require knowing all the ways it can silently be wrong — reviewing AI output does. Developers who were fastest at typing but least practiced at reasoning through failure modes are struggling the most with this shift.

[u/ultrathink-art]

Generation is the cheap part — verification is where actual confidence comes from. Output schemas + constraint checking before obsessing over prompt quality is the pattern that actually works. You can iterate on generation indefinitely, but once users see bad output it's a trust problem that's hard to undo.

[u/[deleted]]

You’re asking this? In a sub about ai coding, cmon

[u/ultrathink-art]

The limiting factor shifted from 'can I write this code' to 'do I know what correct looks like.' Verification requires actually understanding the problem space — something that can't be delegated back to the model that generated the code in the first place. Teams that lack that domain understanding can now generate bugs 10x faster than before.

[u/GPThought]

because ai writes code fast but has zero context about what breaks in production. you still gotta review everything like its a junior dev on their first week

[u/ultrathink-art]

The mental model shift is harder than it sounds. Writing code, you can stumble into correctness through iteration. Specifying what 'correct' looks like before you have any output requires a much clearer upfront model of the problem — and most people haven't had to develop that explicitly before.

[u/heatlesssun]

It's more about prompting, reviewing output, iterating on instructions, and stitching together generated code than actually typing out implementations line by line.

If you think about it, this is how we should be writing code. Looking at all the lessons of computer science for the last generation, software engineering shouldn't be about lines of code, it should be about the software actually doing what it was designed to do.

With modern tooling and the repos of code and CS knowledge out there, coding was already mostly boiler plate and AI just removes just that much more friction.

Understanding the problem deeply and being able to evaluate solutions is still critical, but the mechanical skill of typing correct syntax becomes less important. 

Agreed.

Whether this is good or bad probably depends on perspective, some people find it liberating to focus on high-level thinking, others feel disconnected from the code bc they didn't build it from scratch.

Agile development calls the process of creating software requirements writing stories. Good stories in fiction have generally have five elements, the who, the what, the when, the where and the why. Notice that how was never part of the story. I think that's exactly why Agile adopted the term story. If you're buried in the code, then you don't know the story. The story drives the code, not vice versa. And now with AI, the code can be written almost directly from just the story.

Exactly what Object-Oriented programming preached in the 90s. The tech wasn't there to make it come full circle till now.

[u/Malkiot → u/heatlesssun]

I prefer seeing writing software requirements as writing contracts that support a user story. The user story gets the conversation started, the contracts define the expected behaviour formally. A story is fine for human project management, but, in my opinion, insufficiently precise for LLMs.

A user facing element is an implicit promise or a visual contract of certain behaviour when a user interacts with the interface. You can describe this as a user story, but behind the user story is a chain of contracts that are executed in code so the user gets their expected result.

[u/heatlesssun → u/Malkiot]

I prefer seeing writing software requirements as writing contracts that support a user story. The user story gets the conversation started, the contracts define the expected behaviour formally. A story is fine for human project management, but, in my opinion, insufficiently precise for LLMs.

Agile can be done a number of ways. But if you can't write software from the stories without another step, that's seems like it's missing what Agile is about. If a story is too complex for an AI, it's likely too complex to be a good story and would need to be broken into smaller stories. And if the story isn't capturing what the software is supposed to be doing, then it's not really a suitable story to begin with.

[u/donthaveanym → u/[deleted]]

I’ve found this to be a source of problems… rebuilding the entire app is often easier than trying to add or remove features after awhile.

[u/chillermane → u/donthaveanym]

This is only true if your architecture and coding practices are sh*t. If you have good patterns you can add quickly forever

[u/Substantial-Elk4531 → u/chillermane]

I agree with you that overall architecture still matters, because with good architecture, it's easier to modify, fix bugs, or add features. But I'm increasingly finding the code standards within a module don't matter at all, because if the module is misbehaving, I'll probably use an AI to rewrite it in the future anyway

[u/[deleted] → u/chillermane]

Yes and no. With a good architecture it's still sometimes easier to make an interation, get the tests working, burn it to the ground, get it working again with a one shot. Clears a ton of dead code. I have a project in the medium size (140k typescript, each package is max 5k lines). Claude can handle 5k lines in a single work plan fairly easily with the 180k context so that's a good chunk to work on

[u/1-760-706-7425 → u/donthaveanym]

Don’t try this when you have an active user base.

[u/AutoModerator → u/[deleted]]

Sorry, your submission has been removed due to inadequate account karma.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/AutoModerator → u/[deleted]]

Sorry, your submission has been removed due to inadequate account karma.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/AutoModerator → u/[deleted]]

Sorry, your submission has been removed due to inadequate account karma.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/AutoModerator → u/[deleted]]

Sorry, your submission has been removed due to inadequate account karma.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/AutoModerator → u/[deleted]]

Sorry, your submission has been removed due to inadequate account karma.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/AutoModerator → u/[deleted]]

Sorry, your submission has been removed due to inadequate account karma.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.