AI can now write code, generate tests, document apps, and speed up repetitive tasks. The surface-level story is speed, bar none. But after listening to developers compare workflows, one thing stood out: the hardest part of development remains defining the problem clearly.

AI may change the execution speed, but it doesn’t remove the need for judgment. In many cases, it may even increase it.

AI speeds up execution

Al is already helpful for monotonous, time-consuming, and pattern-based work. The kind of work that developers have always wanted to offload to juniors or interns, like upgrading legacy APIs across large codebases, generating test coverage, producing documentation, parallelizing component work, exploring vendor code, and helping teams move through unfamiliar code more quickly, to name a few. 

When patterns are clear and repetition is high, AI excels and can remove hours of effort. But it doesn’t remove the need to decide what should be built in the first place.

Typing code is not the bottleneck

The difficult part of software development has always been understanding what needs to be built, and building with AI is no different. While it changes how quickly code is written, it has less impact on the earlier stages of development.

Teams still have to hammer out scope, identify edge cases, and decide what should and shouldn’t be built. Translating business requirements into technical decisions is still a core tenet of the work. AI can accelerate code production and reduce repetitive work once those decisions are made, but it still needs a clear definition of the problem and expected behavior. 

As implementation becomes faster, the quality of that planning and upfront thinking has a bigger impact on the outcome.

AI performs best with context, plans, and constraints

There is a common AI myth that you can simply ask it to complete a task. In practice, the quality of the output depends heavily on the context and boundaries provided up front.

That context may start with working in a defined “plan mode,” where the approach is outlined before any implementation begins. In other cases, it comes from scoping the AI to a specific part of the system rather than exposing it to the entire codebase.

Clear rules and instructions also play an important role. These might include coding standards, architectural constraints, or explicit guidance on how features should behave. Documentation is invaluable in this environment, whether project documentation, architectural decision records (ADRs), or well-maintained reference files that establish patterns.

Examples are often just as important as instructions. Representative code or known-good implementations give AI something concrete to follow. Test-first workflows serve a similar purpose by defining expected behavior before code is generated.

The teams that get the most value from AI create the conditions for better output by structuring the input ahead of time.

AI performs worst when under-specified or over-trusted

AI tends to break down in fairly consistent ways, especially when working with limited context or too much autonomy. In those situations, it often makes reasonable-looking decisions that just don’t quite fit. It might refactor code that didn’t need to change, apply patterns inconsistently, or make assumptions about how a system works without fully understanding it.

Tests can also become misleading. In some cases, AI will adjust tests to align with its own output rather than resolving the underlying issue. Everything passes, but the original intent has drifted.

These issues are more noticeable in older or less consistent codebases. When patterns vary or decisions aren’t well documented, AI has a harder time distinguishing between what should be treated as a standard and a one-off. It tends to generalize from whatever it sees most clearly. It also tends to go further than necessary, introducing abstraction or solving adjacent problems that weren’t part of the original task, both of which tend to drift into hallucinatory territory.

All of this reflects how AI behaves in the absence of clear constraints. Though it can move quickly, it still needs human direction and oversight.

Legacy systems present unique challenges

AI tends to perform much better in greenfield environments than in long-standing codebases. But most teams are maintaining and working in systems that have been around for years.  

Legacy systems carry history. Different developers may have solved similar problems in different ways, patterns aren’t always consistent, and many decisions may not have been clearly documented. And unfortunately, AI doesn’t distinguish between what’s intentional and what just accumulated over time, so it tends to treat everything as a pattern worth repeating. Which is where things drift, as it may follow the wrong precedent, extend a one-off solution, or combine approaches that were never intended to work together.

At the same time, legacy systems often contain years of layered decisions that are difficult to untangle, especially for someone new to the codebase. AI is particularly good at working through large amounts of code quickly and helping explain what’s going on. It can surface patterns and make it easier to build a mental model of the system in a fraction of the time it would normally take.

Getting value out of AI usually comes down to scope. In legacy environments, tighter boundaries work better. Focusing on a specific feature or workflow is more reliable than letting it operate broadly, and clear documentation, ADRs, and reference examples help reduce ambiguity. 

The more complex the system, the more intentional the workflow has to be. Which usually means more time spent thinking before handing anything off.

Discernment is the real skill

Developers still need to understand how systems work. That part doesn’t go away, and it’s not something AI can shortcut. If anything, it becomes more important because evaluating output is now part of the job.

That’s where experience starts to stand out—knowing when something is off, even if it technically works. Understanding tradeoffs. Shaping, not just generating, solutions. AI is changing software development, but it doesn’t replace the thinking behind it. It makes good thinking easier to spot and bad thinking harder to hide.