"Problem Engineering" - Where software development is heading

Kapil Kaushik , This is for you, mate. You have been pushing me to share my insights with a larger audience. Here I am.

We tend to fit new power into old patterns until the efficiency gap becomes impossible to ignore. Think of Paul David’s classic account of factory electrification: first streams turned water wheels; then steam replaced the wheel as the prime mover; then electric replaced steam — but for a long time, plants still kept the same central drive + line-shaft + ceiling belts (“group drive”). Machines had to sit where power could reach them, not where work should flow. Productivity gains lagged until the real magic happened: factories redesigned around unit drive — a small motor at each machine — and the layout finally followed the flow of materials and labor, not the flow of power. The constraint wasn’t the technology; it was operating-model imagination.

Software teams are doing the same with GenAI: we’re swapping “typing” for “generation,” while keeping the same SDLC assumptions. We started with copilots: not “more code output” as the goal, but more throughput at the keyboard — faster autocomplete, faster first drafts, less time spent on routine scaffolding. Then we moved into agentic development, where an agent can plan, change multiple files, run commands, and produce a candidate implementation plus evidence (tests/results). Cursor 's Agent explicitly supports multi-file edits and terminal runs, and QuWit is positioned as a task-oriented, agent-first development environment. Yesterday, I actually did this: I handed Antigravity a problem statement (refactor), came back after lunch, and found code written with a round of testing done, waiting to be reviewed — not shipped (for now).

This is not without issues: we’re scaling implementation faster than we’re scaling judgment. OX Security’s “Army of Juniors” finding is a sharp description backed by analysis across 300+ repositories: AI-generated code can be highly functional, yet systematically weak on architectural judgment — compliant with the prompt, blind to system context — surfacing recurring architecture/security anti-patterns. Note, this army doesn’t need breaks. We do. The real question isn’t whether the juniors (pun on Agents) go out for lunch — it’s whether your seniors can inject architectural judgment at review time faster than agents can generate diffs.

Another gap shows up as a measurable Productivity Paradox: teams feel faster, but the org doesn’t move faster. Harness reported that 67% of developers spend more time debugging AI-generated code, and 68% spend more time resolving AI-related security vulnerabilities. Faros’ research ties the bottleneck to review economics: high AI adoption is associated with +154% average PR size, +91% PR review time, and +9% bugs per developer (and in their DORA-focused analysis, delivery performance metrics can remain flat despite higher individual throughput). Output goes up; review/debug queues go up too. This is exactly where Problem Engineering shifts things left: treat the problem spec as the primary artifact, and implementation as a largely automatable consequence.

And then there’s the compounding cost: maintainability. GitClear warns about “AI-driven maintainability decay,” and their 2025 research notes that 2024 was the first year they measured copy/pasted lines exceeding moved lines — where “moved” is a strong refactoring signal — pointing to rising duplication and “endless expansion.” If this kind of mess came from one of our own teams, we’d still use AI for speed — “summarize the diff, spot duplication, suggest refactors, propose tests.” So why can AI not do it for AI code? It can — but it needs the same thing humans need: a clear definition of “better,” grounded in your system constraints.

So what changes when we stop treating AI as a faster keyboard? We make the problem machine-executable: constraints, invariants, non-goals, failure modes, acceptance tests, and the “context pack” (what modules/APIs are canonical, what must not be duplicated). Security checks, dependency policy, architecture rules, regression/contract tests, and sandboxed execution become the control layer. If AI inflates PR size, you counterbalance with incentives and tooling that keep changes small, reusable, and reviewable — and you give agents judgment scaffolding before they write code (a different AI can help you do that).

The next step isn’t faster coding. It’s Problem Engineering: treating the problem spec as the primary artifact, and implementation as a largely automatable consequence.

In the upcoming posts, I will touch on some live code examples, tools, and frameworks to see this practically and how “Problem Engineering” can help.

Share this with your network if this sparked an idea. ♻️

Follow me for more insights on AI, Product, Leadership, and Coding. #ProblemEngineering #AI #Product #Engineering #Leadership