Implementation used to be the clearest evidence of engineering ability. AI is exposing the judgment that working code had made difficult to see.

AI is reducing the cost of turning an idea into working code across software applications. That shifts the constraint in engineering. As implementation accelerates, problem framing, product judgment, failure modelling and validation differentiates great engineers.

This shift in constraint was very visible when I built NeoAmp, a browser extension that brings the look of Winamp and old Windows Media Player visualisations to music streamed through YouTube Music and Spotify. NeoAmp renders visualization through Butterchurn, a WebGL implementation of MilkDrop. While recreating Alchemy, one of Windows Media Player's old visualisations, a scene resembled a symmetric flower. The first version of the flower was created by drawing lines which formed convincing petal shape. But the petals did not react to the music the same way as the original reference did.

The two implementations rendered in isolation with the same passage of real audio.

Frame-by-frame inspection of the reference revealed that the petals were not hand-drawn shapes at all. They were formed by audio waveforms that changed with the music. The difficult part was not expressing the geometry in shader code; it was recognising what the code needed to represent.

Without AI, turning that insight into a Butterchurn preset would have required substantial work across radial geometry, waveform equations, coordinate transforms, feedback, colour and shading. AI compressed much of that implementation work. But, it did not remove the need to describe the behaviour correctly, diagnose why the rendering was wrong or judge whether the generated output actually matched the expected.

That is the shift AI creates: as implementation becomes cheaper, the quality of the problem framing and the ability to verify the result matter more than the mechanics of producing the code.

AI changes where engineering effort matters most

Implementation gets cheaper. Framing, judgment and validation determine more of the outcome

For most of my career, working software was one of the strongest signals of engineering ability. Producing it from a difficult requirement demanded more than knowledge of syntax or frameworks. An engineer had to understand the problem, make design trade-offs, anticipate failure and judge whether the resulting product actually solved the problem. Much of engineering judgment became visible through the software an engineer built.

Great engineers were never defined by implementation speed alone. They combined implementation depth with problem solving, product understanding and judgment. But an engineer could still be exceptionally strong at turning a well-defined requirement into robust software while struggling to question the requirement, frame an ambiguous problem or challenge whether the proposed solution was worth building. AI changes the value of such profile. Once the problem and design are clear, AI can take on much more of the implementation work. The engineer still directs the work and remains accountable for the result, while the AI can produce plausible code without understanding unstated customer context, hidden assumptions or failure conditions. Two engineers may therefore produce similarly convincing implementations while differing sharply in the judgment behind them.

What separates engineers now

Four capabilities become more consequential when implementation accelerates: problem framing, product thinking, engineering judgment and consulting. They are distinct but connected. Problem framing clarifies what problem needs solving and why. Product thinking decides which solution or intervention is worth pursuing. Engineering judgment shapes how the solution is designed, built and verified. Consulting turns those judgments into decisions that others can understand, trust and act on.

AI fluency amplifies existing engineering judgment: it helps an engineer act faster on a sound decision and does the same for a poor one. Domain expertise strengthens all four capabilities by revealing which constraints matter in a particular industry.

None of these capabilities is new. In certain organisations, a business analyst, product manager, architect or account lead exercised them before an engineer joined the work. When AI reduces implementation effort, engineers can enter those decisions earlier. They do not all need to become product managers, but they do need to arrive with a reasoned view.

Problem framing

identifies the real problem

Problem framing turns a requested feature into a problem the team can examine. Suppose an e-commerce team is asked to add a wishlist so customers can save products for later. The implementation questions are straightforward: where should the save button appear, how should saved products be stored, and how should the list behave across devices? Framing starts one step earlier: why do customers need to save products at all? If customers are waiting for a price drop, a price alert may solve the problem better than a wishlist. If they are comparing products over several visits, the wishlist is the right solution.

AI makes this distinction more consequential. It can rapidly elaborate whichever solution it is given, including one built on the wrong assumption. A weak problem framing can therefore generate convincing designs, code and tests before the mistake becomes visible.

Better implementation cannot compensate for solving the wrong problem

A well-framed problem does not determine the solution. It defines the problem clearly enough for the team to evaluate solutions. Product thinking builds on that clarity by comparing possible solutions and deciding which one is worth pursuing, testing or discarding.

Product thinking

decides which solution deserves investment

Understanding the problem does not determine what the team should build. Product thinking connects the problem to the people experiencing it, the outcome the organisation wants to change and the alternatives available. An engineer with product judgment asks who the user is, what they are trying to accomplish, what are their pain points and how the proposed change would improve gains.

Choosing a solution is only the beginning. Product thinking also shapes scope and sequencing: what belongs in the MVP, what can wait, which assumptions should be tested first, and whether the expected value justifies the engineering effort and ongoing maintenance. Tools such as estimates, user journeys, story maps and product canvases support these decisions, but the quality of the decision matters more than the artefact itself.

Product thinking also means negotiating trade-offs with product managers, designers, engineers and business stakeholders when scope, time, customer value and technical quality pull in different directions. A strong engineer can explain those trade-offs, challenge a feature whose value does not justify its cost, propose a smaller alternative and use evidence after release to decide what should happen next.

Product thinking decides what is worth building and how much to commit to it. Engineering judgment begins once that choice has to become a reliable system.

Engineering judgment

asks how the system should be built and where it can fail

Engineering judgment is the ability to make technical decisions when there is no single correct answer. It appears in choices such as where to create a boundary, whether an abstraction is justified, what should be configurable, how much extensibility is worth designing for, and when a simpler solution is better. It also means recognising when readability and maintainability matter more than cleverness, or when performance and scalability justify additional complexity.

Testing requires the same judgment. A strong engineer does not simply ask whether tests exist. They decide which behaviours matter, which failures are worth protecting against, and whether a unit, integration, contract, performance or end-to-end test provides the right evidence. The same reasoning applies to production concerns: concurrency, retries, permissions, dependency failures, traffic growth, observability and recovery. Good engineering is not maximising every quality attribute mentioned; it is understanding which ones matter for the system and making the trade-offs deliberately.

AI can generate an abstraction, add configuration, propose tests or optimise a query. It cannot remove the need to decide whether those choices fit the system. In fact, generating more alternatives makes that judgment more important. The engineer still has to decide what should be simple, what should be flexible, what can fail, which trade-offs are acceptable and what evidence is sufficient to trust the result.

Consulting

carries judgment into the decision

Engineering and product judgment have little effect if they remain inside the engineer’s head. Consulting is the ability to understand what different stakeholders need, form a point of view and help the group make a better decision. That may mean challenging an assumption, exposing a risk, negotiating scope, explaining a technical trade-off in business terms or proposing an alternative when the requested solution is weak.

The difficult part is rarely presenting the information. It is influencing without authority while preserving trust. A strong consultant knows when to push back, when to ask another question, when to recommend a direction and when the decision belongs to someone else. They can handle disagreement and difficult conversations without becoming either passive or combative.

At senior levels, the same capability has to work across different altitudes. A detailed technical discussion may need to become a concise recommendation for a CTO, including the decision, the consequence, the trade-off and the evidence behind it. The goal is not polished communication. It is clear decision-making: what is being recommended, why, what the trade-offs are and what happens next.

Domain expertise sharpens all four capabilities. An engineer who understands how the customer’s business makes money, serves its users and operates under regulatory or contractual constraints can recognise factors that never appear in the ticket. A pricing rule, customer behaviour, contract term or regulation may change how the problem is framed, which solution is worth building, how the system should be designed or what advice should be given to a stakeholder.

These capabilities determine the quality of an engineer’s decisions. AI changes something else as well: how many parts of the product and technology landscape an engineer can contribute to without first developing deep fluency in every tool or framework.

From full-stack to full-spectrum

Full-stack engineering expanded the traditional boundary between frontend and backend. AI is pushing that boundary much further. A strong engineer can increasingly contribute across product, UX, frontend, backend, data, infrastructure, security and delivery without first becoming deeply fluent in every language, framework or tool involved.

Before AI, that breadth was expensive. Becoming productive in another area meant learning its syntax, framework APIs, tooling, conventions and debugging techniques. Engineers therefore built deep expertise in a smaller number of technologies and added breadth selectively. AI removes much of that entry cost by handling syntax, scaffolding, API recall and framework-specific translation.

That changes what breadth can reasonably mean. An experienced backend engineer can now work in an unfamiliar frontend framework, write Terraform, explore a data pipeline or contribute to deployment automation without spending months memorising each ecosystem first.

I think this points towards a broader engineering profile: the full-spectrum engineer. Full-spectrum does not mean expert at everything. It means being able to contribute across a much wider part of the product and technology landscape while retaining deeper judgment in selected areas. AI lowers the cost of entering adjacent domains; experience still determines where an engineer can make independent decisions and where specialist depth is required.

Experience expands the problem you can own

AI lets engineers produce working software earlier and contribute across a wider technical surface. It does not automatically give them the judgment to own a wider problem. That judgment still develops through product decisions, design trade-offs, production failures, customer feedback and seeing the consequences of earlier choices.

Engineering growth therefore becomes less about how difficult the code someone can write is and more about how much of the problem they can safely own. Implementation may be one part of that responsibility; more experienced engineers increasingly shape the problem, choose among competing solutions, anticipate consequences and remain accountable for the outcome.

AI accelerates implementation first, so engineers can produce working code earlier in their careers. It does not automatically give them the judgment to own a larger part of the problem. Product conversations, design decisions, production feedback and the consequences of releases still develop that judgment. The time AI saves on implementation contributes to growth only when engineers use it to participate in those decisions and remain accountable for the outcome.

What matters, then, is not title or years of experience but the scope of responsibility an engineer can handle well. Work that begins after someone else has defined the problem and ends with completed implementation increasingly overlaps with what AI can do. Engineers grow by taking responsibility for more of the problem, the design and the outcome while deepening the knowledge needed to judge whether the result is right.

What should change

Hiring and promotion should put less weight on code output or framework fluency as standalone evidence of engineering strength. Interviews should use ambiguous, job-relevant problems and assess the questions an engineer asks, the assumptions they surface, the trade-offs they make and the evidence they would use to verify the result. Promotion cases should show how someone improved a product decision, reduced technical risk, influenced others and owned an outcome alongside what they shipped.

Development has to expose engineers to the work from which judgment grows. That means customer problems, product trade-offs, design decisions, production feedback and business outcomes. Engineers need opportunities to frame problems, make decisions and see the consequences, with support proportionate to the risk. AI can accelerate implementation; organisations still have to develop the judgment required to direct it.

Engineers should still learn at least one language deeply, understand design and write good tests. Those foundations develop the technical judgment needed to recognise when generated software is wrong. But AI creates an opportunity to spend less time mastering the mechanics of every new framework and more time widening the problem an engineer can own.

In AI-assisted teams, engineering trust should follow judgment, not code volume. The engineers who deserve wider ownership are those who frame the problem well, make sound product and technical trade-offs, expose risk early and can show why the resulting outcome is worth building and safe to trust.