Inverted Coding Paradigm for AI-Assisted SWE

Teachers are most valuable helping students work through problems rather than delivering hours of lecture content in a one-way monologue. Eric Mazur developed peer instruction at Harvard in the early 1990s by moving information transfer out of the classroom and information assimilation into the classroom, which let Mazur leverage valuable classroom time to coach students instead of lecturing them¹. Jonathan Bergmann and Aaron Sams brought the same inversion to high school chemistry in 2007: while recording lectures for absent students, they found that the students who attended used the recordings to review². Khan Academy popularized the model at scale via the internet³.

A similar inversion is available for software engineers and their organizations. Programming may no longer need to compete with other job functions of a software engineer when it comes to valuable in-person office time. Specifically, programming can pivot to an asynchronous or overnight model, while business hours can focus on code review, cross-functional collaboration, and workshopping software plans with agents and humans in the loop.

Gates are Fewer, More Critical

To analyze what exactly AIs have automated for SWEs, and how we can reshape the working day, let’s trace what a task requires from end to end:

Assuming a SWE arrives with an appropriate scope of work in mind:

1. Write up a design doc.
2. Approve the design doc with team feedback.
3. Implement the design doc into code.
4. Iteratively test, validate, and improve code.
5. Send code for review to team.
6. Deploy code.
7. Validate design doc against deployment.

Here, steps 3 and 4 can take up the majority of an individual contributor’s time. As I will discuss later, leveraging loops and test-driven development with agents can relocate the implementation and iterative code improvement work to outside of a human SWE’s business hours.

With agents maximally in the loop, we can annotate the typical SWE workflow from before:

1. Write up a design doc.
   • Now, with an agent in the loop.
2. Approve the design doc with team feedback.
   • Cross-functional (XFN) collaborators can embed requirements, like UI designs, directly into the design doc so agents can build to them.
   • SWEs write lower-level plans, disambiguating implementation choices via interview sessions with agents, and develop full test matrices.
3. Implement the design doc into code.
   • Agents implement code async.
4. Iteratively test, validate, and improve code.
   • Agents “work backwards” against the comprehensive test matrices.
5. Send code for review to team.
   • Agents pre-review much of the work from various adversarial angles and fix issues. The SWE shifts from reading line by line to validating architecture, security, and whether the implementation aligns with their intent.
6. Deploy code.
   • Within careful bounds, agents can also debug and resolve deployment issues.
7. Validate design doc against deployment.
   • With full test matrices, agents can pre-verify the design doc against prod deployments.

A seven-stage model of SWE can be simplified to four discrete review gates, requiring the most critical thinking from the operator:

1. SWEs and cross-functional (XFN) collaborators align on requirements in mostly-human written design docs, rich with artifacts.
2. SWE-developed mostly-prose plan files generated from human-authored design docs, ready to hand off to agents.
3. SWEs code review the agent’s output against the plans.
4. SWEs and XFN collaborators manually validate the design doc against a deployed system.

Effectively, we should restructure the SWE workday against these four types of gates, letting programming work become transparent for SWEs.

This moves the bottleneck rather than removing it. My own overnight runs land between one and nine pull requests by morning against a few thousand agent tool calls⁴, and human review is now the scarcest thing in the system.

The answer is to make each PR self-reviewable: the agent produces and documents everything a human needs to verify it, and orders the diff by risk rather than by filename. I render mine as HTML so the tests, the assumptions, and the unresolved questions sit beside the code instead of in another tab⁵⁶.

Goals and test matrices, in particular, enable this shift of what business hours entail.

Specs & Agent Loops

Spec-driven generation from OpenAPI and Protobuf⁷ has always stopped at the contract surface: models, clients, and server stubs with empty method bodies. The domain logic the contract does not encode stayed human work.

What changed is not that generation exists. It is what can be attempted from a thin or informal spec. Agents draft those bodies, and they accept input far messier than a clean IDL, which is what lets a UI mock URL become an element of the test matrix. The draft is a hypothesis, not a compiled guarantee.

Recent AI systems provide /goal features that allow for “loop engineering” techniques⁸. The result is that SWEs no longer have to monitor agents as they write code; SWEs can work at the level of plans that specify detailed test cases.

Over four consecutive nights, my personal projects drive agent loops that have run a median of about ten hours without me, the longest stretch just over fifteen⁹.

Agents thrash, a lot: they “re-discover” how to use custom knobs within a system, they work down a train of thought that leads nowhere, and so on… the examples are endless, before we even consider the effects of AI hallucination in elongating agent SWE timelines.

In my own overnight builder runs across two days, 52 operations produced 8 deliveries¹⁰. The interesting part is where they failed. None of the failures I root-caused was the model writing bad code. They were orchestration problems, like sessions killed too early by a watchdog or an agent waiting on a process that was already dead.

The key migration for thrash is investing in the matrix of test cases beforehand so agents can write and work against comprehensive test suites.

Agents can effectively “work backwards” from failing tests to find real and correct solutions in almost all domains of testing, including unit tests, load tests, UI tests, and service-level objective (SLO) verification. As in test-driven development, everything that can be encoded via tests or clear verbal acceptance criteria is a surface where agents can work unattended. Passing tests proves the code satisfies the tests, not that the tests captured what we meant, so the matrix itself becomes the artifact worth reviewing.

This test matrix is what makes the async agent shift work. With agent goal loops, thrash costs wall-clock but async wall-clock time is abundant, whether overnight, over the weekends, or during a full day of meetings.

Thrash is not free. Roughly a quarter of my pull requests created by agents in my personal projects in the past few months were closed without ever merging, and the compute those attempts burned is real money whether or not anyone was awake to watch it¹¹.

Collaboration

SWEs’ time in the office is best used writing detailed specs, not writing code or even watching agents write code. These specs include the full product definition from end-to-end, incorporating the designs and insights of cross-functional (XFN) collaborators such as UI designers and product managers. As the docs are changed during the day, agents reconcile major new features or changes async so that the team can come back to the next iteration of work that was built out for them.

Overall, this pattern lets SWEs work at a more creative level. Given the capabilities of agents today, spec files can be detailed documents approachable by many different XFN roles and still include deep technical details where needed.

Takeaways

The fast-advancing capabilities of AI systems have already shown us that specific job functions like programming can be highly automated. The time that frees up gets reallocated to async and off-hours work, much like the inverted classroom model from Khan Academy.

To leverage agents’ ability to deliver real, production-level code and to maximize the utility of in-person collaboration, it’s important for both ICs and orgs to start inverting code-based workstreams: let the code get written overnight, and spend the day at the gates, the specs, and the people.

References