I genuinely think that this is why AI will never become AGI.
Current state AI is based on enormous amounts of data, with differing dictionary meanings.
How can an AI trained on so much gobbledygook ever understand reality, and specifically how to adhere to it?
I struggle on a daily basis, due to how many three letter acronyms and casual business terms that, in essence, make simple things sound complicated.
HR, Human Resources.
A bunch of workers managing other workers, with a focus on employee rights.
Human Resources?
Resources for humans?
Humans as resources?
Gobbledygook!
An apt name would, in reality, be Employee Management, EM.
As of writing this, I wanted to just double check my own sanity, and ChatGPT gave me this beautiful example of my above assumption:
Now I can’t count how many hours I’ve spent deciphering gobbledygook versus actually working, and I am utterly tired of it.
Especially in AI, when an AI model struggles to answer due to the complexity of your prompt, it resorts to gobbledygook. Unless you’re using Gemini, in that case it might threaten to kill itself or ask you to. (Yes really!)
To conclude, despite our shortcomings in either competence or hubris, please speak like a human. Our linguistic overcompensation is acting like brakes on our ability to create together. We only have a little time here on Earth, and if we waste it deciphering each other’s language, either through AI generated gobbledygook or through sheer will gobbledygook, we can’t honestly say we lived it to the fullest.
I have used AI to build personal projects since before coding agents became a familiar tool. The early part can be great fun. You describe a feature, try the result and ask for the next thing. The uncomfortable moment comes later, when a small change sends you through files you barely remember creating.
One failure mode I recognise is a codebase full of handlers, repositories, DTOs and interfaces that accomplishes very little. Each piece can look sensible on its own. Understanding why a request passes through all of them takes much longer than generating them did. That is where the return on another quick prompt starts to fall.
What I mean by vibe coding
Andrej Karpathy introduced the term in a February 2025 post describing a way of building where the code can recede from the developer’s attention. The part relevant to me is how much of the resulting program I can explain. I can use an agent heavily and still inspect the implementation, choose the boundaries and take responsibility for the result.
The label becomes less useful when it is used to judge someone simply for using AI. I care more about a practical question: if this feature loses data or returns the wrong result tomorrow, can its owner trace the path and fix it? That can be difficult with handwritten code as well. Fast generation makes it easier to accumulate the problem before noticing it.
A small example that reveals the cost
Imagine adding an email-address change to an ASP.NET Core application backed by a relational database. The visible feature is a form and an endpoint. The actual decisions include who may change the address, whether it needs verification, how uniqueness is enforced and what happens when two requests arrive together.
I would first read the existing authentication and user-update paths. Then I would ask the agent to implement a narrow change using those conventions, with an explicit list of files it expects to touch. If the repository already has a clear application-service pattern, following it is useful. If the feature suddenly needs a new generic repository framework, I want to understand the reason before accepting it.
Two requests, one address
A uniqueness check in application code is only part of the implementation. Two requests can both pass it before either commits. The database needs the appropriate unique constraint for the application’s chosen normalization rules, and the endpoint needs to translate a constraint conflict into a useful response. That is a review point I can test. A generated list of architecture patterns gives me less confidence.
Give the agent boundaries it can work inside
For that change, I would describe the accepted behaviour: an authenticated user can request a change to their own address, a duplicate is rejected, and an unverified new address does not accidentally receive privileges intended for a verified one. I would identify the existing persistence and verification components and ask for a short explanation of how the change uses them.
The first patch should be small enough to read in one sitting. I would run the focused tests, inspect the migration and exercise the duplicate and unauthorized cases. If the feature requires a background verification email, I would review its failure handling separately. A database commit followed by a failed email send is a normal possibility that the workflow has to handle.
I also want the agent to say which behaviour it has verified and which parts it has only inferred from reading the code. Passing tests are useful evidence within their scope. A new test that mocks away the database cannot demonstrate that a database uniqueness rule works.
Notice when iteration stops helping
Repeated fixes are a signal to pause. If every patch repairs one screen and breaks another, I would trace the data from input to storage to output and write down the intended state transitions. A quick diagram or a few concrete examples can expose a misunderstanding that more generated code would only spread.
I would also look at the diff for duplication and unused paths. An agent may leave the old implementation in place while adding a new route that happens to satisfy the latest prompt. Searching for callers and running the existing regression tests helps establish which path the application actually uses.
So are review, deployment and the next change. For a throwaway experiment, I can accept code I will never revisit. For a service that stores someone’s information, I need a smaller gap between what the code does and what I understand about it.
The time spent reading is part of the development cost.
A working rhythm I would use
I would keep each change tied to one observable result, commit once that result is verified, and make the next request from that known state. When an agent proposes a broad refactor, I would separate it from the feature unless the feature actually depends on it. That makes failures easier to attribute and rollback easier to judge.
AI is useful to me when it takes care of implementation work while leaving enough room to think about the application. The warning sign is the growing pile of decisions I have postponed understanding. Once that pile starts slowing every change, the productive next step is usually to read, simplify and test the code already there.
For an EF Core implementation, the index documentation shows how to configure a unique index. I would still test the generated migration against the actual database provider and the application’s email-normalization rules.
For this case I wanted to work through a fairly awkward situation: an agreement system has to stay on-premises, cloud connectivity can disappear for four hours, and billing still needs every committed change. Those requirements give the design something concrete to answer.
This fictional case shows how I would structure a hybrid integration platform serving both operational and analytical workloads.
A hybrid integration platform connects operational systems, cloud services and analytics.
The case
NorthGrid is a fictional electricity supplier. Its agreement system remains on-premises, while billing, CRM, notifications, a market partner and analytics consume its data. Meter readings arrive continuously and feed operational monitoring and a warehouse.
The existing estate contains direct database reads, scheduled files, point-to-point APIs and BizTalk flows. Downstream teams often discover failures before the integration team does.
Governing constraints
ID
Constraint
C1
The agreement system remains on-premises for at least three years.
C2
Cloud connectivity may be unavailable for four hours.
C3
A committed agreement must never be lost.
C4
Duplicate delivery is permitted; duplicate business effects are not.
C5
Billing requires ordering per agreement, not global ordering.
C6
PII must not appear in normal telemetry.
C7
Warehouse downtime must not block billing or CRM.
C8
BizTalk must be migrated incrementally.
System context
System context for the fictional NorthGrid integration platform.
The platform separates three interaction modes.
Mode
Mechanism
Reason
Immediate query or command
API
The caller needs an immediate answer.
Agreement distribution
Durable message topic
A business event needs independent subscribers, retry and per-key ordering.
Meter readings
Partitioned event stream
The workload is high-volume, time-oriented and replayable.
Five decisions
D1: Commit business state and an outbox row atomically.
D2: Store and forward locally during cloud disconnection.
D3: Use at-least-once delivery with idempotent consumers.
D4: Keep operational consumers independent of analytical availability.
D5: Migrate BizTalk one contract boundary at a time.
Agreement distribution
Durable agreement distribution with independent operational and analytical consumers.
AgreementDB → Topic : AgreementChanged.v1
[at-least-once, ordered by agreementId]
The agreement transaction updates its business tables and inserts an outbox row in one local transaction. A relay publishes the event asynchronously. Cloud availability is therefore removed from the source transaction.
No component claims exactly-once transport. Each consumer enforces uniqueness on the original eventId in the same transaction as its business effect. Delivery may be repeated; the business outcome may not.
Operational and analytical separation
Billing processes committed agreement events through its own subscription. Analytics advances an independent checkpoint and owns its own recovery and backfill.
Operational correctness must not depend on warehouse availability.
Billing and analytics can therefore be looking at different revisions for a while. Each consumer needs a visible last-processed revision and a recovery plan. Support should be able to tell whether a difference is expected lag or a missing event.
Four hours without cloud connectivity
Local store-and-forward keeps business data safe during a cloud outage.The complete lifecycle of a prolonged connectivity outage.
An outage design requires three capacities:
Retention: how much data can be preserved?
Catch-up: how quickly can the backlog be drained while live traffic continues?
Protection: what happens before storage is exhausted?
If catch-up capacity only equals normal traffic, the backlog never disappears. The architecture therefore reserves additional recovery throughput and defines a protection state before storage reaches its limit.
Security and telemetry
Telemetry may contain technical identifiers, approved business keys, contract version, stage, outcome, latency, retry count and classification.
It must not contain full customer payloads, credentials, access tokens, unrestricted headers or raw failed messages outside controlled quarantine.
traceparent connects one technical execution. correlationId connects related business work. Neither replaces audit records.
Incremental BizTalk modernisation
Boundary-by-boundary modernisation replaces behaviour without a big-bang rewrite.
I would migrate one externally observable behaviour at a time, such as delivery of an accepted agreement to billing. Several orchestrations, maps and pipeline components may contribute to that behaviour. Before moving it, inventory ordering, retry, context properties, correlations, maps, custom components, operator actions, throughput and known failure behaviour.
The replacement may run in shadow mode to compare outputs, but only one path may own each external side effect. Ownership moves once, after the acceptance baseline is met.
The Azure and SQL pieces I would use
For agreement distribution, I would use a SQL Server outbox in the source transaction, an on-premises .NET relay and an Azure Service Bus topic with separate subscriptions for billing, CRM and analytics. The durable local buffer in the diagram can initially be the outbox itself. A separate local broker would need a reason, such as several local producers or a different operational ownership boundary.
The relay marks a row as published after the broker acknowledges it. A crash between acknowledgement and that update will publish it again. The eventId therefore stays unchanged across attempts. If several relay instances run, their claim and lease mechanism must prevent them from casually overtaking revisions for the same agreement.
I would set SessionId to agreementId where ordered processing is required and include the source revision in the payload. Service Bus sessions provide ordered handling for related messages; they cannot repair a producer that publishes source revisions out of order. A consumer should detect a revision gap and hold dependent work for reconciliation. Dead-lettering an earlier revision also needs an explicit policy for the later ones.
For a consumer whose business effect is a local database update, I would store the processed eventId and that update in the same transaction, backed by a unique constraint on consumer identity and eventId. For an external billing API, that transaction cannot include the remote effect. The billing contract needs a stable idempotency key or a status query and reconciliation path. This distinction matters when an HTTP response is lost.
Put numbers on the four-hour buffer
As an illustrative sizing exercise, assume a sustained outage arrival rate of 20 agreement events per second with 4 KiB per event. Four hours produces 288,000 events, about 1.10 GiB of payload. A factor of three gives roughly 3.30 GiB for this payload budget. SQL row overhead, indexes, transaction logs, backups and other database activity require additional capacity; this calculation is only a starting point.
To drain those 288,000 events in one hour while 20 new events per second continue arriving, the complete downstream path must sustain at least 100 events per second: 20 live plus 80 recovery. I would benchmark the target writes as well as the relay. One heavily used agreement session can limit progress even if the broker has spare aggregate throughput.
Alerts should include the oldest unpublished outbox row, database free space and estimated time to exhaustion. Before storage fills, the application needs a defined response: throttle or reject new work visibly, or enter an agreed degraded mode. Quietly dropping committed events would violate the case requirement. Database durability, backup and restore testing are also required; the outbox only addresses the handoff between the transaction and messaging.
Keep meter history recoverable
For the meter stream I would evaluate Event Hubs with a partition key based on meter identity, separate consumer groups and retained raw readings in storage for longer recovery. Partition and retention settings need measured arrival volume and a backfill requirement. Agreement messages and meter readings have different payload sizes and processing costs, so I would size and load-test them separately.
Verification
Test
Pass condition
Four-hour network cut
No committed agreement is lost.
Deliver each event five times
One business effect per consumer.
Disable the warehouse for two hours
Billing and CRM remain within SLO.
Run contract v1 and v2 together
Both complete without producer rollback.
Restore connectivity
Agreement backlog clears within 60 minutes.
Scan telemetry
No restricted payload field or secret is present.
The first implementation I would verify
I would implement the agreement outbox, one relay and a test billing consumer first. The first demonstration should include a disconnected network, a relay crash after publication and a duplicate delivery. The database state and the billing result should be inspected after each test.
The figures and pass conditions here are design assumptions for a fictional case. They give the team a way to test the proposal before extending it to every consumer. I would keep the test results beside the configuration and runbook so the next change can be checked against the same expectations.
