AI gets smarter and faster, and tools to work with it improve as well.
But there are some hard limits that won't change, no matter how smart the AI (maybe?).
This is the real value of a software engineer, with or without AI 👇
Long term planning in context
Writing (real) software is not about "make it work (now)".
Software Engineering aims to engineer an architecture that works now, but it's also easy (fast) to maintain and extend in the future 🏗️
Short-term speed and long-term maintenance is a contextual balance, it requires knowledge outside of the codebase.
And it's delicate: too much chaos, and the long-term costs will outweigh any short-term benefit.
One time prompts
On one extreme you have the personal "1 time" script. It must work now, fast, for a one time task.
I recently had such a case: I wanted to extract and map some data from a CSV file. Here is my prompt in summary:
I don't care about the language or tech, extract this data as fast as possible 💁🏼♂️
The AI wrote some bash script, no idea. But it worked, job done.
Long term product
On the other extreme there is the production multi-year product.
Here the constraints are more subtle:
- How much money can the company invest in this solution?
- Is this an MVP feature experiment?
- Is this app only for internal use?
- How many users we plan to support?
The "context" expands beyond the "read this codebase and implement" 🤔
You (engineer) have this context, and that makes you valuable. You know how to structure the implementation beyond code.
But wait, what if we document all of these external constraints for the AI to read?
Problem number 2: context length.
Too much context confuses you (and the AI)
Hypothetically we could write down everything that's happening inside the company, and feed all to the AI. Then the AI knows more than you, and can act accordingly.
(As of today) the AI cannot manage a large context without getting confused 🫠
LLMs are prediction machines. Imagine the sentence "Let's go ...". What's "..." going to be?
If my documents only mention "fish", "lake", "water", then an LLM can confidently complete "fishing".
But imagine we feed in the context too many unrelated information. Suddenly you get "ball", "movie", "mountain". Now "fishing" is not obvious anymore.
That's the state of LLMs: context precision is more valuable than context length 👀
We may overcome this (somehow), but AI today is not there yet.
Software entropy
Open question:
Can AI not only implement new features, but improve/refactor the previous code while doing so?
A large portion of the engineer value today (outside of broader context) is "knowing" which patterns will cause trouble long term.
Example: I see
useEffect. Or worst:as any🤦
In fact, given a clean context and right guardrails, AI today easily one-shots most of the prompt I give it (see Effect, AI and Orchestration).
But "it works" is not enough.
My interventions comes in the form of logic updates and app structure 🏗️
Recent example with xstate: a "timer" machine that worked, but was going to cause problems soon. Here is what I sent after the implementation was completed:
Explore another approach for this. The aim is to avoid duplication of this timer
logic in practice and dialogue as much as possible, have the pause on tab left,
and display the current time in the UI.
The "tick" event may not be needed if the state tracks
the "start time" with a Date and the UI displays the seconds since then.
Then there needs to be a way to account for "time elapsed" in total, which
is (1) what's sent to the backend and (2) the start time when a user comes back
to a previous attempt. Plan the logic for thisMy "knowledge" went beyond the feature: it was an overall view of how I envision the code to work in the future.
Your vision cannot be borrowed by AI, use it 🫡
The more AI paints broader strokes, the more your value falls in the details.
Define the boundaries, bring the vision, and leave AI to fill all the gaps in between 🎨
See you next 👋