Building the Company
Why AI isn't making engineering 10x faster
The GTM side of the same era is Surviving the SaaS repricing and GTM as a system. This page is the delivery loop.
The 10x illusion
Section titled “The 10x illusion”The session — co-founders of a cloud-deploy company, prior startup acquired by Workday, Microsoft and AWS backgrounds — opened on a customer conversation that had stopped being about deploy. Every founder in the room was already experimenting with coding agents. Almost nobody was seeing the return they expected.
The frame they used is Amdahl’s law. A delivery process with five steps that each take the same time — requirements, coding, review, testing, deploy — looks like a hundred hours. Ten-x the coding step and you still have a process of about eighty. A 20% speedup. The uncapped steps become the new gate, and the pattern repeats.
If you have a multi-step process, you’re always gated by the slowest step. The more you speed up certain steps, the ones that you did not speed up become the bottleneck.
The takeaway they kept repeating: a wow, 10x move of the whole workflow only happens if you systematically speed every stage, including the ones past your comfort zone. That is not an engineering-only insight. Finance and marketing have the same shape.
They also named the constraint they keep hearing from customers: engineering sovereignty. Full flexibility. Not tied to one platform, one cloud, or one model provider. Run what you want, when you want, where you want — and still get ROI.
I want to have full flexibility. I don’t want to be tied to any one platform. I don’t want to be tied to one cloud. I don’t want to be tied to one LLM provider. I just want to be able to run what I want, when I want, where I want.
Where the room actually is
Section titled “Where the room actually is”They ran a five-or-six-question self-score (their “AI-native index”) across design, code, review, testing, deploy, and operate. Higher means more of the step is done with agents; humans are still there, setting policy and boundaries, but they are not the work.
What came back in a small founder sample is the usual spread:
| Who | Rough score | What was low |
|---|---|---|
| Engineering leader, ~25-person team, looking to double | “Pretty low” | Review, testing, operate — “not at all” |
| Non-engineer founder on a personal Claude Code stack | 1.8, “assisted” | Deploy 0, review 0; operate was the high (5); design/code/testing around 2 |
| Founder, 9-person team (5 + 4), prior Microsoft and an exit | Native on development; “managed” on support | Support and customer operations still catching up |
Adoption inside one company is not one number. The ~25-person team had people generating slop and people running three agents all day; it was not mandated yet. The 9-person team claimed 100% coverage from concept through test, and a six-month pace the founder said he had not seen in a 20-year career. Both can be true in the same month, in the same community.
Most teams the speakers work with sit in the 1–5 band: AI for coding and maybe review, everything else still manual. That gap — deploy, operate, monitor, troubleshoot — is the difference between “we bought Copilot” and AI-native.
Humans became the bottleneck
Section titled “Humans became the bottleneck”A 10x coding step with human review at the old cadence does not feel like leverage. It feels like drowning.
I get questions from a developer on how we’re supposed to review a PR that has 50,000 lines of code changed by a single developer.
A thousand-line PR at the end of the week, with no daily context, is not a review. It is a new full-time job. The speakers’ own reset a few months earlier came from exactly that frustration.
The answer was not less AI. The answer was more AI.
The name they gave the failure mode is meat proxy: a person forwarding AI-generated text without reading, understanding, or validating it, acting as a relay between systems. Slack alert into the model, model into the terminal, prod error into the model, CI error into the model. Last year that was two tolerable hours around six hours of real work. Now it is most of the day.
Agents can run 24/7. If every review, every gate, and every checkpoint still requires a human, you have built a factory whose output is more work for the people you cannot clone. The job that remains is policy: you can still require a human to approve what ships to prod. You do not have to be in the loop at every step.
Default yes, then loop
Section titled “Default yes, then loop”The mental flip, several months earlier for the speakers: stop asking “can AI do this, or is this still human-led?” Start from yes, unless someone shows a hard reason it is not. Once that is the default, you hunt for the fix — a different model, more thinking effort, an adversarial review — instead of parking the step as “not ready.”
The default answer is yes, unless proven otherwise. Kind of just turn that on its head. It’s going to be AI-native unless you really show me a very good reason why it is not.
The co-founder’s personal tipping point: he now trusts generated code where last year he did not. That is what let them stop babysitting and automate the rest of the loop.
One-shot prompting is the other trap. One prompt, one function, ship it is not how this works. Write loops: one model drafts, another evaluates for brevity, another looks for security issues. Put the human where it actually matters — security, database access, asymptotic behavior — and skip polishing a longer function that has none of those problems.
The ~25-person team’s live limits were real, and the room did not wave them away: graphical tests on a map still needed a person; PRDs came back verbose even when asked not to; a senior would delete 16 generated lines and write three. The response was not “wait for the models.” It was pick the model for the job, add a brevity evaluator, and stop expecting one shot to be the system.
A colleague’s line in the room: you are not writing software. You are writing systems that write software.
Take the work off the laptop
Section titled “Take the work off the laptop”The first meat-proxy move is physical. Coding agents that only run on a founder’s laptop stop when the laptop closes — a flight, a meeting, lunch. Move the agent into the cloud and it runs 24/7. Then you can attach the rest: webhooks so a CI failure or a prod alert wakes an agent instead of waiting for a paste; persistent sessions so the next agent can inspect what the last one was doing; enough access to open a PR without a shortcut around the pipeline.
The properties they argued for, as a checklist rather than a vendor:
| Property | What it replaces |
|---|---|
| Proactive | You should not have to ask “do we have stale dependencies / a CVE.” The agent surfaces it. |
| Reactive | A CI failure or an alert starts a session. You do not paste the error. |
| Persistent context | Related work is discoverable. Two agents on the same incident can find each other. |
| Connected | Read the log, jump services, open a PR. No merge-to-main without the pipeline. |
| Self-updating | Do not wait for a vendor connector. The agent writes the integration. |
| Model-agnostic | New GitHub issues on Opus, three-hour jobs on something cheaper, your policy. |
The demo in the room was a cloud VM with a chat interface and almost no buttons: connect a subscription, ask it to listen for GitHub events, watch a new issue spawn a session. The portable version of that demo is the webhook. A customer typing feedback on the site can be the same trigger as a GitHub issue — triage, design, implement, test, review, deploy — with a human only where you wrote that they must be.
The job is setting, writing that policy, setting those policy guidelines.
The people question
Section titled “The people question”This is the part of the session that was not a tooling talk.
Three years ago, the strong engineer who still works the old way would have been the hire you wanted. If they cannot make the flip — default yes, loops, policy not paste — they get passed by people who will. A founder in the room who is all-in on development said they had to let those people go. Output did not drop. It went up, and frustration went down, because the remaining team would take the leap. Brutal, and, in a small startup, how they described the constraint: limited cash, everyone has to produce a certain way, and the competitor is already doing it.
Mandate vs. grass-roots was the other split. The ~25-person team had not mandated yet; the leader’s read was that they needed to. The 9-person team already had. Neither is a morality play. It is whether the slowest human step is allowed to remain the gate.
Numbers from the room
Section titled “Numbers from the room”| Figure | Value |
|---|---|
| Amdahl illustration | 5 equal steps; 10x one step ≈ 20% overall |
| Delivery stages they scored | Design, code, review, test, deploy, operate |
| Self-score in the room (one founder) | 1.8, “assisted”; deploy 0, review 0 |
| Team sizes in the room | ~9 (5 + 4) all-in; ~25 mixed, looking to double in 4–5 months |
| Review load cited | 50,000-line PR from one developer; 1,000-line PRs without daily context |
| Copy-paste tax, as described | ~2 hours/day last year → ~8–9 hours/day now |
| Trust tipping point (one co-founder) | Did not trust generated code last year; does now |
Sources
Section titled “Sources”One working session (Sep 18, 2026) with the co-founders of a cloud-deploy company — prior startup acquired by Workday; Microsoft and AWS backgrounds — facilitating a founder roundtable on why coding agents are not returning 10x. Members in the room included an engineering leader of a ~25-person team, a 9-person-team founder coming off a prior exit, and a non-engineer founder assembling a personal agent stack. Related pages: Surviving the SaaS repricing for the market version of “product is now the easy part,” Building your executive team for the people decisions this session only touched.