Hardware is hard and I applaud every effort to make it easier for tinkerers to build atop a platform. I've been away from it for a long time but how does the RPi system stack up in comparison? With all the hats available and the variety of cases, it shouldn't be too difficult to match the aesthetics, power consumption and exploit all the pluggable peripherals. What are the blind spots?
I started my software career maintaining and forking Unicode parsers. Arabic, Hindi, Chinese and Thai among many other complex languages. It was great fun and it helped me get a deep understanding of how complex writing was and appreciate the beauty of being able to reduce this complexity down to data structures and functions.
Absolutely cool demo. I used to love this feature in SwiftKey. It still works but after their acquisition by Microsoft they've gone downhill. I've since switched to iOS but would love to try Futo out when it's available for iOS
Easily 99 percent on most tasks. As an example, for a Python project with a dozen modules and ~50 files,a simple instruction like "Design a config file backed by Pydantic to store the project's settings. Keep the models modular" sets up nested Pydantic models, moves the settings to sensibly named JSON fields and updates the code to use Pydantic classes everywhere. Takes a few minutes maybe. Manually done the same task would take me half a few hours in the best case and a day in the worst case.
However I find their claim "I've lead teams of really competent engineers and I can leave them without supervision for months and come back and not feel like throwing away the entire code base." dubious. We all know how much effort it is to keep the quality of even small patches consistent.
Design, architecture, style and refactoring still require significant involvement. Providing only a description and a criteria will likely produce hopelessly messy code, which is also what you get with most corporate dev teams.
That's fair. In all honesty I'm already feeling challenged but given how much time I save I can set aside some time to keep myself sharp. I can learn more languages. Additionally, as pointed out by others, I'm trading coding effort for design and and strategy, which generally control business outcomes a lot more.
Having said that, I won't use AI for production system if I don't understand the programming constructs in enough detail.
I'm in the "haven't written any code in a while" boat ATM. I'd love to see examples of issues that are so big that they warrant reverting to manual coding.
My main issue has been the inconsistent quality across between model releases and the tendency to insert older APIs or documentation, especially with command line tools.
I can understand if the model struggles with a million line monolithic codebase with a decade of cruft but can't think of why it'd be too much of a pain with new codebases.
If you look at Australian IT companies they're management and consultant heavy. Roles like architects, review boards, program managers etc., exceed actual engineering roles. In such a set up it takes forever to get any real work done.
Then Australian real wages have also declined. So there is already low motivation to work beyond the minimum expectation.
Australia also has strong social security, at least until now, and there are plenty of odd jobs due to the real estate and tourism industries, so there is little pressure to survive unless you owe too much credit.
Automation and technology adoption also lags behind. For example, people still wait thirty minutes on a call to get an appointment with a doctor instead of making an online booking.
For all of these reasons productivity has been low and declining. An extra day off work is a strong stimulus for squeezing what gets done into the rest of the days.
In my opinion this is an extreme, just as the work yourself to death culture in India and China is. On a scale of a few decades economies where people worked agressively harder have grown tremendously but at the expense of the long-term wellbeing of the people. Places like Australia that were well off and felt little pressure to compete have sustained good quality of life but at the expense of having no competetitve edge anymore.
> Kiselev’s child reader is being treated as a participant in mathematics, not as a recipient of facts.
Not sure how the other makes this claim when the passage he himself cites is just another clever proof in the list of clever things that maths books throw at you:
> It is easy to convince oneself that there exist infinitely many prime numbers. Indeed, suppose the contrary, that the number of primes is finite. Then there must exist a greatest prime; let it be a. To refute this assumption, imagine the new number N formed by the rule N = (2·3·5·7···a) + 1, that is, the product of all the primes up to a, plus one… The first term is divisible by every number in the list 2, 3, 5, …, a, while the second (the unit) is not divisible by any of them. Hence there is no greatest prime, and so the sequence of primes is infinite.
I wish someone had told me how common this was back when I worked myself to death fixing every UI abnormality that no one except some misincentivized testers used to report at my first job. At the time I thought it was dishonest to say something was irreproducible and it'd be beneath me to patch an issue knowing it'll sprout ten others.
I'm proud of fixing everything properly but I won't repeat it ever unless the company actually has that high a bar across the board.
1. The time spent to think and iteratively understand what you want to build
2. The time spent to spell out how you want to build it
The cost for #2 is nearly zero now. The cost for #1 too is slashed substantially because instead of thinking in abstract terms or writing tests you can build a version of the thing and then ground your reasoning in that implementation and iterate until you attain the right functionality.
However, once that thing is complex enough you still need to burn time on identifying the boundaries of the various components and their interplay. There is no gain from building "a browser" and then iterating on the whole thing until it becomes "the browser". You'll be up against combinatorial complexity. You can perhaps deal with that complexity if you have a way to validate every tiny detail, which some are doing very well in porting software for example.
1. The model's default world model and priors diverge from ours. It may assume that you have another car at the wash and that's why you ask the question to begin with.
2. Language models do not really understand how space, time and other concepts from the real-world work
3. LLM's attention mechanism is also prone to getting tricked as in humans
Similar questions trick humans all the time. The information is incomplete (where is the car?) and the question seems mundane, so we're tempted to answer it without a second thought. On the other hand, this could be the "no real world model" chasm that some suggest agents cannot cross.
I use Obsidian to record decisions, plan every day and take detailed notes. Very handy for recalling the nitty gritty for future reference be it performance reviews, writing blogs or updating my resume.
So the root cause was the model's indisposition to calling the skills. That seems contrary to what we see with function calling. Models call functions quite reliably most of the time. This is more likely because of the instructions not being clear about what skills are, as this snippet, albeit in isolation, seems to suggest:
> Before writing code, first explore the project structure, then invoke the nextjs-doc skill for documentation.