DEV Community: Irvan Gerhana Septiyana

What Leaves When an Engineer Leaves

Irvan Gerhana Septiyana — Wed, 01 Jul 2026 13:04:29 +0000

Engineering Documentation Series — Article 1 of 50

Every team has some version of this story, so start with the composite.

A senior engineer gives two weeks' notice after six years. She designed the billing reconciliation system, chose its consistency model, negotiated the three exceptions that keep a large customer from churning, and decided — for a reason she could explain in thirty seconds — why a nightly job retries exactly four times and not three or five.

None of this is secret. All of it is in production, running, observable. The code compiles. The tests pass. The system works.

On her last Friday, the team takes her to lunch. On Monday, the billing system runs exactly as before. For three months, nothing breaks.

Then a regulatory change requires a modification to how partial refunds are reconciled. An engineer opens the module. The code is clear enough — he can read what it does. What he cannot recover is why it does it that way. Why four retries. Why that customer is special. Why the consistency model tolerates a window that, on paper, looks like a bug. He spends three weeks reconstructing reasoning that once lived, complete and confident, in a single person's mind. He gets most of it right. The part he gets wrong causes an incident the following quarter.

The instinct is to file this under "she should have written more documentation." That instinct is correct. The reason we usually give for it is wrong — and the wrongness is the subject of this article, and in a quieter way the subject of this entire series.

The industry has quietly agreed on the wrong definition

Ask a room of engineers what documentation is for, and the answers cluster around one theme: explaining. Documentation explains how to use the API. It explains how to set up the project. It explains what the function does. Under this definition, documentation is a communication tool — a translation of code into prose for someone who has not yet read the code.

This definition is so widespread it has become invisible. It shapes how teams budget time ("we'll document it after the feature ships"), how they measure quality ("is the README current?"), and how they assign ownership ("whoever wrote the code writes the docs"). It is the definition embedded in nearly every documentation tutorial, which is why nearly every tutorial teaches Markdown, headings, and tools — the mechanics of explaining — rather than the thing that actually matters.

The explaining definition is not wrong so much as it is small. It captures the least durable, least valuable function of documentation and mistakes it for the whole. The engineer who left did not fail to explain her code. Her code was perfectly explained — by itself. What she failed to preserve was something code can never contain.

What actually disappeared

Look again at what was lost. It was not knowledge of what the system does; that survived her departure intact, because it is encoded in the running system and recoverable by anyone willing to read it. What disappeared was the knowledge of why — the decisions, the rejected alternatives, the constraints that were live at the time, the context that made a strange-looking choice the correct one.

This distinction has a name. Knowledge that can be written down, transferred, and read is explicit knowledge. Knowledge that lives in a person's judgment and intuition — the kind you demonstrate but struggle to articulate — is tacit knowledge. The terms come from the philosopher Michael Polanyi, whose formulation, "we can know more than we can tell," predates software by decades and survives every change of technology since.

Here is the engineering reframing, and it is the first load-bearing claim of this article: source code is the explicit residue of a large body of tacit reasoning, and it preserves almost none of the reasoning. We have good evidence that this gap is where engineering effort actually goes. In a large-scale field study of professional developers across seven industrial projects, totaling more than 3,000 working hours, developers spent roughly 58% of their time not writing code but trying to comprehend existing code — and the single most common driver of the long, difficult comprehension sessions was insufficient or missing explanation of intent, present in 46% of them (Xia et al., IEEE Transactions on Software Engineering, 2018). The code was right there, readable, and still the reasoning had to be reconstructed. That reconstruction is the tax an organization pays when the why was never preserved.

The tax is not evenly distributed, either. In the same study, junior developers spent about 66% of their time on comprehension against 44% for seniors — which is to say the cost of missing knowledge falls heaviest on exactly the people who just arrived and have no one left to ask.

So documentation, properly understood, is not the act of explaining code. It is the act of capturing the tacit reasoning that code cannot hold, before the only copy walks out the door.

The root cause is a category error, not a discipline problem

It is tempting to explain missing documentation as a discipline failure — engineers are busy, writing is tedious, deadlines win. That explanation is comforting because it implies an easy fix: more discipline, better tooling, a documentation item in the Definition of Done. Teams have tried all of these for years. The knowledge keeps leaving anyway.

The deeper cause is that the explaining definition tells engineers to document the wrong things. If documentation exists to explain what code does, the natural thing to write is a description of what the code does — and that is precisely the information the code already provides and the system already enforces. Engineers correctly sense this kind of documentation is low-value, so they skip it, and they are not wrong to skip it. The tragedy is that in skipping the worthless documentation, they also skip the valuable kind, because the definition never distinguished between them.

The root cause, then, is a category error. We treat documentation as a writing problem — producing clear prose about code — when it is a knowledge problem: which knowledge an organization cannot afford to lose, and how to move it out of fragile human memory into a durable, shared form. Once the category is corrected, the discipline problem largely dissolves. Engineers are rarely reluctant to preserve knowledge they can see is irreplaceable. They are reluctant to transcribe knowledge the compiler already has.

The engineering principle: a single knowledge-holder is a single point of failure

Engineers already possess the principle they need. They simply apply it to servers and not to people.

No competent engineer designs a critical system to depend on a single machine with no redundancy. The reason is not that the machine is unreliable on any given day — it is that the consequence of its failure is unbounded and the failure is certain on a long enough timeline. We replicate and remove single points of failure not because we expect failure tomorrow, but because we refuse to let the system's survival depend on a component that will, eventually, fail.

A person who is the sole holder of critical knowledge is a single point of failure with a guaranteed eventual outage called resigning. And this is not a hypothetical risk — it is the measured norm. When researchers computed the "truck factor" of 133 popular GitHub projects — the minimum number of developers who would have to leave before the project is incapacitated — 65% had a truck factor of two or fewer, and about a third had a truck factor of one (Avelino et al., International Conference on Program Comprehension, 2016). Most real systems are one or two departures away from losing the people who understand them. A larger 2024 study of more than 36,000 open-source projects found that 89% lost their entire core team at least once, and only about 27% of those recovered (Nourry et al., 2024). Knowledge concentration is not an edge case. It is the default condition of software.

What makes this worse is that the risk is widely felt and rarely managed. In a survey of 269 professional engineers, 75% rated bus factor as a serious concern and 63% had worked on a high-risk, low-bus-factor project within the past year — yet only 19% worked somewhere the risk was actually tracked and communicated (JetBrains study, ICSE-SEIP, 2022). Engineers know the building has one exit. Almost no one has mapped it.

The principle generalizes beyond any technology: knowledge concentrated in a single holder is an architectural risk, and the mechanism for removing it is the same as for any single point of failure — replication into a durable, independent store. Documentation is that replication. Notably, when the truck-factor researchers asked developers how they would actually mitigate the risk, the single most-cited practice was not pairing, not tests, not "readable code" — it was documentation. The people closest to the problem name the same fix.

The mental model: documentation is organizational memory

If you take one idea from this article, take this one, because the remaining forty-nine articles lean on it.

A human mind has two kinds of memory. Working memory holds what you are thinking about right now; it is fast, rich, and almost entirely lost within seconds unless something transfers it. Long-term memory is slower to write and less vivid, but it persists — it is what lets you be, tomorrow, a continuation of who you were today rather than starting from nothing each morning.

An organization has the same two layers, and documentation is its long-term memory. The working memory of an organization is the live knowledge in the heads of its current engineers — vivid, detailed, and constantly overwritten and lost as people move and forget and leave. Without a mechanism to consolidate that working memory into something durable, an organization is amnesiac: it knows only what its current members happen to remember, and it forgets a little more with every departure. Documentation is the consolidation mechanism — how an organization's fleeting working memory becomes durable long-term memory that outlives the individuals who formed it.

The organizational-memory research bears this out as a measurable phenomenon rather than a metaphor. A systematic review of 91 empirical studies of knowledge loss from employee turnover found turnover to be among the most frequently reported causes of organizational knowledge loss, and found that tacit knowledge — the hard-to-write-down kind — causes disproportionately greater harm when it leaves (2023 systematic review of 91 empirical studies, 2000–2022). The reframing also changes who you are writing for. The true reader of documentation is not the colleague at the next desk who could have asked you in person. It is the engineer who has not yet joined the company — the one who will inherit this system after everyone who built it is gone.

This model survives any change of technology. It said nothing about Markdown, wikis, or repositories, because none of those are the point. The point is the transfer of fragile working memory into durable organizational memory, and that need will outlast every tool we currently use to satisfy it.

A framework for deciding what to preserve: the Preservation Matrix

The organizational-memory model tells you why to document. It does not yet tell you what — and "document everything" fails as surely as "document nothing," because when everything is preserved the irreplaceable knowledge drowns in the trivial.

Two properties decide whether any piece of knowledge is worth preserving. The first is its cost to re-derive: how much effort, time, and risk it would take to reconstruct from scratch if lost. The second is its probability of loss: how likely it is to leave the organization. Cross them and you get a simple decision tool — call it the Preservation Matrix:

                    LOW cost to re-derive        HIGH cost to re-derive
                  ┌────────────────────────────┬────────────────────────────┐
   HIGH           │  Skim / auto-generate      │  PRESERVE FIRST            │
   probability    │  (changelogs, obvious      │  the "why": decisions,     │
   of loss        │   how-tos — cheap to       │  rationale, constraints,   │
                  │   regenerate)              │  the four-retries reason   │
                  ├────────────────────────────┼────────────────────────────┤
   LOW            │  Ignore                    │  Preserve if you can       │
   probability    │  (the system already       │  (deep tacit expertise —   │
   of loss        │   enforces it; the code    │  expensive, but mentorship │
                  │   is the documentation)    │   may beat written docs)   │
                  └────────────────────────────┴────────────────────────────┘

The top-right quadrant is your organizational memory's most precious cargo: knowledge both expensive to re-derive and likely to be lost. That is, almost always, the knowledge of why — the decisions and their rationale, the alternatives considered and rejected, the constraints that were live at the time. The four-retries choice lives here. So does the consistency-model decision and the reason that one customer is special.

The bottom-left quadrant is its opposite: knowledge cheap to recover and unlikely to be lost — the description of what the code does, which the code already holds and the system already enforces. This is exactly the documentation the explaining definition tells us to write, and exactly the documentation that goes stale fastest and matters least.

The matrix collapses to a single question an engineer can ask in the moment: if the people who hold this knowledge left tomorrow, how expensive would it be to recover, and how likely is it that no one could? The knowledge that scores high on both is what you write down. The rest can wait, or be derived, or be left to the system.

What this looks like in practice

Made concrete, the matrix redirects effort away from the documentation most teams produce and toward the documentation almost no team produces.

Take the choice to use eventual consistency in the billing system rather than strong consistency. The explaining definition produces, at best, a description of how the eventually-consistent system behaves. The Preservation Matrix produces something more durable: a short record of the decision itself — the problem that forced it, the alternatives on the table, the constraints (latency budgets, throughput targets, the cost of distributed transactions) that ruled the alternatives out, and the assumptions the decision depends on, so a future engineer can recognize when those assumptions stop holding and the decision should be revisited.

That record is what the industry calls an Architecture Decision Record, and a later article is devoted to it. The mechanics are not the point here. The point is that the matrix tells you the ADR is worth writing and why — it is top-right knowledge — while the explaining definition cannot even see it, because no one is "explaining" anything. They are preserving a decision. The same lens applies to the four-retries choice: nothing to write under the explaining definition, one irreplaceable sentence to write under the matrix — the sentence the returning engineer spent three weeks failing to reconstruct.

The strongest objections, taken seriously

A skeptical senior engineer has real counterarguments, and an honest case has to meet them rather than pretend they don't exist.

"Good code is self-documenting — write readable code instead of prose." This is partly right, and the right part matters: a well-named function does make the what self-evident, which is exactly why the bottom-left quadrant of the matrix says don't bother documenting it. But even careful advocates of self-documenting code concede the limit. As one puts it, readable code "is a great goal, sometimes achievable, but it doesn't remove the need to comment your code" — because the why, the business rule, the non-obvious quirk, is precisely what clean naming cannot express. Self-documenting code wins the bottom-left quadrant and leaves the top-right untouched. The two positions are not actually in conflict; they are talking about different quadrants.

"Documentation always rots, so it's worse than useless — stale docs mislead." This is the most serious objection, and it is true for the wrong documentation. Documentation that restates what the code does rots fast, because the code changes underneath it; that is another reason the bottom-left quadrant is a trap. But decision rationale — why a choice was made, against which alternatives, under which constraints — does not rot the same way, because the historical fact of the decision doesn't change even when the code does. You can read a five-year-old ADR and it remains true about the moment it describes. The rot objection is an argument against preserving the what, which the matrix already tells you to skip. It is not an argument against preserving the why.

"AI will just generate the documentation now." Returned to below — but briefly: a model can generate a fluent description of what code does, which is the quadrant that was never the problem. It cannot recover a decision rationale that was never recorded anywhere, because that knowledge exists in no text for it to read. AI lowers the cost of the cheap quadrant and does nothing for the expensive one.

The honest synthesis is that the objections are mostly right about the documentation the matrix already tells you not to write, and mostly silent about the documentation it tells you to write.

The trade-offs are real

It would be dishonest to present knowledge preservation as free. Preserving knowledge costs time at the moment of writing, when the pressure to ship is highest and the value is least visible. Preserved knowledge can itself decay if a decision changes and its record is never updated. And some tacit expertise is so deeply tacit that any written form loses what mattered — the bottom-right quadrant of the matrix — and the time is better spent on mentorship or pairing.

These costs are why the matrix matters rather than a blanket "document more." A blanket instruction ignores the trade-offs and collapses under them; teams told to document everything learn the cost is real and the value diffuse, and they stop. The matrix concentrates the cost where the return is highest. The decision to not document something cheap-to-recover is not negligence — it is correct engineering, the same way declining to add redundancy to a non-critical component is correct.

So the recommendation is conditional, as engineering recommendations should be. Preserve aggressively when knowledge is expensive to re-derive and likely to be lost. Preserve sparingly, or not at all, when the system already holds and enforces it. The skill is not writing more. It is knowing which knowledge is irreplaceable.

Why prevention has to happen at the moment of the work

There is a reason the opening story ends in an incident rather than a near-miss, and it is a property of knowledge, not of that particular team. Knowledge decays in a way that hides the decay until the moment it is needed.

A system whose knowledge has left looks identical, from the outside, to a system whose knowledge is fully preserved. It runs the same and passes the same tests. The loss is invisible right up until someone needs the missing knowledge — and by then the people who held it are gone, the context is unrecoverable, and the cost of reconstruction has multiplied. This is the defining feature of the knowledge problem: the cheapest moment to preserve knowledge is exactly when it feels least necessary, and the moment it becomes obviously necessary is exactly when preservation has become impossible.

Prevention therefore has a specific shape. Knowledge must be captured while it is live — when the decision is being made and the context is still in the room. Captured then, it costs a sentence. Recovered later, it costs weeks, and the recovery is often wrong. The preventive practice is not "schedule a documentation sprint" — by the sprint, the knowledge has already decayed — but "capture decisions as they are made." The highest-leverage documentation habits in this series will all turn out to happen at the moment of the work, not after it.

This is an organizational property, not an individual virtue

It is easy to read all of this as advice to individual engineers: be the person who writes things down. That reading is not wrong, but it is incomplete, and the incompleteness matters.

Preservation only works if the organization treats it as infrastructure rather than personality. If it depends on which individuals happen to be conscientious, then the practice itself has a bus factor — it survives only as long as the diligent people stay, and collapses exactly when they leave, which is when it is needed most. And the payoff of getting this right shows up at the organizational level, not the individual one: DORA's State of DevOps research, the largest ongoing study of software delivery, has found a clear link between internal documentation quality and organizational performance, and found that documentation quality amplified the effectiveness of every technical capability it studied — teams with strong documentation saw dramatically larger performance gains from the same practices than teams with poor documentation (DORA, 2021–2022). Documentation, at the organizational scale, behaves less like a chore and more like a multiplier on everything else the engineering organization does.

This is the difference between an organization that knows things and one that remembers them. The first depends on its current members and forgets a little with every departure. The second accumulates knowledge over time, gets smarter as it ages, and treats the loss of any individual as survivable. Every later article in this series is, in some sense, about how to become the second kind of organization.

Where this is heading

This reframing is about to matter more than it has, for a reason that has nothing to do with human readers. Organizations are beginning to connect automated systems — including AI — to their own knowledge, asking machines to reason over what the organization knows. Those systems can only reason over knowledge that has been preserved in a durable, accessible form. They are blind to whatever still lives only in human heads.

This is the real answer to "AI will just write the docs." A model can generate a competent description of what code does — the cheap quadrant, which was never the problem. It cannot hand a new engineer, or a new agent, the reasoning behind a decision that was recorded nowhere, because that knowledge exists in no text it can read. An organization whose critical knowledge was never externalized cannot give that knowledge to a machine any more than it could give it to a new hire. The knowledge problem is the same problem, now with a second kind of reader that also cannot ask a colleague over lunch. The organizations whose memory is intact will find they have been preparing for this without knowing it. The rest will discover the problem they postponed has compounded.

What should change after reading this

If this article has done its work, one belief should feel different than it did a few minutes ago. Documentation was, at the start, a writing task — clear prose about code, done after the real work when time allowed. It should now look like something else: the mechanism by which an organization preserves the knowledge it cannot afford to lose, the long-term memory that lets it survive the departure of any individual mind.

A few things follow, worth carrying into the rest of the series and into your own work. The most valuable documentation captures why, not what, because the why is the knowledge both expensive to re-derive and certain to be lost — the top-right quadrant of the Preservation Matrix. The cheapest moment to preserve knowledge is while it is live, and that moment does not return. And the question that should become reflexive — the entire practice in miniature — is this: if the people who hold this knowledge left tomorrow, what would the organization be unable to recover?

The answer to that question is what you write down. Everything else in this series is an elaboration of how.

Next in the series — Article 2: The Six-Month Half-Life of a Wiki.

Sources and evidence notes

Per the editorial standard, confidence is flagged where it matters: peer-reviewed studies are treated as strongest; large-scale industry research (DORA) is strong but correlational; practitioner cases and estimates are labeled as such.

Program comprehension (peer-reviewed). Xia, Bao, Lo, Xing, Hassan, Li, "Measuring Program Comprehension: A Large-Scale Field Study with Professionals," IEEE Transactions on Software Engineering, 2018. ~58% of developer time on comprehension; missing/insufficient explanation the top driver of long comprehension sessions (46%); juniors 66% vs seniors 44%.
Truck/bus factor (peer-reviewed). Avelino, Passos, Hora, Valente, "A Novel Approach for Estimating Truck Factors," ICPC 2016. 133 GitHub systems; 65% truck factor ≤ 2; ~34% = 1; developers ranked documentation the #1 mitigation. Nourry et al., 2024 — 36,000+ projects; 89% lost their core team at least once, ~27% recovered.
Bus factor as a felt-but-untracked risk (peer-reviewed). JetBrains study, ICSE-SEIP 2022. 269 engineers; 75% rate it important, 63% recently on a high-risk project, only 19% where it was tracked.
Knowledge loss from turnover (peer-reviewed systematic review). Synthesis of 91 empirical studies (2000–2022): turnover a leading cause of organizational knowledge loss; tacit knowledge disproportionately harmful when lost.
Documentation ↔ organizational performance (industry research, correlational). DORA / Accelerate State of DevOps, 2021–2022. Clear link between documentation quality and organizational performance; documentation quality amplified the impact of every technical capability studied. Strong but survey-based and correlational, not a controlled experiment.
Real-world cost cases (secondary / illustrative). David DeLong, Lost Knowledge, and related reporting: Boeing's veteran-knowledge loss contributing to a multi-week 737/747 line shutdown and a $1.6B charge; a single veteran engineer's retirement projected at >$400K first-year disruption. Use as illustration, not as precise engineering metrics.
Onboarding time (practitioner estimate). Developer-experience practitioners report new hires taking 2–3 months longer to reach productivity under poor documentation, and 3–10 hours/week lost to searching for undocumented information. Directionally consistent with the peer-reviewed comprehension data; treat the specific figures as estimates.
Tacit vs. explicit knowledge (foundational). Michael Polanyi, The Tacit Dimension (1966): "we can know more than we can tell."
Dissenting view (practitioner). Self-documenting-code advocates concede readable code "doesn't remove the need to comment" the why; documentation-rot critics correctly note that stale descriptive docs can mislead — both addressed directly in the objections section.

The Rise Of AI Systems Engineering

Irvan Gerhana Septiyana — Thu, 25 Jun 2026 04:49:00 +0000

I no longer think "AI Engineer" fully describes where this profession is heading.

That title made sense when the primary challenge was integrating language models into applications.

Today, the challenges look very different.

The difficult questions are no longer:

Which model should we use?

How many parameters does it have?

What's the benchmark score?

Instead, they're becoming:

How do we govern AI?

How do we evaluate AI?

How do we secure AI?

How do we integrate AI into existing business processes?

How do we ensure automated decisions remain explainable?

How do we prevent organizational knowledge from disappearing?

Those aren't model questions.

They're systems questions.

And systems require engineers.

Engineering Is Moving Up The Stack

One phrase has stayed with me throughout this transition.

AI writes implementations.

Engineers design systems.

That doesn't mean engineers stop writing code.

Far from it.

Code remains one of the most powerful tools we have.

But it is increasingly becoming the medium through which decisions are expressed—not the primary source of value itself.

The value lies in knowing what should be built, why it should be built, and how it should evolve.

AI accelerates implementation.

It doesn't replace intentional design.

What This Means For Junior Engineers

One concern I hear frequently is that AI will remove the learning opportunities that junior developers once relied on.

I think that's a valid concern.

Many experienced engineers developed their intuition by repeatedly implementing similar systems.

Those repetitions mattered.

They created pattern recognition.

They created judgment.

They created experience.

AI changes that pathway.

The repetitive work is disappearing.

That doesn't mean learning disappears.

It means organizations need to become much more intentional about how engineers develop judgment.

Future engineers will likely learn through:

Reviewing AI-generated implementations.

Comparing architectural alternatives.

Investigating production incidents.

Participating in design reviews.

Understanding business domains.

Learning how experienced engineers reason—not simply how they type.

Experience becomes less about repetition.

More about exposure to meaningful decisions.

That shift won't happen automatically.

Engineering organizations will have to design for it.

What Senior Engineers Should Learn

Seniority has traditionally been associated with technical expertise.

That won't disappear.

But another capability is becoming increasingly valuable.

The ability to organize complexity.

The best engineers I've worked with rarely impressed me because they wrote elegant algorithms.

They impressed me because they reduced uncertainty.

They made difficult decisions easier.

They simplified architectures.

They documented knowledge.

They aligned teams.

They transformed ambiguity into clarity.

Those capabilities become dramatically more valuable when AI handles much of the implementation.

The Future Isn't About Writing Less Code

Ironically, I don't think the future is about writing less software.

I think humanity will produce more software than at any other point in history.

The difference is who—or what—writes the first draft.

Engineers will increasingly become:

System designers.

Architecture reviewers.

Context engineers.

Knowledge curators.

Evaluation specialists.

Governance designers.

Security reviewers.

Implementation remains important.

But implementation alone is no longer sufficient.

A Prediction

Every major shift in software engineering has changed what engineers spend their time doing.

Assembly gave way to higher-level languages.

Manual deployment gave way to cloud infrastructure.

Infrastructure gave way to platforms.

Now implementation is giving way to orchestration.

Five years from now, I suspect many engineers will look back and realize they spend surprisingly little time manually writing code.

Not because software became less important.

Because understanding became more valuable.

Final Thoughts

If someone asked me today what software engineering means, my answer would be very different from what it would have been five years ago.

Software engineering is no longer just the discipline of writing programs.

It is the discipline of transforming human knowledge into reliable systems.

Artificial Intelligence hasn't diminished that responsibility.

It has amplified it.

Because when implementation becomes inexpensive, every decision made before implementation becomes exponentially more important.

That is why I spend less time writing code than ever before.

Yet I have never felt more like an engineer.

Continue Learning

Over the past year, I've been documenting this shift while building production-grade Enterprise AI systems—from canonical data architecture and business taxonomies to financial NER, entity resolution, evaluation pipelines, and automated reconciliation.

One lesson became clear throughout that journey:

Building reliable AI systems has far less to do with choosing the "best" model than with designing systems that organizations can trust.

Those ideas became the foundation of the Enterprise AI Automation Blueprint.

Inside, you'll find:

Enterprise AI Architecture
Canonical Data Modeling
Business Taxonomy Design
Synthetic Enterprise Dataset Engineering
Financial Named Entity Recognition (NER)
Entity Resolution
Decision Intelligence
Automated Reconciliation
FastAPI Production APIs
Evaluation & Benchmarking
Production-ready Python Source Code

The goal isn't to teach another AI framework.

It's to explore how AI integrates into real software systems—where architecture, governance, business context, and engineering discipline matter just as much as the model itself.

If that aligns with the kind of engineering you're interested in, you can explore the complete blueprint here:

📘 Enterprise AI Automation Blueprint

https://uigerhana.gumroad.com/l/enterprise-ai-automation-blueprint

I'm also publishing an ongoing series on Dev.to covering Enterprise AI, Software Architecture, AI Governance, Cybersecurity, and Production Engineering.

If these ideas resonate with you, I'd love to continue the conversation.

Because I believe the next generation of software engineers won't simply write better code.

They'll build better systems.

Engineering Judgment Is Becoming The Scarcest Resource

Irvan Gerhana Septiyana — Thu, 25 Jun 2026 04:48:00 +0000

If implementation is becoming cheaper, what becomes expensive?

Judgment.

Not intuition.

Not opinions.

Engineering judgment.

The ability to make decisions under uncertainty.

This has always been one of the defining characteristics of experienced engineers.

The difference is that AI has made it much more visible.

Judgment Cannot Be Generated

Suppose two engineers receive exactly the same feature request.

"Build an API to automate invoice reconciliation."

An AI assistant can generate a functional implementation for both of them.

The syntax will probably be similar.

The framework might even be identical.

Yet the final systems could look completely different.

One engineer might produce a tightly coupled service that works today but becomes increasingly difficult to maintain.

Another might separate business rules, entity resolution, reconciliation logic, and orchestration into independent components designed to evolve over time.

The code generator didn't make that decision.

The engineer did.

This is why architecture still matters.

The implementation is no longer the differentiator.

The decisions behind the implementation are.

AI Doesn't Replace Complexity

It Changes Where Complexity Lives

One misconception surrounding AI-assisted development is that complexity somehow disappears.

It doesn't.

Complexity simply migrates.

Years ago, much of our effort was spent translating ideas into code.

Today, AI performs much of that translation.

The difficult work now happens before implementation begins.

Questions like:

What problem are we actually solving?
Which data should become the source of truth?
Where should business rules live?
What assumptions are safe?
How do we measure success?
How do we evaluate failures?
Which decisions should remain deterministic?

These questions cannot be answered through autocomplete.

They require context.

Building Software Has Become An Information Problem

One of the biggest lessons I learned while building enterprise AI systems is that software development increasingly resembles information engineering.

The implementation itself is rarely the bottleneck.

Information is.

Missing requirements.

Incomplete documentation.

Conflicting business rules.

Undefined ownership.

Legacy processes.

Historical decisions that nobody remembers making.

These become the limiting factors.

The engineer who can organize information effectively often creates more value than the engineer who simply writes code faster.

The New Daily Workflow

Several years ago, a typical development cycle looked something like this:

Requirement
      ↓
Design
      ↓
Write Code
      ↓
Debug
      ↓
Deploy

Today, my workflow feels very different.

Business Problem
        ↓
Context Collection
        ↓
Architecture Design
        ↓
AI Implementation
        ↓
Human Review
        ↓
Security Validation
        ↓
Evaluation
        ↓
Production

Notice what changed.

Writing code is still there.

It simply occupies a much smaller percentage of the overall process.

The surrounding engineering activities have become far more important.

My Most Valuable Hours Aren't Spent Coding

This realization surprised me.

When I review my own work over the past year, the highest-impact decisions rarely happened inside an IDE.

They happened while answering questions such as:

Should this become a separate service?

Should this data be canonical?

Can this decision be audited?

What happens if this AI prediction is wrong?

How should confidence scores influence downstream automation?

Can this architecture evolve without rewriting everything?

These conversations created far more business value than writing another API endpoint.

Ironically, AI made that possible by reducing the amount of repetitive implementation work.

Enterprise AI Changed My Perspective

When people hear "AI Engineering," many immediately think about:

Prompt engineering.

Fine-tuning.

Model selection.

Inference speed.

Those topics matter.

But after working on enterprise automation projects, I realized they represent only one layer of the system.

The real engineering challenges appeared elsewhere.

How do we model business knowledge?

How do we define entities consistently?

How do we resolve ambiguity?

How do we measure correctness?

How do we explain automated decisions?

How do we maintain trust over time?

Those questions are architectural.

Not algorithmic.

Systems Age Differently Than Models

Large language models improve every few months.

Software architectures often remain in production for years.

Sometimes decades.

That creates an interesting asymmetry.

A model can be replaced.

A poorly designed architecture becomes increasingly expensive.

This is why long-term thinking matters more than ever.

The organizations creating durable AI systems aren't simply adopting better models.

They're building architectures capable of surviving multiple generations of models.

In other words, they're optimizing for adaptability rather than novelty.

AI Is Raising The Abstraction Level

Programming has always evolved through abstraction.

Assembly became C.

C became Java.

Manual infrastructure became cloud platforms.

Virtual machines became containers.

Containers became serverless.

Each shift removed a layer of operational complexity.

AI represents another abstraction layer.

Instead of writing every implementation manually, engineers increasingly describe intent.

The machine generates implementation.

Humans validate outcomes.

This doesn't reduce the need for engineering.

It changes where engineering happens.

Higher abstractions demand stronger reasoning.

Not weaker.

The Best Engineers Are Becoming Multipliers

One pattern continues to emerge across high-performing engineering teams.

The strongest engineers aren't necessarily the fastest programmers.

They're the people who improve everyone else's ability to build software.

They define architectures.

Standardize data.

Create reusable systems.

Document decisions.

Design evaluation frameworks.

Reduce ambiguity.

AI amplifies those contributions.

A well-designed system allows dozens of developers—and dozens of AI agents—to work consistently.

A poorly designed system simply accelerates inconsistency.

That may become one of the defining characteristics of engineering in the AI era.

The engineer who creates clarity will create leverage.

I Spend Less Time Writing Code Than Ever Before.

Irvan Gerhana Septiyana — Thu, 25 Jun 2026 04:46:30 +0000

Yet I'm Building More Software Than Ever.

Artificial Intelligence didn't reduce the amount of engineering I do.

It changed what engineering looks like.

Introduction

Five years ago, I measured my productivity the same way many software engineers did.

How many pull requests did I merge?

How many features did I finish?

How many lines of code did I write?

How many bugs did I fix?

The assumption seemed obvious.

Writing more code meant creating more value.

Looking back, I don't think that assumption was ever completely true.

It was simply the easiest thing to measure.

Today, my workday looks completely different.

I spend significantly less time writing implementations.

Instead, I spend most of my time reviewing AI-generated code, designing architectures, defining business rules, modeling data, validating assumptions, creating evaluation pipelines, and thinking about how systems should evolve over the next several years.

Ironically...

I'm shipping more software than ever before.

That observation completely changed how I think about software engineering in the age of AI.

The Industry Is Measuring The Wrong Thing

Whenever a new coding model is released, the conversation almost always follows the same pattern.

Can it solve LeetCode?

Can it build a CRUD application?

Can it generate a React frontend?

Can it create a REST API?

Can it write unit tests?

These are interesting benchmarks.

They're also increasingly irrelevant.

Because production software has never been limited by typing speed.

The bottleneck has always been something much harder.

Understanding.

Understanding users.

Understanding businesses.

Understanding systems.

Understanding trade-offs.

Those are the activities that determine whether software survives long after the demo.

Software Engineering Has Always Been About Decisions

One misconception I frequently see is the idea that software engineering is fundamentally the act of writing code.

Code is important.

But code is the output.

Engineering is the decision-making process that produces that output.

Every production system is the result of thousands of decisions.

Should this service own the data?

Where should validation happen?

How do we recover from failures?

Who owns this business rule?

How should permissions evolve?

How do we audit automated decisions?

These questions exist long before the first function is written.

AI has become remarkably good at generating implementations.

It has not eliminated the need to answer those questions.

If anything, it has made them more important.

The Economics Of Software Development Have Changed

Economists often describe technological progress as reducing the cost of production.

The same principle applies to software engineering.

For decades, writing software was expensive.

Developers spent countless hours implementing boilerplate code.

Authentication.

Validation.

Database models.

Configuration.

Documentation.

Infrastructure.

Much of that work can now be generated in minutes.

The cost of implementation has fallen dramatically.

Whenever the cost of one activity decreases, another activity becomes relatively more valuable.

In software engineering, that activity is judgment.

AI Didn't Eliminate Engineering

It Eliminated Friction

This distinction is incredibly important.

Many headlines suggest that AI is replacing software engineers.

I think something much more interesting is happening.

AI is replacing friction.

The repetitive friction of implementation.

Generating another API endpoint.

Writing another serializer.

Creating another migration.

Formatting another configuration file.

These tasks still matter.

But they no longer dominate the engineering process.

The result is that engineers can spend more time solving problems rather than translating solutions into syntax.

That shift is subtle.

It is also profound.

A Personal Observation

Over the past several months, I have been building a Transaction Intelligence System designed for enterprise financial automation.

Initially, I assumed that the AI model would be the most difficult part of the project.

I was wrong.

Training the Named Entity Recognition model was relatively straightforward.

The difficult work happened before training ever began.

Designing canonical data structures.

Creating synthetic enterprise datasets.

Defining business taxonomies.

Building entity resolution pipelines.

Designing evaluation frameworks.

Understanding reconciliation workflows.

Those tasks consumed far more time than writing Python.

Interestingly, AI accelerated almost every implementation step.

It never removed the need to understand the business.

That realization fundamentally changed how I use AI.

Instead of asking:

"Can AI write this code?"

I began asking:

"What problem should this system actually solve?"

The second question consistently produced better software.

The New Bottleneck

Today, generating software is relatively inexpensive.

Understanding complexity is not.

When an engineer receives a feature request, the challenge is rarely implementing it.

The challenge is interpreting everything that wasn't written down.

Hidden business rules.

Historical decisions.

Regulatory constraints.

Security requirements.

Data ownership.

Failure scenarios.

These forms of organizational knowledge rarely exist inside documentation.

They exist inside conversations, experience, and institutional memory.

No language model can infer knowledge that has never been explicitly represented.

That means the engineer's role is shifting.

Not away from software.

Toward understanding.

Architecture Has Become A Multiplier

One insight continues to surprise me.

AI rewards good architecture.

It doesn't replace it.

When systems have:

clear ownership
consistent domain models
explicit business rules
modular services
reliable interfaces

AI becomes dramatically more productive.

When those foundations are missing, AI simply generates complexity faster.

This is why architecture is becoming more—not less—valuable.

AI amplifies the quality of the system it operates within.

It doesn't compensate for its absence.

The Shift I Didn't Expect

When I first started using AI coding assistants, I thought they would help me write code faster.

They did.

But that wasn't the biggest change.

The biggest change was where my attention moved.

Less time typing.

More time reviewing.

Less time implementing.

More time designing.

Less time debugging syntax.

More time validating assumptions.

Less time memorizing APIs.

More time understanding organizations.

I didn't stop engineering.

I simply started engineering at a higher level of abstraction.

And I suspect this is where the profession is heading.

The AI Model Isn't Your Competitive Advantage.

Irvan Gerhana Septiyana — Thu, 25 Jun 2026 02:24:02 +0000

Your Governance Model Is.

Every time a new AI model is released, the same conversation happens.

Is it smarter?

Is it faster?

Is it cheaper?

Can it write better code?

Can it reason better?

The industry has become obsessed with comparing models.

But after spending the last year building enterprise AI systems, I've started believing we're optimizing the wrong thing.

The companies creating the most value with AI aren't necessarily using the best model.

They're building the best systems around the model.

That's governance.

The Model Is Becoming A Commodity

Not long ago, choosing an AI model was one of the biggest technical decisions a company could make.

Today that decision is becoming much easier.

OpenAI.

Anthropic.

Google.

Meta.

Mistral.

Qwen.

DeepSeek.

Every few months another excellent model appears.

Performance gaps continue to shrink.

Eventually every engineering team will have access to highly capable models.

When everyone has similar intelligence...

Something else becomes the differentiator.

Enterprise AI Doesn't Fail Because Of The Model

I've seen AI projects fail for reasons that had nothing to do with machine learning.

Nobody knew:

Who owned the prompts.

Who approved changes.

Where the business rules lived.

Which datasets were trusted.

How outputs were validated.

How decisions were audited.

The AI generated excellent answers.

The organization simply couldn't trust them.

Intelligence Without Governance Creates Chaos

Imagine an AI agent capable of approving invoices.

The model performs brilliantly.

Accuracy is above 95%.

Now ask a different question.

Who approved the prompt?

Who can modify the workflow?

Can every decision be audited?

Can outputs be reproduced?

What happens when regulations change?

Who owns the responsibility if the AI makes an incorrect financial decision?

Suddenly the discussion isn't about AI anymore.

It's about governance.

Governance Is The Operating System

I've started thinking about AI governance as the operating system surrounding intelligence.

The language model is only one application running inside that environment.

Without governance, even brilliant models become difficult to trust.

Good governance defines:

Who can access information.

Who owns decisions.

How knowledge evolves.

How policies are enforced.

How systems remain explainable.

The smarter the AI becomes, the more valuable governance becomes.

Context Beats Capability

Many organizations assume stronger models automatically produce better business outcomes.

In practice, I've found the opposite is often true.

A slightly less capable model operating inside:

high-quality data
clear ownership
business taxonomies
evaluation pipelines
strong security controls
deterministic business rules

often outperforms a more advanced model operating inside organizational chaos.

The difference isn't intelligence.

It's context.

Governance Is More Than Compliance

The word "governance" often sounds bureaucratic.

Documentation.

Approvals.

Policies.

Compliance.

But modern AI governance is much broader.

It's about making intelligence reliable.

Good governance answers questions like:

Where did this answer come from?

Can we reproduce it?

Which knowledge sources were used?

Can we explain this decision?

Can we measure quality?

Can we improve safely?

Those aren't legal questions.

They're engineering questions.

Security Is Governance

One realization surprised me while working on production AI systems.

Security isn't separate from governance.

It's part of governance.

Authentication.

Authorization.

Audit trails.

Secret management.

Role-based access control.

Data lineage.

Approval workflows.

They're all mechanisms that determine whether intelligence can safely operate inside an organization.

The AI model isn't responsible for these things.

The surrounding system is.

Architecture Is Governance

The same realization applies to architecture.

Canonical data models.

Business taxonomies.

Entity resolution.

Decision engines.

Evaluation frameworks.

These aren't isolated engineering concepts.

They're governance mechanisms.

They create consistency.

Consistency creates trust.

Trust enables automation.

Automation creates business value.

AI Teams Need New Roles

As enterprise AI matures, I think we'll see new engineering responsibilities emerge.

Not just:

Machine Learning Engineer.

Prompt Engineer.

AI Engineer.

But also:

AI Platform Engineer.

AI Governance Engineer.

AI Systems Architect.

Evaluation Engineer.

Decision Intelligence Engineer.

Because the difficult problems are moving away from model training.

They're moving toward system design.

My Biggest Lesson

The biggest improvements I've seen in AI projects rarely came from changing models.

They came from changing everything around the model.

Better data.

Better ownership.

Better evaluation.

Better architecture.

Better governance.

The language model stayed exactly the same.

The business outcomes improved dramatically.

The Next Competitive Advantage

Every company will eventually have access to powerful AI.

That won't be rare.

What will be rare is organizational maturity.

Companies that understand:

how data flows,

how decisions are made,

how knowledge is managed,

how security is enforced,

and how governance evolves,

will consistently outperform organizations chasing the latest model release.

The future of AI won't belong to companies with the smartest models.

It will belong to companies with the smartest systems.

Final Thoughts

For the past few years, the AI industry has focused almost entirely on intelligence.

The next decade will be about infrastructure.

Governance.

Architecture.

Evaluation.

Security.

Compliance.

Knowledge.

Those are the foundations that transform impressive demos into trusted enterprise systems.

Maybe the real breakthrough isn't GPT-6.

Maybe it's finally realizing that intelligence is only one layer of the architecture.

The system around it is what creates lasting business value.

Continue Learning

Many of the ideas in this article came from building a production-grade Transaction Intelligence System for enterprise financial automation.

While documenting the project, I realized that successful AI systems depend on much more than model performance.

They require architecture, governance, business context, and engineering discipline.

That's why I created the Enterprise AI Automation Blueprint—a practical resource for developers and architects who want to build production-ready AI systems rather than one-off prototypes.

Inside you'll find:

Enterprise AI Architecture
Canonical Data Modeling
Business Taxonomy Design
Financial Named Entity Recognition (NER)
Entity Resolution
Decision Intelligence
Automated Reconciliation
FastAPI Production APIs
Evaluation & Benchmarking
Production-ready Python Source Code
Synthetic Enterprise Datasets

If you're interested in building AI systems that organizations can actually trust in production, you can explore the complete blueprint here:

📘 Enterprise AI Automation Blueprint

👉 https://uigerhana.gumroad.com/l/enterprise-ai-automation-blueprint

I'm also publishing an ongoing Dev.to series covering Enterprise AI, Software Architecture, AI Governance, Cybersecurity, and Production Engineering.

If you're building AI beyond demos, I'd love to connect.

Happy building.

AI Didn't Replace Junior Developers.

Irvan Gerhana Septiyana — Thu, 25 Jun 2026 01:48:07 +0000

It Replaced Junior Tasks.

Over the last year, one headline has appeared over and over again.

"AI will replace junior developers."

Every time a new coding model is released, someone predicts the end of entry-level software engineering.

Cursor.

Claude Code.

GitHub Copilot.

Codex.

Windsurf.

The conclusion always seems to be the same.

"Why hire a junior developer when AI can write code?"

At first, that argument sounds convincing.

Until you spend a few months building software with AI every single day.

Then something interesting happens.

You realize AI isn't replacing junior developers.

It's replacing junior tasks.

Those are very different things.

Writing Code Was Never The Job

Many people assume software engineering is primarily about writing code.

That's understandable.

Code is the most visible part of the profession.

It's what appears on GitHub.

It's what fills pull requests.

It's what AI generates.

But software engineering has always been much larger than syntax.

Good engineers spend far more time thinking than typing.

They ask questions.

They clarify requirements.

They understand trade-offs.

They design systems.

Code is simply the artifact that emerges from those decisions.

AI Is Extremely Good At Repetition

Ask an AI assistant to generate:

CRUD APIs
Database models
Dockerfiles
React components
Unit tests
Documentation

You'll probably get something useful.

Those are repetitive engineering tasks.

They're valuable.

But they aren't the whole profession.

Writing another controller isn't what makes someone a great engineer.

Understanding why that controller exists does.

Junior Tasks Are Becoming Automated

Think about how many early-career engineering tasks are repetitive by nature.

Creating REST endpoints.

Writing serializers.

Generating validation schemas.

Converting SQL into ORM models.

Building boilerplate.

Formatting code.

Generating tests.

These activities consume a significant amount of time.

AI dramatically reduces that effort.

That's good news.

Developers now spend less time fighting syntax.

And more time solving problems.

The Work Doesn't Disappear

It Moves

Whenever technology automates one layer of work, another layer becomes more valuable.

We saw this with cloud computing.

We saw it with CI/CD.

We saw it with containerization.

AI follows the same pattern.

As implementation becomes cheaper...

Understanding becomes more expensive.

Understanding Is Becoming The New Competitive Advantage

Imagine two developers.

Developer A can generate an API in thirty seconds.

Developer B can explain:

where the business rules belong
how authorization should work
why a service boundary exists
how failures should be recovered
what happens when requirements change

Who creates more long-term value?

The answer has very little to do with typing speed.

AI Doesn't Understand Your Business

One lesson became obvious while working on enterprise automation projects.

AI understands programming surprisingly well.

It understands Python.

Go.

TypeScript.

FastAPI.

React.

SQL.

What it doesn't understand is your organization.

It doesn't know:

why invoices are processed differently after approval
why one customer receives special payment terms
why an old workflow still exists
why finance rejects certain transactions

Those decisions belong to the business.

Someone still has to model them.

Experience Isn't About Memorization

Historically, junior developers learned by implementing repetitive features.

That pathway is changing.

Future engineers will probably spend less time memorizing syntax.

And more time learning:

systems thinking
architecture
domain modeling
communication
security
reliability
business context

Ironically, AI may accelerate professional growth by removing repetitive work earlier.

The Skill Nobody Talks About

One skill has quietly become incredibly valuable.

Asking better questions.

AI responds to prompts.

Engineering responds to problems.

The quality of the solution often depends on the quality of the question.

That has always been true.

AI simply makes it more obvious.

My Workflow Looks Completely Different

I still write code every day.

But I spend much less time writing boilerplate.

Instead I spend more time thinking about:

How should data flow?

What belongs inside the domain model?

Which service owns this responsibility?

How do we benchmark success?

How do we explain decisions?

Ironically...

I probably write fewer lines of code today.

Yet I feel like I'm solving much bigger problems.

The Future Software Engineer

The next generation of engineers won't compete with AI.

They'll collaborate with it.

The differentiator won't be typing speed.

It won't be remembering obscure language syntax.

It will be the ability to transform ambiguous business problems into reliable software systems.

That's a fundamentally different skill.

And one I believe will become increasingly valuable over the next decade.

Final Thoughts

AI isn't making software engineering less important.

It's changing what software engineering means.

The industry is moving away from measuring output.

And toward measuring judgment.

The best engineers won't necessarily be the ones who write the most code.

They'll be the ones who make the best decisions before any code is written.

Maybe AI didn't replace junior developers.

Maybe it simply gave them the opportunity to become senior engineers much faster.

The challenge is deciding what to learn next.

Continue Learning

Over the past several months, I've been documenting how these ideas apply in real enterprise systems.

Instead of focusing on AI demos or prompt tricks, I built and documented a complete Enterprise AI Transaction Intelligence System—covering the architecture, data models, automation pipelines, and engineering practices behind production-ready AI.

Inside the Enterprise AI Automation Blueprint, you'll find:

Enterprise AI Architecture
Canonical Data Modeling
Synthetic Enterprise Dataset Engineering
Financial NER
Entity Resolution
Business Rule Engines
Automated Reconciliation
FastAPI Production APIs
End-to-End Evaluation Framework
Production-ready Python Source Code

If you're interested in building AI systems that solve real business problems—not just generate code—you can learn more here:

📘 Enterprise AI Automation Blueprint

👉 https://uigerhana.gumroad.com/l/enterprise-ai-automation-blueprint

I'm also publishing an ongoing Dev.to series on Enterprise AI Engineering, Software Architecture, AI Automation, and Production Systems.

If you're building the future of software with AI, I'd love to have you along for the journey.

Happy building. 🚀

AI Engineers Are Becoming Security Engineers.

Irvan Gerhana Septiyana — Thu, 25 Jun 2026 01:46:59 +0000

Most Just Don't Realize It Yet.

A few years ago, building software and securing software felt like two different jobs.

Software engineers shipped features.

Security engineers found vulnerabilities.

Everyone had their own responsibility.

Today, AI is quietly changing that relationship.

Every time you ask an AI assistant to generate production code, you're making security decisions—even if you don't realize it.

That's why I believe AI engineers are slowly becoming security engineers.

Whether they're prepared for it or not.

AI Doesn't Just Write Code

It Writes Trust

Modern AI coding assistants can generate an incredible amount of software in minutes.

Authentication.

REST APIs.

Dockerfiles.

Terraform.

GitHub Actions.

Database schemas.

Entire backend services.

The speed is genuinely transformative.

But every generated line of code carries an assumption.

Should this endpoint require authentication?

Should this object be serialized?

Should this field be encrypted?

Should this request be logged?

Should this API expose detailed error messages?

These aren't programming questions.

They're security questions.

The Faster We Build

The Faster We Can Introduce Risk

One thing I've noticed while working with AI-assisted development is that implementation has become dramatically faster.

Architecture hasn't.

Threat modeling hasn't.

Security reviews haven't.

Governance hasn't.

As a result, many teams accidentally compress implementation while leaving security processes unchanged.

That creates a dangerous imbalance.

Code arrives faster than organizations can confidently review it.

AI Doesn't Understand Your Threat Model

Large language models understand common programming patterns remarkably well.

They know how to build authentication.

They know how to create APIs.

They know how to connect databases.

What they don't know is:

your regulatory requirements
your internal policies
your security architecture
your compliance obligations
your acceptable risk level

Every company has a different threat model.

AI can't infer that context unless engineers explicitly provide it.

Every Prompt Is A Design Decision

Imagine asking an AI assistant:

Build a file upload service.

Most developers immediately focus on functionality.

Will it upload files?

Will it store them?

Will it return URLs?

Security engineers hear a different question.

What file types are allowed?

How large can uploads be?

Can malware be uploaded?

Where are files stored?

Can uploaded files execute?

Who owns access permissions?

Can attackers overwrite existing objects?

The prompt didn't mention any of those concerns.

That doesn't mean they disappear.

Vibe Coding Changes The Attack Surface

One of the most interesting consequences of AI-assisted development is that software can now grow much faster than organizations expect.

More endpoints.

More services.

More integrations.

More APIs.

More infrastructure.

Every new component increases the attack surface.

The AI didn't create that attack surface.

It simply accelerated how quickly it appeared.

Security Is Becoming An Engineering Skill

Historically, developers could rely on dedicated security teams for reviews.

That model is changing.

Modern engineering teams are expected to think about security much earlier.

Infrastructure as Code.

DevSecOps.

Shift Left Security.

Secure by Design.

AI is accelerating that transition.

The earlier code is generated, the earlier security must be considered.

AI Should Review AI

One habit dramatically improved my workflow.

Instead of accepting generated code immediately, I started asking a second question.

Review this implementation as if you were performing a professional penetration test.

Or:

Identify every possible security weakness before this reaches production.

The results were fascinating.

The AI frequently identified concerns that never appeared during generation.

Not because the model became smarter.

Because the prompt changed the objective.

Generation and review are different tasks.

Both deserve equal attention.

Production Is More Than Functionality

Working software proves that code executes.

Secure software proves that systems survive.

Attackers don't care how elegant your architecture is.

They care about assumptions.

Every missing authorization check.

Every exposed secret.

Every forgotten validation rule.

Every overly permissive policy.

Production systems are rarely compromised because of spectacular mistakes.

They're compromised because of ordinary ones.

The Future Engineer

I don't believe AI will eliminate software engineering.

I think it will redefine it.

Future engineers won't simply write code.

They'll design systems.

Review risks.

Model threats.

Validate assumptions.

Question generated implementations.

Understand business context.

Security becomes part of engineering—not a separate phase after engineering.

The Biggest Shift

The biggest mindset change isn't learning a new AI framework.

It's recognizing that every AI-generated feature deserves the same engineering discipline as handwritten code.

AI accelerates implementation.

It doesn't eliminate responsibility.

The person deploying the application still owns the outcome.

Final Thoughts

The future of software development isn't about choosing between AI and security.

It's about combining both.

AI will continue writing more code.

Humans will continue making the decisions that determine whether that code is safe, reliable, and trustworthy.

That's why I believe the most valuable engineers of the next decade won't simply know how to prompt AI.

They'll know how to question it.

Resources

Much of this perspective came from building production-grade Enterprise AI systems where architecture, business rules, and security matter just as much as machine learning.

While documenting those projects, I realized that successful AI systems depend on far more than model accuracy—they depend on thoughtful engineering.

If you're interested in learning how to design production-ready AI architectures, build reliable automation pipelines, and structure enterprise systems beyond demos, I've documented the complete process in the Enterprise AI Automation Blueprint.

The bundle includes:

Enterprise AI Architecture
Canonical Data Modeling
Production AI Pipelines
Financial NER
Entity Resolution
Business Rule Engines
FastAPI Services
Evaluation Frameworks
Synthetic Enterprise Datasets
Production-ready Python Source Code

📘 Enterprise AI Automation Blueprint

👉 https://uigerhana.gumroad.com/l/enterprise-ai-automation-blueprint

I'm also publishing long-form articles on Dev.to about Enterprise AI, Software Architecture, Cybersecurity, and AI Engineering.

If you're interested in building systems that survive production—not just impress during demos—I hope you'll follow along.

Happy building.

I Let AI Write My Backend.

Irvan Gerhana Septiyana — Thu, 25 Jun 2026 01:46:02 +0000

Then I Ran a Security Audit.

Artificial Intelligence has completely changed how I build software.

Today I can ask an AI assistant to generate:

REST APIs
Authentication
Database models
Docker configurations
Unit tests
CI/CD pipelines

Within minutes, I have a working application.

That's incredible.

Like many developers, I gradually became more confident in AI-generated code.

Maybe a little too confident.

So I decided to run a simple experiment.

I asked AI to build an entire backend application.

Then I audited it like I would any production system.

The results completely changed how I think about AI-assisted development.

Not because the code was bad.

Because security wasn't part of the conversation.

The Application Worked Perfectly

Every endpoint responded.

Authentication worked.

CRUD operations worked.

The API documentation looked clean.

Even the tests passed.

If this had been a weekend side project, I probably would have pushed it to production without thinking twice.

That's exactly what scared me.

Because working software isn't necessarily secure software.

Security Isn't Measured By "It Works"

One mistake many developers make is assuming that a successful demo equals a production-ready system.

Those are two very different goals.

A secure backend must answer questions like:

Who is allowed to access this endpoint?
What happens if someone sends unexpected input?
Can an attacker enumerate resources?
Are secrets protected?
Are requests rate limited?
Can actions be audited later?

None of those questions are answered simply because an API returns 200 OK.

What The Audit Found

The generated application wasn't full of catastrophic vulnerabilities.

Instead, it contained dozens of small assumptions.

Individually they looked harmless.

Together they created risk.

Examples included:

Missing input validation
Overly permissive CORS configuration
Generic error messages exposing implementation details
No request rate limiting
Weak authorization boundaries
Missing audit logging
No account lockout strategy
Insufficient secret management guidance

None of these issues prevented the application from functioning.

Every one of them mattered in production.

AI Writes Code

Attackers Read Code

One realization stood out during the audit.

AI optimizes for producing working implementations.

Attackers optimize for finding assumptions.

Those objectives are completely different.

An endpoint doesn't need to be broken to become vulnerable.

Sometimes it only needs one forgotten authorization check.

One missing validation rule.

One predictable identifier.

One leaked configuration.

Production failures are often built from small oversights—not dramatic mistakes.

The Real Problem Isn't AI

It's Trust.

I don't think AI coding assistants are dangerous.

I think unquestioned trust is.

The more capable these tools become, the easier it is to believe that generated code is automatically production-ready.

That assumption creates a new kind of engineering risk.

Not because AI is replacing developers.

Because developers stop questioning the output.

Security Is Context

AI understands common programming patterns remarkably well.

What it doesn't understand is your organization's security model.

It doesn't know:

your compliance requirements
your internal policies
your threat landscape
your customer obligations
your infrastructure architecture

Only your engineering team knows those things.

Security isn't something the model can infer.

It's something your organization defines.

Vibe Coding Changes The Risk

The rise of AI-assisted development has dramatically reduced the time required to build software.

That's a good thing.

But it also changes how security risk accumulates.

In the past, developers spent hours writing authentication logic.

Today it appears in seconds.

That speed is valuable.

It also means insecure patterns can spread across projects much faster than before.

AI doesn't invent new vulnerabilities.

It scales existing ones.

Code Review Matters More Than Ever

Ironically, AI hasn't reduced the importance of code reviews.

It's increased it.

Reviewing AI-generated code shouldn't focus only on correctness.

It should also examine:

authentication
authorization
validation
logging
observability
secrets
dependency management
error handling
business logic

The faster code is generated, the more important thoughtful review becomes.

Security Should Be Part Of The Prompt

One habit completely changed my workflow.

Instead of asking AI:

Build an authentication API.

I started asking:

Build an authentication API and explain every potential security risk in the implementation.

Or:

Review this code as if you were a senior security engineer performing a production security audit.

The quality of the conversation changed immediately.

AI became more than a code generator.

It became a reviewer.

That shift alone uncovered issues I would have otherwise missed.

Engineering Doesn't End At Generation

Generating software is becoming easier every month.

Engineering isn't.

Architecture still matters.

Threat modeling still matters.

Security reviews still matter.

Business rules still matter.

Compliance still matters.

Reliability still matters.

AI has dramatically accelerated implementation.

It hasn't eliminated engineering.

If anything, it's made engineering judgment even more valuable.

Final Thoughts

I still use AI every day.

Probably more than ever.

It has become one of the most valuable tools in my workflow.

But I no longer treat generated code as finished software.

I treat it as the beginning of an engineering conversation.

Because production systems aren't judged by how quickly they're generated.

They're judged by how reliably they survive.

And security is one of the reasons they survive.

Resources

Over the past several months I've been documenting what it actually takes to build production-ready AI systems—from architecture and data modeling to automation and enterprise integration.

The result is the Enterprise AI Automation Blueprint, a practical resource focused on building real systems rather than demos.

Inside you'll find:

Enterprise AI Architecture
Canonical Data Design
Financial NER
Entity Resolution
Business Rules & Decision Engines
FastAPI Production APIs
Evaluation & Benchmarking
Production-ready Python source code
Synthetic enterprise datasets

If you're interested in building AI systems that are maintainable, explainable, and ready for production—not just impressive on demo day—you can learn more here:

📘 Enterprise AI Automation Blueprint

👉 https://uigerhana.gumroad.com/l/enterprise-ai-automation-blueprint

I'm also publishing technical articles on Dev.to covering Enterprise AI, Software Architecture, AI Automation, and Production Engineering.

If that's your kind of engineering, I'd love to have you along for the journey.

Happy building—and happy reviewing.

AI Agents Don't Understand Your Business.

Irvan Gerhana Septiyana — Thu, 25 Jun 2026 01:43:00 +0000

Your Taxonomy Does.

Every week, a new AI Agent framework appears.

One week it's LangGraph.

The next it's CrewAI.

Then AutoGen.

Then OpenAI Agents.

Then Model Context Protocol.

The ecosystem is moving incredibly fast.

Naturally, companies ask the same question.

"Can we build an AI agent for our business?"

The answer is usually yes.

But I think it's the wrong question.

A better question would be:

Does your business have a language your AI can actually understand?

Because that's where most enterprise AI projects quietly fail.

Every Business Has Its Own Language

Walk into any enterprise and listen carefully.

People don't speak generic English.

They speak the language of the business.

Finance teams talk about:

invoices
purchase orders
credit notes
contracts
reconciliation

Manufacturing teams talk about:

work orders
production batches
material movements
BOMs
quality inspections

Healthcare teams discuss:

encounters
diagnoses
insurance claims
providers
referrals

Every industry has its own vocabulary.

Humans learn it over time.

AI doesn't.

The Problem Isn't Intelligence

Let's imagine an AI agent receives this message.

PART PMT ALPHABRIDGE SOLUTIONS MFG-INV-000157

Can it answer:

Has this invoice been paid?

Not immediately.

Because the agent doesn't know:

What is "PART PMT"?

What is "MFG"?

Is "ALPHABRIDGE" a customer?

A supplier?

A partner?

A subsidiary?

What does this invoice belong to?

The model understands language.

It doesn't understand your company.

This Is Where Taxonomy Matters

A taxonomy isn't just a list of labels.

It's a shared definition of how your business describes the world.

Instead of treating every document as plain text, taxonomy gives structure to meaning.

For example:

PAYMENT_TYPE

↓

PARTIAL PAYMENT

CUSTOMER

↓

ALPHABRIDGE SOLUTIONS

DOCUMENT

↓

INVOICE

STATUS

↓

OPEN

Suddenly the system isn't reading text anymore.

It's interpreting business concepts.

AI Needs Definitions Before It Needs Prompts

One thing surprised me while building an enterprise Transaction Intelligence platform.

Prompt engineering wasn't the hardest part.

Building the business vocabulary was.

Before training a single model, we spent time defining:

customer entities
invoice structures
payment types
reconciliation states
contract relationships
document categories

Only then could the models produce reliable results.

Without shared definitions, every prediction became ambiguous.

Taxonomy Creates Consistency

Imagine ten developers building ten different services.

Without taxonomy:

One service calls it:

Invoice

Another says:

Billing Document

Another uses:

Reference

Someone else stores:

Invoice ID

Eventually every API starts speaking a different language.

Now imagine introducing an AI agent.

Which term should it trust?

Taxonomy Is The Foundation Of Enterprise AI

A well-designed taxonomy becomes the contract between humans, software, and AI.

Everything speaks the same language.

Documents.

Databases.

APIs.

Models.

Dashboards.

Agents.

That consistency dramatically reduces ambiguity across the entire organization.

This Is Bigger Than Machine Learning

Many engineers associate taxonomy with NLP.

In reality, it affects almost every part of software engineering.

Database design.

API contracts.

Search.

Analytics.

Data warehouses.

Knowledge graphs.

Feature stores.

Machine learning pipelines.

Even observability.

Once your business vocabulary becomes standardized, every downstream system becomes easier to build.

AI Agents Need Context, Not Just Intelligence

One misconception I see frequently is that better models automatically produce better enterprise agents.

In practice, agents fail for a much simpler reason.

They don't have enough context.

Context doesn't magically appear inside an LLM.

It comes from structured knowledge.

Customer masters.

Contract relationships.

Business rules.

Taxonomies.

Canonical data models.

That's the real memory of an enterprise.

We Don't Need Smarter Agents First

We Need Smarter Data

The next breakthrough in enterprise AI probably won't come from another prompt.

Or another framework.

Or another model.

It will come from organizations that finally organize their business knowledge into something machines can reason about.

That starts with taxonomy.

My Biggest Lesson

Building enterprise AI changed how I think about software.

Initially I believed the language model would be the center of the architecture.

Over time I realized something different.

The center wasn't the model.

It was the business vocabulary.

The model simply consumed it.

The better our taxonomy became...

The more reliable every downstream system became.

Final Thoughts

Artificial Intelligence is incredibly good at generating language.

Enterprise software isn't built on language.

It's built on meaning.

Meaning comes from shared definitions.

Shared definitions become taxonomy.

Taxonomy becomes knowledge.

Knowledge becomes automation.

And only then do AI agents become truly useful.

Maybe the next question we should ask isn't:

"Which AI model should we use?"

Maybe it's:

"Does our business have a language that AI can actually understand?"

That question has changed the way I build software.

I suspect it will change enterprise AI over the next decade as well.

Resources

The ideas in this article come from building a complete Enterprise AI Transaction Intelligence System designed for large-scale business reconciliation.

The full implementation covers:

Canonical Data Architecture
Business Taxonomy Design
Synthetic Enterprise Dataset Engineering
Financial Named Entity Recognition (NER)
Entity Resolution
Business Rules
Automated Reconciliation
FastAPI Production APIs
End-to-End Evaluation Framework

If you'd like to explore the architecture, source code, datasets, and implementation in depth, you can find everything here:

📘 Enterprise AI Automation Blueprint

👉 https://uigerhana.gumroad.com/l/enterprise-ai-automation-blueprint

I'm also publishing an ongoing series on Dev.to about Enterprise AI Engineering, AI Automation, Software Architecture, and Production Systems.

If you're building AI for real businesses—not just demos—I hope you'll join the journey.

How We Built an AI-Powered Transaction Intelligence System for Large-Scale Enterprise Reconciliation

Irvan Gerhana Septiyana — Thu, 25 Jun 2026 01:40:51 +0000

From Unstructured Bank Statements to Automated SAP Reconciliation

For years, I've read articles claiming that AI would revolutionize enterprise finance.

Most of them focused on chatbots.

Some focused on invoice OCR.

Others showcased impressive AI demos that never left the prototype stage.

Then I joined a project that exposed a very different problem.

It wasn't about generating text.

It wasn't about building another AI assistant.

It was about helping automate reconciliation for one of the largest B2B financial operations I had ever encountered.

The challenge wasn't measured in thousands of transactions.

It was measured in enterprise-scale payment flows representing nearly two trillion in annual incoming transfers from business partners.

And almost every payment arrived through direct bank transfers.

No payment gateway.

No checkout flow.

No structured metadata.

Just money.

The Enterprise Reality Nobody Talks About

When people think about digital payments, they usually imagine something like this:

Customer

↓

Checkout

↓

Payment Gateway

↓

Order Completed

Everything is connected.

Everything is deterministic.

Enterprise finance rarely works like that.

Business partners transfer money directly to corporate bank accounts.

Payment terms are negotiated through contracts.

Invoices are settled weeks or months later.

One payment may settle:

a single invoice,
multiple invoices,
a contract milestone,
a partial payment,
or even an advance payment.

The bank only receives the transaction.

It doesn't understand the business.

A Single Transaction Can Mean Many Things

Imagine receiving the following transaction:

PART PMT ALPHABRIDGE SOLUTIONS MFG-INV-000157

To an accountant, this immediately carries meaning.

To a machine, it is simply text.

The system still has to answer:

Which customer made the payment?
Which invoice does it reference?
Is this a partial payment?
Which contract governs this transaction?
Can it be reconciled automatically?
Should SAP recognize this payment?

These are not language problems.

They are business understanding problems.

Why Traditional Automation Reached Its Limits

Many enterprise reconciliation systems rely heavily on deterministic rules.

For example:

If the transaction contains an invoice number,

match the invoice.

Simple.

Until reality intervenes.

Invoices appear in different formats.

Customers use abbreviations.

Contracts evolve.

Payment references become inconsistent.

Eventually the rule engine becomes increasingly difficult to maintain.

Every new exception introduces another rule.

Eventually the rules become the problem.

We Changed the Question

Instead of asking:

"How do we match transactions?"

we asked:

"How do we help machines understand business transactions?"

That small change completely transformed the architecture.

Instead of building a matching engine,

we built a Transaction Intelligence System.

The Architecture

The pipeline looked like this.

MT950 Bank Statement
        │
        ▼
Canonical Transformation
        │
        ▼
Business Taxonomy
        │
        ▼
Financial Named Entity Recognition
        │
        ▼
Entity Resolution
        │
        ▼
Business Validation
        │
        ▼
Reconciliation Decision
        │
        ▼
SAP Integration

Every layer solved a different problem.

No single AI model was responsible for everything.

Understanding Before Automation

One of the most important lessons from the project was this:

Artificial Intelligence does not replace business understanding.

It amplifies it.

Before the system could automate anything, it first needed to understand:

customers,
invoices,
contracts,
purchase orders,
payment types,
business relationships.

Only after these concepts became structured could reconciliation be automated with confidence.

Why Synthetic Data Became Essential

Like many enterprise environments, we couldn't simply publish or train on confidential financial records.

Instead, we designed a synthetic enterprise dataset that preserved business relationships without exposing sensitive information.

The dataset included:

customer master data,
contracts,
invoices,
purchase orders,
MT950 bank statements,
reconciliation ground truth.

This allowed us to develop, benchmark, and improve the entire pipeline while respecting privacy and compliance requirements.

Beyond Named Entity Recognition

Many NLP projects stop after extracting entities.

Enterprise software cannot.

Extracting:

ALPHABRIDGE SOLUTIONS

is useful.

Knowing that it corresponds to:

Customer ID:
CUS-00002

is transformative.

Entity Resolution connected language with business identity.

Business rules connected identity with operational decisions.

That combination enabled reliable automation.

From Intelligence to Action

The final objective was never to build a better NLP model.

The objective was operational impact.

Once transactions could be interpreted with sufficient confidence, the reconciliation engine determined whether payments could be automatically recognized and forwarded into the enterprise financial workflow.

Instead of asking finance teams to manually investigate every incoming transaction, the system classified, validated, and prepared transactions for downstream processing based on deterministic business logic and AI-assisted understanding.

This significantly reduced manual effort while improving consistency across large volumes of enterprise payment data.

What I Learned

This project fundamentally changed how I think about enterprise AI.

The most difficult part wasn't training the transformer.

It wasn't building APIs.

It wasn't deploying models.

The hardest challenge was designing a system capable of understanding how the business actually operates.

Enterprise AI is less about prompts.

It is more about architecture.

Less about models.

More about knowledge.

Less about automation.

More about understanding.

Final Thoughts

The AI industry often celebrates models.

Enterprise organizations measure outcomes.

The companies that create the greatest value with AI will not necessarily be the ones using the newest models.

They will be the ones capable of transforming fragmented operational data into reliable business intelligence.

That is where automation truly begins.

Not with an AI agent.

Not with a chatbot.

But with understanding.

Want to Build Enterprise AI Systems?

This project inspired me to document the complete engineering process behind a production-ready Transaction Intelligence System.

Inside the Enterprise AI Automation Blueprint, you'll find:

Enterprise AI Architecture
Canonical Data Design
Financial Named Entity Recognition (NER)
Synthetic Enterprise Dataset Engineering
Entity Resolution
Automated Reconciliation
FastAPI Production APIs
Evaluation & Benchmarking
Production-ready Python source code

If you're interested in building AI systems that solve real enterprise problems—not just prototypes—you can explore the complete blueprint here:

📘 Enterprise AI Automation Blueprint

👉 https://uigerhana.gumroad.com/l/enterprise-ai-automation-blueprint

I'm also publishing a free engineering series on Dev.to covering Enterprise AI, Software Architecture, AI Automation, and Production AI Systems.

I hope it helps you build systems that don't just generate intelligence—but deliver measurable business impact.

I Think We're Measuring Software Engineers Wrong.

Irvan Gerhana Septiyana — Thu, 25 Jun 2026 01:38:28 +0000

AI Changed the Metrics. We Haven't.

A few years ago, one question appeared in almost every engineering interview.

"How many programming languages do you know?"

Then it became:

"How many years of experience do you have?"

Today it's slowly becoming:

"Which AI coding tool do you use?"

Cursor.

Claude Code.

GitHub Copilot.

Codex.

Windsurf.

Lovable.

Bolt.

The tools have changed.

But I think we're still measuring engineers using the wrong metrics.

We Used To Reward Code

For decades, software engineering rewarded output.

More commits.

More pull requests.

More features.

More lines of code.

It made sense.

Writing software was expensive.

Every line represented time.

Effort.

Knowledge.

Today...

AI can generate hundreds of lines before you finish your coffee.

Suddenly, writing code is no longer the bottleneck.

So why are we still acting like it is?

Code Has Become Cheap

This isn't a bad thing.

It's progress.

Boilerplate.

CRUD endpoints.

Configuration files.

Documentation.

Tests.

Much of this can now be generated in seconds.

The cost of producing code has dropped dramatically.

Whenever something becomes cheaper...

Something else becomes more valuable.

So What's Becoming Valuable?

Not syntax.

Understanding.

Good engineers don't just write software.

They answer questions like:

How should this system evolve over the next three years?

Which service should own this data?

What happens when the database is unavailable?

How do we avoid duplicating business rules?

How do we keep different teams from stepping on each other?

None of these questions disappear because AI exists.

In many ways, they become even more important.

AI Doesn't Understand Your Company

One thing I've noticed while building enterprise software is that AI understands programming surprisingly well.

It understands Python.

Go.

TypeScript.

React.

FastAPI.

SQL.

What it doesn't understand is your business.

Ask it to generate an authentication service.

You'll probably get a good result.

Ask it to explain why Customer A can partially pay Invoice B under Contract C while Customer D cannot.

Now the conversation changes completely.

That's no longer a programming problem.

That's institutional knowledge.

Every Company Has Hidden Logic

Every business has rules that never appear in tutorials.

Healthcare.

Manufacturing.

Banking.

Insurance.

Retail.

Logistics.

Government.

Eventually you discover sentences like:

"This customer follows the legacy billing process."

Or:

"That contract uses a completely different approval workflow."

Or:

"Invoices created before 2022 are handled differently."

None of this exists inside a language model.

Someone has to model it.

Someone has to protect it.

Someone has to maintain it.

That's engineering.

The Best Engineers I Know

The engineers I admire rarely impress me because they code faster.

They impress me because they reduce complexity.

They ask better questions.

They see failure modes before they happen.

They simplify architectures.

They create systems that other engineers enjoy working on.

Ironically...

Many of them probably write fewer lines of code than junior developers.

But every line carries much more value.

AI Is Raising the Bar

Some people worry AI will replace software engineers.

I think something different is happening.

AI is raising the minimum expectation.

If everyone can generate CRUD applications...

CRUD applications stop being impressive.

The differentiator becomes everything around the code.

Architecture.

Communication.

Domain modeling.

Reliability.

Observability.

Business understanding.

These aren't disappearing.

They're becoming the job.

My Workflow Changed Completely

I still use AI every day.

Probably more than ever.

But I ask different questions now.

Instead of:

"Write this API."

I ask:

"What architecture would make this easy to maintain?"

Instead of:

"Generate a database schema."

I ask:

"What's the domain model behind this business?"

Instead of measuring how quickly I can generate code...

I measure how many future problems I can avoid.

That single shift has probably saved me more time than any coding assistant ever has.

Maybe Experience Isn't About Code

Sometimes we describe senior engineers as people who know more technologies.

I'm no longer convinced that's true.

Maybe seniority is simply the ability to recognize patterns.

To understand trade-offs.

To make good decisions with incomplete information.

AI can help us write implementations.

Experience still helps us choose the right implementation.

Those are very different skills.

Final Thoughts

Software engineering isn't disappearing.

It's evolving.

As AI continues to automate implementation, the profession moves closer to what it has always been underneath:

Designing reliable systems that solve meaningful problems.

The tools will continue to improve.

Models will become faster.

Frameworks will come and go.

But one thing will remain surprisingly constant.

Technology changes.

Engineering judgment compounds.

And I suspect that's what will separate great engineers from everyone else over the next decade.

Continue Learning

Over the past several months, I've been documenting how these ideas apply in real enterprise software.

Instead of focusing on AI demos, I built a complete Enterprise AI Transaction Intelligence System that covers the entire engineering lifecycle:

Canonical Data Architecture
Synthetic Enterprise Dataset Design
Financial Named Entity Recognition (NER)
Entity Resolution
Business Rules & Decision Engines
Automated Reconciliation
FastAPI Production APIs
End-to-End Evaluation & Benchmarking

The complete implementation—including three technical handbooks, production-ready Python source code, synthetic datasets, and architecture documentation—is available here:

📘 Enterprise AI Automation Blueprint

👉 https://uigerhana.gumroad.com/l/enterprise-ai-automation-blueprint

I'm also publishing a long-form Dev.to series on Enterprise AI Engineering, Software Architecture, and Production AI Systems.

If you're interested in building systems that last—not just demos—I hope you'll follow along.

Happy building. 🚀

Why Most AI Projects Never Reach Production

Irvan Gerhana Septiyana — Thu, 25 Jun 2026 01:37:22 +0000

They Don't Have an AI Problem. They Have an Engineering Problem.

Artificial Intelligence has never been more accessible.

In just a few months, we've gone from experimenting with chatbots to building AI agents capable of writing code, generating reports, creating applications, and even orchestrating workflows.

Open social media and you'll see countless posts claiming:

"I built an AI SaaS in a weekend."

"I replaced my workflow with AI."

"My AI agent now runs my business."

The demos are impressive.

The prototypes are exciting.

But there's a question we rarely ask.

How many of these projects are still running six months later?

From my experience, surprisingly few.

Not because the models are bad.

Not because the frameworks are immature.

But because production systems require far more than intelligence.

They require engineering.

The Demo Is The Easy Part

Today, building an AI demo is easier than ever.

Need a chatbot?

Use an API.

Need document extraction?

Use an LLM.

Need a dashboard?

Generate it with AI.

Within a few hours, you can produce something that looks remarkably polished.

This is both the greatest strength and the greatest danger of modern AI development.

The ease of creating demonstrations can create the illusion that the difficult work is finished.

In reality, it has barely begun.

Production Doesn't Care About Your Demo

A production system has very different requirements.

It needs to answer questions that rarely appear in tutorials.

What happens when the API times out?

What if the data format changes?

How are failures logged?

Who owns the business rules?

How are predictions validated?

What if the customer data is incorrect?

Where does the source of truth live?

None of these questions are solved by choosing a better language model.

They are solved through software engineering.

AI Solves Understanding

Engineering Solves Reliability

One realization completely changed how I approach AI systems.

Machine learning helps software understand information.

Software engineering helps software survive reality.

These are complementary disciplines.

Not competing ones.

An intelligent model without reliable architecture quickly becomes an unreliable product.

The Invisible Work

When people showcase AI projects, they usually present the exciting parts.

The interface.

The conversation.

The predictions.

What they rarely show are the components that make those predictions trustworthy.

Data validation.

Canonical models.

Observability.

Retry mechanisms.

Monitoring.

Business rules.

Testing.

Versioning.

These systems are rarely visible to users.

Yet they determine whether an AI application succeeds in production.

Building Intelligence Isn't Enough

Imagine building an AI assistant for enterprise finance.

A bank statement arrives.

The model extracts an invoice number.

Success?

Not yet.

The system still needs to determine:

Does the invoice exist?

Is it already paid?

Which customer owns it?

Does the payment amount match?

Should reconciliation happen automatically?

Those questions require business knowledge.

Not language generation.

Architecture Becomes Your Competitive Advantage

The AI ecosystem changes almost weekly.

New models arrive.

Frameworks evolve.

Benchmarks improve.

Architecture changes much more slowly.

A well-designed system can replace models over time while preserving the surrounding business logic.

This is why architecture often becomes the most valuable long-term investment.

Not because it's exciting.

Because it lasts.

The Engineers Who Thrive

As AI continues to automate repetitive coding tasks, the value of engineers will shift.

Writing code becomes easier.

Designing systems becomes more important.

Future engineers will spend less time implementing features and more time answering questions like:

How should information flow?

Where should business rules live?

How should services communicate?

How do we ensure trust?

How do we measure business outcomes?

These questions cannot be answered through autocomplete.

They require experience, judgment, and engineering thinking.

Production AI Is A Team Sport

Another misconception is that AI projects succeed because of one exceptional model.

In reality, production systems depend on collaboration.

Data engineers ensure reliable pipelines.

Backend engineers expose APIs.

Machine learning engineers train models.

Software architects design systems.

Domain experts define business rules.

Operations teams monitor production.

AI becomes one component within a much larger ecosystem.

My Biggest Lesson

The more enterprise systems I build, the less obsessed I become with model benchmarks.

Instead, I pay attention to the surrounding architecture.

Because users don't experience models.

They experience products.

A model with 98% accuracy inside a fragile application creates a poor user experience.

A slightly less accurate model inside a well-engineered system often creates a far better one.

Final Thoughts

Artificial Intelligence is changing software development forever.

There is no doubt about that.

But the future belongs to engineers who understand that AI is not the product.

It is one layer of the product.

Great software is still built on solid architecture.

Reliable data.

Thoughtful design.

Clear business understanding.

Engineering has not become less important.

It has become more important than ever.

Resources

If you're interested in building production-ready AI systems rather than one-off demos, I've documented the architecture behind a complete Enterprise AI Transaction Intelligence System.

The project covers:

Canonical Data Architecture
Synthetic Enterprise Dataset Design
Financial NER
Entity Resolution
Business Rules
Automated Reconciliation
FastAPI APIs
End-to-End Benchmarking

along with production-ready Python source code and implementation guides.

📘 Enterprise AI Automation Blueprint

👉 https://uigerhana.gumroad.com/l/enterprise-ai-automation-blueprint

I'm also publishing an ongoing Dev.to series about Enterprise AI Engineering, Production AI Systems, and AI Automation.

If that's your kind of engineering, I'd love to have you along for the journey.