AI-Assisted Software Development Finally Made Us Engineers

A structural engineer has never welded a beam. They design it, spec the tolerances, set the load limits, choose the code standard, and sign off on the inspection. Someone else does the welding.

That is how every engineering discipline works. Civil, electrical, mechanical, aerospace. You plan, then you verify. Execution belongs to someone else.

Software was the exception. We called ourselves engineers and then spent our careers personally typing the execution. Architecture got whatever hours were left over, which on most teams was none. AI-assisted software development is the first thing in thirty years that has actually changed that split, and it changes it in a direction most teams are not prepared for.

The sequence on an engagement now runs: define the problem, choose the architecture, write the constraints, decide what "correct" means, build the guardrails. AI does the legwork. Then we verify against the standard we set.

That was always the part I was hired for. What has changed is that it is now the whole team's mode of work, not just mine.

Software was the only engineering discipline that also did the execution

The naming problem was never pedantic. It had consequences.

When the same person designs and builds, planning competes with shipping for the same hours — and shipping always wins, because shipping is visible. Every startup I have worked with has made that trade, usually without noticing. The architecture conversation gets deferred to "after this release," and there is always another release.

That is why technical debt is treated as inevitable rather than as a decision. It is the predictable output of a discipline where the designer is also the tradesperson, under deadline.

Move execution off the engineer's hands and the trade disappears. Planning is no longer competing with typing. It becomes the work.

What bad AI-driven architecture looks like at month six

Delegated implementation does not fail loudly. It fails on a delay, and the delay is roughly six months. Here is what it looks like when it arrives.

The same logic exists five times. Each task was generated in isolation, with no shared abstraction, because nobody specified one. It works. Then a business rule changes and you discover the rule lives in five places, three of which nobody remembers.

Nothing has seams. The code works but cannot be tested, because every dependency is concrete. AI writes the happy path and wires it directly — that is the shortest correct answer to the question it was asked. If you did not ask for injection points, you did not get them.

The schema grew per feature. Tables were added as each task needed them, with no normalization decision anywhere. Individually reasonable. Collectively, reporting is now impossible and every query joins six tables.

Performance is fine until it isn't. N+1 queries and unbounded fan-out are invisible at a hundred records and fatal at a hundred thousand. Nobody set a performance budget, so nothing failed a test.

The tell is the velocity curve. Three excellent months, then a cliff. Every change starts touching more files than it should. That curve is the single most reliable signal that implementation was delegated without architecture.

None of this is an argument against delegation. It is an argument that AI-generated code inherits the quality of the specification it was given, and specification is a senior skill.

It is also the debt that shows up in a data room. Everything on that list is something an investor's technical due diligence will find, usually at the least convenient moment.

The guardrails that make delegation safe

There is a line I use with every client: your standards should run without you. If the process breaks when you are not looking, it is not a process — it is a habit, and habits do not survive delegation.

That was true before AI wrote any code. It is now the whole game. A rule that is not enforced in the pipeline is a suggestion, and a suggestion has no effect on a model that was not told about it.

The mistake I see most often is trying to install the whole standard at once. It fails every time, because a gate nobody can pass gets switched off in week two. Add one gate at a time, in the order the team can absorb, and each one holds.

The ladder I take clients up, roughly over ninety days:

1. Lint and format — auto-fix what can be fixed, block on the rest. Cheap, uncontroversial, and it establishes that the pipeline has authority.
2. Tests must pass to merge. Not a coverage number yet. Just: green or it does not land.
3. A coverage threshold that starts where you are. This is the part people get wrong. Set the floor at today's actual number, whatever it is, and raise it two percent a month. A target of eighty percent on a codebase sitting at twelve is theatre. A floor that ratchets is a system.
4. Security scanning on dependencies. Automated, boring, catches things nobody was going to catch by reading.
5. Required review on every pull request. Last, because it costs human time and it only works once the cheaper gates have cleared the noise.

Alongside that, two rules about what tests are for:

New work requires tests. Bug fixes require a regression test. The second is the more interesting one, because a regression test is not coverage — it is a contract. It encodes a decision: this specific thing must never happen again, and here is the proof. Coverage tells you code ran. A contract tells the next reader, human or model, why the behaviour is what it is.

Write the decisions down. Architecture decision records are already in my standards for every client, and delegation makes them load-bearing rather than tidy. If the reasoning behind an architecture is not written somewhere retrievable, it is not available to whoever picks up the next task — and increasingly, that is not a person who can ask you a question.

Two more boundaries worth setting explicitly before you scale output:

• Define "correct" before work starts. Acceptance criteria, a performance budget, and a list of what must not change. If criteria only appear afterwards, you are reviewing, not specifying.
• Decide what may change without a human ruling. Public claims, pricing, database schema, and anything touching authentication or money get a decision first. Everything else can proceed unsupervised. Draw that line once, write it down, and enforce it in the pipeline.

The economics changed for small teams

This is the part I did not expect, and it is the most valuable consequence for the companies I work with.

Every practice I have pushed on clients for years lost the same argument. Automated test coverage. CI/CD. Infrastructure as code. Real observability. Code review that is not a rubber stamp. Documentation that is not a stale README.

The objection was never that founders disagreed. It was that retrofitting a test suite onto an untested codebase is weeks of unglamorous work with no visible feature output. For a five-person team with runway pressure, that never wins a priority meeting. So it got deferred, and the debt compounded.

Those tasks are high-effort and low-creativity. That is precisely the profile of work that delegates well. What used to be weeks is now hours — which means the coverage ratchet I described above stops being a two-year project and becomes a two-month one.

In Canada there is a funding angle — SR&ED and programs like DMAP can offset some of this work, and I have used both with clients in Toronto and across the GTA. But money was never the binding constraint. Senior engineering hours were, and that is the constraint that moved.

Here is the asymmetry that matters most: these practices are more valuable when AI writes the code, not less. When a human who understood the whole system wrote every line, a thin test suite was survivable — the understanding lived in someone's head. When implementation is delegated, the test suite is your only evidence that the generated code does what you meant. Testing stops being hygiene and becomes the verification layer. It is no longer optional.

A five-person startup can now run the engineering practices of a thirty-person one. That is a real structural advantage, and most of them are not taking it.

How to tell whether you have engineers senior enough to plan

If you are non-technical, you cannot evaluate the architecture. You can evaluate whether anyone is doing architecture. These questions work without a technical background — and they pair with the broader signs that a business has outgrown its current technology leadership.

1. "What did you decide not to build, and why?" Someone who plans has rejected alternatives and can name them. Someone who executes has only ever built what was asked.
2. "What breaks first at ten times our current volume?" A planner has a specific answer and usually a number. "We'll deal with it when we get there" means nobody has modelled it.
3. "Can I see the acceptance criteria before the work starts?" If criteria only ever appear in a pull request description afterwards, the planning happened retroactively, which is to say it did not happen.
4. "What is this system not allowed to do?" Constraints are the output of planning. A team that cannot list its constraints does not have any.
5. Watch what happens when AI output is wrong. Do they fix the output, or fix the specification and the guardrail? Fixing the output is execution. Fixing the spec so the error cannot recur is engineering. This is the most revealing of the five.

The red flag to watch for is simpler than any of them: if velocity is the only metric anyone reports, you are being shown execution and asked to infer engineering.

Where this approach fails

It would be dishonest to sell this as universal. Four places it does not hold.

Genuinely novel problems. Models are trained on what exists. For a problem with no prior art, delegation produces confident, conventional answers to an unconventional question.

Ambiguous requirements. Poor specification used to fail slowly, because a human implementer asked questions. Now it fails fast and at volume — you get the wrong thing built correctly, quickly.

High-consequence domains where verification is expensive. In regulated work, payments, or anything safety-adjacent, delegation is still fine. But verification cost dominates, and it can exceed what you saved. Do the arithmetic before assuming a gain.

Teams with no senior engineer at all. This is the important one. AI is a multiplier on engineering judgment, including the absence of it. A team that could not plan before will now build the wrong architecture faster than they previously could have built anything. The failure arrives sooner and larger.

And one correction to a common expectation: this does not reduce headcount the way people hope. It changes what you hire for. Fewer hands for typing, more judgment at the front of the process, and someone accountable for verification at the end.

Get the planning right before you scale the output

Delegating implementation is the easy half. The hard half is having the architecture, the constraints and the verification standard in place first — and most teams discover the gap at month six, when the velocity curve bends and every change costs more than the last.

If you are increasing how much code your team generates and you are not sure the planning layer underneath it is strong enough, that is worth checking before it compounds. A Technology Health Check is a fixed-scope review of your architecture, stack, team and risk, with a written report in about two weeks. If you need the planning capacity itself rather than a review, that is what a fractional CTO is for — the role is covered in full in this guide — senior engineering judgment embedded in your team, accountable for the decisions, without a full-time hire.

Book a call and we will spend thirty minutes on where your process is actually thin. No obligation, no pitch.

Execution got cheap. Judgment did not.