Where is the complexity in code, really? 🤔
Answer: connecting multiple independent systems 👀
Single environment and limited use cases are easy, any AI already automates that. The value is found in making multiple pieces work together.
Let me explain what I mean 👇
AI builds websites. Well...
I recently built a browser script (javascript). Well, I didn't do it exactly, the "AI" did all the work 💁🏼♂️
The scope is limited: browser API, reading and changing the DOM, javascript only 🤝
There is no more value in these tasks. A few prompts and tweaks, and shipped without any issues.
That's the same for single-system requirements, e.g. only browser (no external request) or only server (no database connection).
It's just like working solo on a project: no communication overhead, no misunderstanding, no contract required between people.
Communication is hard
It all falls apart with multiple systems:
- Client sends correct request, verifies correct response, handle miscommunication
- Server connects to database, timeouts, streams
The art of software engineering is found in connecting multiple complex systems 🏗️
AI is not there (yet?)
Case in point: local-first sync engine
Last week I published an article about a local-first sync engine architecture (no code).
My point is: you cannot ask to an AI "make a local-first sync engine" and expect that it figures out every step (in code as well).
Because there is no strictly a "valid answer" 💁🏼♂️
Software engineering is about tradeoffs
The sync engine in the article handles real-time updates by syncing using web workers+socket.
But that's not necessary for all apps, not even all local-first apps. Not even for a sync engine 🙌
Sync engine = Something that syncs changes between systems
Adding "real-time" is a new requirement, which introduces new tradeoffs, and new complexity (e.g. sockets, streams, real-time database updates).
These are all added "systems". This is the definition of "complexity". AI is not (yet) good at this, and that's where you bring value 🫡
Figure out the complexity, and fill the blanks
AI is still great in single systems, or when given strict instructions about how systems connect.
You first design the architecture of the whole system (chatting with AI), and then use AI to code each system in isolation ✨
Example: I am working on a simplified sync architecture, without real-time updates (planning to publish the code 🔜).
I discussed syncing and authentication with Grok. Based on my ideas and my guidance, I asked the AI to find pitfalls and propose solutions.
Once I had an idea of the system as a whole, I can then ask the AI to sketch the shape of the API, the database schema, queries, and more:
I don't expect AI to then code everything without guidance 👀
There are too many variables in a complex system (e.g. what libraries I am using, what runtime, what server stack, what database).
But, I still find value in AI when working on smaller problems.
If you didn't yet, check out the full article on my sync engine: How to implement a Sync Engine for the Web 🚀
How I implemented a Sync Engine for the Web ⚡️ 👉 Local (reactive) database 👉 Web worker in the background 👉 CRDTs 👉 Web socket connection The full architecture explained in the article step by step 👇 typeonce.dev/article/how-to…
Many people asked for the actual code. As mentioned, I am working on a simplified architecture for a web sync engine, code coming soon 🔜
Meanwhile, the Effect Days are approaching, see you there soon 👀
See you next 👋