Software Engineering Has Changed For Good - by Luke Wilson

Over the last three months at work, I have not written a single line of production code by hand. That doesn't mean I'm not doing good engineering work. It just means how I work has changed.

This is what one of my typical production tasks look like: I open Codex with the GitHub CLI installed. I tell it to read a specific issue number. It pulls the issue, scans the repository, and summarizes relevant files. I ask it to produce a concrete implementation plan: files to modify, functions to add, migrations required, test updates, and potential side effects. I review every word of that plan. If something is vague, I interrogate it: "Show me every file that references this symbol." "Where exactly is this logic currently implemented?" "Why is this safe given the current auth flow?" "What breaks if we do this?" If I don't trust an answer, I ask it to cite exact file paths and code blocks. If needed, I manually verify. Once the plan is correct, I start a fresh session with a clean context window. I paste in the finalized plan and required architectural constraints. For large tasks, planning and implementation happen in separate sessions to avoid running out of context or polluting it with junk argumentative information. I have an agent generate the implementation using the plan. A good plan contains all the information the agent will need to do the work; they shouldn't have to go searching like the planner did. Some have explained this part as writing plans that "juniors can follow."

For non-trivial changes: I run a second agent pass to compare the implementation against the requirements stated by the plan. I manually review the diff. I run tests. I manually test edge cases. I push revisions back to the agent for targeted fixes. Sometimes I include screenshots of what I'm seeing. That helps agents understand how the things they change are affecting the app. Only after manual verification do I commit.

Time distribution on a medium task is roughly:

• 25–35% planning and constraint definition
• 40–50% reviewing, testing, and iterating
• 15–25% agent execution time

The typing is the smallest component. I see a roughly 5–10x speedup for standard application work when I use this agentic workflow.

While I use a workflow like this for all my work, agents are best today at the following tasks:

• CRUD feature additions
• API integrations
• Schema migrations
• Writing tests
• Refactors with clear boundaries
• Small internal tooling
• Generating boilerplate-heavy infrastructure

Example: a coworker built a Python GUI to manage running Node processes in about 20 minutes. Previously that would have been a half-day task of learning the GUI framework, getting up to speed on programming in Python, and scouring documentation. I don't think he viewed a single page of documentation.

I really do feel like the guy in this picture when I approach a coworker to save them hours of their day with Claude Code.

But here's where agents do not work well yet:

• Large-scale architectural refactors without strict guardrails
• Long-lived stateful systems where context exceeds model limits
• Debugging issues that require deep runtime inspection
• Anything requiring terminal-level visibility without manual piping
• Autonomous maintenance without human review

The main constraints right now are:

• Context window limits (200k–300k tokens)
• You must carefully control what information the agent sees. Too little context produces hallucination. Too much produces dilution. Someone said you get about enough context for the full movie script of the first Star Wars, since usually about 30-60k tokens go directly to the system prompt before you write a single message.
• Architectural drift
• If constraints are not explicitly stated, agents will redesign unrelated modules to resolve local issues. I've found this can be mitigated using explicit scope in plans, and by stating what's off-limits if necessary.
• Verification cost
• Agents can hallucinate file references or misinterpret behavior. If you don't already understand the system, you cannot reliably detect errors. This is why it is so important to be actively part of the investigative planning in your workflow. Otherwise, you will find that the implementation doesn't work, and you won't know why or where to start with fixing it.
• Tooling mismatch
• Most development environments are designed for humans. Agents do not have native access to debuggers, terminal state, or runtime introspection unless explicitly wired, and likely through MCP. MCP isn't very efficient, and every function you expose takes up some of your context.

The practical skill is no longer "write code quickly." It is "define constraints precisely and verify outputs rigorously." You still need to understand:

• System design tradeoffs (for example: monolith vs distributed)
• State management strategies
• Dependency boundaries
• CI/CD pipelines
• Code quality standards
• Security implications
• Performance bottlenecks

Agents are not good at critical thinking or long-horizon reasoning. They are generally short-sighted and will offer solutions that work in theory but fail to hold up to real development or scrutiny. That's not to say that agents are bad at planning. They are very useful for that.

The engineers who benefit most from agents are those who:

• Can decompose problems cleanly
• Can articulate invariants and constraints
• Can recognize when a generated solution violates architectural intent
• Can design workflows around context limitations
• Can automate their own review and testing loops

The biggest misunderstanding is thinking this eliminates engineering fundamentals. It does not. It eliminates large amounts of typing and code-writing, major time-wasters.

On the career side, the observable difference between engineers using structured agent workflows and those who are not is throughput and iteration speed. Over time, that compounds.

If you are a new developer today, the useful path is:

• Learn how to read code deeply.
• Learn system architecture.
• Build projects using agent workflows.
• Practice writing implementation plans before implementation.
• Practice reviewing machine-generated diffs critically.
• Learn how to structure repositories for agent-friendly development.
• Build CI/CD pipelines and test harnesses that agents can leverage.

Memorizing data structures is less valuable than understanding when and why certain patterns are appropriate. Most common structures are already implemented in libraries. The important part is in knowing which to use and why.

For decades, the human-computer interface for development has been syntax and manual editing. Now intent description plus verification is becoming the dominant loop. Humans specify intent and constraints. Agents produce implementation candidates. Humans verify and adjust. That's way faster than manual implementation, and so this changes how much one engineer can own. One engineer can now maintain entire products end-to-end, including planning, development, testing, reviewing, and provisioning and maintaining cloud deployment infrastructure. What previously took teams to do can now be done by one skilled engineer.

If you resist AI entirely, you will likely move slower relative to peers who embrace it. If you resist it as long as you can, you may find one day that you are technically inferior and you will have to fast-adapt while everyone else has had years of practice. The productivity gap is already visible in some teams. You don't want to be last.

But I'm not here to fearmonger and tell you, like all the goofy AI company CEOs, that you're losing your job by next year. I just don't believe that's true. I think the CEOs are a little afraid of the economic changes, so they fearmonger while they still can. We engineers are now about 5-10x more productive than before. A single person can own a product. We are destined to end up wealthier if we take ownership of these valuable skills while we can. Huge technological innovations like these don't come often. I think you should be excited for change that you can totally hop onto, and if you're reading this post then that likely means you are already very early.

You're early.