548 karma · joined September 2, 2019
Reach me at: twitter.com/tjchear twitter.com/sheetUIOfficial linkedin.com/in/tjchear
Just my two cents. No matter whether you use AI or not, I’m sure you’ll gain something.
Humans aren’t without flaws; prior to coding assistants, I’ve lost count of the times my PM telling me to rush things at the expense of engineering rigor. We validate or falsify the need for a feature sooner and move on to other things. Sometimes it works sometimes a bug blows up in our faces, but things still chug along.
This point will become increasingly moot as AI gets better at generating good code, and faster, too.
One can continue to perfect and exercise their craft the old school way, and that’s totally fine, but don’t count on that to put food on the table. Some genius probably can, but I certainly am not one.
There’s a time in my life where I designed languages and wrote compilers. One type of language I’ve always thought about that could be made more approachable to non technical users is an outline-liked language with English like syntaxes and being a DSL, the shape of the outline would be very much fixed and on a guardrail, and can’t express arbitrary instructions like normal programming languages, but an escape hatch (to more expressive language) for advanced users can be provided. An area where this DSL can be used would be common portal admin app generation and workflow automation.
That said, with the advent of AI assistants, I’m not sure if there is still room for my DSL idea.
Secondly, bloated comes in so many forms and they all have different reasons. Did you mean bloated as in huge dependency installs like those node modules? Or did you mean an electron app where a browser is bundled? Or perhaps you mean the insane number of FactoryFactoryFactoryBuilder classes that Java programmers have to bear with because of misguided overarchitecting? The 7 layer of network protocols - is that bloating?
These are human decisions - trade-offs between delivering values fast and performance. Foundational layers are usually built with care, and the right abstractions help with correctness and performance. At the app layers, requirements change more quickly and people are more accepting of performance hits, so they pick tech stacks that you would describe as bloated for faster iteration and delivery of value.
So even if I used abstraction as an analogy, I don’t think that automatically implies AI assisted coding will lead to more bloat. If anything it can help guide people to proper engineering principles and fit the code to the task at hand instead of overarchitecting. It’s still early days and we need to learn to work well with it so it can give us what we want.
That said, as long as there’s the potential for AI to hallucinate, we’ll always need to be vigilant - for that reason I would want to keep my programming skills sharp.
AI assisted software building by day, artisanal coder by night perhaps.
According to the article, as long as the tech workers contribute to improving or creating a product (be it games or apps), they count as R&D cost.
I built this because I thought it'd be neat to have some of that vim-like agility when editing a webpage.
It's got some learning curve for obvious reasons, but if you're up for a challenge here's a quickstart doc: https://vivpage.vercel.app/doc/quickstart
I'm optimistic we'll pull through.
My observation on what I did right is similar: remove the need for sign ups so users can use it and see value immediately.
As for what happened after that, I've had one well known online Japanese tech zine (gigazine) did a write up, stackshare ranked it as top 5 upcoming tools, various back links from other websites that mine for interesting bits from HN, several VC reachouts, saw lots of interesting uses of my tool, and some recurring revenue.
[0] https://sheetui.com [1] https://cs.cards
The AI Systems of Left 4 Dead - Akamaihd.net https://steamcdn-a.akamaihd.net/apps/valve/2009/ai_systems_o...