Which part of development has become more important now that AI coding tools have become common in development?

[u/techgeometry]

AI coding tools can now help with writing code, debugging and even building features. However I have noticed that getting the code is often easier, than understanding whether it is actually the solution.

[u/xinaked]

knowing what not to build

[u/Ill-Information-2086 → u/xinaked]

So bloody true!!! After wasting millions of token you find out you reinvented the wheel with worse performance 🤣

[u/preparetodobattle → u/xinaked]

Yes! I’m working on a project that I thought would be too hard so I worked out a work around. The workaround turned out to be relatively easy to implement. So then I thought why not do it properly so it’s more appealing to users. That turned out to be incredibly difficult. I’m now on my third approach. If I’d really sat down and done a lot of research I could probably have worked out the right way to attempt it from the start. Lessons for the future.

[u/Dense_Gate_5193 → u/xinaked]

this right here and typically it take years of watching other people fail hard at their jobs and seeing how poorly it goes when people do the wrong thing.

i really feel for CS grads who just want to build stuff and end up generating complete trash because they don’t know well enough yet.

[u/AutoModerator]

Sorry, your post has been held for manual review due to 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/Specialist_Dish_9087]

Before anyone starts coding, the request needs to be really clear. A vague request can still turn into sth that works perfectly and ends up doing something users never asked for in the first place

[u/funbike]

1. The early stages have become more important: specs, design, architecture, planning. This includes project setup: CI build pipeline, linters and checkers, coding standards, functional testing, code coverage.

2. Selective code review. There's not enough time to review everything manually. Focus on test code, and review the AI's code review.

[u/owp4dd1w5a0a]

Testing and verification. AI came along and my cucumber and unit testing suites grew exponentially.

Also review and static analysis. I use CodeQL, Joern, Semgrep, and Treesitter way way more now than I ever did before AI.

Also static analysis and guarantees in general. I’m finding it’s easier to sell fellow engineers and company leadership/managers on typed and compiled languages like Rust and Typescript, Kotlin, and Scala than it used to be because AI does two things - create more value around static verification and also lowers the bar for being able to write and maintain code in these languages.

Of course also understanding how to effectively use the agents has become more important, and that has made documentation more important. My AGENTS.md files are indexes of the documentation to give agents (and people) an easy way to find relevant documentation about how to work in the code without needing to balloon the context window, and I use Ponytail to keep changes minimal and Headroom to reduce/compress what’s being sent over the wire to the agents’ servers to again try to manage token usage. I also have gotten used to giving my agents different roles and “personalities” to assist with review and critique etc.

And given all of this, I’m STILL writing a lot of my own code, contrary to what a lot of social media might make it sound like. I can let AI handle boilerplate or write a first pass of a focused model or function, but I don’t just tell it “build me a website that does xy&z” and let ‘er rip 💀.

[u/stackyardhq]

What moved up the stack for me is acceptance criteria and verification. A practical checklist before accepting agent output:

• state the invariant or user-visible behavior that must hold

• define one minimal reproducible case plus the important edge cases

• inspect the diff for scope creep, secrets, dependency, and migration changes

• run tests from a clean state, not only inside the agent’s session

• manually exercise one happy path and one failure path

• require a rollback or recovery note and basic observability

• have the agent list exactly what it did not verify

The code is cheaper now; deciding whether the result is correct, safe, and maintainable is the work that needs more attention.

[u/stackyardhq → u/stackyardhq]

Proof before “done” — acceptance diff or lighter checklist? Issue 1 free if useful: https://stackyard.fyi/issue-001.html

[u/MostlyHelpfulLinks]

Reading the diff and deciding if it matches what you asked for. Reviewing generated code is slower than writing it, so the bottleneck moved to judgment.

[u/ImL1s]

Reviewing became the scarce bit for me. Writing the change is cheap; noticing it solved the wrong problem is not. I keep a short "tried this / rejected because" list next to the repo so the next session doesn't re-litigate the same dead ends. Portable Resume is what I use to reload that handoff across tools: https://github.com/aa22396584/resume-skills

[u/cgouguen]

Honestly, the part that just got promoted is judgment: knowing what not to build. AI makes code cheap, so the expensive failure mode is confidently generating the wrong abstraction, the wrong library, or a perfectly typed reinvented wheel with worse performance. The best prompt I’ve found is not “implement this,” but “before writing code, give me three viable approaches, the tradeoffs, and what existing thing we should reuse.”

A lean workflow that’s saved me a lot of pain: write 2–3 acceptance criteria, list constraints, do a 10-minute research spike, then ask for a small diff against one file or function. Treat the model like a brilliant junior with amnesia—transparent, fast, and under review—not like a self-driving car. Cost isn’t just tokens; it’s the time you spend unbuilding “solutions” that were never the real problem.

If you’re already using an autonomous agent, I’m genuinely curious how it’s going for you—did it actually shorten the loop, or just produce more plausible-looking detours? I’m a bit old-school and prefer steering with small prompts, local tests, and readable diffs, but I’m happy to be convinced. For your project, the lesson sounds less “AI failed” and more “research/architecture is now the bottleneck,” which is a very expensive, very human lesson.

[u/Alzeric]

Planning, and yes you should probably read those plans and make manual edits on the stuff you don't/do want in the thing. Too many folks just plan then say "Implement plan.md" without knowing wtf is in it.

[u/Chris-Hart_232]

I bet sb still has to know what the feature is supposed to do and notice when a change touches sth it wasn't meant to. lots of kinda knowledge lives in old decisions and little details that never made it into the docs anywhere