AI in software development · Constrained environments
Applying AI to software development in environments with constraints.
Many organisations cannot adopt AI coding the way public advice describes it. This page sets out how GZLighTek works when the network is closed, data cannot leave the boundary, and every action may be audited.
Why common AI-coding advice does not transfer
Most guidance on AI-assisted coding assumes an open laptop, a public network, and a team free to choose its tools. A controlled enterprise environment usually offers none of the three.
Paste the code into a chat and iterate.
Source and data may not cross the boundary. The workflow has to run where the code lives, or not at all.
Install the latest tool or plugin.
Software on a managed workstation arrives through an approval process. A tool that cannot be approved cannot be part of the method.
Let the model write the code and the tests together.
Tests produced from the same source as the code agree with it by construction, so they cannot detect a misunderstanding that both share.
Trust the result if it looks right.
Where outputs are reviewed, released and audited, “looks right” is not evidence. Someone must be able to reproduce the result later and show how it was produced.
Move fast and fix it later.
Change windows, review gates and rollback duties make late fixes expensive. The cost of an error is set by the process around it, not by how quickly the code was written.
None of this makes AI unusable in such environments. It means the method has to be designed around the constraints first, and the tools chosen afterwards.
Principles the rest of the page depends on
Six ideas that stay the same whatever tool or model is in use.
Reproducible over fast
A result that cannot be produced again from recorded inputs is an anecdote. We prefer a slower path that another person can repeat and check.
Feedback from build and test output
The model works against real compiler, build and test results, not against its own description of what the code should do. Failures go back in as input, and each round is recorded.
An independent oracle
Code and tests are not generated from the same source. Expected behaviour comes from an independent specification, so the two can disagree, and a disagreement is information.
Freeze the tests before changing code
Once tests are agreed, they are fixed for that change. Code is edited to satisfy them; the tests are not edited to satisfy the code. Any change to a frozen test is a separate, reviewed decision.
Bounded context
The model sees only what the task needs: the relevant files, interfaces and rules. A smaller, explicit scope is easier to review, easier to keep inside the boundary, and leaves fewer ways to go wrong.
Drift between documents and code
Specifications and code diverge over time. We treat each as evidence about the other, check them against each other at defined points, and record which one was corrected.
How GZLighTek applies it
A sequence we follow for each change. The steps are small on purpose, each leaves a record, and a person decides at each gate.
Specify
The change is written down as behaviour: inputs, outputs, edge cases, and what must not change. This document is the independent source the tests are derived from.
Freeze the oracle
Tests are derived from the specification, not from the code yet to be written, then reviewed and frozen. They fail first, which confirms they actually check something.
Scope the context
We decide which files, interfaces and rules the model may see for this change, and list them. Anything outside the list stays outside.
Generate and iterate
The model proposes code. The build and the frozen tests run, and their real output goes back as the next input. Every round, with its inputs and results, is logged.
Review
A person reads the diff against the specification, not just the test result. The reviewer can see what the model was given, what it produced, and what was run.
Trace and reconcile
The specification, tests, code and log are linked to the change record. Where document and code disagree, the disagreement is resolved explicitly and noted.
The same sequence applies with or without network access. What changes between environments is which steps run where, covered next.
Working inside the boundary
Constraints are treated as design inputs. Each one changes the method in a specific way.
Closed network
There is no route to external services. Models and tooling run inside the boundary, or the model is replaced by a procedure that works offline. Dependencies are brought in once, through the approved channel, and recorded.
Nothing can be installed
Where software cannot be installed, the method is expressed as practice rather than product: written specifications, frozen tests, scoped context, review checklists. Starting with only what is already approved is a valid starting point.
Data stays inside the boundary
Source, test data and logs do not leave. We work with data that is synthetic or already cleared for the environment, and keep the model’s inputs to the minimum the task needs.
Audited logs
Activity may be reviewed by someone who was not there. We keep records that stand on their own: what was asked, what context was supplied, what came back, what a person approved. They are written in the same terms the audit uses.
Traceability and quality control are not extras added for these environments. They follow directly from these four conditions.
Knowing whether it works
A claim that AI helps is only useful if it can be checked against something other than impressions.
We look at outcomes a reviewer can inspect: how often a change passes review on the first read, how often frozen tests catch a real defect before release, how many defects come back after release, how much rework follows. Each is compared against the same team’s own baseline for similar work, with the sample size stated.
The lines-of-code trap
Counting lines rewards volume. A model can generate a great deal of code very quickly, and every line is something to review, test, secure and maintain. A metric that rises when code is added will rise whether or not the software got better. Output measured in lines tells you how much was generated, not how much was delivered.
Other signals to treat with care
- Acceptance rate of suggestions: it shows habit, not correctness.
- Self-reported time saved: hard to verify.
- Coverage of tests generated from the code under test: it agrees with the code by construction.
Time and cost usually improve when rework falls. We report them last, and only from measured work.
Questions to ask before adopting AI in an enterprise environment
Useful for us and for any other supplier. If several answers are “unknown”, that is the first piece of work. Questions about deploying the tool itself (endpoint, model version, logs) are in the wiki (English).
- Where may source code and data be processed, and by whom?
- What can be installed, who approves it, and how long does approval take?
- Is there a network path to any external model, and is it permitted for this work?
- What must be recorded for audit, who reads the records, and how long are they kept?
- Who owns the specification, and is it independent of the people writing the code?
- How are tests approved, and can they be fixed before the code changes?
- Which changes need human sign-off, and what does the reviewer see?
- How will the result be reproduced later, by a different person, on a different machine?
- When the model’s output is wrong, who notices, how, and how late?
- How will success be measured, against which baseline, and which metrics are ruled out?
Working behind an enterprise AI gateway
Many organisations route all model access through a single gateway that handles keys, logging and limits. GZLighTek works within that model. We understand what comes with it: audit requirements, limits on provider features, and usage-based cost. We design the working process around those constraints instead of asking for them to be removed.
Read the technical note on gateways (English) →Command tables, configuration and CI checklists
A separate reference covers the CLI commands, configuration and pipeline checks for using an AI coding assistant in development. It is written for engineers who need to look something up.
Open the wiki (English) →Tell us about your environment
Describe the constraints you work under. We will say plainly whether this method fits, and how.