DEV Community: Yao Ke

Human: Tool Choice

Yao Ke — Tue, 24 Jun 2025 11:30:27 +0000

As I was reading Svelte 5's documentation I noticed something interesting,
a page with .txt files for LLMs to crawl svelte.dev.

This got me thinking, as more and more code is written by AI, how will this affect
the tooling we choose. This applies in all sorts of areas, but especially in
terms of programming languages. Consider the following points:

Popularity

The elephant in the room for choosing any technology is popularity. React is
popular because React is popular. Once a tool is established as commonplace and
the de facto standard, it tends to cement itself until a generational improvement.

This is with good reason too. Popularity means proven, popularity means better
tooling, popularity means better support, popularity means more educational
material, popularity means more jobs/employees.

Popularity means better AI code generation.

Since AI is trained on all the code on the public internet, having seen more examples of a popular technology such as React, it'll understand it better and be able to apply it to more diverse situations.

Quality

The quality of the codebase online is also very, very important. The old adage
remains true:

Garbage in, garbage out.

Althought a technology like React is popular, it also means that there is more
than enough spaghetti code online written in it. This can significantly impact
the model's performance if the model's trainers did not carefully curate the data
or otherwise combat low quality training data.

Whilst languages like Haskell are niche, it may actually be much more suited for
LLM code generation since the dozens of Haskell coders are nerds who write high quality
code!

Adoption

Although the migration from Svelte 4 to Svelte 5 is generally an improvement,
one hilarity I encountered is that no matter how much I specified "use Svelte 5",
the models will continue to use Svelte 4.

It seems that in the modern age, we not only need to convince humans to switch,
but machines too!

Imperative vs Declarative Tooling

Recently I've been writing a bit of SwiftUI code, and the experience is totally
different. Since the layout and structure shown on the page is so declarative, it's so much easier to just generate correct code on the first go without some funky formatting issue.

Note that declarative means more "here's what I want", instead of "follow this step by step". This is more of a continuum/spectrum rather than classification. C is declarative compared to assembly, and Python is comparative compared to C.

It's akin to the much higher quality of AI code in languages like Python and Swift, compared to lower level languages like C. I suppose this is true even for human programmers, but even truer for AI which struggles to think continuously across long contexts. As such, the design choices made in the tooling itself, whether that be languages or frameworks, can significantly impact the quality of AI generation. I've yet to see AI mess up PyTorch code because it's just so declarative.

In the future, we may even see AI friendliness as a core trade-off when designing new tooling.

Final Thoughts

I do not know what will actually be optimal tech stack as your decisions will
be affected by some weighted combination of the above factors. Never mind the
fact that choosing a tech stack was already a chore before AI.

Tools development in the future will need to take AI into consideration and alway provide as much training data and explanation as it can. This not only allows AI
generation, but stronger automated feedback and debugging too.

Ultimately, the right tool will always prove to be the easiest to work with, whether by human or AI. I personally would rather just use the easiest tool I prefer, but your mileage may vary. Maybe some esoteric stack like Haskell backend, Flutter frontend is the future of AI web development.

I wish I could've ended on a more definitive note, but I suppose a more objective measure of the tools AI is next to impossible. Perhaps I can end on on list of questions for the reader to explore:

How much autonomy does the AI have in your workflow? If more than 50%, then maybe it should take priority in your choice of tools?
Are LLMs actually self-aware of what tools they excel at using?
Are tools easier for humans easier for LLMs too?
Do you have an emotional connection to a tool? Will that affect your motivation and willingness to vet the AI code?
How will adoption of new tools change? If BigCorp releases BigCorpLang, and an accompanying LLM, then adoption/learning cost is drastically reduced!
Can we ever expect to measure the performance of LLMs on a tool by tool, language by language basis in a feasible and cost effective way?
Will LLMs ever be able to learn on the job? Can we effectively teach it new tools and not just shove a huge .txt file into its system prompt and limited context window?

Architecting In The Age of AI

Yao Ke — Tue, 24 Jun 2025 11:28:29 +0000

The other day I watched an interview where the CEO of Microsoft, Satya Nadella was talking about how in the future software development will be less about writing code and more about higher level system design.

This is definitely one of the more grounded takes on AI's impact on coding. In my personal experience of using generative models such as ChatGPT, it's definitely not ready to completely replace human engineers yet, but it's certainly not useless.

So coming back to the titular claim, what has really changed in the world of programming? Should we strive to all become architects, or is handcrafting every UTF-8 symbol still mission critical?

In the following sections, I'll explore the different aspects of programming, and notate with + (it matters more now) and - (it matters less now) to paint my mental picture of programming in 2025.

Syntax (-)

Syntax and language specific notations is becoming less and less important. In my experience of coding in Python, Java, C and Golang, I had already noticed that I was becoming more and more syntax agnostic. In the same family of languages (in this case the C family of languages), syntactic difference such as func vs def vs function matter less and less.

A proficient C programmer can just as easily understand Python code generated by AI given a bit of time to connect the dots. Now, more quickly than ever, can a Java programmer contribute to a C project.

Language specific foot guns (+)

Whilst syntax is arguably less important, I would not be confident in saying languages are a thing of the past. This is due to the many nuances of particular languages which must be reasoned about carefully.

Everyone jokes about how Python is basically pseudocode, but it too has its unseeming language features. For instance, what could go wrong in the following code?

def spawn_lst(init, lst = []):
    lst.append(init)
    return lst

In Python, mutable default arguments are evaluated once and shared across function calls!

This means:

x = spawn_lst(5) # == [5]
y = spawn_lst(6) # == [5, 6]

x is y # == True

However, to someone who doesn't have a strong grasp of Python, or more importantly, memory referencing and pointers, this can seem totally intangible and ridiculous.

But the bigger point is this, whilst syntactical differences for equivalent concepts have become trivial, not all languages are the same under the hood. Which leads me to my next point.

Programming concepts (+)

What exactly is the important thing about languages and design in general? Concepts and ideas.

Design philosophies and understanding certain choices become more important than every. Golang refuses to have class whilst in Java, everything must be in a class. Swift uses automatic reference counting, C uses manual memory management whilst Python uses garbage collection. In Haskell, you can only code pure functions and all side effects must be wrapped in monads (a monoid in the category of endofunctors of course).

All of these higher level ideas become increasingly important to understand and master. They affect things beyond the fascade of syntax. They effect how you code and why you code in certain patterns. Cue the time I copied generated React code and kept wondering why the state was not saved (I called useCustomHook twice 🤕).

Style Guides (-)

Whilst style guides remain generally important for both human and AI readers, it's not as critical for the human programmer/architect to be aware of the best style for a particular language. This is simply because the AI will automatically adhere to the best style for you! With the addition of tools like linters and language servers, it's increasingly easier to write code with is of perfect convention.

Project Structure (+)

This involves perhaps one of the biggest limitations of LLMs, context window. An not just the raw advertised context window, but the true, effective context window (see Nvidia's RULER). As such, breaking down large projects into components with well designed and exposed interfaces is crucial to scaling AI coding.

As such, I believe the most powerful AI coding tools in the future will intelligently manage the limited effective context window to design software component by component, with a sensible and well-designed overall architecture. The human will guide it along the way and each individual component will be reliable and self-contained.

Tips for programmers

Perhaps it is time to shift away from the keyboard. I know, this sounds like sacrilege. But perhaps the flowchart zealots were right all along.

There is of course no substitute for complete beginners typing out every character of the code just as a beginner in maths should learn to add and multiply by hand. But now we enter a new age where our new "calculator", generative AI, has dropped. Now we don't need to do the calculations by hand anymore. So what should we be doing instead?

I think pen and paper design, or something to that effect. But not just for behavioural diagrams and flow charts. Something in between code and specification. Something where implementation is shaping, but not concrete. Where structs are labelled in detail, constructors and destructors are well defined with responsibilities, inheritance hierarchies, mutations are clearly labelled...

In other words, you paint the detailed skeleton of the code, and the AI fleshes it out. The more detailed the technical the skeleton, the better.

Conclusion

Whilst typing every single character may be a thing of the past, high level understanding and concrete reasoning of design has never been more important. Having a solid grasp of key language concepts allow you to quickly get up to speed in any language regardless of the syntax with AI generated code.

Understanding, integrating and designing said code will continue, in the forseeable future, be a challenging human endeavour.

Has this really changed since the past? We should strive to be better architects, but we always should've strived to be better architects. I guess the difference is now we have more time and ability to focus on architecting when the AI is doing the typing.

Typing line by line will be like sewing, a fun pastime for the nostalgic. I'll definitely be one.

Read other articles: https://yaoke.pro/blogs