The origin. Posted by u/Plus_Major1553 to r/AI_Agents, spotted 14 September 2026.
What we know. The account of what was built, and how, comes directly from that post. We have not independently verified the two systems described.
A poster in r/AI_Agents describes a marketing job at a large company, no background in software engineering, and a habit of taking every problem straight to ChatGPT and AI coding tools. What came out the other end were two internal systems now running inside a real company. A finance and operations platform, and a facial verification system for employee attendance.
What actually got built
The first system is described as an "Enterprise Finance & Operations Platform" spanning multiple business units. According to the poster it includes finance and operations workflows, AI assisted document and text processing, switching between business units, drag and drop workflows, role based access control, cloud security, and desktop application functionality.
The second is a facial verification system built for employee attendance. The poster says it uses computer vision, APIs, microservices, and containerization, and that it processes an employee's photo to verify who they are.
None of this came from a computer science background. The poster is explicit that the process did not feel like "programming" in the way they understood the word. It was describing what they wanted to AI, getting code back, running it, pasting the errors back in when it broke, and repeating that loop until the thing worked.
The loop is the method, not the tools
Strip away the specific systems and what is left is a repeatable process. Describe the outcome, get a first attempt, run it, feed the failure back in, repeat. That loop does not require reading the code that comes out. It requires being precise about what "working" means, and being patient enough to run the cycle far more times than a first attempt suggests.
That is the part worth taking from this, more than the systems themselves. Most people with a real problem and no engineering background stop at the first answer because it does not fully work. The poster kept the loop running past the point where a first draft usually gets abandoned, long enough for a working internal tool to come out the other end.
Where the loop stops being enough
The risk in this story is not that someone without an engineering background wrote software. It is what that software touches. Role based access control, cloud security, and a system that stores and matches employee faces are not places where "it works when I test it" is the same as "it is safe to run." A describe, run, fix loop will happily produce something that passes every test you think to try and still mishandle sensitive data, grant access it should not, or fail quietly in a way nobody notices until it matters.
That does not make the approach wrong. It means the loop is good for building a first version, not for deciding whether that first version is safe to keep running.
Two things follow from that, and either one can start tomorrow. First, if you or someone on your team has a real, scoped problem and no developer to hand it to, use the same loop. Describe the outcome precisely, get a draft, run it, feed back what broke, repeat, and start with something reversible: a report, a form, an internal dashboard. Not anything that touches identity, payroll, or access control on day one. Second, if a system like this is already running in your business, built the same way, find the pieces that touch security, compliance, or personal data and get someone who did not build it to look at just those pieces. The rest of the system can keep working exactly as it does.
The honest version of this story is not that anyone can now build enterprise software. It is that describe, run, fix, repeat is a real method and it works, and the only judgment it does not replace is knowing which parts of what you just built need a second pair of eyes before they carry real weight.