In the realm of contract work, invoicing often feels like a tedious chore that consumes valuable time and mental energy. As a seasoned professional who’s navigated these waters for years, I decided it was time to revolutionize my approach. The result? A serverless invoice management system that transformed a hours-long ordeal into a 5-minute task.…

This is an interesting paper I read last month. The notes on this paper gave me an idea of having linkblogs…

Original Paper link

Some quotes

Under 4: Parting comments

ORMs are a vital tool for rapid prototyping. But they often sacrifice the ability to push logic into the DBMS in exchange for interoperability with multiple DBMSs. Developers fall back to writing explicit database queries to override the poor auto-generated queries. This is why using a RDBMS that supports SQL is the better choice.

Echoing my post on ORMs epmhasis mine

The portion below, under the sections of blockchain is where things get personal…

Shots Fired for blockchains Ofcourse emphasis mine

We are required to place trust in several entities in today’s society. When one sells a house, they trust the title company to manage the transaction. The only applications without real-world trust are dark web interactions (e.g., money laundering). Legitimate businesses are unwilling to pay the performance price (about five orders of magnitude) to use a blockchain DBMS. If organizations trust each other, they can run a shared distributed DBMS more efficiently without wasting time with blockchains. To the best of our knowledge, all the major cryptocurrency exchanges run their businesses off traditional RDBMSs and not blockchain systems.

Blockchain proponents make additional meaningless claims of achieving data resiliency through replication in a peer-to-peer environment. No sensible company would rely on random participants on the Internet as the backup solution for mission-critical databases.

Essentially, Blockchain is a solution looking for a problem. And more ofthen than not, there are always better solutions then what Blockchain offers.

On ability to have a better onboarding DX.

One of the salient selling points of many non-relational DBMSs is a better “out-of-box” experience than RDBMSs. Most SQL systems require one first to create a database and then define their tables before they can load data. This is why data scientists use Python notebooks to analyze data files quickly. Every DBMS should, therefore, make it easy to perform in situ processing of local and cloudstorage files. DuckDB’s rising popularity is partly due to its ability to do this well. (My Note: Didn’t think about this till now…)

Youtube Video, via JS Party podcast episode Building LLM agents in JS

Notes

Non Agentic workflow: Do it start to finish. Mostly zero shot prompts.

Agentic workflow: Revise, iterative, reflect, use tools if you need to….

Four design patterns.

1. Reflect: Produce one thing and ask another chat thread with different system prompt to evaluate it. E.g. Create a code, than ask a rubberduck debugger to read it line by line, or run the test suite and provide the result to LLM generated the code to evaluate it. Or write a post, and ask an editor LLM to reflect it, and ask writer LLM to update the post on feedback.

2. Tool Use: Use tools and function calls, there are lot of that, even we have developed one for SourceSailor.

3. Planning: Like give a task to LLM and then ask it to plan the solution step by step, and then ask LLM to execute the plan. Take the task description, create a plan, break a plan to subtasks, and then use aider to execute the plan.

4. Multiagent Collaboration: Create multiple LLMs for one single task, and create an orchestrator LLM to collaborate between them. Like one LLM (Powred by sonnet) for figuring out style, another LLM (Opus) for generating the writing, another LLM (Opus or Gemini or GPT) to do the reflection and a haiku or 4o powered LLM which orchestrates between them.

After more than a year, the blog is getting an update. This is a short summary of what is getting changed…

(via)

It’s not their fault. They enrolled in a master’s program to get a job in tech. Why? Let’s be candid: tech has promised job security and agreeable (sometimes borderline perverse) financial returns for a couple of decades. Many tech employers also spin a yarn about “saving the world” and coast on the reputational allure of “if you work here, you’re a genius.” Sounds great, doesn’t it? Except, now that students have invested five figures of money in their tech education1, had their skulls crammed full of ‘invisible hand of the market’ propaganda, and counted on having secured their ticket to the party, they’re seeing layoffs. They’re seeing exposés. They’re seeing compensation adjustments at the most lucrative tech companies. And they’re seeing a news cycle that oscillates wildly between blaming AI for these changes and extolling it as the solution.

you learn to write Dijkstra’s from a blank editor so you can get the job at Twitter, but once you accept the offer you never actually do that. What you need to do is understand, update, and (optimistically) un***k existing systems written by other people.

Obligatory…

Are large language models gonna cause programmers to lose their jobs? Not anymore than StackOverflow did, in my view. However, it’s going to change them…somewhat.