How we work
AI-directed does not mean AI-decided.
VenSoc directs AI engineering agents inside a discipline built specifically to counteract where they are weakest: overconfidence, unverified claims of completion, and total memory loss between sessions. The discipline is the product.
In short
Five rules, and what each one costs us
- 01
Nothing is inferred
No database column, API field, environment variable or file path is used before it has been read at its source.
The characteristic failure of AI-assisted engineering is not bad code — it is plausible code that references things which do not exist. A model that has seen created_at and updated_at will happily write deleted_at into a query. It compiles, it reads correctly, and it fails in production against a schema that never had that column. Every identifier is verified against the migration, the model, the OpenAPI schema or the config file before it is typed.
What it costs
It is slower. Reading a migration to confirm four column names takes minutes that feel wasted right up until the first time it is not.
- 02
A test that cannot fail is not evidence
Tests are written before the code, and each one is proven to fail when the behaviour it guards is deliberately broken.
A passing test suite is only meaningful if the tests can distinguish working code from broken code. This is not theoretical: a guard on this very website was found to be passing while catching nothing, because the assertion was loose enough to be satisfied by the failure it was meant to detect. Mutation — breaking the code on purpose and confirming the test goes red — is the only way to know.
What it costs
Roughly a third more time on the test suite, and the occasional uncomfortable discovery that a test you were relying on was decorative.
- 03
Quality rules are build gates, not review notes
If a rule matters, the build fails when it is broken. If it only lives in a document, it will be skipped.
This site carries seven custom build gates: WCAG contrast across every semantic token pair in both themes, placeholder content, AI-crawler visibility fetched as GPTBot, browser console cleanliness, security headers, client confidentiality, and sitemap integrity. Every one of them caught a real defect that human review had already passed over. The same approach is applied to client work, calibrated to what that system actually risks.
What it costs
Gates have to be built and maintained, and a badly written gate blocks good work. Each one has to earn its place by catching something real.
- 04
Written decisions, not remembered ones
Every significant architectural choice is recorded with the alternative that was rejected and what it would have cost.
AI agents have no memory between sessions and human teams have unreliable memory across quarters. A decision record states what was chosen, what was rejected, and why — so nothing gets silently re-litigated six months later by someone who was not in the room, and so a fresh session can resume without repeating the analysis.
What it costs
Documentation discipline that has to be maintained even when the pressure is to ship.
- 05
“Done” means a command was run
Work is reported complete with the output that proves it, never with “this should work”.
The failure mode this prevents is specific: a feature reported as delivered where the tests were written but never executed, the file was created but left empty, or the integration was mocked. Every completion report on a VenSoc engagement names the command, shows the result, and lists explicitly what is not done.
What it costs
Reports are longer and occasionally less flattering. That is the point.
What an engagement actually looks like
- 01
Discovery
1–2 weeks
A written technical assessment: current-state architecture, the real constraints, a costed plan, and the risks we can already see. Yours to keep whether or not you continue with us.
- Current-state architecture, documented
- Constraints and risks named explicitly
- A costed delivery plan with phases
- 02
Architecture
1–2 weeks
A decision record for every significant choice, stating the alternative and what it would have cost. Nothing gets re-litigated later, because the reasoning is written down.
- Decision records with rejected alternatives
- Data model and integration contracts
- The verification gates the build will be held to
- 03
Delivery
Fortnightly increments
Working software in your environment every two weeks. Tests written before the code and proven to fail when the code is deliberately broken.
- Deployable increments, not demos
- Test suites with mutation-proven assertions
- Command output with every completion report
- 04
Operate
Ongoing
Monitoring, a named on-call owner, and a documented exit: your repositories, your infrastructure, your IP, transferable at any point without penalty.
- A named engineer who owns production
- Runbooks for the failures we anticipated
- An exit path that does not require our cooperation
In every contract
- You own the code and the IP from the first commit.
- Four hours of daily overlap with UK and EU business hours as standard.
- “Done” means a command was run and its output shown — never “this should work”.
- Exit provisions and knowledge transfer written into every contract.
Common questions
- Does AI write the code?
- AI agents write a large share of the implementation. Architecture, data modelling, security decisions and the definition of correctness are human, and every change passes gates a human wrote. The accountable engineer is a person, named in your contract.
- How do you stop AI-generated code from being subtly wrong?
- Three mechanisms. No identifier is used before it is read at its source. Tests are written first and proven to fail when the code is broken. Every quality rule is a build gate, so a regression stops the build rather than reaching review. Overconfident output is the expected failure mode, so the process assumes it.
- What happens if we want to leave?
- You take the repositories, the infrastructure definitions and the documentation, all of which are already yours. Exit provisions and knowledge transfer are written into every contract from the start, and no part of the system depends on VenSoc-hosted infrastructure unless you asked for it.
- Who do we actually talk to?
- The engineer doing the work. There is no account manager layer between you and the person who understands your system, and there is no handover from the people who sold the work to the people who deliver it.
The discipline is easier to judge against your own system than in the abstract.
Bring us something that is not working the way it should. You get a written assessment either way.