AI engineering
We build regulated enterprise applications with AI agents doing most of the implementation work. Architecture, threat model, acceptance criteria and release sign-off stay with named humans. Every change traces back to a written requirement.
- Most of the code is written by agents. None of it reaches production without a human decision on the record.
- Requirements arrive as numbered acceptance criteria. Each one gets a test and a place in the trace matrix.
- Gates are pipeline steps, so the same standard applies to every change, at any hour.
Every claim on this page has an edge. The limits are written out in full, in the same words we use in a scoping call.
The claim, narrowed
Minimal human dependency, defined
The claim is narrow and we mean it literally. Most of the code is written by agents. None of it reaches production without a human decision on the record.
Here is what a working day looks like. A feature begins as a written specification with numbered acceptance criteria. An engineer sets the architecture, the data boundaries and the constraints the implementation must respect. An AI coding agent then works inside a repository that has been prepared for it: house rules in writing, fixtures, linters, type checks, a test harness and a CI pipeline that already knows how to say no. The agent takes one criterion at a time, writes the code and the tests, runs the suite, and iterates until the criteria pass. Work arrives as small commits tied to criterion identifiers.
The engineer spends the day on specification, boundaries, review and judgment calls. Not on typing implementation. That is the whole shift. Throughput stops being limited by keyboard hours and starts being limited by how quickly your organization can decide things and how quickly a senior engineer can read a diff properly.
What this does not mean, stated plainly
- Not unsupervised shipping
- There is no path from an agent’s output to a running system that does not pass a human gate.
- Not production access
- An agent does not hold production credentials, touch live patient data, or deploy anything. Agents work in prepared environments with scoped access, agreed with you in advance.
- Not “the model wrote it, so it is correct”
- Generated code is treated exactly like contractor code from someone you have never met: assume nothing, test everything, read the diff.
- Not fewer accountable people
- Named humans own the architecture, the threat model, the acceptance decision and the release. Their approval is recorded at each of those points, with a timestamp, against a specific requirement.
- Not skipping design
- The opposite. When implementation gets cheap, sloppy specification becomes the most expensive thing in the project. So the specification work goes up, not down.
The pipeline
From requirement to release
Agentic delivery only works if the pipeline around the agent is stricter than the one around a human team. Ours is. Here is the whole route, end to end, with the human gates marked.
Three things make this pipeline hold. First, requirements are written so a machine can check them, which forces ambiguity to surface before code exists rather than during user acceptance testing. Second, the repository is conditioned for agent work before the first feature starts, so the agent is coding against a standard rather than inventing one. Third, the gates are deterministic: they run the same way on every change, at any hour, regardless of who or what produced it.
-
Intake and constraint capture
We write down what the system must do, what it must never do, and what it must prove. Regulatory obligations, data classification, integration surfaces and non-negotiables are captured before any design work starts.
-
Executable specification
Requirements become numbered acceptance criteria stored in the repository, each phrased so a test can pass or fail it. Ambiguity is resolved here, in writing, with your subject matter experts in the room.
-
Architecture and threat model Human gate
A named engineer sets module boundaries, data flows, failure modes and trust boundaries, and records the trade-offs that were considered and rejected. Agents do not choose the architecture.
-
Repository conditioning
We prepare the codebase for agent work: written house rules, fixtures and seed data, linters, type checks, the test harness, the CI pipeline and the exact commands an agent is permitted to run. This unglamorous step is why the rest of the pipeline works.
-
Implementation loop
The coding agent takes one acceptance criterion at a time, writes the code and the tests, runs the suite, and iterates until the criterion passes and nothing else breaks. Output lands as small, readable commits referencing the criterion identifier.
-
Automated verification
Every change runs the full gate set: build, unit and integration tests, coverage measured against acceptance criteria, static analysis, dependency and license scanning, and any project-specific checks. A red gate stops the change. There is no override that is not itself recorded.
-
Human review Human gate
An engineer reads the diff properly: boundary conditions, error paths, data handling, migration safety, and whether the tests actually test the thing they claim to. Approval is recorded against the criterion and the commit.
-
Evidence assembly
Specification version, design notes, test results, review records and approvals are assembled into a package shaped for your quality process. It is generated from the same repository as the code, so it cannot quietly drift out of date.
-
Release sign-off Human gate
A named person approves the release against the acceptance criteria and the evidence package. Builds are reproducible from the tag, so the artifact that was validated is the artifact that runs.
-
Maintenance and drift control
Dependency updates, security patches and regression sweeps run as scheduled agent work through the same gates as feature work. Maintenance stops being the thing that gets deferred until it becomes a project.
The control plane
What humans own
Five artifacts never leave human hands. They are also the five an auditor, a quality lead or your own engineering team will ask about first.
-
System architecture and boundaries
Module boundaries, data flows, failure modes and trust boundaries, with the trade-offs that were considered and rejected written down beside them.
-
Data governance and PHI handling
What the system holds, who may read it, and how it is segregated, minimized, logged and retained. Scope, redaction, hosting and retention are settled before the first line is written.
-
The threat model
Who might attack the system, what they would want, and which failures are unacceptable rather than merely inconvenient. Agents implement controls; they do not decide which risks you accept.
-
Acceptance criteria
What done means, written so a test can pass or fail it, agreed with the people who own the requirement before implementation starts.
-
Release sign-off
A named person approves each release against the criteria and the evidence. Auditors are not asking whether a machine helped write the code; they are asking who decided, on what basis, and where that is written down.
The gate set
The quality gates
Nothing merges on an agent’s word. Every change runs the same set, in the same order, whoever or whatever produced it. A red gate stops the change, and there is no override that is not itself recorded.
- Specification first
- Requirements exist as numbered acceptance criteria in the repository before any code is written. Ambiguity is resolved in writing, with your subject matter experts, rather than during user acceptance testing.
- Acceptance criteria as executable tests
- Each criterion is phrased so a test can pass or fail it, and coverage is measured against the criteria rather than against lines of code.
- Build and test suite
- Build, unit and integration tests run on every change. A red suite blocks the merge; it does not get waved through because the release is close.
- Static analysis and type checks
- Linters, type checks and project-specific rules run as pipeline steps, so house style is enforced by machine rather than remembered by whoever is reviewing.
- Dependency and license review
- Dependency and license scanning runs on every change, and dependency updates pass through the same gates as feature work.
- Human code review
- An engineer reads the diff properly: boundary conditions, error paths, data handling, migration safety, and whether the tests test the thing they claim to. Approval is recorded against the criterion and the commit.
- Reproducible builds
- Pinned toolchains, lockfiles and containerized builds mean a tag rebuilds to the same artifact.
- Traceability
- Requirement to commit to test to review to release. The matrix is assembled from the repository, not reconstructed by an analyst months later from commit messages and memory.
Capabilities
What we actually deliver
Seven things you can put in a statement of work. Each one is a deliverable that lands in your repository, not a posture.
-
Executable specifications
We turn requirements into specifications an agent can act on and a test can check. Each acceptance criterion gets an identifier, a test, and a place in the trace matrix before any code is written.
-
Agentic implementation
AI coding agents carry the bulk of the build inside a conditioned repository: house rules, fixtures, linters, tests and CI already in place. They work against the specification, not against a vague prompt.
-
Agents built to your process
We build custom AI agents for your workflow: specification-to-test generation, traceability checks, migration passes, evidence packaging. They run in your pipeline, on your rules, with your approvals.
-
Deterministic quality gates
Nothing merges on an agent’s word. Build, unit and integration tests, static analysis, dependency and license scans, and coverage of every acceptance criterion run on each change. A red gate blocks the merge.
-
Traceability by construction
Every commit references the requirement it serves. Every requirement links to its tests, its review, and the person who approved it. The audit trail is a by-product of the workflow, not a document written afterwards.
-
Validation-ready documentation
Design specifications, risk notes, test evidence and release records are generated with the code and versioned beside it. Teams working under HIPAA, GxP or 21 CFR Part 11 get artifacts shaped for their validation process.
-
Legacy code, read and rewritten
An agent will read every file in an old system without getting bored. We use that to map undocumented behavior, recover rules buried in code, write characterization tests, then modernize against those tests rather than against assumptions.
Tooling
Where AI does the work
AI does three different jobs in an engagement. All three pass through the same gates.
-
Building the software
AI coding agents work in the repository against real tests and carry the sustained implementation loop, one acceptance criterion at a time.
-
Inside your delivery pipeline
Custom agents we build to follow your process, not ours: specification-to-test generation, traceability checks, migration passes, evidence packaging.
-
Inside your product
For the case where the product you are shipping needs a language model inside it, rather than a model helping to build it. Integrated under the same gates as the rest of the system.
Trust comes from the gates, not the model
The specification, the tests, the automated gates, human sign-off and the audit trail are what you rely on. None of them depend on a particular model. So we choose the model for each task and fit that choice to your security, data-residency and procurement requirements, rather than standardizing on one. In practice the work splits three ways, and each kind can go to a different model.
- Analysis and review
- Architecture-level reasoning, complex refactors and review passes.
- Building
- The sustained implementation loop, criterion by criterion.
- Bulk changes
- High-volume mechanical work: sweeps, checks and bulk transformations.
We do not publish pricing or benchmark claims here: those belong in your own measurements, on your own workload.
Regulated environments
Why this is safer under audit
Regulated projects rarely fail because people wrote code too slowly. They fail because nobody can prove what changed, why it changed, who agreed to it, and whether the thing that was validated is the thing that is running.
-
The gates are deterministic
A quality gate implemented as a pipeline step applies the same standard to every change. It does not get tired at seven on a Friday, does not wave through a small fix because the release is close, and does not have a bad week.
-
Traceability is a by-product, not a chore
Every commit references the requirement it serves. Every requirement links to its tests, its review and its approver. The trace matrix is assembled from the repository rather than reconstructed months later from memory and commit messages.
-
Builds are reproducible
Pinned toolchains, lockfiles and containerized builds mean a tag rebuilds to the same artifact. That is the difference between a validated system and a system that was validated once, in an environment nobody can recreate.
-
The history is complete
Specification version, the change itself, the test run, the reviewer, the approver, the timestamps. Because the pipeline produces this as it goes, there is no gap between the work and the record of the work.
-
Human approval is recorded at every gate
Architecture, acceptance, release. Each one names a person. Auditors are not asking whether a machine helped write the code. They are asking who decided, on what basis, and where that is written down.
-
Documentation is generated alongside the code
Design specifications, risk notes and test evidence are produced from the same source of truth and versioned with it. The most common validation failure we see is documentation that describes a system that no longer exists. This workflow removes the opportunity.
-
Consistency scales
The hundredth screen is built to the same standard as the first, because the standard is written down and enforced by machine rather than carried in the habits of whoever was free that sprint.
The environments we design and document toward
- HIPAA. Protected health information handled with the segregation, minimization, access control and logging it requires, decided before implementation rather than retrofitted.
- GxP. Specification, risk assessment, test evidence and release records produced as the work happens, in a shape your quality function can take into its own process.
- 21 CFR Part 11. Audit trails, electronic signature semantics, versioning and retention designed into the schema, with the change history to support them.
Outcomes
What changes for your team
The benefits are real and they are structural. We are not going to attach a percentage to any of them. You will measure them on your own codebase, in the first engagement, with your own numbers.
-
Timelines compress
Elapsed calendar time moves out of implementation and into decisions. Work that used to sit in a backlog because nobody had capacity to type it now waits only on someone being willing to specify it and review it.
-
Teams get smaller and more senior
A senior engineer with agents covers ground that used to need a squad. Fewer people means fewer handoffs, fewer coordination meetings and less of the context loss that happens every time work passes between hands.
-
One standard applies everywhere
House rules live in the repository as text and are enforced in CI. The codebase reads as though one careful author wrote all of it, because in a real sense one careful process did.
-
Key-person dependency drops
The knowledge that usually lives in one contractor’s head is externalized into the specification, the tests and the repository conventions. Onboarding becomes reading rather than archaeology. If we walked away tomorrow, you would hold a system your own team can pick up.
-
Maintenance gets lighter, not heavier
Coverage exists because criteria required it. Documentation matches the code because it was generated with it. Dependency and security work is routine agent labor passing through the same gates, so the backlog of deferred upgrades that eventually forces a rewrite does not accumulate.
-
Change gets cheaper as the system ages
That is the inversion worth paying attention to. In most enterprise codebases, the cost of a change rises every year. With a specification-led, test-covered, agent-maintained codebase, the second year is easier than the first.
The domain
The domain underneath the method
The delivery model is new. The subject is not. WeCSharp has been building enterprise software for healthcare since before agents could write code, and that is precisely why we trust agents with implementation and not with judgment.
Our work has centered on the healthcare industry and on clinical trials: protocol-driven data capture, study and site operations, workflow systems that have to survive an inspection, audit trails and electronic signature semantics, controlled document handling, and integration with the enterprise estate that already exists around them. Operational efficiency, streamlined workflow and the effectiveness of trial operations were the goals before, and they are the goals now.
Read the list beside this as the evidence, not the history. Years of shipping software into regulated environments is what tells us where the gates belong, which failure modes matter, what an auditor will ask for, and which parts of a clinical workflow you do not let anything move fast through. An agent is a very capable implementer. Domain knowledge is what decides what it should implement.
- Rapid application development, worked collaboratively with your people rather than delivered over a wall.
- Bespoke design, build, deployment and maintenance shaped to one organization rather than configured from a product.
- Azure environments managed and administered by people who have run them for years.
- SharePoint administration across user and group management, sites and content, permissions and search.
- Delivery across time zones for clients in different countries, run on written specifications and recorded decisions.
- A startup posture: ship value early, refine on real feedback, take calculated risks deliberately rather than accidentally.
The edges
What we do not claim
Every claim on this page has an edge. Here is where it sits. If a vendor tells you their AI practice has no limits, you are being sold something.
How an engagement starts
The first slice
Nobody should take this on faith, including you. So the first engagement is small, scoped and timeboxed before it starts, and it runs on your own codebase.
-
Pick one real thing
A feature you actually need, a module that needs modernizing, a defect class that keeps coming back, or a validation package that is behind the code it describes. Not a demo, not a sandbox, not a greenfield toy. Something with your constraints and your mess in it.
-
Agree the acceptance criteria and the timebox
We write the criteria down and scope the slice before starting, so there is a definition of done that neither side can move afterwards.
-
Run the full pipeline on that slice
Specification, architecture note, conditioned repository, agent implementation, the gate set running in your CI, human review, evidence package, sign-off. The same route as a year-long engagement, at one-slice scale.
-
Keep everything, whichever way it goes
The working code, the tests, the CI configuration, the trace matrix, the documentation, and a written account of where the agents performed well and where they needed a person. If the result does not convince you, you still own a tested slice of software and a quality pipeline you did not have before.
Before you ask
Questions we get
Short answers. Where the honest answer is “it depends on your contract”, that is what it says.
Who owns the code and the IP?
You do. The code, the tests, the pipeline configuration, the specifications and the evidence package are delivered into your accounts and repositories. Ownership and license terms are settled in the engagement agreement before work starts, not assumed from a web page.
What happens when the agent gets it wrong?
The same thing that happens when a person gets it wrong: a gate fails, or a reviewer catches it, and the change does not merge. That is the reason the gates sit before the merge rather than after the release.
Where an agent needed a person, we write that down. Knowing which parts of your system agents handle well is part of what you are paying for.
Is our code or data used to train models?
That depends on the terms of the account the work runs under and on the contract between you and us, so it is not something we will assert in the abstract on a marketing page. We confirm the applicable terms in writing before an engagement starts.
Independently of those terms, we design the environment so that what an agent can see is the smallest set that lets it do the work.
Do you use agents on validated systems?
Yes, inside the change control you already run. The agent produces the change; your validation process decides whether it is fit for use. We build to your quality procedures rather than asking you to adopt ours, and we hold no certification or attestation of our own.
Can you work alongside our engineers?
That is the normal shape. Your engineers keep domain ownership and review rights; we bring the pipeline and the implementation capacity. Written specifications and recorded decisions are what make this work across time zones without a standing meeting.
What if we want a human to write a specific component?
Then a human writes it. The method is a default, not a religion. Anything with a safety consequence, and anything genuinely novel, is often better written by a person — and it passes through exactly the same gates either way.
If your question is not here, ask it: start a conversation.
Start with one slice
Bring one real problem from your own codebase. We will scope it, put a timebox on it, and run the full pipeline on it. You keep the code, the tests, the pipeline and the evidence either way.
The only address we use is contact@wecsharp.com. There is no phone queue and no sales team behind it.