Our AI-Assisted Software Development Process

We use AI as a tool while we build software. Analysis, drafts and tests move faster. Every line that reaches the floor is reviewed and tested by a person. The responsibility stays with us.

This article explains where the tool enters the process, where it stays out, and how data is protected along the way. The principle text is on our AI-assisted development page.

Where it speeds the work up

In factory and enterprise integration work, the benefit sits in five places.

• Understanding old code. Tracing flows in an integration with little documentation, mapping dependencies and drafting a technical document. The draft becomes a document once a person corrects it.
• Reading device and service documents. Pulling the fields and message structures out of a long protocol or service text. The result does not enter the code until it is checked on the real device or in a test environment.
• Tests and sample data. Draft tests and synthetic data for edge cases such as a rejected notification, a missing field, a network drop and a resubmit. The reject and retry scenarios in our İTS notification article are an example. The notification rule itself is explicit code.
• Reading logs. Looking for a pattern in a large log and proposing a root-cause hypothesis. The hypothesis stays open until a person checks it against the record.
• A mapping draft. A first version of the transformation between ERP or WMS fields and an e-document or notification format. That first version does not go out until it has been reviewed.

How a mapping job actually runs

The boundary is easier to see on a concrete job. A shipping line in ERP has to become fields on an e-document.

1. A person marks the mandatory fields. The tool extracts a candidate list from the long text. The list is compared with the document line by line.
2. A mapping table is written: source field, target field, what happens if it is empty, and how the unit is converted.
3. The tool produces a first version of the transformation code from that table.
4. A person reads the code and tries it with a synthetic shipment. A missing identifier, a zero quantity and a resubmit are run on purpose.
5. Code that passes the tests goes to review. The review note and the test result are part of the delivery record.

Real shipments, real customers and real documents do not pass through the tool. The sample data is synthetic.

Where it stays out

Three limits come before speed.

• We do not send production data, serial numbers, or customer or patient information to an external AI service. Confidential data, personal data and access credentials do not go to the tools either. Where we need data, we use anonymized or synthetic data. The Turkish Personal Data Protection Authority's guide on generative AI treats processing in these systems under Law No. 6698. Its recommendations say that if the same result can be reached without processing personal data, anonymization should be preferred. That is the rule we apply.
• We do not put the tool's output straight into a validated system. The change goes through the company's change-management and validation process.
• The decision on the line is explicit code. Tolerance, reject and notification rules are written so they can be tested and traced. The tool can help draft those rules. It does not make the decision while the line is running.

We agree in writing, at the start of the project, which tools will be used. We use only tools that offer corporate privacy terms. If you ask, we turn AI off for the project entirely. That commitment is also written on our FAQ page.

Where it sits in the process

Our development process starts with a discovery conversation. We break the work into small deliveries and review working software together at regular intervals. The tool does not replace that rhythm. In discovery, you describe the need. We write the design decision, and you approve it. The tool produces drafts and tests while that decision is being built. What you see at delivery is software that has been reviewed and run.

The order is the same for old software with weak documentation. First a map of the flow, then tests, then a move in small steps. In modernization work we use the tool to speed up the map and the test draft. A person makes the decision to move, and a person puts it into service. Maintenance and support continues after go-live. There, too, the tool drafts log and impact analysis. A change is still not released until it has been reviewed.

What a review looks like

A review is not a stamp on the draft. The reviewer looks for three things. Does the code apply the rule in the mapping table as written? Does a failure leave a record, or does it pass silently? Did the test also try the value on the boundary? If all three are in place, the change enters the delivery. If not, the draft goes back. The tool may produce another draft. Nothing is released without a review note.

Whoever uses the tool, a person owns the delivery. The person who produced the draft and the person who reviews it may be the same. The review note is still written. A second pair of eyes comes in for a risky mapping, or on a validated line. What you see at the regular review is working software. A draft you have not seen does not go live. The review note, the test result and the release decision stay on the same record. Nothing is left that can later be split off as "the tool wrote this".

What actually gets faster

What the tool shortens is reading time and drafting time. Discovery, the decision, the review and the release stay where they are. The gain shows up as documentation arriving earlier, edge-case tests written up front, and a candidate cause in the log seen sooner. Each project starts with a different documentation and code debt, so we do not pin that gain to a single number of days. What we look at is reviewed code, and a test that can be run again, reaching you at the regular review.

The technology is chosen for the job. The tool does not make that choice. A tool in use today can be replaced by another later. What stays is the review, the tests, the data boundary and the transfer of the code to you. We settle that in writing at the start of the project.

Who owns the code

The source code and intellectual property of work that has been paid for are transferred to you. We write that condition into the contract. A draft the tool produced is part of that delivery. An unreviewed draft does not count as a delivery.

Frequently Asked Questions

Does AI write the code that reaches the floor?

It can produce a draft. Every line that reaches the floor is reviewed and tested by a person. The responsibility stays with us.

Does our data go to an AI tool?

Confidential data, personal data and access credentials do not. Production data, serial numbers, and customer and patient information are included in that. We agree the list of tools in writing at the start of the project.

Can AI make the decision on the line?

No. Tolerance, reject and notification rules are explicit code. The tool can help draft those rules. At runtime, the decision is in the code.

Who owns the source code?

The source code and intellectual property of work that has been paid for are transferred to you. The condition is written into the contract. The detail is on our FAQ page.

Facing a similar challenge? Tell us about your project and we'll get back to you within one business day.

All product and company names are trademarks of their respective owners; softhan is not an authorized representative or partner of these companies.