software-engineering on S Anand

AI in SDLC at PyConf

Thu, 19 Mar 2026 14:58:26 +0530

I was at a panel on AI in SDLC at PyConf. Here’s the summary of my advice:

Process

Make AI your entire SDLC loop. Record client calls, feed them to a coding agent to directly build & deploy the solution.
Record your prompts, run post-mortems, and distill them into SKILLS.md files for reuse.

Prompting

Ask AI to make output more reviewable. Don’t waste time reviewing unclear output.
Prefer directional feedback (feeling, emotion, intent) over implementational.
Also give AI freedom to do things its way. Learn from that - you’ll be surprised.

Learning

Prefer interns / outsiders over experts. They don’t slow the process with preconceptions and leverage AI better.
Stop learning what AI does well. Learn what AI fails at - using AI. Keep re-assessing these.

Adoption

Developer using AI are still accountable for their code. (Agents might become accountable in the future.)
Start with new projects: less competition, fewer preconceptions, lower risk.
Start in domains where failure is OK, rather than making AI safe enough for high-risk domains.
Create safe spaces where hallucinations don’t matter and run experiments there to learn what AI can do.
Plan for where AI’ll be a year later. It’s growing very rapidly.

The full details of the panel discussion are at Who Owns the Commit?

If a bot passes your exam, what are you teaching?

Sun, 09 Nov 2025 15:53:58 +0000

It’s incredible how far coding agents have come. They can now solve complete exams. That changes what we should measure.

My Tools in Data Science course has a Remote Online Exam. It was so difficult that, in 2023, it sparked threads titled “What is the purpose of an impossible ROE?”

Today, despite making the test harder, students solve it easily with Claude, ChatGPT, etc. Here’s today’s score distribution:

I solved one question with Codex CLI. I ran I chrome --remote-debugging-port=9222 and prompted Codex to:

Use CDP to visit https://exam.sanand.workers.dev/tds-2025-09-roe and solve Q4. Click on the “Check” button to verify the solution.

That was it. ~6 minutes and ~50 cents later, it solved the problem.

This works reliably. It worked 3/3 times.

This runs in parallel. I can answer different questions in different Codex sessions.

This is already in use. Several students got 10/10 in 15 minutes - on a 45 minute exam.

So I need better evaluations. Instead of “Can you(r agent) solve this?”, I should check if they can:

Turn a messy brief into an agent-friendly spec + plan
Set up and connect the right tools
Solve within a time and cost budget
Test & debug without a human
Recover from errors
Adapt to new situations

Also, code is the by-product (of AI coding or copying). Learning lives in the execution logs. That’s what I should evaluate.

Point I’m pondering: If a bot can pass my exam, what exactly am I teaching?

Mon, 08 Apr 2019 10:16:58 +0000

If you’re a seasoned developer that enjoys working with data, have good front-end skills, and are challenged by impossible deadlines, please drop me a note. I’d love to work with you at Gramener Mumbai.

Facts and Fallacies in Software Engineering

Tue, 22 Aug 2006 12:00:00 +0000

Facts in Software Engineering

People

The most important factor in software work is the quality of the programmers.
The best programmers are up to 28 times better than the worst programmers.
Adding people to a late project makes it later.
The working environment has a profound impact on productivity and quality.

Tools and Techniques

Hype (about tools and techniques) is the plague on the house of software.
New tools/techniques cause an initial loss of productivity/quality.
Software developers talk a lot about tools, but seldom use them.

Estimation

One of the two most common causes of runaway projects is poor estimation.
Software estimation usually occurs at the wrong time.
Software estimation is usually done by the wrong people.
Software estimates are rarely corrected as the project proceeds.
It is not surprising that software estimates are bad. But we live and die by them anyway!
There is a disconnect between software management and their programmers.
The answer to a feasibility study is almost always “yes”.

Reuse

Reuse-in-the-small is a well-solved problem.
Reuse-in-the-large remains a mostly unsolved problem.
Reuse-in-the-large works best for families of related systems.
Reusable components are three times as hard to build, and should be tried out in three settings.
Modification of reused code is particularly error-prone.
Design pattern reuse is one solution to the problems of code reuse.

Complexity

For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity.
Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical.

Requirements

One of the two most common causes of runaway projects is unstable requirements.
Requirements errors are the most expensive to fix during production.
Missing requirements are the hardest requirements errors to correct.

Design

Explicit requirements “explode” as implicit (design) requirements for a solution evolve.
There is seldom one best design solution to a software problem.
Design is a complex, iterative process. Initial design solutions are usually wrong, and certainly not optimal.

Coding

Designer “primitives” (solutions they can readily code) rarely match programmer “primitives”.
COBOL is a very bad language, but all the others (for business applications) are so much worse.

Error-removal

Error-removal is the most time-consuming phase of the life cycle.

Testing

Software is usually tested at best at the 55-60 percent (branch) coverage level.
100 percent coverage is still far from enough.
Test tools are essential, but many are rarely used.
Test automation rarely is. Most testing activities cannot be automated.
Programmer-created, built-in, debug code is an important supplement to testing tools.

Reviews/Inspections

Rigorous inspections can remove up to 90 percent of errors before the first test case is run.
But rigorous inspections should not replace testing.
Post-delivery reviews (some call them “retrospectives”) are important, and seldom performed.
Reviews are both technical and sociological, and both factors must be accommodated.

Maintenance

Maintenance typically consumes 40-80 percent of software costs. It is probably the most important life cycle phase of software.
Enhancements represent roughly 60 percent of maintenance costs.
Maintenance is a solution, not a problem.
Understanding the existing product is the most difficult task of maintenance.
Better methods lead to MORE maintenance, not less.

Quality

Quality IS: a collection of attributes.
Quality is NOT: user satisfaction, meeting requirements, achieving cost/schedule, or reliability.

Reliability

There are errors that most programmers tend to make.
Errors tend to cluster.
There is no single best approach to software error removal.
Residual errors will always persist. The goal should be to minimize or eliminate severe errors.

Efficiency

Efficiency stems more from good design than good coding.
High-order-language code can be about 90 percent as efficient as comparable assembler code.
There are tradeoffs between size and time optimization.

About Research

Many researchers advocate rather than investigate.

Fallacies in Software Engineering

About Management

Fallacy: You can’t manage what you can’t measure.
Fallacy: You can manage quality into a software product.

People

Fallacy: Programming can and should be egoless.

Tools and Techniques

Fallacy: Tools and techniques: one size fits all.
Fallacy: Software needs more methodologies.

Estimation

Fallacy: To estimate cost and schedule, first estimate lines of code.

Testing

Fallacy: Random test input is a good way to optimize testing.

Reviews

Fallacy: “Given enough eyeballs, all bugs are shallow”.

Maintenance

Fallacy: The way to predict future maintenance cost and to make product replacement decisions is to look at past cost data.

About Education

Fallacy: You teach people how to program by showing them how to write programs.

These are from Robert Glass’ book Facts and Fallacies in Software Engineering.

Classic texts in computer science

Wed, 21 Jun 2006 12:00:00 +0000

Classic texts in computer science. Worth reading for the sheer insight.

Update: The link didn’t seem to work in Feb 2007. Here’s the list.

An axiomatic basis for computer programming by C. A. R. Hoare
Communicating Sequential Processes (CSP) by C. A. R. Hoare
Call-by-name, call-by-value, and the lambda calculus by Gordon Plotkin
Towards a theory of type structure by John C. Reynolds
Definitional interpreters for higher-order programming languages by John C. Reynolds
An APL Machine 1970 by Philip S. Abrams
Henry Baker’s Archive of Research Papers (many classic Lisp papers)
The Anatomy of a Large-Scale Hypertextual Web Search Engin by Sergey Brin and Lawrence Page
No Silver Bullet: Essence and Accidents of Software Engineering by Frederic P. Brooks, Jr.
A Mathematical Theory of Communication by Claude Shannon
Communication Theory of Secrecy Systems by Claude Shannon
Bayesian Networks without Tears by Eugene Charniak
A Universal Algorithm for Sequential Data Compression by Jacob Ziv and Abraham Lempel
A Relational Model of Data for Large Shared Data Banks 1970 by Edgar F. Codd
Let’s Build a Compiler 1988-1995 by Jack Crenshaw
Gauging Similarity via N-Grams: Language-Independent Sorting, Categorization, and Retrieval of Text by Marc Damashek
Worse Is Better by Richard P. Gabriel
Hints on Programming Language Design by C.A.R. Hoare
Why Functional Programming Matters by John Hughes
The Design of APL by Kenneth E. Iverson
The Early History Of Smalltalk by Alan Kay
Computer Programming as an Art by Donald E. Knuth
The next 700 programming languages by Peter J. Landin
Recursive Functions of Symbolic Expressions and their Computation by Machine (Part I) 1960 by John McCarthy
FORTH - A Language for Interactive Computing by Charles H.Moore
Teach Yourself Programming in Ten Years 2001 by Peter Norvig
Parenthetically Speaking, a collection of essays from the 1990s by Kent M. Pitman
The Definition and Implementation of a Computer Language based on constraints by Guy Lewis Steele Jr.
Growing a Language by Guy Lewis Steele Jr.
Epigrams on Programming by Alan J. Perlis
The Complexity of Theorem Proving Procedures by Stephen A. Cook
Steps Toward Artificial Intelligence by Marvin Minsky
The Original ‘Lambda Papers’ by Guy Steele and Gerald Sussman
A Method for Obtaining Digital Signatures and Public-Key Cryptosystems by R.L. Rivest, A. Shamir, and L. Adleman
The UNIX Time-Sharing System by Dennis Ritchie and Ken Thompson

Comments

jawahar 6 Feb 2007 5:52 am: anand this link is not working !!
Classic-texts-in-computer-science – maxviv 5 Jun 2016 7:15 pm (pingback): […] Classic texts in computer science […]

Why we all sell code with bugs

Fri, 26 May 2006 12:00:00 +0000

Why we all sell code with bugs.

All the reasons are tied up in one truth: every time you fix a bug, you risk introducing another. Don’t we all start out with the belief that software only gets better as we work on it? Nobody on our team intentionally creates new bugs. Yet we have done accidentally.

Metafor

Tue, 29 Mar 2005 12:00:00 +0000

Metafor is a tool that turns English into code. Check out the movie demo and Hugo’s Metafor website.

Tips on writing better software

Mon, 11 Oct 2004 12:00:00 +0000

Alan Cox: Tips on writing better software.

Outsource your own job

Sat, 21 Aug 2004 12:00:00 +0000

Outsource your own job. A programmer outsourced his job to an Indian programmer. Salary arbitrage: $67,000 - $12,000 = $55,000. He’s planning to get another job and do this again. (It’s probably not true, though)

Great Hackers

Thu, 29 Jul 2004 12:00:00 +0000

Excellent article by Paul Graham on great hackers.

Blogger at Google

Sun, 09 Feb 2003 12:00:00 +0000

A blogger’s first week at Google. Ovidiu Predescu. via GoogleBlog

Famous software glitches

Thu, 12 Sep 2002 12:00:00 +0000

Speaking of bugs, here are some famous software glitches – right from the Patriot missiles misfiring to the London Millenium bridge wobbling. Some links are broken, though. (More glitches and links)

Music helps identify software bugs

Thu, 12 Sep 2002 12:00:00 +0000

Music helps identify software bugs. I’m sure it can be extended to many other forms of ordered data. DNA sequences, time series, etc.

Joel on Software

Thu, 09 Aug 2001 12:00:00 +0000

Joel writes on software. “Good software takes 10 years” is a good read.

The Cathedral and the Bazaar

Sun, 11 Feb 2001 12:00:00 +0000

Eric has updated The Cathedral & the Bazaar

Software horror stories

Thu, 18 Jan 2001 12:00:00 +0000

Software can kill. Literally. Read software horror stories.

Microsoft interview question

Mon, 15 Jan 2001 12:00:00 +0000

“Write a one-line C expression to determine if a number is a power of 2”. Microsoft is famous for asking such questions to their programmers. Or you might want to find out what the assembly code

CWD
XOR AX, DX
SUB AX, DX

does. Satish’s site has the answer, but not the question. More questions: 1 2